| davecheney | ping | 06:46 |
|---|---|---|
| davecheney | TheMue: feel like doing some testing ? | 07:29 |
| TheMue | davecheney: Morning. | 07:29 |
| TheMue | davecheney: For sure. | 07:29 |
| davecheney | TheMue: sudo add-apt-repository ppa:gophers/go | 07:31 |
| dimitern | morning :) | 07:31 |
| davecheney | sudo apt-get install juju-core | 07:31 |
| davecheney | hello! | 07:31 |
| TheMue | dimitern: Good morning. | 07:32 |
| TheMue | davecheney: Does it conflict with my environment? Last time of done a test like that it harmed my .ssl | 07:33 |
| davecheney | what is a .ssl ? | 07:33 |
| davecheney | themue what is a .ssl ? | 07:36 |
| TheMue | davecheney: I meant the directory ~/.ssl (or has it been ~/.ssh). A test for roger removed all rights. ;) | 07:37 |
| davecheney | no, it will not affect .ssh | 07:37 |
| TheMue | 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:38 |
| davecheney | install a package from a ppa will not harm your machine | 07:39 |
| davecheney | it has not harmed mine | 07:39 |
| davecheney | if you are concerned, please do not participate | 07:39 |
| TheMue | davecheney: No, only wanted to get sure. Not that the ppa go conflicts with the manually installed go. | 07:41 |
| davecheney | TheMue: yes, thta is correct, do not install the golang-{tip,stable,weekly} package from that ppa | 07:42 |
| TheMue | davecheney: So what exactly shall I install now? | 07:44 |
| davecheney | sudo add-apt-repository ppa:gophers/go | 07:44 |
| davecheney | sudo apt-get install juju-core | 07:44 |
| TheMue | davecheney: OK, one moment. | 07:44 |
| davecheney | add an sudo apt-get update in the middle | 07:45 |
| TheMue | davecheney: Good, will do, the ppa is through. | 07:45 |
| rogpeppe | davecheney, TheMue: morning! | 07:46 |
| davecheney | morning rog | 07:46 |
| TheMue | rogpeppe: Morning. | 07:46 |
| davecheney | fun and games | 07:46 |
| davecheney | who is still running precise ? | 07:46 |
| rogpeppe | davecheney: if you had a moment to have a look at some of my outstanding reviews, that would be marvellous... | 07:47 |
| rogpeppe | davecheney: i am | 07:47 |
| TheMue | davecheney: I do. | 07:47 |
| davecheney | fancy test 1.9.2 before I send out the release notification | 07:47 |
| rogpeppe | davecheney: i'll try the apt-get install | 07:47 |
| rogpeppe | davecheney: should i uninstall first? | 07:47 |
| davecheney | rogpeppe: nope | 07:47 |
| davecheney | https://docs.google.com/a/canonical.com/document/d/1siI1MeZmUP_NenX2Glhex1RODLChoU3ImzNfnVsg1Y8 | 07:48 |
| TheMue | davecheney: So, install is through, installed juju-core_1.9.2-1~721~precise1_amd64.deb ok. | 07:48 |
| rogpeppe | davecheney: that comes up as an untitled document for me | 07:48 |
| rogpeppe | davecheney: with nothing in | 07:49 |
| TheMue | davecheney: Regarding the document like for rogpeppe here. | 07:49 |
| davecheney | rogpeppe: https://docs.google.com/a/canonical.com/document/d/1siI1MeZmUP_NenX2Glhex1RODLChoU3ImzNfnVsg1Y8/edit | 07:49 |
| rogpeppe | davecheney: do i need to apt-get update? (i already have already done apt-get install juju-core in the past) | 07:49 |
| davecheney | dpkg -l juju-core | 07:49 |
| davecheney | if it says 1.9.2-1 | 07:49 |
| davecheney | you're good | 07:49 |
| davecheney | which juju | 07:50 |
| davecheney | if that says /usr/bin/juju | 07:50 |
| davecheney | you're good | 07:50 |
| rogpeppe | davecheney: i tell a lie. it was just known to apt-cache, that's all. | 07:50 |
| TheMue | davecheney: /usr/bin/juju and 1.9.2-1~721~precise1 here | 07:51 |
| rogpeppe | davecheney: as expected: http://paste.ubuntu.com/1362048/ | 07:51 |
| davecheney | TheMue: then follow the instructions in the document with respect to your environments.yaml and try to bootstrap | 07:52 |
| rogpeppe | davecheney: i guess i should uninstall pyjuju | 07:52 |
| davecheney | rogpeppe: i'm surprised both could be installed at once | 07:52 |
| rogpeppe | davecheney: they couldn't | 07:53 |
| rogpeppe | davecheney: it failed doing the first install (and i have not done apt-get install juju-core in the past!) | 07:53 |
| rogpeppe | davecheney: after doing apt-get remove juju, it installed just fine | 07:55 |
| davecheney | two secs, changing machines | 07:56 |
| davecheney | how's it going ? | 08:03 |
| rogpeppe | davecheney: how's what going? | 08:04 |
| davecheney | anyone tried 1.9.2 ? | 08:05 |
| TheMue | davecheney: Hmm, I'm funnily missing my .juju directory. Dunno why yet. | 08:05 |
| davecheney | TheMue: when was the last time you deployed juju ? | 08:06 |
| rogpeppe | davecheney: i think we should default the public-bucket setting to something useful | 08:06 |
| davecheney | rogpeppe: already fixing it | 08:06 |
| TheMue | davecheney: Before I made some changes here on my system to work with lxc. | 08:06 |
| TheMue | davecheney: But isn't juju bootsrap intended to create an initial one? | 08:07 |
| davecheney | TheMue: not our version | 08:07 |
| davecheney | did the python version make one if missing ? | 08:07 |
| rogpeppe | davecheney: nope | 08:07 |
| TheMue | davecheney: Yes, because it complains. | 08:07 |
| davecheney | TheMue: please raise that as a bug, i don't think anyone has that on their radar | 08:08 |
| TheMue | davecheney: I'll create one by hand. My latest tests have been for William, before Copenhagen. Grmlblx! | 08:08 |
| davecheney | https://codereview.appspot.com/6851057 | 08:08 |
| TheMue | davecheney: Yep, will do. | 08:08 |
| rogpeppe | davecheney: jujud version reports 1.9.1 BTW. should it be 1.9.2 ? | 08:10 |
| rogpeppe | davecheney: it's bootstrapped fine, for the record | 08:10 |
| davecheney | rogpeppe: what tools did it download, from cloud-init-output | 08:10 |
| rogpeppe | davecheney: 1.9.2 | 08:11 |
| rogpeppe | davecheney: (from the status output) | 08:11 |
| davecheney | strange, you sohld have a jujud on your system | 08:11 |
| davecheney | what are the md5 sums | 08:11 |
| rogpeppe | % md5sum /usr/bin/juju* | 08:11 |
| rogpeppe | cec0c4334013c5141e6853335074df49 /usr/bin/juju | 08:11 |
| rogpeppe | d12c6225e72bd840f83d583f403f1842 /usr/bin/jujuc | 08:11 |
| rogpeppe | 72aad860f374b312dd054b3a548489ed /usr/bin/jujud | 08:11 |
| rogpeppe | aaahhh | 08:12 |
| rogpeppe | modification time on those files is november 1st | 08:12 |
| rogpeppe | which might indicate that the apt-get install didn't. | 08:12 |
| davecheney | should be today | 08:12 |
| davecheney | dpkg -l juju-core | 08:12 |
| rogpeppe | no, ctime is this morning | 08:13 |
| rogpeppe | it's just apt-get setting mtime inappropriately | 08:13 |
| rogpeppe | (i wish things wouldn't do that - mtime is useful info) | 08:13 |
| rogpeppe | davecheney: ii juju-core 1.9.1-0~708~pr Juju is devops distilled | 08:14 |
| davecheney | y'all got the wrong version mate | 08:14 |
| rogpeppe | davecheney: i did apt-get update, and the version is still the same | 08:15 |
| TheMue | 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 |
| rogpeppe | davecheney: (dpkg -l lists the same version, at any rate) | 08:15 |
| rogpeppe | TheMue: what errors do you get? | 08:16 |
| rogpeppe | TheMue: (this is useful stuff, to find out what problems people are likely to run into) | 08:16 |
| TheMue | rogpeppe: First my ~/.juju has been missing, now I get a "error: cannot query old bootstrap state: Access Denied". | 08:16 |
| rogpeppe | TheMue: sounds like your amazon keys are wrong | 08:17 |
| davecheney | TheMue: that means you don't own your control bucket | 08:17 |
| davecheney | either your keys are wrong | 08:17 |
| davecheney | or you down't own it | 08:17 |
| rogpeppe | TheMue: yeah, try renaming your control bucket | 08:17 |
| rogpeppe | TheMue: where did you get the name of the control bucket from? | 08:17 |
| TheMue | One moment. | 08:17 |
| rogpeppe | 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 |
| davecheney | TheMue: did you set control-bucket: juju-dist by mistake ? | 08:19 |
| rogpeppe | i remember running into this issue | 08:19 |
| rogpeppe | TheMue: perhaps you could paste what you've currently got in your environments.yaml | 08:19 |
| davecheney | rogpeppe: -1, that would mean someone else who had different amazon credentials could not drive a shared environment | 08:19 |
| rogpeppe | davecheney: they couldn't anyway - they couldn't access the bucket | 08:20 |
| davecheney | rogpeppe: hmm | 08:20 |
| davecheney | that is a point | 08:20 |
| rogpeppe | davecheney: anyway, i think the idea is to delete the control bucket and use instance tags, which amounts to much the same thing. | 08:20 |
| davecheney | in that case +1 | 08:21 |
| davecheney | raise an issue | 08:21 |
| rogpeppe | davecheney: so it'll go away of its own accord | 08:21 |
| rogpeppe | davecheney: oh.... except for upload-tools | 08:21 |
| * davecheney waves fist at upload tools | 08:22 | |
| rogpeppe | davecheney: for upload-tools (which only developers need), we could have another attribute | 08:23 |
| rogpeppe | davecheney: it's not really a control bucket in that case anyway | 08:23 |
| davecheney | rogpeppe: yup, i don't think we need to advertise our developer hooks | 08:25 |
| rogpeppe | davecheney: i think we should document them like we document everything | 08:26 |
| rogpeppe | davecheney: but most people should not need 'em | 08:26 |
| davecheney | so, anyone bootstrapped yet ? | 08:27 |
| * davecheney afk for 20 mins, dinner is on the table | 08:32 | |
| rogpeppe | davecheney: yeah sure, but you said i'd got the wrong version | 08:32 |
| davecheney | apt-get update && apt-cache search juju-core | 08:34 |
| rogpeppe | davecheney: that doesn't tell me the juju-core version | 08:35 |
| rogpeppe | davecheney: dpkg -l says it's still 1.9.1 | 08:35 |
| TheMue | 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 |
| rogpeppe | TheMue: they can be anything | 08:39 |
| rogpeppe | TheMue: but the control-bucket must be unique | 08:39 |
| rogpeppe | TheMue: on s3 | 08:39 |
| rogpeppe | TheMue: just type some random alphanumeric characters for the control bucket name | 08:40 |
| TheMue | rogpeppe: OK, will take a uuid | 08:41 |
| davecheney | rogpeppe: not sure what is wrong with your machine | 08:45 |
| davecheney | http://ppa.launchpad.net/gophers/go/ubuntu/dists/precise/main/binary-amd64/Packages | 08:45 |
| TheMue | rogpeppe: Ah, this time it looks better. No error. | 08:45 |
| davecheney | the ppa is up to date | 08:45 |
| rogpeppe | TheMue: what does this print for you? /usr/bin/jujud version | 08:46 |
| TheMue | rogpeppe: A fine "1.9.2-precise-amd64". :) | 08:46 |
| TheMue | davecheney: So, after bootstrapping, what shall I test next for you? | 08:47 |
| davecheney | TheMue: juju ssh -- 'uname -a' | 08:47 |
| davecheney | sorry juju ssh 0 -- 'uname -a' | 08:48 |
| * TheMue still wonders at which point his ~/.juju has gone. | 08:48 | |
| davecheney | shuld be the precise kernel | 08:48 |
| davecheney | default-series is sitll busted | 08:48 |
| rogpeppe | davecheney: i've no idea what's wrong with my machine either. i've steered clear of all dpkg internals before now. | 08:48 |
| davecheney | sudo apt-get remove juju-core | 08:48 |
| davecheney | apt-get update | 08:48 |
| davecheney | try readding the ppa | 08:48 |
| rogpeppe | TheMue: you need plan 9's dump filesystem :-) | 08:48 |
| davecheney | check in /etc/apd/source.apt.d/ | 08:48 |
| TheMue | rogpeppe: Gna, he again. :D | 08:49 |
| TheMue | rogpeppe: On OS X I've got my tome machine. | 08:49 |
| rogpeppe | davecheney: do you mean /etc/apt/sources.list.d ? | 08:49 |
| rogpeppe | davecheney: in there i see a file gophers-go-precise.list, containing this: | 08:50 |
| rogpeppe | deb http://ppa.launchpad.net/gophers/go/ubuntu precise main | 08:50 |
| rogpeppe | deb-src http://ppa.launchpad.net/gophers/go/ubuntu precise main | 08:50 |
| TheMue | 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 |
| rogpeppe | which looks plausible to me | 08:50 |
| rogpeppe | deb http://ppa.launchpad.net/gophers/go/ubuntu precise main | 08:51 |
| rogpeppe | deb-src http://ppa.launchpad.net/gophers/go/ubuntu precise main | 08:51 |
| davecheney | 3.2.0, that is precise | 08:51 |
| davecheney | TheMue: try destroying that environemnt | 08:51 |
| davecheney | adding "default-series: quantal" and bootstrapping again | 08:51 |
| davecheney | my suspicion is that you will get precise again | 08:52 |
| TheMue | davecheney: ok | 08:52 |
| rogpeppe | 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 |
| davecheney | yeah, i should have suggested that | 08:53 |
| rogpeppe | davecheney: it doesn't mean i've actually got 1.9.2 installed now | 08:53 |
| davecheney | you can find the link here https://code.launchpad.net/~dave-cheney/+recipe/juju-core | 08:53 |
| rogpeppe | davecheney: i wonder if it's a caching issue | 08:54 |
| davecheney | apt-get update | grep ppa | 08:55 |
| davecheney | annoyingly it only syas the host | 08:55 |
| davecheney | not the sub repo | 08:55 |
| davecheney | if you see Ign | 08:55 |
| davecheney | then it could be a cachcing issue | 08:55 |
| davecheney | you can remove the cache | 08:55 |
| davecheney | but that would be getting a bit too serious | 08:55 |
| davecheney | as long as you have the deb installed, that'll do | 08:55 |
| rogpeppe | davecheney: http://paste.ubuntu.com/1362136/ | 08:55 |
| rogpeppe | davecheney: hmm, should it mention gophers there? | 08:56 |
| davecheney | rogpeppe: mine doesn't :( | 08:56 |
| davecheney | which is shitful | 08:56 |
| rogpeppe | davecheney: well, when i just did add-apt-repository, it seemed to do something, so maybe that was the problem | 08:57 |
| TheMue | davecheney: Hmm, this time ssh after bootstrap needs a bit longer. | 08:58 |
| rogpeppe | davecheney: but apt-get update still leave me on 1.9.1 | 08:58 |
| Aram | have to catch a plane guys | 08:58 |
| Aram | see you later | 08:58 |
| TheMue | 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. | 08:59 |
| * rogpeppe has no idea what the relationship between apt and dpkg is | 09:00 | |
| davecheney | rogpeppe: dpkg is debian package == deb | 09:06 |
| davecheney | which handles package | 09:06 |
| davecheney | apt is the bit that gets packages onto and off your system | 09:06 |
| davecheney | TheMue: as i thought, that is still precise | 09:06 |
| rogpeppe | davecheney: i'm not sure i understand the distinction there | 09:06 |
| rogpeppe | davecheney: apt is just a glorified url fetcher? | 09:07 |
| TheMue | davecheney: So not what you wanted. | 09:07 |
| rogpeppe | davecheney: except it must wrap dpkg to do the work, i guess | 09:07 |
| davecheney | TheMue: nope, really annoyting #1074064 | 09:08 |
| davecheney | rogpeppe: yes, apt calls dpkg | 09:08 |
| davecheney | rogpeppe: in true python style, apt will cook you dinner if you treat it right | 09:08 |
| davecheney | rogpeppe: dpkg is to tar, what apt is to wget | 09:08 |
| davecheney | rogpeppe: and if you find using apt too cumbersome | 09:09 |
| rogpeppe | davecheney: ok, i see | 09:09 |
| davecheney | ther eis always aptitude, or synaptic | 09:09 |
| rogpeppe | davecheney: the only problem i have with apt is that it prints too much crap | 09:09 |
| davecheney | rogpeppe: lets do some reviews | 09:12 |
| davecheney | https://codereview.appspot.com/6851057/ | 09:12 |
| rogpeppe | davecheney: i'll swap ya: https://codereview.appspot.com/6843059/ | 09:13 |
| davecheney | done! | 09:13 |
| rogpeppe | davecheney: (by no means a fair swap though!) | 09:13 |
| davecheney | ... 800 lines | 09:14 |
| rogpeppe | davecheney: most of that is tests | 09:18 |
| rogpeppe | 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:19 |
| rogpeppe | davecheney: thinking about it, i'm not sure that config is the right place to default the public bucket | 09:21 |
| rogpeppe | davecheney: oops | 09:22 |
| rogpeppe | davecheney: scratch that! | 09:22 |
| rogpeppe | davecheney: i thought i was looking at environs/config | 09:22 |
| rogpeppe | davecheney: LGTM | 09:22 |
| niemeyer | Hello all! | 11:00 |
| rogpeppe | niemeyer: yo! | 11:00 |
| rogpeppe | niemeyer: i've been wondering about the best place to pass the root CA certificate around. | 11:03 |
| rogpeppe | niemeyer: my current thinking is that it can be a new field in state.Info | 11:04 |
| rogpeppe | niemeyer: does that seem reasonable to you? | 11:04 |
| niemeyer | rogpeppe: Yeah, seems right | 11:05 |
| rogpeppe | niemeyer: cool | 11:05 |
| rogpeppe | 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:05 |
| rogpeppe | niemeyer: but i think that's just something we document | 11:06 |
| niemeyer | rogpeppe: Hmm.. yeah | 11:07 |
| niemeyer | rogpeppe: We can fix it easily, I guess, if we find a better way | 11:07 |
| niemeyer | rogpeppe: But feels like a good way in principle | 11:07 |
| rogpeppe | niemeyer: great | 11:07 |
| rogpeppe | 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:09 |
| niemeyer | rogpeppe: Bootstrap the function or Bootstrap the method? | 11:10 |
| rogpeppe | niemeyer: Bootstrap the method | 11:10 |
| niemeyer | rogpeppe: Why do we need the root cert there? | 11:10 |
| rogpeppe | niemeyer: because the newly bootstrapped instance needs to know the root CA cert | 11:11 |
| rogpeppe | niemeyer: so that it can pass it to new instances | 11:11 |
| niemeyer | rogpeppe: Hmm.. why? | 11:11 |
| rogpeppe | niemeyer: so that the new instances can verify they're talking to the right server | 11:11 |
| niemeyer | rogpeppe: Shouldn't they use the server cert for that? | 11:12 |
| rogpeppe | niemeyer: TLS authentication works by verifying against root CAs, no? | 11:12 |
| niemeyer | rogpeppe: How can the client tell if a signature for which I'm providing a cert is a root cert or not? | 11:13 |
| rogpeppe | 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 |
| rogpeppe | niemeyer: which is all we need... i think | 11:14 |
| niemeyer | rogpeppe: That works too, for sure.. it'd be easy to make the server cert itself work as well | 11:15 |
| niemeyer | rogpeppe: Maybe we don't want that, though.. | 11:15 |
| rogpeppe | niemeyer: how would that work? i went off that route ages ago at your prompting | 11:15 |
| niemeyer | rogpeppe: I don't think there's any off route done so far | 11:16 |
| rogpeppe | niemeyer: we can verify the server cert name, which could be useful | 11:16 |
| niemeyer | rogpeppe: What you've implemented is not my wishes.. it's barebones TLS | 11:16 |
| rogpeppe | niemeyer: i'm talking about my original thoughts about certificate distribution, which verified against the certificates directly, not against a root CA. | 11:16 |
| niemeyer | rogpeppe: That's what I'm talking about too.. I'm not suggesting changing anything that is in place right now | 11:17 |
| rogpeppe | niemeyer: i'm not quite sure what you mean by "make the server cert itself work as well" | 11:17 |
| niemeyer | rogpeppe: Okay, nevermind | 11:17 |
| rogpeppe | niemeyer: by passing around the root CA cert, we make it possible to upgrade server certs in the future | 11:18 |
| niemeyer | rogpeppe: So you want to send the root cert to every client | 11:18 |
| rogpeppe | niemeyer: yeah | 11:18 |
| niemeyer | rogpeppe: That starts to feel more like an environment setting | 11:18 |
| rogpeppe | 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 |
| rogpeppe | niemeyer: but i can certainly see it as an environment setting in the future | 11:19 |
| rogpeppe | niemeyer: so that we can update the root certificate | 11:19 |
| niemeyer | rogpeppe: Indeed | 11:20 |
| niemeyer | rogpeppe: So, should we do that now instead of waiting and fixing? | 11:24 |
| rogpeppe | niemeyer: i don't think there's any particular need - it will really be adding rather than fixing, i think | 11:24 |
| rogpeppe | niemeyer: i think we'll still need the mechanisms i'm putting in place | 11:25 |
| niemeyer | rogpeppe: Cool | 11:25 |
| rogpeppe | niemeyer: it would be great to get some feedback on https://codereview.appspot.com/6843059/ if you have some time today, BTW | 12:34 |
| niemeyer | rogpeppe: Will run through the whole queue today still | 12:35 |
| rogpeppe | niemeyer: yeah, but i know this'll be near the bottom 'cos it's big :-( | 12:35 |
| niemeyer | rogpeppe: You'll have some feedback before the end of your day still | 12:36 |
| rogpeppe | niemeyer: cool, that would be lovely | 12:36 |
| rogpeppe | niemeyer: it's a pity it turned out so big - conceptually it's only about 6 operations | 12:37 |
| niemeyer | rogpeppe: I know.. it's just dense | 12:37 |
| rogpeppe | niemeyer: yes. there are a lot of little decisions went into some parts of it. | 12:38 |
| TheMue | lunchtime, bbl | 12:54 |
| niemeyer | TheMue: Enjoy | 13:00 |
| TheMue | And back again. | 13:16 |
| TheMue | niemeyer: Thx. | 13:16 |
| niemeyer | TheMue: Wow :) | 13:16 |
| niemeyer | TheMue: That's fast | 13:17 |
| TheMue | niemeyer: Yeah, want to step out earlier today. ;) | 13:17 |
| TheMue | Now I have to think about a good unit testing for lxc. | 13:20 |
| rogpeppe | niemeyer: ping | 13:39 |
| niemeyer | rogpeppe: hi | 13:39 |
| rogpeppe | niemeyer: just wanted to check something for reasonableness | 13:39 |
| niemeyer | rogpeppe: Sure thing | 13:39 |
| rogpeppe | niemeyer: the juju command now reads from the user's home directory (to get the root CA certificate) | 13:39 |
| rogpeppe | niemeyer: and i'm slightly reluctant to add fake home directory wrapping to every single test in cmd/juju | 13:40 |
| rogpeppe | niemeyer: and there is an easy workaround, but i'm not sure you'll like it, hence my asking | 13:40 |
| rogpeppe | 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 |
| rogpeppe | niemeyer: all the calls in cmd/juju call juju.NewConn(env, nil) | 13:41 |
| niemeyer | rogpeppe: Sounds reasonable | 13:42 |
| rogpeppe | 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 |
| niemeyer | rogpeppe: Well, I can foresee cases where we'll want to define it in code too | 13:42 |
| rogpeppe | niemeyer: i'm not sure what you mean | 13:43 |
| niemeyer | rogpeppe: But it's not really important right now | 13:43 |
| niemeyer | rogpeppe: "always nil" | 13:43 |
| rogpeppe | niemeyer: another possibility is to add a flag that specifies the filename or the root certificate itself. | 13:44 |
| niemeyer | rogpeppe: "or the root" or "of the root"? | 13:44 |
| rogpeppe | niemeyer: both :-) | 13:44 |
| niemeyer | rogpeppe: So I don't understand what this means | 13:44 |
| rogpeppe | niemeyer: the filename of the root certificate, or the root certificate itself (as a literal string) | 13:45 |
| niemeyer | rogpeppe: You're suggesting we overload a single argument to mean both a filename and the data for the cert? | 13:45 |
| rogpeppe | niemeyer: no, i'm saying the flag might specify either - we'd need to decide | 13:46 |
| rogpeppe | niemeyer: or we might have two flags | 13:46 |
| niemeyer | rogpeppe: Why is that different from Bootstrap? | 13:46 |
| niemeyer | rogpeppe: The whole thing is starting to feel a bit hackish, to be honest.. | 13:47 |
| niemeyer | rogpeppe: We have a mechanism to read the environment data from disk abstracted away | 13:47 |
| niemeyer | rogpeppe: and then we take that data, and go back to disk to look for more | 13:47 |
| * niemeyer looks at some code | 13:47 | |
| rogpeppe | niemeyer: we need to be able to save something to disk and then recover that, and that's what this is about | 13:48 |
| rogpeppe | 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 |
| niemeyer | rogpeppe: This looks like the wrong place to be doing this | 13:49 |
| niemeyer | rogpeppe: Exactly | 13:49 |
| rogpeppe | niemeyer: i'd prefer to pass something into the juju calls that abstracts out the data saving and restoring | 13:49 |
| niemeyer | 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:49 |
| niemeyer | rogpeppe: (which means it *is* an env setting, after all) | 13:50 |
| rogpeppe | :-| | 13:50 |
| rogpeppe | niemeyer: we still need some way of saving data and restoring it | 13:50 |
| niemeyer | 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 |
| rogpeppe | niemeyer: the environment config only gets us some of the way | 13:50 |
| niemeyer | 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 |
| niemeyer | rogpeppe: So we avoid the two-worlds situation | 13:51 |
| rogpeppe | niemeyer: the place that's already managing $HOME stuff is environs/config | 13:52 |
| rogpeppe | niemeyer: and i'm not convinced that should be the place that generates a certificate and key | 13:52 |
| niemeyer | rogpeppe: Uh.. no? | 13:52 |
| niemeyer | rogpeppe: Look for any logic about $HOME there | 13:52 |
| rogpeppe | niemeyer: i'm thinking about authorized_keys | 13:53 |
| niemeyer | rogpeppe: Ah, okay | 13:53 |
| niemeyer | rogpeppe: But see ReadEnvirons | 13:53 |
| rogpeppe | niemeyer: yeah, that's a reasonable place (but not with that name) | 13:54 |
| niemeyer | Interesting.. I guess we're not yet generating the default environments.yaml in the Go port? | 13:54 |
| rogpeppe | niemeyer: no. this was talked about this morning actually. | 13:54 |
| rogpeppe | niemeyer: i didn't realise the python version did | 13:55 |
| niemeyer | rogpeppe: Oh, what was the context/conclusion? | 13:55 |
| rogpeppe | niemeyer: TheMue was trying to get a working juju live | 13:55 |
| rogpeppe | niemeyer: i think davecheney might've raised an issue actually | 13:56 |
| rogpeppe | niemeyer: personally, i think it would be better as a separate command | 13:56 |
| TheMue | rogpeppe: I have raised it after dave asked me to do so. | 13:56 |
| rogpeppe | niemeyer: juju generate-environment, or something | 13:57 |
| rogpeppe | TheMue: cool | 13:57 |
| niemeyer | rogpeppe: A separate command won't make the first-user experience any simplre | 13:57 |
| niemeyer | simpler | 13:57 |
| rogpeppe | niemeyer: no, but unexpected side-effects aren't great either | 13:57 |
| niemeyer | rogpeppe: They're not great if they're not great | 13:57 |
| rogpeppe | niemeyer: when does the python version generate a new environments.yaml? when it can't find one? | 13:58 |
| niemeyer | rogpeppe: What's the actual problem? | 13:58 |
| niemeyer | rogpeppe: Sounds.. sensible? :) | 13:58 |
| rogpeppe | 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 |
| rogpeppe | niemeyer: particularly as it might contain some secret information. | 13:59 |
| rogpeppe | niemeyer: but i can see the ease-of-use argument too | 13:59 |
| niemeyer | rogpeppe: You mean an automatically generated environments.yaml will contain secret information? That'd be curious. :) | 14:00 |
| rogpeppe | 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 |
| niemeyer | rogpeppe: Either way, let's get over it. It's a default sample file.. I think it's working fine so far. | 14:00 |
| rogpeppe | niemeyer: so which provider does it provide an entry for? | 14:01 |
| rogpeppe | niemeyer: or does it perhaps provide an entry for all known providers? | 14:01 |
| niemeyer | rogpeppe: We support a single provider.. the answer seems straightforward | 14:01 |
| rogpeppe | niemeyer: we will support many. | 14:01 |
| niemeyer | rogpeppe: Probably the local one in the future.. ec2 right now | 14:01 |
| niemeyer | Plus commented out samples | 14:01 |
| rogpeppe | niemeyer: i wonder if it might actually be good to generate a sample file with entries for all providers. | 14:02 |
| rogpeppe | niemeyer: then the user can choose the one they want | 14:02 |
| niemeyer | <niemeyer> Plus commented out samples | 14:02 |
| niemeyer | rogpeppe: The local provider is going to be ubiquitous | 14:02 |
| niemeyer | rogpeppe: We can keep it as the default | 14:02 |
| rogpeppe | niemeyer: yeah. | 14:02 |
| niemeyer | rogpeppe: Either way, we don't have to solve that now.. the current answer is obvious | 14:02 |
| rogpeppe | niemeyer: so... do we want a method on EnvironProvider that returns a sample environment config? | 14:03 |
| rogpeppe | niemeyer: so that we don't always produce a sample with the same control-bucket or admin-secret, for example | 14:03 |
| rogpeppe | niemeyer: (that's always a stumbling block) | 14:04 |
| niemeyer | rogpeppe: I suggest renaming ReadEnvirons to LoadEnvirons, and bundling it there | 14:04 |
| niemeyer | rogpeppe: only in the case where "" is used, specifically | 14:05 |
| rogpeppe | niemeyer: that sounds reasonable | 14:05 |
| rogpeppe | niemeyer: so would we store the root CA certificate in environments.yaml or in a file alongside it? | 14:06 |
| niemeyer | rogpeppe: Maybe we don't even have to rename, actually.. just document it properly | 14:06 |
| niemeyer | rogpeppe: I think the current mechanism we are putting in place works best | 14:06 |
| niemeyer | rogpeppe: <env name>.pem | 14:06 |
| rogpeppe | niemeyer: so if we fail to load the configuration because the <env-name>.pem file exists, we generate it? | 14:08 |
| niemeyer | rogpeppe: s/exists/doesn't exist/, sounds sane | 14:09 |
| rogpeppe | 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:09 |
| niemeyer | <niemeyer> rogpeppe: I think the current mechanism we are putting in place works best | 14:10 |
| niemeyer | rogpeppe: Although, maybe we do need it | 14:10 |
| rogpeppe | [13:50:03] <niemeyer> rogpeppe: (which means it *is* an env setting, after all) | 14:10 |
| niemeyer | rogpeppe: Yes, of course, we need the settings too | 14:10 |
| niemeyer | rogpeppe: Otherwise we can't send | 14:10 |
| rogpeppe | niemeyer: exactly | 14:10 |
| niemeyer | rogpeppe: root-pem, though, I assume | 14:11 |
| rogpeppe | niemeyer: pem is just the format; root-cert describes what it is | 14:11 |
| rogpeppe | niemeyer: root-cert-pem if you like, but i don't think the "pem" is necessary at that level | 14:12 |
| niemeyer | rogpeppe: So far I've seen a single file being used | 14:12 |
| niemeyer | rogpeppe: For both cert and key | 14:12 |
| rogpeppe | niemeyer: yes, but in the config it makes sense to have two attributes | 14:12 |
| rogpeppe | niemeyer: i started off with one | 14:12 |
| rogpeppe | niemeyer: but it made things awkward | 14:13 |
| niemeyer | rogpeppe: If we have two attributes, let's have two files too | 14:13 |
| niemeyer | rogpeppe: It actually seems to make sense to have two files | 14:13 |
| rogpeppe | niemeyer: agreed | 14:13 |
| rogpeppe | niemeyer: that's what i'd done previously | 14:13 |
| niemeyer | rogpeppe: Why did it change? | 14:13 |
| rogpeppe | niemeyer: when they weren't stored in the config, it made sense to keep them together as a blob | 14:14 |
| niemeyer | rogpeppe: I'm not sure about how that's related | 14:14 |
| rogpeppe | niemeyer: maybe it was just a consequence of me re-branching from an earlier version | 14:15 |
| niemeyer | rogpeppe: Okay, either way.. | 14:15 |
| niemeyer | rogpeppe: What are we doing then? | 14:15 |
| rogpeppe | niemeyer: i'm not entirely happy about losing another week's worth of work, but there we go | 14:15 |
| niemeyer | rogpeppe: root-cert, root-private-key + root-cert-path, root-private-key-path? | 14:16 |
| niemeyer | rogpeppe: Why are you losing anything? | 14:16 |
| niemeyer | rogpeppe: None of that logic is in place yet? | 14:16 |
| niemeyer | rogpeppe: and I hope such a simple change doesn't take *a week* | 14:16 |
| rogpeppe | niemeyer: because all the stuff i've been doing this week relies on passing around root-cert explicitly | 14:16 |
| niemeyer | rogpeppe: I did all of the config refactoring in two days | 14:17 |
| niemeyer | rogpeppe: I'm hoping this is significantly simpler | 14:17 |
| rogpeppe | niemeyer: i'm not saying that it'll take a week | 14:17 |
| niemeyer | rogpeppe: You just said that | 14:17 |
| rogpeppe | niemeyer: but that most of what i've done this week i'll need to redo | 14:17 |
| niemeyer | rogpeppe: Woah? | 14:17 |
| niemeyer | rogpeppe: I really don't see how that's possible | 14:18 |
| rogpeppe | niemeyer: well, i hope not | 14:18 |
| niemeyer | rogpeppe: Sending the server pem to the machine is done the same way.. generating keys is done the same way.. | 14:18 |
| niemeyer | etc | 14:18 |
| rogpeppe | niemeyer: anyway, i should be able to drag out my earlier branch which implements exactly root-cert, root-private-key + root-cert-path, root-private-key-path AFAIR | 14:18 |
| niemeyer | rogpeppe: Changing a parameter to a config.Foo() should be on the trivial side | 14:18 |
| rogpeppe | niemeyer: maybe you're right | 14:19 |
| niemeyer | rogpeppe: This should really not take long if one is actually focusing on doing it | 14:19 |
| niemeyer | rogpeppe: We can also continue to move the existing branches forward, since this is trivial to adapt in a follow up | 14:20 |
| rogpeppe | niemeyer: i've got quite a few branches for review, but now none of them are valid. | 14:20 |
| niemeyer | rogpeppe: Why? | 14:20 |
| rogpeppe | niemeyer: well, because they all use the mechanism that we've decided we're not going to use. but if you think it's ok to move forward from there, that seems better to me. | 14:21 |
| niemeyer | rogpeppe: I think pretty much everything I've seen so far looks like progress | 14:21 |
| rogpeppe | niemeyer: good | 14:21 |
| niemeyer | rogpeppe: We still need Bootstrap, etc | 14:21 |
| niemeyer | rogpeppe: Tweaking Bootstrap on a follow up to take the cert from the config should be on the trivial side | 14:22 |
| rogpeppe | niemeyer: change Bootstrap to take a config.Config argument rather than a PEM []byte, right? | 14:23 |
| niemeyer | rogpeppe: Bootstrap already takes an env, doesn't it? | 14:25 |
| === TheMue_ is now known as TheMue | ||
| rogpeppe | niemeyer: ah, good point | 14:25 |
| mgz | guess I should actually add this channel to the list of ones I should sit in now... | 14:27 |
| niemeyer | rogpeppe: I'll step out for lunch.. back in a bit | 14:27 |
| rogpeppe | niemeyer: enjoy! | 14:27 |
| TheMue | niemeyer: Enjoy. | 14:30 |
| * niemeyer respawns | 15:32 | |
| TheMue | niemeyer: One question about Open vSwitch. Just seen it again in the slides Mark sent to us. Which role does is have together with LXC? I never used Open vSwitch before. | 15:39 |
| niemeyer | TheMue: It's responsible for the routing | 15:57 |
| niemeyer | TheMue: But don't worry about it for now | 15:57 |
| TheMue | niemeyer: OK, already thought so. Just wanted to have it confirmed. | 15:57 |
| niemeyer | TheMue: We may end up not even needing it in step one | 15:58 |
| niemeyer | TheMue: Since VPC can deal with multiple IPs | 15:59 |
| niemeyer | TheMue: Of course, we actually have to get VPC working in the first place :) | 15:59 |
| TheMue | niemeyer: Hehe, yep. | 16:01 |
| === mmcloud_ is now known as mmcloud | ||
| niemeyer | Hmm, we still haven't done the config-per-charm thingy | 16:37 |
| niemeyer | I'll put that on my list for next week | 16:37 |
| niemeyer | rogpeppe: What is MaxPathLen is Certificate? | 16:58 |
| rogpeppe | niemeyer: i believe it's the maximum number of delegations from root to leaf | 16:58 |
| TheMue | Hmm, tests needing root rights aren't nice. But the first one passes. | 16:58 |
| niemeyer | rogpeppe: Have you checked? | 16:59 |
| rogpeppe | niemeyer: nope | 16:59 |
| rogpeppe | niemeyer: i'll check | 16:59 |
| niemeyer | rogpeppe: Seems worthy of understanding before dumping a number there | 16:59 |
| rogpeppe | niemeyer: good point. i was right... almost. 0 is a more appropriate value. | 17:03 |
| niemeyer | rogpeppe: :-) | 17:03 |
| niemeyer | rogpeppe: What does it mean? | 17:03 |
| rogpeppe | niemeyer: it's the number of intermediates in the chain | 17:03 |
| niemeyer | rogpeppe: Downstream or upstream? | 17:04 |
| rogpeppe | niemeyer: from root to leaf | 17:04 |
| rogpeppe | niemeyer: or vice versa | 17:04 |
| niemeyer | rogpeppe: Is this pointing out the number of certificates that are part of the chain that certifies the present certificate, or is it the number of certificates that may be certified by the certificate being created? | 17:06 |
| rogpeppe | niemeyer: it's the number of certificates in any chain derived from the certificate we're creating | 17:07 |
| rogpeppe | niemeyer: if MaxPathLen was 1, then the root certificate we're creating would be able to create certificates that could create certificates verifiable against our root certificate | 17:08 |
| niemeyer | rogpeppe: Why would we restrict this? | 17:08 |
| rogpeppe | niemeyer: it depends how important we deem the root certificate | 17:09 |
| niemeyer | rogpeppe: In which sense? | 17:09 |
| rogpeppe | niemeyer: if we don't mind a state server being able to create certificates for new environments, then we should allow delegation, yeah | 17:10 |
| rogpeppe | niemeyer: choosing no delegation was a totally arbitrary decision - i don't know enough about our security model to know if we want to allow that or not | 17:11 |
| niemeyer | rogpeppe: Okay, sounds good then.. it's cool to keep it at zero until we understand | 17:11 |
| niemeyer | rogpeppe: How about this "anyServer"? | 17:12 |
| rogpeppe | niemeyer: i'll leave the field in, with a comment | 17:12 |
| niemeyer | rogpeppe: 'k | 17:12 |
| rogpeppe | niemeyer: ah yes, "anyServer" :-) | 17:12 |
| rogpeppe | niemeyer: ok, so the default when doing tls authentication is to verify the host name | 17:12 |
| rogpeppe | niemeyer: a certificate is issued for a particular host name | 17:12 |
| rogpeppe | niemeyer: but in our case, when we issue the cert, we don't know the host name | 17:13 |
| niemeyer | rogpeppe: Yeah | 17:13 |
| niemeyer | rogpeppe: In fact, I think in many cases we won't even *have* a hostname | 17:13 |
| rogpeppe | niemeyer: so we cheat, by issuing with a known CommonName (which is used for the host name), and setting the host name to that when verifying | 17:13 |
| niemeyer | rogpeppe: Where do we put that info? | 17:14 |
| rogpeppe | niemeyer: it's in the tls.Config struct | 17:15 |
| niemeyer | rogpeppe: Where? | 17:15 |
| rogpeppe | niemeyer: you can see it used in the checkTLSConnection function in the tests | 17:16 |
| rogpeppe | niemeyer: tls.Config.ServerName | 17:16 |
| niemeyer | rogpeppe: The documentation says this is used for virtual hosting | 17:17 |
| rogpeppe | niemeyer: yeah | 17:17 |
| rogpeppe | niemeyer: so we've got a "virtual host" which is any server we choose to name... | 17:17 |
| TheMue | So, I'm off. Have a nice weekend. | 17:17 |
| niemeyer | rogpeppe: What happens if we don't put that in? | 17:17 |
| rogpeppe | TheMue: have a good one | 17:17 |
| niemeyer | TheMue: Thanks, you too! | 17:17 |
| rogpeppe | niemeyer: it takes the host name from the net.Conn AFAIR | 17:18 |
| rogpeppe | niemeyer: and then the authentication fails | 17:18 |
| niemeyer | rogpeppe: Hmm.. strange | 17:18 |
| niemeyer | rogpeppe: It has an explicit VerifyHostname | 17:18 |
| TheMue | rogpeppe: Will have, tomorrow with a Celtic Night, Malts, Guiness, Stew, Folk Music ... | 17:18 |
| rogpeppe | TheMue: have fun | 17:20 |
| rogpeppe | ! | 17:20 |
| rogpeppe | TheMue: enjoy the irish tunes... | 17:20 |
| TheMue | rogpeppe: Yeah, will do so. | 17:20 |
| rogpeppe | niemeyer: i'll just have a look. | 17:20 |
| niemeyer | rogpeppe: I'm checking too | 17:21 |
| niemeyer | rogpeppe: If that works, I'd prefer to have it set to in the generated certificate "*", which is closer to the actual convention used in certs, and not mangle it when connecting | 17:23 |
| niemeyer | rogpeppe: That would mean people can actually use real hostname checking by merely generating a real certificate, if they wish | 17:24 |
| rogpeppe | niemeyer: i tried using * | 17:24 |
| rogpeppe | niemeyer: it doesn't work | 17:24 |
| niemeyer | rogpeppe: What happens?" | 17:24 |
| rogpeppe | niemeyer: unless you set ServerName to "*" of course | 17:24 |
| rogpeppe | niemeyer: one mo, i'll show you | 17:25 |
| rogpeppe | niemeyer: hmm, i was absolutely certain i'd tried it and it failed... but it works. http://play.golang.org/p/FijZRXselX | 17:29 |
| rogpeppe | niemeyer: that's much better. i couldn't believe it wasn't possible to do it. | 17:30 |
| rogpeppe | "*" it is | 17:30 |
| niemeyer | rogpeppe: Superb | 17:30 |
| * rogpeppe thinks that's probably one of the larger programs around to have run in the go playground | 17:32 | |
| negronjl | m_3: ping | 17:45 |
| negronjl | sorry ... wrong channel :) | 17:45 |
| niemeyer | rogpeppe: Phew, delivered! | 17:53 |
| rogpeppe | niemeyer: yay! well done. | 17:53 |
| niemeyer | rogpeppe: Looking good.. some comments, but nothing significant | 17:54 |
| rogpeppe | niemeyer: that's relief :-) | 17:54 |
| rogpeppe | a | 17:54 |
| rogpeppe | niemeyer: i've succeeded in merging the environs/config root-cert changes, BTW and all tests are now passing, which is a relief. | 17:56 |
| rogpeppe | niemeyer: the consequential changes were much bigger than i'd like though, i'm afraid. https://codereview.appspot.com/6846066 | 18:03 |
| niemeyer | rogpeppe: No worries | 18:06 |
| niemeyer | rogpeppe: I predict they'll all be easily agreeable changes | 18:06 |
| rogpeppe | niemeyer: yeah, there's nothing particular controversial there. | 18:06 |
| rogpeppe | ly | 18:06 |
| rogpeppe | niemeyer: "*" isn't a universal wildcard unfortunately. we'll still have to set ServerName: http://play.golang.org/p/n4MTKb6fLM | 18:10 |
| rogpeppe | niemeyer: "*" doesn't match "something.com" | 18:10 |
| rogpeppe | niemeyer: this seems relevant: http://www.tbs-certificats.com/FAQ/en/320.html | 18:11 |
| niemeyer | rogpeppe: Hm | 18:14 |
| rogpeppe | niemeyer: we'll still use "*" as a common name though | 18:16 |
| rogpeppe | niemeyer: i was *sure* i'd encountered an issue with it :-) | 18:16 |
| niemeyer | rogpeppe: Okay, I guess we can go with "unknown" as a hostname for now and check later | 18:16 |
| rogpeppe | niemeyer: sounds reasonable. | 18:17 |
| rogpeppe | niemeyer: i'll leave CommonName = "*" | 18:17 |
| niemeyer | rogpeppe: We could set the ServerName based on whether we have a CommonName == "*" in the future, I guess | 18:18 |
| rogpeppe | niemeyer: we don't know the common name until the handshake is done, and then it's too late | 18:19 |
| rogpeppe | niemeyer: we could use InsecureSkipVerify and then do our own checking i suppose | 18:19 |
| niemeyer | rogpeppe: Perhaps, but that's too early I think.. CommonName == "*" + "unknown" sounds fine for now | 18:21 |
| rogpeppe | niemeyer: agreed | 18:21 |
| rogpeppe | niemeyer: time to stop for the day. thanks for the review; will address on monday. have a great weekend! | 18:22 |
| niemeyer | rogpeppe: Thanks a lot for the hard work, and have a pleasant weekend too! | 18:23 |
| === rog is now known as Guest2621 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!