| kholkina | dpb1 hi! do you know an answer for my question published yesterday? | 08:42 |
|---|---|---|
| kholkina | cannot find full logs for this channel | 08:43 |
| dpb1 | kholkina: perhaps in a few more hours. yesterday was a US holiday, most of the contributers were off. | 10:22 |
| === shardy is now known as shardy_lunch | ||
| === shardy_lunch is now known as shardy | ||
| rharper | kholkina: w.r.t user-data; cloud-init does not currently watch the metadata url for changes. Unless your instance-id changes, cloud-init does not re-read the metadata and take action. Adding a scripts_user/always won't help if cloud-init has already booted and initialized the instance. Do you have any background on what you're trying to do? | 14:16 |
| kholkina | rharper: I want to have an ability to get (and execute) updated userdata on instance reboot. What is the better way to do this? | 14:23 |
| rharper | just a single key or you really want the whole instance to be reconfigured; I don't know all of what you have in your user-data | 14:23 |
| rharper | any background about the data change? are you adding a user or installing a package; things that cloud-init normally does during boot? | 14:25 |
| kholkina | just a single key in the section 'cloud-config' | 14:25 |
| kholkina | now I'm trying to manipulate ssh-keys | 14:26 |
| rharper | looking to add a key, or modify existing ones? | 14:28 |
| smoser | other question is "host" or "user/public" keys | 14:29 |
| kholkina | modify keys in 'default_user/.ssh/authorized_keys' | 14:29 |
| smoser | kholkina: right. so for now, cloud-init will only do that once per instance. you could possibly change something to make it do it every boot, but it really only appends keys. | 14:33 |
| kholkina | smoser: Yes, I've found that it's possible only to add new keys on reboot. But I need to delete some files from /var/lib/cloud to do this. So would be nice if you can suggest better solution to get an updated data | 14:39 |
| smoser | kholkina: well, you could change the frequency of 'ssh' config module | 14:41 |
| smoser | but doing so would have the unwanted side affect of re-generating ssh keys for the host | 14:41 |
| smoser | kholkina: i dont have a good suggesiton for you at the moment. :-( | 14:43 |
| smoser | we do plan to make cloud-init more dynamic in this regard, but nothing right now/ | 14:43 |
| smoser | what cloud is this? | 14:43 |
| kholkina | openstack | 14:44 |
| smoser | yeah, k'm sorry. i dont have a good answer for you. :-( | 14:48 |
| kholkina | do I need to remove a cache or it will work just with [ssh, always] in cloud.cfg? | 14:49 |
| rharper | I kind of think that you don't want to have it regen the host keys; might be better to watch the metadata URL yourself and read-and-apply the change outside of cloud-init for now | 14:51 |
| rharper | smoser: for cached openstack, re-invoking cloud-init single wouldn't have it re-read metadata URL would it? | 14:53 |
| smoser | no, it wont. | 14:53 |
| rharper | if you removed the obj cache, it might, right ? | 14:54 |
| smoser | well, but then it would probably mostly think it was a new isntance. | 14:54 |
| rharper | hrm, yeah | 14:54 |
| smoser | an dif that wasnt the behavior it did have, then i wouldnt want to tell someone to rely on that | 14:54 |
| rharper | yeah | 14:55 |
| dojordan | @blackboxsw - question about the dhcp-discovery. I am getting a permission denied on the temp dir in /run/cloud-init when calling dhclient, but there is a comment in the method saying to use /var/tmp since /run/cloud-init is mounted noexcec... Not really sure why its using the wrong directory: Command: ['/run/cloud-init/tmp/cloud-init-dhcp-zz0g2p4_/dhclient', '-1', '-v', '-lf', '/run/cloud-init/tmp/cloud-init-dhcp-zz0g2p4_/dhc | 20:20 |
| meetingology | dojordan: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. | 20:20 |
| rharper | wow, uhm, thanks? meetingology ? | 20:27 |
| nacc | rharper: did someone forget to stop a meeting? | 20:27 |
| rharper | possibly | 20:27 |
| rharper | that'd be blackboxsw | 20:27 |
| * nacc thought the bot didn't listen outside of meetings | 20:27 | |
| nacc | #endmeeting | 20:27 |
| * nacc may not have perm if they didn't start it | 20:28 | |
| rharper | right | 20:28 |
| rharper | I think blackboxsw might need to do that | 20:28 |
| rharper | prolly forgot since open hours last week, I suspect | 20:28 |
| nacc | although i thought the bot changed the topic too, but maybe i'm wrong | 20:28 |
| nacc | yeah, likely | 20:28 |
| rharper | yeah, this is the same instance as the other ubuntu channels, so maybe blackboxsw has it tweaked some | 20:28 |
| dojordan | dumb question, but cloud-init runs as root, correct? if so, how come when mkdtemp runs as root it returns /run/cloud-init even though it is mounted noexec? | 21:41 |
| rharper | dojordan: two things going on; 1) systemd makes /tmp and /var/tmp unusable as the systemd tmp cleaning service can nuke those at any time; so cloud-init moved it's "tmp" space under a path cloud-init owns (/run/cloud-init) 2) specifically around the dhclient and tmp dirs is related to apparmor policy around dhclient | 21:50 |
| dojordan | 2) makes sense, and I believe I am running into that. However, the temp_utils.py:_tempfile_dir_arg first checks if _TMPDIR has already been set and if so returns it | 21:52 |
| dojordan | therefore it does not honor the needs_exe if it is not the first invocation of the function, right? | 21:52 |
| rharper | lemme look at the code | 21:53 |
| rharper | oh, I see | 21:53 |
| rharper | if a non-exec user calls it first, the second caller cannot reset it | 21:54 |
| rharper | that's bit naughtly; | 21:54 |
| rharper | well, one hammer is to fetch the global and reset _TMPDIR = None to recall it; but that seems wrong | 21:55 |
| dojordan | what's the point of the global | 21:55 |
| rharper | makes a singleton | 21:55 |
| dojordan | maybe im missing something | 21:55 |
| rharper | once we've figured out a TMPDIR, we just keep reusing it | 21:55 |
| rharper | we don't need a per-call different tmp directory | 21:55 |
| rharper | just need to find one tmpdir with the required features and they all callers use that one | 21:56 |
| dojordan | unless we have an needs_exe=False then needs_exe=True | 21:56 |
| rharper | yeah, that seems like an issue; I suspect if your datasource is not running local, it's request to have a tmpdir with needs_exec set isn't the first one; it seems like trouble to re-issue on (if it's currently non-empty) | 21:57 |
| rharper | since the EC2 datasource was moved to run at localtime, it is likely a first user of that and gets to set the needs_exec=True first; | 21:58 |
| dojordan | what's weird is it is running local but i guess there must be an earlier call still | 21:58 |
| rharper | it seems so | 21:59 |
| rharper | azure's OpenSSLManager uses mkdtmp | 22:00 |
| dojordan | yup, just found that | 22:00 |
| dojordan | thoughts on best fix? one option is looks at needs_exe first. If it is true then just use the _EXE_ROOT_TMPDIR | 22:02 |
| rharper | I'm not sure yet | 22:03 |
| rharper | that's one way; but I | 22:03 |
| rharper | I | 22:03 |
| rharper | bah | 22:03 |
| rharper | I | 22:03 |
| dojordan | haha | 22:04 |
| rharper | i'm somewhat concerned with changing the global if the dir is populated; | 22:04 |
| dojordan | my thought was not to change the global | 22:04 |
| dojordan | since the _EXE_ROOT_TMPDIR is static anyway | 22:04 |
| rharper | right; one could just return the different directory (assuming it exists) | 22:04 |
| rharper | not clear if that could cause confusion w.r.t where a callers files are | 22:05 |
| dojordan | but the only way to guarantee one directory then is always use the exe root one, which seems wrong too | 22:08 |
| blackboxsw | #endmeeting | 22:09 |
| rharper | yay blackboxsw has returned | 22:09 |
| blackboxsw | sorry was afk for a kiddo dr checkup. reading scroll back | 22:10 |
| rharper | dojordan: I *think* it could be OK for the root case to use the need_exec to pick the path it returns, despite what's set in the global | 22:10 |
| blackboxsw | but looks like endmeeting didn't close anything ( and I thought Ihad already posted the closing logs from last meeting last week at cloud-init.github.io | 22:10 |
| rharper | blackboxsw: yeah, no idea; maybe meetingology just needs a kick in the pid | 22:11 |
| blackboxsw | will ping in #meetingology channel on that, not sure why it responded to that earlier message, all cmds should start with a # | 22:12 |
| rharper | hehe | 22:13 |
| blackboxsw | testing in a side channel, any command that starts with @ also seems to get parsed by meetinology | 22:15 |
| rharper | hehe | 22:20 |
| dojordan | @blackboxsw, I am testing out the ephemeral ipv4 stuff now, but for some reason broadcast address is not in the lease file. any thoughts? | 23:19 |
| rharper | dojordan: is the netmask included? if so you can derive broadcast IIRC | 23:27 |
| dojordan | okay cool. that was my backup plan :) | 23:28 |
| dojordan | do I apply the mask to the fixed address or the router to get the broadcast address? | 23:29 |
| dojordan | i guess fixed is probably more reliable | 23:29 |
| blackboxsw | hrm, I thought we had a helper function for deriving that broadcast addr | 23:33 |
| blackboxsw | :w | 23:33 |
| * blackboxsw checks around | 23:34 | |
| blackboxsw | nah was net_prefix_to_ipv4_mask and it's ilk in cloudinit/net/network_state.py | 23:40 |
| blackboxsw | I thought I saw a discussion on one branch that discussed potentially writing a utility to do that calculation. | 23:40 |
| blackboxsw | if a helper function is writting dojordan to calculate broadcast, I guess I'd like to see if live in cloudinit/net/network_state.py like the other net-related helper funcs | 23:42 |
| blackboxsw | if a helper function is written* | 23:43 |
| dojordan | cool, i'll put it there | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!