[06:46] ping [07:29] TheMue: feel like doing some testing ? [07:29] davecheney: Morning. [07:29] davecheney: For sure. [07:31] TheMue: sudo add-apt-repository ppa:gophers/go [07:31] morning :) [07:31] sudo apt-get install juju-core [07:31] hello! [07:32] dimitern: Good morning. [07:33] davecheney: Does it conflict with my environment? Last time of done a test like that it harmed my .ssl [07:33] what is a .ssl ? [07:36] themue what is a .ssl ? [07:37] davecheney: I meant the directory ~/.ssl (or has it been ~/.ssh). A test for roger removed all rights. ;) [07:37] no, it will not affect .ssh [07:38] davecheney: No, that has been the test for Roger. My question has been: How does those installations effect my environment? If it could lead to a conflict I would work with a copy of my VM. [07:39] install a package from a ppa will not harm your machine [07:39] it has not harmed mine [07:39] if you are concerned, please do not participate [07:41] davecheney: No, only wanted to get sure. Not that the ppa go conflicts with the manually installed go. [07:42] TheMue: yes, thta is correct, do not install the golang-{tip,stable,weekly} package from that ppa [07:44] davecheney: So what exactly shall I install now? [07:44] sudo add-apt-repository ppa:gophers/go [07:44] sudo apt-get install juju-core [07:44] davecheney: OK, one moment. [07:45] add an sudo apt-get update in the middle [07:45] davecheney: Good, will do, the ppa is through. [07:46] davecheney, TheMue: morning! [07:46] morning rog [07:46] rogpeppe: Morning. [07:46] fun and games [07:46] who is still running precise ? [07:47] davecheney: if you had a moment to have a look at some of my outstanding reviews, that would be marvellous... [07:47] davecheney: i am [07:47] davecheney: I do. [07:47] fancy test 1.9.2 before I send out the release notification [07:47] davecheney: i'll try the apt-get install [07:47] davecheney: should i uninstall first? [07:47] rogpeppe: nope [07:48] https://docs.google.com/a/canonical.com/document/d/1siI1MeZmUP_NenX2Glhex1RODLChoU3ImzNfnVsg1Y8 [07:48] davecheney: So, install is through, installed juju-core_1.9.2-1~721~precise1_amd64.deb ok. [07:48] davecheney: that comes up as an untitled document for me [07:49] davecheney: with nothing in [07:49] davecheney: Regarding the document like for rogpeppe here. [07:49] rogpeppe: https://docs.google.com/a/canonical.com/document/d/1siI1MeZmUP_NenX2Glhex1RODLChoU3ImzNfnVsg1Y8/edit [07:49] davecheney: do i need to apt-get update? (i already have already done apt-get install juju-core in the past) [07:49] dpkg -l juju-core [07:49] if it says 1.9.2-1 [07:49] you're good [07:50] which juju [07:50] if that says /usr/bin/juju [07:50] you're good [07:50] davecheney: i tell a lie. it was just known to apt-cache, that's all. [07:51] davecheney: /usr/bin/juju and 1.9.2-1~721~precise1 here [07:51] davecheney: as expected: http://paste.ubuntu.com/1362048/ [07:52] TheMue: then follow the instructions in the document with respect to your environments.yaml and try to bootstrap [07:52] davecheney: i guess i should uninstall pyjuju [07:52] rogpeppe: i'm surprised both could be installed at once [07:53] davecheney: they couldn't [07:53] davecheney: it failed doing the first install (and i have not done apt-get install juju-core in the past!) [07:55] davecheney: after doing apt-get remove juju, it installed just fine [07:56] two secs, changing machines [08:03] how's it going ? [08:04] davecheney: how's what going? [08:05] anyone tried 1.9.2 ? [08:05] davecheney: Hmm, I'm funnily missing my .juju directory. Dunno why yet. [08:06] TheMue: when was the last time you deployed juju ? [08:06] davecheney: i think we should default the public-bucket setting to something useful [08:06] rogpeppe: already fixing it [08:06] davecheney: Before I made some changes here on my system to work with lxc. [08:07] davecheney: But isn't juju bootsrap intended to create an initial one? [08:07] TheMue: not our version [08:07] did the python version make one if missing ? [08:07] davecheney: nope [08:07] davecheney: Yes, because it complains. [08:08] TheMue: please raise that as a bug, i don't think anyone has that on their radar [08:08] davecheney: I'll create one by hand. My latest tests have been for William, before Copenhagen. Grmlblx! [08:08] https://codereview.appspot.com/6851057 [08:08] davecheney: Yep, will do. [08:10] davecheney: jujud version reports 1.9.1 BTW. should it be 1.9.2 ? [08:10] davecheney: it's bootstrapped fine, for the record [08:10] rogpeppe: what tools did it download, from cloud-init-output [08:11] davecheney: 1.9.2 [08:11] davecheney: (from the status output) [08:11] strange, you sohld have a jujud on your system [08:11] what are the md5 sums [08:11] % md5sum /usr/bin/juju* [08:11] cec0c4334013c5141e6853335074df49 /usr/bin/juju [08:11] d12c6225e72bd840f83d583f403f1842 /usr/bin/jujuc [08:11] 72aad860f374b312dd054b3a548489ed /usr/bin/jujud [08:12] aaahhh [08:12] modification time on those files is november 1st [08:12] which might indicate that the apt-get install didn't. [08:12] should be today [08:12] dpkg -l juju-core [08:13] no, ctime is this morning [08:13] it's just apt-get setting mtime inappropriately [08:13] (i wish things wouldn't do that - mtime is useful info) [08:14] davecheney: ii juju-core 1.9.1-0~708~pr Juju is devops distilled [08:14] y'all got the wrong version mate [08:15] davecheney: i did apt-get update, and the version is still the same [08:15] Hmm, my problem seems to go deeper. Thankfully I've got a snapshot of an older vm. I'll look for my juju environment there. [08:15] davecheney: (dpkg -l lists the same version, at any rate) [08:16] TheMue: what errors do you get? [08:16] TheMue: (this is useful stuff, to find out what problems people are likely to run into) [08:16] rogpeppe: First my ~/.juju has been missing, now I get a "error: cannot query old bootstrap state: Access Denied". [08:17] TheMue: sounds like your amazon keys are wrong [08:17] TheMue: that means you don't own your control bucket [08:17] either your keys are wrong [08:17] or you down't own it [08:17] TheMue: yeah, try renaming your control bucket [08:17] TheMue: where did you get the name of the control bucket from? [08:17] One moment. [08:19] i wonder if we should derive the name of the control bucket from the AWS_ACCESS_KEY_ID and the environment name, and delete it from the environments.yaml config [08:19] TheMue: did you set control-bucket: juju-dist by mistake ? [08:19] i remember running into this issue [08:19] TheMue: perhaps you could paste what you've currently got in your environments.yaml [08:19] rogpeppe: -1, that would mean someone else who had different amazon credentials could not drive a shared environment [08:20] davecheney: they couldn't anyway - they couldn't access the bucket [08:20] rogpeppe: hmm [08:20] that is a point [08:20] davecheney: anyway, i think the idea is to delete the control bucket and use instance tags, which amounts to much the same thing. [08:21] in that case +1 [08:21] raise an issue [08:21] davecheney: so it'll go away of its own accord [08:21] davecheney: oh.... except for upload-tools [08:22] * davecheney waves fist at upload tools [08:23] davecheney: for upload-tools (which only developers need), we could have another attribute [08:23] davecheney: it's not really a control bucket in that case anyway [08:25] rogpeppe: yup, i don't think we need to advertise our developer hooks [08:26] davecheney: i think we should document them like we document everything [08:26] davecheney: but most people should not need 'em [08:27] so, anyone bootstrapped yet ? [08:32] * davecheney afk for 20 mins, dinner is on the table [08:32] davecheney: yeah sure, but you said i'd got the wrong version [08:34] apt-get update && apt-cache search juju-core [08:35] davecheney: that doesn't tell me the juju-core version [08:35] davecheney: dpkg -l says it's still 1.9.1 [08:39] rogpeppe: It seem to be my values for control-bucket and admin-secret, found them in an old saved env. How can I obtain the get my ones? I alredy checked my amazon keys, they are correctly set in the environment (not yaml). [08:39] TheMue: they can be anything [08:39] TheMue: but the control-bucket must be unique [08:39] TheMue: on s3 [08:40] TheMue: just type some random alphanumeric characters for the control bucket name [08:41] rogpeppe: OK, will take a uuid [08:45] rogpeppe: not sure what is wrong with your machine [08:45] http://ppa.launchpad.net/gophers/go/ubuntu/dists/precise/main/binary-amd64/Packages [08:45] rogpeppe: Ah, this time it looks better. No error. [08:45] the ppa is up to date [08:46] TheMue: what does this print for you? /usr/bin/jujud version [08:46] rogpeppe: A fine "1.9.2-precise-amd64". :) [08:47] davecheney: So, after bootstrapping, what shall I test next for you? [08:47] TheMue: juju ssh -- 'uname -a' [08:48] sorry juju ssh 0 -- 'uname -a' [08:48] * TheMue still wonders at which point his ~/.juju has gone. [08:48] shuld be the precise kernel [08:48] default-series is sitll busted [08:48] davecheney: i've no idea what's wrong with my machine either. i've steered clear of all dpkg internals before now. [08:48] sudo apt-get remove juju-core [08:48] apt-get update [08:48] try readding the ppa [08:48] TheMue: you need plan 9's dump filesystem :-) [08:48] check in /etc/apd/source.apt.d/ [08:49] rogpeppe: Gna, he again. :D [08:49] rogpeppe: On OS X I've got my tome machine. [08:49] davecheney: do you mean /etc/apt/sources.list.d ? [08:50] davecheney: in there i see a file gophers-go-precise.list, containing this: [08:50] deb http://ppa.launchpad.net/gophers/go/ubuntu precise main [08:50] deb-src http://ppa.launchpad.net/gophers/go/ubuntu precise main [08:50] davecheney: It returns "Linux domU-12-31-39-0E-C5-E1 3.2.0-32-virtual #51-Ubuntu SMP Wed Sep 26 21:53:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux" [08:50] which looks plausible to me [08:51] deb http://ppa.launchpad.net/gophers/go/ubuntu precise main [08:51] deb-src http://ppa.launchpad.net/gophers/go/ubuntu precise main [08:51] 3.2.0, that is precise [08:51] TheMue: try destroying that environemnt [08:51] adding "default-series: quantal" and bootstrapping again [08:52] my suspicion is that you will get precise again [08:52] davecheney: ok [08:53] davecheney: i used curl to fetch the ppa.launchpad.net/gophers/.../Packages url and it gives me juju core with version 1.9.2 as expected [08:53] yeah, i should have suggested that [08:53] davecheney: it doesn't mean i've actually got 1.9.2 installed now [08:53] you can find the link here https://code.launchpad.net/~dave-cheney/+recipe/juju-core [08:54] davecheney: i wonder if it's a caching issue [08:55] apt-get update | grep ppa [08:55] annoyingly it only syas the host [08:55] not the sub repo [08:55] if you see Ign [08:55] then it could be a cachcing issue [08:55] you can remove the cache [08:55] but that would be getting a bit too serious [08:55] as long as you have the deb installed, that'll do [08:55] davecheney: http://paste.ubuntu.com/1362136/ [08:56] davecheney: hmm, should it mention gophers there? [08:56] rogpeppe: mine doesn't :( [08:56] which is shitful [08:57] davecheney: well, when i just did add-apt-repository, it seemed to do something, so maybe that was the problem [08:58] davecheney: Hmm, this time ssh after bootstrap needs a bit longer. [08:58] davecheney: but apt-get update still leave me on 1.9.1 [08:58] have to catch a plane guys [08:58] see you later [08:59] davecheney: Ah, now: "Linux ip-10-244-154-239 3.2.0-32-virtual #51-Ubuntu SMP Wed Sep 26 21:53:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux" You're right. [09:00] * rogpeppe has no idea what the relationship between apt and dpkg is [09:06] rogpeppe: dpkg is debian package == deb [09:06] which handles package [09:06] apt is the bit that gets packages onto and off your system [09:06] TheMue: as i thought, that is still precise [09:06] davecheney: i'm not sure i understand the distinction there [09:07] davecheney: apt is just a glorified url fetcher? [09:07] davecheney: So not what you wanted. [09:07] davecheney: except it must wrap dpkg to do the work, i guess [09:08] TheMue: nope, really annoyting #1074064 [09:08] rogpeppe: yes, apt calls dpkg [09:08] rogpeppe: in true python style, apt will cook you dinner if you treat it right [09:08] rogpeppe: dpkg is to tar, what apt is to wget [09:09] rogpeppe: and if you find using apt too cumbersome [09:09] davecheney: ok, i see [09:09] ther eis always aptitude, or synaptic [09:09] davecheney: the only problem i have with apt is that it prints too much crap [09:12] rogpeppe: lets do some reviews [09:12] https://codereview.appspot.com/6851057/ [09:13] davecheney: i'll swap ya: https://codereview.appspot.com/6843059/ [09:13] done! [09:13] davecheney: (by no means a fair swap though!) [09:14] ... 800 lines [09:18] davecheney: most of that is tests [09:19] davecheney: the core code is actually not too big (and would be a lot smaller if it wasn't for the infernal complexity of x509) [09:21] davecheney: thinking about it, i'm not sure that config is the right place to default the public bucket [09:22] davecheney: oops [09:22] davecheney: scratch that! [09:22] davecheney: i thought i was looking at environs/config [09:22] davecheney: LGTM [11:00] Hello all! [11:00] niemeyer: yo! [11:03] niemeyer: i've been wondering about the best place to pass the root CA certificate around. [11:04] niemeyer: my current thinking is that it can be a new field in state.Info [11:04] niemeyer: does that seem reasonable to you? [11:05] rogpeppe: Yeah, seems right [11:05] niemeyer: cool [11:05] niemeyer: the only slight wrinkle is that Environ.StateInfo can't currently return it (and even if it did, you wouldn't want to trust it) [11:06] niemeyer: but i think that's just something we document [11:07] rogpeppe: Hmm.. yeah [11:07] rogpeppe: We can fix it easily, I guess, if we find a better way [11:07] rogpeppe: But feels like a good way in principle [11:07] niemeyer: great [11:09] niemeyer: i derailed yesterday and added a new RootCertPEM argument to StartInstance, then realised this morning that it's unnecessary. but Bootstrap still needs another argument (unless we want to deduce the root cert from the state server cert, which i'm reluctant to do) [11:10] rogpeppe: Bootstrap the function or Bootstrap the method? [11:10] niemeyer: Bootstrap the method [11:10] rogpeppe: Why do we need the root cert there? [11:11] niemeyer: because the newly bootstrapped instance needs to know the root CA cert [11:11] niemeyer: so that it can pass it to new instances [11:11] rogpeppe: Hmm.. why? [11:11] niemeyer: so that the new instances can verify they're talking to the right server [11:12] rogpeppe: Shouldn't they use the server cert for that? [11:12] niemeyer: TLS authentication works by verifying against root CAs, no? [11:13] rogpeppe: How can the client tell if a signature for which I'm providing a cert is a root cert or not? [11:14] niemeyer: it can tell that the cert provided by the server is signed by the same root cert it was given at bootstrap time [11:14] niemeyer: which is all we need... i think [11:15] rogpeppe: That works too, for sure.. it'd be easy to make the server cert itself work as well [11:15] rogpeppe: Maybe we don't want that, though.. [11:15] niemeyer: how would that work? i went off that route ages ago at your prompting [11:16] rogpeppe: I don't think there's any off route done so far [11:16] niemeyer: we can verify the server cert name, which could be useful [11:16] rogpeppe: What you've implemented is not my wishes.. it's barebones TLS [11:16] niemeyer: i'm talking about my original thoughts about certificate distribution, which verified against the certificates directly, not against a root CA. [11:17] rogpeppe: That's what I'm talking about too.. I'm not suggesting changing anything that is in place right now [11:17] niemeyer: i'm not quite sure what you mean by "make the server cert itself work as well" [11:17] rogpeppe: Okay, nevermind [11:18] niemeyer: by passing around the root CA cert, we make it possible to upgrade server certs in the future [11:18] rogpeppe: So you want to send the root cert to every client [11:18] niemeyer: yeah [11:18] rogpeppe: That starts to feel more like an environment setting [11:19] niemeyer: the client needs to know it before it connects to the state, so it's not that useful as part of the environment settings [11:19] niemeyer: but i can certainly see it as an environment setting in the future [11:19] niemeyer: so that we can update the root certificate [11:20] rogpeppe: Indeed [11:24] rogpeppe: So, should we do that now instead of waiting and fixing? [11:24] niemeyer: i don't think there's any particular need - it will really be adding rather than fixing, i think [11:25] niemeyer: i think we'll still need the mechanisms i'm putting in place [11:25] rogpeppe: Cool [12:34] niemeyer: it would be great to get some feedback on https://codereview.appspot.com/6843059/ if you have some time today, BTW [12:35] rogpeppe: Will run through the whole queue today still [12:35] niemeyer: yeah, but i know this'll be near the bottom 'cos it's big :-( [12:36] rogpeppe: You'll have some feedback before the end of your day still [12:36] niemeyer: cool, that would be lovely [12:37] niemeyer: it's a pity it turned out so big - conceptually it's only about 6 operations [12:37] rogpeppe: I know.. it's just dense [12:38] niemeyer: yes. there are a lot of little decisions went into some parts of it. [12:54] lunchtime, bbl [13:00] TheMue: Enjoy [13:16] And back again. [13:16] niemeyer: Thx. [13:16] TheMue: Wow :) [13:17] TheMue: That's fast [13:17] niemeyer: Yeah, want to step out earlier today. ;) [13:20] Now I have to think about a good unit testing for lxc. [13:39] niemeyer: ping [13:39] rogpeppe: hi [13:39] niemeyer: just wanted to check something for reasonableness [13:39] rogpeppe: Sure thing [13:39] niemeyer: the juju command now reads from the user's home directory (to get the root CA certificate) [13:40] niemeyer: and i'm slightly reluctant to add fake home directory wrapping to every single test in cmd/juju [13:40] niemeyer: and there is an easy workaround, but i'm not sure you'll like it, hence my asking [13:41] niemeyer: i'm making juju.NewConn take a root certificate argument (same as juju.Bootstrap - if it's nil, it's read from $HOME/.juju) [13:41] niemeyer: all the calls in cmd/juju call juju.NewConn(env, nil) [13:42] rogpeppe: Sounds reasonable [13:42] niemeyer: the workaround is to make them call juju.NewConn(env, defaultRootCertPEM), where defaultRootCertPEM is a variable that's always nil except when testing [13:42] rogpeppe: Well, I can foresee cases where we'll want to define it in code too [13:43] niemeyer: i'm not sure what you mean [13:43] rogpeppe: But it's not really important right now [13:43] rogpeppe: "always nil" [13:44] niemeyer: another possibility is to add a flag that specifies the filename or the root certificate itself. [13:44] rogpeppe: "or the root" or "of the root"? [13:44] niemeyer: both :-) [13:44] rogpeppe: So I don't understand what this means [13:45] niemeyer: the filename of the root certificate, or the root certificate itself (as a literal string) [13:45] rogpeppe: You're suggesting we overload a single argument to mean both a filename and the data for the cert? [13:46] niemeyer: no, i'm saying the flag might specify either - we'd need to decide [13:46] niemeyer: or we might have two flags [13:46] rogpeppe: Why is that different from Bootstrap? [13:47] rogpeppe: The whole thing is starting to feel a bit hackish, to be honest.. [13:47] rogpeppe: We have a mechanism to read the environment data from disk abstracted away [13:47] rogpeppe: and then we take that data, and go back to disk to look for more [13:47] * niemeyer looks at some code [13:48] niemeyer: we need to be able to save something to disk and then recover that, and that's what this is about [13:49] niemeyer: the thing that i think is most hackish is the interface in the juju package, which really shouldn't know about $HOME stuff really, probably. [13:49] rogpeppe: This looks like the wrong place to be doing this [13:49] rogpeppe: Exactly [13:49] niemeyer: i'd prefer to pass something into the juju calls that abstracts out the data saving and restoring [13:49] rogpeppe: I think we should put that in the environment configuration as you originally suggested, given that we've already said we're going to be distributing that to all machines anyway [13:50] rogpeppe: (which means it *is* an env setting, after all) [13:50] :-| [13:50] niemeyer: we still need some way of saving data and restoring it [13:50] rogpeppe: This means we could put the whole logic within the existing functions that deal with pulling the env out of disk from environs [13:50] niemeyer: the environment config only gets us some of the way [13:51] rogpeppe: If the root cert isn't found there, we generate it in place around the logic that is already managing $HOME stuff [13:51] rogpeppe: So we avoid the two-worlds situation [13:52] niemeyer: the place that's already managing $HOME stuff is environs/config [13:52] niemeyer: and i'm not convinced that should be the place that generates a certificate and key [13:52] rogpeppe: Uh.. no? [13:52] rogpeppe: Look for any logic about $HOME there [13:53] niemeyer: i'm thinking about authorized_keys [13:53] rogpeppe: Ah, okay [13:53] rogpeppe: But see ReadEnvirons [13:54] niemeyer: yeah, that's a reasonable place (but not with that name) [13:54] Interesting.. I guess we're not yet generating the default environments.yaml in the Go port? [13:54] niemeyer: no. this was talked about this morning actually. [13:55] niemeyer: i didn't realise the python version did [13:55] rogpeppe: Oh, what was the context/conclusion? [13:55] niemeyer: TheMue was trying to get a working juju live [13:56] niemeyer: i think davecheney might've raised an issue actually [13:56] niemeyer: personally, i think it would be better as a separate command [13:56] rogpeppe: I have raised it after dave asked me to do so. [13:57] niemeyer: juju generate-environment, or something [13:57] TheMue: cool [13:57] rogpeppe: A separate command won't make the first-user experience any simplre [13:57] simpler [13:57] niemeyer: no, but unexpected side-effects aren't great either [13:57] rogpeppe: They're not great if they're not great [13:58] niemeyer: when does the python version generate a new environments.yaml? when it can't find one? [13:58] rogpeppe: What's the actual problem? [13:58] rogpeppe: Sounds.. sensible? :) [13:59] niemeyer: i dunno. if i call juju bootstrap accidentally on the wrong machine, i'm not sure i want it to lay a turd in my home directory [13:59] niemeyer: particularly as it might contain some secret information. [13:59] niemeyer: but i can see the ease-of-use argument too [14:00] rogpeppe: You mean an automatically generated environments.yaml will contain secret information? That'd be curious. :) [14:00] niemeyer: i thought it might take some info from environment variables (e.g. AWS_SECRET_KEY) but i guess it doesn't need to [14:00] rogpeppe: Either way, let's get over it. It's a default sample file.. I think it's working fine so far. [14:01] niemeyer: so which provider does it provide an entry for? [14:01] niemeyer: or does it perhaps provide an entry for all known providers? [14:01] rogpeppe: We support a single provider.. the answer seems straightforward [14:01] niemeyer: we will support many. [14:01] rogpeppe: Probably the local one in the future.. ec2 right now [14:01] Plus commented out samples [14:02] niemeyer: i wonder if it might actually be good to generate a sample file with entries for all providers. [14:02] niemeyer: then the user can choose the one they want [14:02] Plus commented out samples [14:02] rogpeppe: The local provider is going to be ubiquitous [14:02] rogpeppe: We can keep it as the default [14:02] niemeyer: yeah. [14:02] rogpeppe: Either way, we don't have to solve that now.. the current answer is obvious [14:03] niemeyer: so... do we want a method on EnvironProvider that returns a sample environment config? [14:03] niemeyer: so that we don't always produce a sample with the same control-bucket or admin-secret, for example [14:04] niemeyer: (that's always a stumbling block) [14:04] rogpeppe: I suggest renaming ReadEnvirons to LoadEnvirons, and bundling it there [14:05] rogpeppe: only in the case where "" is used, specifically [14:05] niemeyer: that sounds reasonable [14:06] niemeyer: so would we store the root CA certificate in environments.yaml or in a file alongside it? [14:06] rogpeppe: Maybe we don't even have to rename, actually.. just document it properly [14:06] rogpeppe: I think the current mechanism we are putting in place works best [14:06] rogpeppe: .pem [14:08] niemeyer: so if we fail to load the configuration because the .pem file exists, we generate it? [14:09] rogpeppe: s/exists/doesn't exist/, sounds sane [14:09] niemeyer: are you actually suggesting we go back to my original plan of having root-cert and root-private-key as attributes in the config? [14:10] rogpeppe: I think the current mechanism we are putting in place works best [14:10] rogpeppe: Although, maybe we do need it [14:10] [13:50:03] rogpeppe: (which means it *is* an env setting, after all) [14:10] rogpeppe: Yes, of course, we need the settings too [14:10] rogpeppe: Otherwise we can't send [14:10] niemeyer: exactly [14:11] rogpeppe: root-pem, though, I assume [14:11] niemeyer: pem is just the format; root-cert describes what it is [14:12] niemeyer: root-cert-pem if you like, but i don't think the "pem" is necessary at that level [14:12]