openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

Just fyi, the cloud-init format 'spec' has something similar that bypasses
the file injection (which is a bad/insecure/incompatible concept that
needs to be gotten rid of imho) by having the following syntax it
understands:

http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc
/examples/cloud-config-user-groups.txt

Is there anyway a windows version of cloud-init could be done, either
ported, or patched, or a service like cloud-init could be added to windows
images (using a startup program in the windows image that could just be a
call-out to a python interpreter or something different...). In the linux
image world it is pretty common to have a version of cloud-init be
bootstrapped into the image so it would seem like windows could be similar.

On 10/31/12 6:09 PM, "Lars Kellogg-Stedman" <lars@xxxxxxxxxxxxxxxx> wrote:

>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                        |
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp