=== cpaelzer__ is now known as cpaelzer
catphishwhat does public_ssh_keys in the metadata do?08:51
catphishi think i'll just not worry about meta-data keys unless i find i actually need them09:04
otubo(sorry I was just disconnected from irc, will paste the messages again)09:37
otuboOdd_Bloke: hey, thanks a lot for the reivew! Regarding the commit message, I guess it is on the PR itself? it too big? Or do you need more details?09:37
=== hjensas__ is now known as hjensas
smoserc-i runs as root on travis ?12:46
catphishquick question - what's the correct way to have cloud-init only run once, specifically once my config has applied successfully i don't want subsequent boots to waste time looking for an updated configuration from the network13:21
catphishideally i'd want this to be reversible so that if a machine is cloned, i could easily trigger it to run again, but only in that specific case13:21
anankeperhaps disable the systemd services as part of runcmd module13:23
anankethough I wonder if 'waste time' is actually a noticable problem13:25
otuboOdd_Bloke: OH, just noticed you might be referring to the PR template. Danm, sorry, my PR is old and we didn't have it back then. I'm gonna work on that.13:26
catphishactually, thinking about it, it would be even better if my datasource itself could compare the UUID of the machine with the one from the previous run, and return a dummy data set if they match13:26
catphishananke: well because my datasource is network based, i don't really want subsequent boots to hang if there's a network problem, and the process of doing the network based config does delay the boot a little even when it's working correctly13:27
catphishi'll see if i can have my datasource do the work itself and compare the UUID from the BIOS with the one from the last run13:28
smosercatphish: what you're describing is basically how it works.13:36
smoseryou could say specifically which datasource your're' talking about13:38
smoserbut ec2, openstack (on intel/kvm) and others do that. (check_instance_id is what determines "is this new").13:39
minimalHi folks. Is there any agreement on whether strings in user-data (i.e. YAML) should be single-quoted or double-quoted? Is see varying uses of both in the docs and in the testcases13:41
catphishsmoser: that's ideal, do they pull the instance id from the bios for the check?13:42
catphishsmoser: sorry, it's *my* datasource, i haven't pushed it yet13:42
catphishi'll go check check_instance_id anyway, thanks!13:43
smoserthey compare the cached instance id to what is exposed by the platform in dmi data.13:43
catphishperfect, that's exactly what i want do do, i'll go and find that code13:43
smoserbuton those platforms the platform states taht instance-id == <that-value>13:43
smoserwe're not just comparing serial number or some other field.13:44
catphishi'm not sure i understand, but perhaps i will if i read the code13:45
smoserthe platform (ec2 and openstack) state that they expose the instance-id through dmi13:45
catphishlooks like check_instance_id will do what i want, in openstack it calls instance_id_matches_system_uuid13:49
catphishdigitalocean calls: instance_id_matches_system_uuid(self.get_instance_id(), 'system-serial-number') which is close to what i actually want, thank you!13:51
Odd_Blokeotubo: Yeah, only asking because I want to be sure that the words attached to your name in the squash commit are the ones you would choose. :)14:18
otuboOdd_Bloke: ACK on the text :-)14:20
Odd_Blokeminimal: There is not, to my knowledge.14:25
Odd_BlokeBoth quote types are valid and have different uses (per the YAML spec: https://yaml.org/spec/1.2/spec.html#id2786942), primarily to do with escaping.14:27
Odd_Bloke(But it sounds to me like single-quoted for preference, and double-quoted if necessary makes sense.)14:27
minimalOdd_Bloke: ok. Am working on a PR to revise/correct docs for a particular issue where a value needs to be quoted and thought it would make sense for all relevant testcases and docs to use the same notation.14:29
minimalOne of the examples I want to correct is macaddress value, it must be quoted (either single or double) but the docs don't indicate this and there's only 1 testcase where its quoted (single in this case). So I need to decide whether to specify single or double in my PR14:32
minimalSo I'll go with single quote then.14:33
Odd_BlokeYeah, that sounds good to me!14:34
minimalhave found quite a few minor user-data issues that the current testcases don't pick up on14:35
otuboOdd_Bloke: also, is it ok to "Update branch" from the Github interface? Does it generate garbage upon merge?14:37
minimalanother question, is regarding the User & Groups module, the setting "inactive" doesn't make sense. The docs state: "Mark user inactive. Default: false"14:37
Odd_Blokeotubo: We'll do it if necessary before merge, but it's totally fine for you to do too.14:37
minimalHowever according to "useradd" docs for "--inactive" it is used for "The number of days after a password expires until the account is permanently disabled." which is not the same thing14:38
Odd_Blokeminimal: Yeah, that seems like a clear issue: it _looks_ like the code will currently allow you to pass a string and it will DTRT, so that may just be a documentation issue at least?14:41
minimalI mean the c-i docs define inactive as a boolean whereas the code when creating the user for most OSes calls "useradd --inactive" with no value which means the value in /etc/default/useradd is used, which is "-1" which means disable the inactive feature - end result, defining inactive: true in user-data in reality does not use the inactive feature14:43
minimaltypically the useradd/usermod inactive feature takes a value for numeber of days14:44
minimalOdd_Bloke: yeah I'd expect the user-data inactive to take days as a param. However FreeBSD maps this to "pw useradd -E" and its not clear if for FreeBSD if this is a boolean or takes a number as well (only online pw man I've found doesn't document -E)14:51
minimalOdd_Bloke: just retested to double check my notes - inactive: '5' works but inactive: 5 (without any quotes) does nothing15:05
Odd_Blokeminimal: Right, the code checks specifically for a string; if the value is one then it will add `["--option", "value"]` to the command line, if it _isn't_ a string (i.e. a bool as documented, or an int as you just tried) then it adds only ["--option"].15:07
Odd_BlokeThat int fact is definitely going to catch people out, no matter how we change the docs.15:07
minimalWell my concern is I don't know how FreeBSD acts and so if I update the docs (and testcases) to expect a string with a number of days will it break FreeBSD?15:08
minimalalso the only testcase I could find that specified inactive doesn't actually check/simulate /etc/shadow to verify if it acts as expected15:09
Odd_Blokehttps://github.com/canonical/cloud-init/blob/master/cloudinit/distros/__init__.py#L473-L484 is the code I'm referring to, FAOD.15:09
Odd_BlokeYeah, that's a great Q about BSD too.15:09
minimalyeah, __init__.py is used for *most* OSes but not BSD, freebsd.py passes "-E" to "pw user" instead15:10
Odd_BlokeI can't find -E but https://www.freebsd.org/cgi/man.cgi?pw(8) does have `-e`: "Set the account's expiration date."15:11
minimalyeah, same page I found. That's why I couldn't work out what -E does (or is it a typo?)15:12
Odd_BlokeIt looks like -E was introduced when FreeBSD support first landed in 2013, so it could either be a typo or something that has changed since then.15:12
Odd_Blokemeena: Goneri: Are either of you able to weigh in?15:13
Odd_Blokeminimal: (They're our two most active *BSD contributors. :)15:13
* Goneri reads15:13
minimalif its meant to be "-e" then we're in even more of a bind as that takes a date string rather than a number of days15:13
minimalhmm, it does take a number of days if "+" prefixed.......15:14
Gonerito disable an account we should probably do something like that: pw mod user root -w no15:19
GoneriI remember on BSD you've got a case where the account is disabled and another one where it's just the password. I cannot really elaborate on the, but I remember it was rather different comparing with Linux.15:21
Gonerialso on NetBSD and OpenBSD, you cannot enable/disable a password. You instead need to nuke the password and to restore the PW auth, you need to reset a new PW.15:23
minimalwell I guess that's the underlying question - what is the "inactive" setting supposed to achieve? Is it meant to disable an account (in which case current functionality does not achieve that - the useradd --inactive flag and the underlying /etc/shadow field control "The number of days after a password has expired during which the password should still be accepted"15:24
minimaldisabling password is expected to be controlled by "lock_passwd" user-data setting15:25
GoneriGood question, my understanding is that we just disable the pw auth. We can face some surprise otherwise, fFor instance if we disable the root password, and we actually really kill it.15:26
minimalGoneri: I mean there are 2 distinct user-data settings for users: "inactive" and "lock_passwd", what you're describing should be controlled by "lock_passwd"15:27
Goneriit's more a question for the core team.15:27
Goneriwhat is the meaning of the inactive flag15:27
Goneriand we will probably need to audit the current code base, to ensure we match the expectation.15:28
minimalI expect these options were created by looking at the various options that useradd and usermod take and mapping to them15:29
minimalso useradd has an "--inactive" option and usermod has a "--lock" option (this just puts a "!" in front of the password)15:30
minimallocking account for useradd/usermod is controlled by "--expiredate" which maps to user-data "expiredate"15:31
minimalOdd_Bloke: so I think the current situation is that for user-data "inactive" the FreeBSD code should use "-e" instead of "-E" and it should accept a string containing a number of days and then map that to calling "pw useradd -e +VALUEd"15:34
minimalwith this in mind I can update the docs to indicate that "inactive" takes a string of number of days and someone (trying not to volunteer myself ;-)) can update the current testcase that specifies "inactive" to actually also simulate /etc/shadow file and check that the value is placed in there correctly15:36
minimalthere's no schema defined currently in the cc_users_group.py file so nothing to fix in that15:43
GoneriI'm glad we've got a volonter15:43
Odd_BlokeIn terms of 'what is the "inactive" setting supposed to achieve?', it's intended to allow users to specify `--inactive <value>` to the useradd call that happens for this user; our docs (and behaviour) should be aligned with `--inactive`s actual interface and behaviour.15:57
Odd_Bloke"I expect these options were created by looking at the various options that useradd and usermod take and mapping to them" <-- aha, yep, exactly that15:57
minimalI'll revise the description for "inactive" to reflect the reality16:00
Odd_Blokehttps://www.freebsd.org/cgi/man.cgi?query=pw&apropos=0&sektion=8&manpath=FreeBSD+9.3-RELEASE+and+Ports&arch=default&format=html (note this is for FreeBSD from ~2013) also does not mention -E, so I think that must just be a bug?16:02
Odd_BlokeGoneri: Do you know(/can you check) if `-E` will work at all with `pw useradd`?16:02
minimalBTW there's no user-data setting for defining a user's password expiry date. "expiredate" controls when the account is disabled, not when the password expires.16:12
minimalI guess because useradd/usermod don't appear to have options to control this (it managed by /etc/default/useradd and the user's /etc/shadow entry)16:14
GoneriOdd_Bloke, the flag does not exist.16:40
=== ijohnson is now known as ijohnson|lunch
Odd_Blokeminimal: So given ^, we may also want to document that the option does not work for FreeBSD.17:37
meenawell, crap17:40
meenacan we just outright reject it on (Free?)BSD?17:41
blackboxswparide: I approved https://github.com/canonical/cloud-init/pull/576 for this iteration as I think we can address the cpick issue when we next hit it if we have a need to test locally during our next release freeze. rharper is there still something that you wanted to block for this pass on bddeb?17:48
=== ijohnson|lunch is now known as ijohnson
minimalOdd_Bloke: if freebsd.py is changed to use "-e +DAYSd" then it should work as well18:03
Odd_BlokeYeah, that would work.  A bit of me wonders if we should allow FreeBSD users to pass whatever they want to `-e` (i.e. expect them to pass +2d if that's what they mean), so that they aren't restricted to only using the subset of expiration functionality that's supported on Linux.18:08
Odd_BlokeBut then it means that user config is less portable between Linux and BSD, which is also less than ideal.18:09
Odd_BlokeI suppose that if someone wants some of the BSD-specific functionality then they can always use a runcmd instead.18:10
rharperblackboxsw: no; I'm fine with bddeb18:17
johnsonshiOdd_Bloke blackboxsw: Hi folks, I'm looking to get https://github.com/canonical/cloud-init/pull/594 in by the next SRU. The PR adds "report_failure" functionality (description in the PR). The changes in that PR are fairly short (mostly changes in DataSourceAzure.py and the azure.py helper). Most of the lengthy additions comes from additional UTs I added for the report failure functionality.18:48
blackboxswthanks rharper.18:48
blackboxswjohnsonshi: excellent. we talked about reviewing this PR at today's standup meeting.  So, we expect to close it out shortly and we'll make sure it's in for the next SRU.18:49
johnsonshiI've performed deployment tests to ensure that (1) there are no regressions, and (2) that the report failure functionality works. Also added lots of UTs covering each possible case. I think the PR should be ready now :)18:49
blackboxswwhich I think is before end of year.18:49
johnsonshiblackboxsw: Thanks!18:49
=== MAbeeTT_ is now known as MAbeeTT

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