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" <l...@seas.harvard.edu> 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 <l...@seas.harvard.edu> | >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@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
