openstack team mailing list archive

[Lars Kellogg-Stedman <lars@xxxxxxxxxxxxxxxx>]

TL;DR: The way OpenStack handles the adminPass attribute during
metadata injection is not useful on operating systems without an
/etc/passwd and /etc/shadow.  I would like to make the adminPass value
available on a Windows instance, and this is my proposal for how to do
it.

I've been putting together a Windows 2008 server image for deploying
in our OpenStack environment.  I started by setting it up to act just
like our Linux images:

- It has sshd running as a service via Cygwin
- It runs a script at startup to pull an ssh key from the 
  metadata server for the Administrator account.

This works great!  But I've had some push-back from folks who argue
that this process won't be familiar to a typical Windows
administrator, so I started trying to figure how to get an
administrator password either (a) into the instance from the person
creating it, or (b) back to the person creating the instance after
generating the password.

(a) is relatively easy to do via the user-data attribute, and I have a
prototype of that working.  However...

One of my colleagues mention that there was some mechanism for
injecting passwords into instances -- which sounds perfect.  Based on
my efforts in #openstack, it appears that very few people take
advantage of this feature or even know how it operates, so I went
diving through the code and eventually found myself in
nova/virt/disk/api.py, where I discovered that even with
config_drive=True, nova will attempt to copy /etc/passwd and
/etc/shadow (which don't exist) off the config drive to modify them
locally.  This obviously fails, leaving the admin password
inaccessible.

I would like to propose that if config_drive=True, that the admin
password simply get written into a file, where it could be used by
operating systems without an /etc/passwd or /etc/shadow file.  

If this sounds like a good idea, I'll work up a patch.  It seems that
for this to work, inject_data needs to know whether or not it's
targeting a config_drive or an actual partition...and so does
inject_data_into_fs.  Maybe something like:

In virt/libvirt/connection.py:

    disk.inject_data(injection_path,
                     key, net, metadata, admin_pass, files,
                     partition=target_partition,
                     use_cow=FLAGS.use_cow_images,
                     config_drive=config_drive)

And in virt/disk/api.py:

    def inject_data(image,
                    key=None, net=None, metadata=None, admin_password=None,
                    files=None, partition=None, use_cow=False, config_drive=False):

    ...
        inject_data_into_fs(img.mount_dir,
                        key, net, metadata, admin_password, files,
                        config_drive=False)
    ...

    def inject_data_into_fs(fs, key, net, metadata, admin_password, files,
                        config_drive=False):
    ...
    if admin_password:
        if config_drive:
            _inject_admin_password_as_file_into_fs(admin_password, fs)
        else:
            _inject_admin_password_into_fs(admin_password, fs)

Thoughts?

-- 
Lars Kellogg-Stedman <lars@xxxxxxxxxxxxxxxx>  |
Senior Technologist                           | http://ac.seas.harvard.edu/
Academic Computing                            | http://code.seas.harvard.edu/
Harvard School of Engineering                 |
  and Applied Sciences                        |