/srv/irclogs.ubuntu.com/2017/08/08/#cloud-init.txt

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 password18:39
ys__wondering will it work?18:40
rharperys__: 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  itself19:27
ys__rharper: yes you are right, it might be cleaner if just use a script to reset the password after URL query19: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
rharperit'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-data19:54
rharperdifferent types of configuration is applied either once per instance, once per boot, or always, depending on the type19:54
rharpercloud-init does not (yet) dynamically watch metadata service and automatically reapply if the configuration has changed19:54
ys__ok19:54
rharperif 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 firstboot19:55
rharpermuch 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
rharperyou'll need to remove anything under /var/lib/cloud/19:57
rharperif 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 file19:58
rharperI've got to step out for a bit, but blackboxsw is still here and can help answer any more questions you might have19:59
ys__ok thanks19:59
blackboxsw+119:59
blackboxswyeah 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 data20: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
blackboxswthat'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
blackboxswys__: 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
blackboxswI 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 implement21:00
blackboxswbut yeah probably rely on a script to reset password for the time being21:01
ys__ok thanks21:01
blackboxswok just integrated cloud-init analyze subcommand into cloudinit.cmd.main http://pastebin.ubuntu.com/25272516/21:36
blackboxswtook a  bit of restructuring on this today to allow an existing standalone tool (cloudinit-analyze)  to be called as a subcommand under cloud-init21:37
blackboxswbut it'll set a good precendent (once we review/agree) for pulling other tools into the fold21:37

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