harlowjahmmm, are these new errors01:22
harlowja(running on a mac)01:22
harlowjamore things not mocked?01:22
smoserharlowja, :-(11:34
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
dgarstangThree year old bug... https://bugs.launchpad.net/cloud-init/+bug/1404060 ... would be nice if it was fixed16:55
smoserdgarstang, were you the one that mentioned the related permissions issue on created directories ?17:24
dgarstangsmoser: I don't think that was me17:24
smoserthat was wraithm17:25
smoser07/25/16 16:11:31 <wraithm>   I'm trying to make an EC2 AMI with a centralized authorized keys file (ie. in sshd_config: AuthorizedKeysFile /etc/ssh/authorized_keys/%u). I see in the cloud-init source-code, cloudinit/ssh_util.py, the function setup_user_keys asserts the parent folder to be mode 700. Those permissions don't work with this AuthorizedKeysFile value. Having /etc/ssh/authorized_keys be mode 755 is what works. Is there a w17:25
smoseray around this?17:25
hans__hi folks, i had a build question. i am trying to create a local build of cloud-init using the latest revision, but I see pep8 errors. is this a known issue? seems strange because the launchpad build is passing17:25
dgarstangsmoser: similar, but different17:25
smoserhans__, pep8 is an obnoxiously moving target17:26
hans___smoser - any recommendations for getting a successful local build?17:28
smoseryou're seeing errors on tests/unittests/test_handler/test_handler_mcollective.py ?17:29
hans___yes, exactly. 4 errors17:29
smoseri'll fix that. :-(17:29
smoserwhere did you grab cloud-init from ?17:29
hans___thank you. lp:cloud-init17:29
dgarstangsmoser: me?17:30
smoserhans___, git ?17:31
smoserdgarstang, sorry, that was for dgarstang17:31
dgarstangsmoser: oh, it's just the latest canonical upstream ami17:31
smoserdgarstang, sorry, the question about cloud-init was for hans___  :)17:32
hans___smoser, using bzr-builder, since it looked like the git recipe packaging hasn't landed yet?17:32
dgarstangsmoser: take upstream ami, rebundle into a new ami with packer. that new rebundle modifies /etc/ssh/sshd_config to add second location of ssh keys. When 2nd instance boots, cloud-init reads the sshd config file, and puts the packer key in the wrong place17:32
dgarstangsmoser: D'oh. Ok17:32
smoserhans___, ok.17:33
smoserhans___, i'll get the flake8 issue fixed in git.17:39
smosernot sure what i want to do about the other.17:39
wraithmsmoser: What do you think about splitting the ssh module into a host ssh-keygen module and an inserting user authorized keys module?17:39
smoserwraithm, that does seem like a reasonable idea.17:40
harlowjashouldn't be to hard either wraithm17:40
harlowjaits pretty seperated in code as is17:40
smoserso your issue, wraithm , what would you think the right thing to do is there?17:41
smoserok. so lets get git working17:42
wraithmYeah! The code was very easy to read.17:42
wraithmSo, the runcmd: - 'chmod 755 /etc/ssh/authorized_keys' suggestion worked for me17:43
wraithmbut what would be ideal is having a module for only generating host ssh keys17:43
=== gfidente is now known as gfidente|afk
wraithmI was also very tempted by not running the ssh module and just using runcmd/bootcmd to run ssh-keygen17:45
smoserso the format of /etc/ssh/authorized_keys is the same as ~/.ssh/authorized_keys ?17:45
wraithmNot quite. It's a folder with a bunch of authorized_keys files in it17:46
smoserok. yeah.17:46
wraithmin sshd_config I have a line: AuthorizedKeysFile /etc/ssh/authorized_keys/%u17:46
smoserbut even if not split out, its only seting the permissions because generally it has to.17:46
wraithmwhere %u is the username of the person attempting to log in17:46
smoserif you set ~/.ssh/ to world writable, ssh will ignore the keys17:46
wraithmBut /etc/ssh/authorized_keys needs to be world readable17:47
wraithmin my case17:47
wraithmie 755 instead of 700, which I think is what ~/.ssh/ gets chmodded to in ssh_util.py17:48
wraithmAnother possible solution is changing the code to do different modes depending on the location of the file17:48
smoserthat seems to be the right thing, trying to think of what the right rules for permissions are17:51
wraithmI don't know know what sshd's permissions logic is :/ It's not really mentioned anywhere in the man pages.17:52
smoserit seems like 700 is overkill actually17:52
smosermy desktop has 755 on ~/.ssh/17:52
wraithmWhat about ~/.ssh/authorized_keys?17:52
wraithmoh, nevermind17:53
wraithmSo, 755 works for ~/.ssh? Maybe that's the solution.17:53
smoserseems 777 is even ok17:55
smoserseems 775 is ok17:55
smoserjust can't have other writable17:55
smoserthis is testing i'm doing on yakkety, so different ssh's could have different behavior17:55
smoserbut maybe17:55
wraithmThough, now I'm thinking that I still feel like generating host keys should be a different operation from inserting user authorized_keys. You could imagine people with some single-sign-on scheme (ldap/kerberos or whatever) baked into a cloud image. Authorized_keys is irrelevant to them.17:57
smoserwraithm, but it only inserts them if keys were provided.17:59
smoserso, then providing keys to the system is "irrelevant to them"17:59
smoserthis seems sane for my local quick testing:18:00
smoser http://paste.ubuntu.com/21032867/18:00
wraithmOh really? I look at the code and it looks like the root user always gets their key inserted.18:00
smoserwell, only if there was akey to insert18:00
smoserif theres no keys, then it shouldnt do anything. if it does (and it breaks things) then yeah, we need to fix that too18:00
wraithmOh, okay. So, what if I wanted to create some default users, but I still don't want the keys to be inserted?18:01
wraithmWhich is actually sorta what I'm doing.18:01
smoserit only inserts the key in to the default user i think18:01
wraithmRight, and that breaks my thing18:01
smoserthe one that gets identified as 'default'18:01
smosernot to all users.18:02
wraithmBecause ssh_util.py asserts /etc/ssh/authorized_keys to 70018:02
wraithmwhich is a directory in my case analogous to ~/.ssh18:02
smoserright. read that paste above though... i think that logic would work for you18:02
smoseri'm not opposed to your suggestion of splitting them, but even if they're split, the key  insertion is doing the wrong thing for the case you provided.18:03
wraithm755 doesn't have world write permissions18:04
wraithmI see18:04
wraithmThat code looks good18:04
hans___smoser, i made the pep8 fixes in a private branch, but it looks like i see some test failures as well. checked that these are present in lp revision <1258 as well. there are 8 failures, all about virtual routers. do i need to set this up locally to run the tests?18:11
smoserhans___, hm.. probably similar to what harlowja complained about above.18:14
harlowjaya, probably18:14
smoserwe really need some infrastgructure to test on non-ubuntu18:15
smoserhans___, what is your system you're running on ?18:15
smoserand are you running tox ?18:15
hans___smoser - can't see the history, unfortunately, since i'm in webchat at the moment. i'm running pbuilder in a xenial container. ran tox successfully yesterday, haven't tried today18:16
hans___smoser, just ran tox again successfully18:20
smoserthis sucks18:44
smoserthe import of lp:cloud-init from bzr to git18:45
smosera.) "flattened" all history. making log of trunk show lots of people's in-branch commits that in bzr are nicely hidden , and only shown when bzr log --include-merged18:45
smosernot a huge deal, but means that 'git log' is full of stuff like:18:46
smoser Remerge against head/master18:46
smoser merge from trunk18:46
smoserright, which bzr handles so nicely.  it allows you to accept your human.18:47
smoserand that you suck18:47
smoserother thing is that we lose the '--fixes' metadata18:47
harlowjathe feature i used every now and then18:47
harlowjaif i remembered to18:48
smoseri'm gonna look see if there is any obvious way to fix those things18:48
smoseri'd be ok if it onverted the '--fixes' metadata into (Fixes LP: #XXXXX)18:48
smoserand i think i'd even be ok if it just purged the merged18:48
smoseri'd prefer that to a bunch of "fix spelling" and "fix tox i never thought someone would see this" commits18:49
rharperwas someone else hacking on package/brpm ?  I'd really like to build my branch as an rpm so I can test a cross-distro feature;  I've got most of the bzr to git stuff fixed up (just a few more naming things w.r.t using git archive instead of bzr export); I saw some mention of spec files and such a few days ago18:51
smoserlarsks, ^18:52
smoserrharper, ^18:52
larsksrharper: yeah, me...there's a proposed merge that should work.18:53
larsksAnd if it doesn't work, let me know :)18:53
smoserthat link for fusionic... c#18:53
smoserreally ?18:53
rharperalso noticed the basic renderer doesn't like the spec file and python-cheetah was a requirement;18:53
harlowjasmoser  u're probably gonna have to do that soon, and squash those commits into the one that actually matters18:53
harlowjaand then force update the repo18:53
harlowjaits really basic18:54
rharperright, I mean, the spec file didn't include the # template: cheetah18:54
rharperwhich it should if it requires cheetah18:54
rharperwhich it does18:54
harlowjawho wrote that crap18:54
harlowjaprobably that scott guy18:54
larsksrharper: the spec file is correctly identified as a cheetah template in any case, but yeah you need cheetah installed for that to work :)18:55
larsksI ran into the same thing a day or two ago.18:55
larsksI sort of think the templater should blow up instead of falling back to basic...18:55
harlowjaya, stupid rendering crap18:56
harlowjawho wrote that18:56
rharperit has a "## this is a cheetah template"  but the type matcher, wants '##  template: cheetah' ;18:59
rharperTYPE_MATCHER = re.compile(r"##\s*template:(.*)", re.I)18:59
rharperthat said, even if the template was marked correctly, it would do the fallback18:59
rharperthough log that it could't find cheetah18:59
larsksrharper: I updated the merge request to include the appropriate template: line in both (redhat + suse) spec files.19:07
rharperlarsks: do you have a link to your merge ?19:12
* rharper is looking for what you did around oauthlib 19:13
larsksrharper: sure.  uh...did nothing arounmd oauthlib, though.  https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/30095319:14
rharperand the rpm installs on centos 7 ?  I didn't find a python-oauthlib package available19:14
larsksI haven't made any changes to requirements.  I've tested the rpm building on fedora.  Let me take a look at centos.19:15
larsksCentOS only ships 0.7.5, which means that requirements introduced sinc then aren't available.  You can get python-oauthlib through EPEL, though.19:18
larsksI am working on getting a newer version of cloud-init into RHEL, which means it should eventually show up in centos.  We may bundle all the requirements into a single cloud-init-deps package, at least in the short term.19:19
larsksrharper: ^^^19:19
rharperlarsks: you're branch just worked =)  thanks19:40
larsksThat's what I like to hear :)19:41
rharperI added epel-release, and the installed the cloud-init package created; +119:42
rharperso, something that we should look at is the default /etc/cloud/cloud.cfg sets the distro to ubuntu19:43
rharpersmoser: not sure how we 'd want to template that in the default config file19:44
larsksrharper: one option would be to produce cloud.cfg for the packages are part of the brpm/bddeb scripts.19:49
larsks*as part of...19:49
rharperhrm, centos7 has fun wit python2.6 and 2.7 and argparse ..19:49
larsksrharper: but centos 7 ships with python 2.7...19:50
larskswhere does 2.6 come into things?19:50
rharperyou're right;19:50
smoseri'm fine with requiring distro to ship something that changes the default user.19:50
rharperI saw some thread mention 2.6 didn't have argparse package19:50
smoserand fine carrying 'clouduser' as default even.19:50
smoserit doesnt have it builtin19:50
rharperpkg_resources doesn't find 'argparse' package which is required for cloud-init; but not expressed in the spec file19:50
smoseroh yeahy, and something was really wierd there for rh.19:51
rharpersmoser: ah; I didn't find the obvious python-argparse package in epel or otherwise ;19:51
rharperpython2.7 says it provides python-argparse19:51
smoserharlowja, had more info on that.19:51
rharperbut pgk_resources does't find it19:51
smoseri think i'm going to have to push overwrite git history.19:52
smoseri dont have it yet, but i really dont want to lose fixes metadata19:52
rharpersmoser: also, on the distro front; in lxd images: there is an opensuse image, but no sles that I can find (like no rhel) ; would you be ok to add 'opensuse' to the distro classes ?19:52
smoseri woudl have thoguht something worked there. but yeah.19:53
larsksrharper: yeah, you shouldn't need python-argparse, and I thought there was some logic in there to avoid listing the requirement for python 2.7 and later...19:53
larsksrharper: still an issue for the package?19:53
rharperlarsks: let me merge in trunk19:54
rharperbut I think I'm pretty recent (from Friday I think)19:54
rharperjust running /usr/bin/cloud-init --help on centos7 after package/brpm from your branch shows me this argparse pkg thingy19:54
larsksrharper: let me take a look, it's possible I lost some logic while fiddling with brpm.19:55
rharpersure;  http://paste.ubuntu.com/21048423/19:58
rharperthat's what I see19:58
rharperfedora24 fails in the same way;19:59
larsksYeah, that's because I seem to have dropped some code that handled this in brpm. Sorry!  Fixing.20:01
rharperI see this https://bugzilla.redhat.com/show_bug.cgi?id=700596#c220:02
rharperso sounds like we should drop it from the setup requirements20:02
rharperpython2.7 -c 'import argparse' does indeed work on c7 and f2720:03
smoserlarsks, i saw a change to finding topdir that used git, right?20:03
larskssmoser: yeah.20:03
smoseri'd prefer to not rely on git, as the tools ideally would work without it.20:03
smoserat least read-requirements and such.20:03
smoserat least it seems sane to me that an environment variable can be set to say "this is where the top is" and then it use that.20:04
larsksOkay.  I wanted it to work without having to set environment variables :)20:04
smosersure. it shoudl do that too20:05
smoserit did at least.20:05
larsksI will fix it up.20:05
smoseragain.. just so you're aware, i'm going to try to get a re-import done20:06
larsksSure.  Just ping me when you do that and I will fix the merge request.20:07
larskssmoser: rharper: i've just pushed new changes to that merge request.  (a) this squashes everything down to a single commit, and (b) this correctly excludes argparse from the requirements for python >= 2.7 and (c) this will use CLOUD_INIT_TOP_D in read-dependencies if it is set.20:18
harlowjalarsks do u know how many people use spacewalk21:02
harlowjawe have this code that i may just make into a real-clout-init-top-level-module21:03
larsksharlowja: I have no idea...21:03
harlowjadamn, redhat people supposed to know21:03
larsksharlowja: not my bailiwick :) Ask me about openstack...21:03
harlowjawhats openstack21:03
harlowjasounds weird21:03
larsksMmmm, pancakes...21:05
harlowjaok, i'll submit a spacewalk module21:05
harlowjai convinced myself21:05
harlowjasmoser did u push up to git with squished things21:05
harlowjaprobably shouldn't do much with git until u do that21:06
harlowjaotherwise git be screwy when i `git pull`21:06
=== psauxww is now known as er1k757

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!