ys__ | Hi I am trying to use cloudinit to reset password, but not sure if it is doable. | 18:38 |
---|---|---|
ys__ | My idea is running a user script on every boot to query a url. If the response is True, then rm sem/config-set_passwords file. After reboot vm, the password will be reset to original password | 18:39 |
ys__ | wondering will it work? | 18:40 |
rharper | ys__: if you're going to query a URL to determine if you want to reset a passwd; you might avoid using the cloud-config entirely and just have your script run; and modify the passwd itself | 19:27 |
ys__ | rharper: yes you are right, it might be cleaner if just use a script to reset the password after URL query | 19:44 |
ys__ | rharper: BTW, I saw a file cloud-config.txt in /var/lib/cloud, is it retrieved from metadata service endpoint (169.254.169.254) ? | 19:50 |
ys__ | I tried to rm this file along with user-data.txt and user-data.txt.i in the same dir, then reboot the vm, cloudinit will re-created those files again. Is it retrieved from 169.254.169.254 this time? or it was cached somewhere? | 19:52 |
rharper | it's the combined cloud-config that was sent to the instance from the datasource used; depending on the cloud (and datasource) it may come from a metadata service url (like the one you see) | 19:53 |
ys__ | the reason i ask is because after I create the vm, I manually updated userdata in openstack and curl 169.254.169.254 reflected the update. | 19:53 |
ys__ | Then I removed those files, reboot the vm, however cloud init re-created those files with original user-data | 19:54 |
rharper | different types of configuration is applied either once per instance, once per boot, or always, depending on the type | 19:54 |
rharper | cloud-init does not (yet) dynamically watch metadata service and automatically reapply if the configuration has changed | 19:54 |
ys__ | ok | 19:54 |
rharper | if you want to re-run cloud-init on the same instance with new user-data, you'll need to do somethign like: rm -rf /var/lib/cloud/* and reboot; this wipes out the per-instance data, and cloud-init will run like firstboot | 19:55 |
rharper | much of the data consumed is cached in /var/lib/cloud/instances/<instance-id>/* | 19:56 |
ys__ | yes i actually rm /var/lib/cloud/instances/<instance-id>/cloud-config.txt, user-data.txt and user-data.txt.i (any file with userdata) | 19:56 |
ys__ | but still re-created with original user-data (guess didn't query 169.254.169.254) | 19:57 |
rharper | you'll need to remove anything under /var/lib/cloud/ | 19:57 |
rharper | if it finds the instance-id of an instance matches an existing directory in /var/lib/cloud/instances/ then it will assume it can use the cache and reloads it from the pickled object file | 19:58 |
rharper | I've got to step out for a bit, but blackboxsw is still here and can help answer any more questions you might have | 19:59 |
ys__ | ok thanks | 19:59 |
blackboxsw | +1 | 19:59 |
blackboxsw | yeah generally for clean reboot testing and validation we 'sudo rm -rf /var/log/cloud-init* /var/lib/cloud; sudo reboot' .. In this case, cloud-init will perform all initialization as if it were greenfield (unbooted) install and it will query your metadata service to pull all updated data | 20:02 |
ys__ | yeah, i didn't realize there is a pickled obj file... | 20:03 |
ys__ | i thought if cloudinit found some missing file, it will back to metadata service and retrieve the data. Now it make sense. | 20:04 |
ys__ | thanks! | 20:04 |
* blackboxsw also wondered initially about also attempting something like 'sudo cloud-init single --name cc_users_groups --frequency always since the user password was configured via userdata, but I *think* that might run into the caching problem too. | 20:09 | |
ys__ | blackboxsw: will that reset user's password (to default) on every boot if frequency always? | 20:15 |
blackboxsw | that'd be something that would have to be manually run each time I believe (it doesn't permanently designate frequency == always for the module). It just allows the module to look at the existing cache I thought and determine if the module was already run. I'll test now to confirm. | 20:17 |
blackboxsw | ys__: validated that even --frequency always hits the cache despite changed user-data. only fully proven approach is to rm -rf /var/lib/cloud in that case currently. | 20:56 |
ys__ | blackboxsw: Thanks. I guess best way i can do currently is to use a user script to query a url and rely on another script to reset password. | 21:00 |
blackboxsw | I like the idea of ignoring the cache with some of these "cloud-init single --frequency always runs" I'll look at how tough that would be to implement | 21:00 |
blackboxsw | but yeah probably rely on a script to reset password for the time being | 21:01 |
ys__ | ok thanks | 21:01 |
blackboxsw | ok just integrated cloud-init analyze subcommand into cloudinit.cmd.main http://pastebin.ubuntu.com/25272516/ | 21:36 |
blackboxsw | took a bit of restructuring on this today to allow an existing standalone tool (cloudinit-analyze) to be called as a subcommand under cloud-init | 21:37 |
blackboxsw | but it'll set a good precendent (once we review/agree) for pulling other tools into the fold | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!