[rhos-list] cloud-init configuration for ssh access

[Steven Dake]

On 11/01/2013 04:58 AM, Perry Myers wrote:
> On 10/31/2013 04:49 PM, David Raddatz wrote:
>> A quick post-mortem on this issue and I wanted to share what we learned (or "I" learned anyway) in case it avoids problems for others...
>>
>> While I was apparently following the docs by "just install cloud-init on your VM image", while working with Lars we discovered if you reboot your image after installing cloud-init, it will create some files/directories in /var/lib/cloud which will then prevent the instance from allowing ssh to work (my Permission denied issue I was seeing).
>>
>> For example, doing the following:
>> - create VM and install RHEL 6.4 and set up with other files/software
>> - install/configure cloud-init on VM
>> - reboot VM (just to make sure it still boots)
>> - shutdown VM
>> - run virt-sysprep on image (per recommendation in docs)
>> - upload to glance and launch instance using the defined keypair
>> - trying to use ssh -i with the same keypair results in Permission denied
>>
>> Whereas, doing the following:
>> - create VM and install RHEL 6.4 and set up with other files/software
>> - install/configure cloud-init on VM
>> - shutdown VM
>> - run virt-sysprep on image (per recommendation in docs)
>> - upload to glance and launch instance using the defined keypair
>> - trying to use ssh -i with the same keypair Works! No password prompt (as expected)
>>
>> Not rebooting the VM allowed the ssh to work as the /var/lib/cloud directory was empty when it was shutdown.
>>
>> Not sure if this is a doc issue (to warn people NOT to reboot the VM after cloud-init installation/configuration) or a bug (which Lars was going to investigate a little) but thought it was worth a quick email to warn folks about.
>>
>> Thanks again to Lars for his assistance on this,
> Interesting.  Lars/Steve, is this a bug or just a docs issue do you think?
>
> Perry

Perry,

The tl;dr version is the code is working as intended.  Recommend more docs.

The cloud-init code is designed to only run the cloud config modules 
once by default.  Modules can be configured to "run-always" with an 
optional override configurable per module.  Cloud-init places locks in 
the /var/lib/cloud/* directories to prevent modules that have already 
run from running on the next boot.

If the boot process fails in some way (eg the metadata service is 
unavailable) the modules still run, and locks are still created.

The rationale is that if you have physical storage connected to the 
virtual machine, it doesn't make sense to run the configuration that the 
cloud config provides on each fresh reboot of the vm since it could at 
worse confuse/break the operating system's existing storage or at best 
result in slower boot cycles.

One possible improvement that could be considered upstream is to record 
those locks only on successful module executions.  I believe that would 
solve the particular problem Lars pointed out in a followup email.  
Another possibility is to specify run-always in the cloudconfig, but 
this may result in unintended consequences as described previously.

Regards
-steve

> _______________________________________________
> rhos-list mailing list
> rhos-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhos-list