The support of (user) meta-data injection will be significantly enhanced on July 25. This allows to have more flexibility to customize and configure generic cloud images on their first boot in Open Telekom Cloud.

File injections for passwords and hostnames have been replaced to leverage the new mechanism, so file injections no longer happen unless explicitly requested by the user. Our public images have been adjusted to accept the meta data from the meta data server.

This results in a small change on Linux and some more significant changes for Windows VMs; this document describes both how the user experience changes as well as how customers need to adapt their images if they are using private images rather than the public images provided by OTC. Running or rebooted VMs are not affected by this change; the meta-data injection only happens on the first boot of a newly created VM.

During the change deployment, there is a time window (Mon, Jul 25 16:00 to 18:30 CEST max), where newly deployed VMs may receive inconsistent meta data or may not be able to reach the meta data server at all, resulting in VMs that have no keys, password, hostname or other customer data injected resulting in the user not being able to log in to those VMs.

To avoid having to create and maintain dozens of images in a public cloud, a standard mechanism to configure and customize generic images in the cloud has been established. This mechanism consists of the cloud platform providing meta data (e.g. via an emulated floppy drive or a web server) to the booting VM where a piece of software gets started on the first boot to pick up the configuration and then act accordingly.

On OpenStack clouds, nova (the compute service) provides the meta data via the meta data service at http://169.254.169.254/ and Linux images built for the cloud use cloud-init to configure and customize the system accordingly.

When Open Telekom Cloud was released publicly in March 2016, the public Linux images did rely on cloud-init and meta data service (MDS) to retrieve the injected ssh key. The root password setting and hostname setting on the other hand was still done by a legacy mechanism using file injections. Also the web interface did not provide an interface for injecting custom user data (YAML) for full control; the workaround for this shortcoming was to inject files into the files into the /etc/cloud/cloud.cfg.d/ directory. On Windows, the password and hostname setting did rely completely on file injection.

The password and hostname setting on Linux are now done via configuration on the metadata server. The cloud-init in OTC's public Linux images has been adjusted to set the hostname received from the meta-data server. In addition, the customer can now provide up to 16k of additional user data (YAML) via the web interface ("service console") and via the nova command line parameter --user-data FILE which is transparently provided to the VM to retrieve from http://169.254.169.254/2009-04-04/user-data.

On Windows, the password and hostname setting and the keyboard configuration are now done using cloudbase-init; the Windows cousin of Linux cloud-init. File injection is still available, but only if requested explicitly by the user.

There are two areas in which this change affects you:

• If you are using Open Telekom Cloud public images, the user interface to set passwords changes.
• If you are using private images, you need to adjust the images.

If you are using the standard way of accessing Linux VMs via an injected SSH key, nothing changes for you. Also, the well-known username/password credentials (for local (noVNC) login only!) continue to work as emergency login mechanism.

If you are using the web interface (or otc command line) to set a password, you will however notice that the password setting field on the ECS VM creation page is gone. To set a password for a user in a Linux VM, you can use one of three modules from cloud-init; please review this cloud-init document.

1. The chpasswd module allows to set the (clear text) passwords for several users and also allows to prevent the need to change it on first login (expiration).

2. The password module will set the password of the default user to the provided clear text password. The example contains disabling expiration - not recommended.

3. The users module allows to configure users, including setting the password by hash. It also allows to set the per user sudo powers, ssh key injection etc.

Note that both password and chpasswd use plaintext passwords, which can be retrieved by any (unprivileged) local user of the VM by looking at the user-data from the MDS. So enabling expiration by default is not so bad after all. Note that the special string RANDOM can be used to have cloud-init generate a random password that gets posted to the console on boot-up. Please also note that indentation is essential for YAML and that there is no space between username and password in the chpasswd module.

The users module does provide a way to inject hashed passwords, so they are relatively secure if a good password is used. Please note that when using the users module and not explicitly listing the default user, the default user generation (with username linux on ImageFactory images) will be suppressed.

Generate the password hash for the users module with a command like this:

Change the Salt to a random alphanumeric string with at least 8 characters. When using the web interface to inject the user data, please be aware that opening "User Defined Configuration" will not only give access to the User Data Injection Field, but also create one file to be injected. You don't need it, click "delete" to remove this line.

We still recommend to use ssh keys to log in and to not change the ssh_pwauth setting which in our configs disallows password authentication via ssh. If you really need to allow password authentication via ssh, make sure you do not have clear text passwords easily accessible in MDS and you have changed the default password for the default user.

See the cloud-init documentation for more examples. cloud-init user data can also be used to inject and run scripts, install packages and/or package updates (package_upgrade: true), setting hostnames and DNS resolvers, registering with chef or puppet, adjust mount points, call a URL (phone home), injecting ssh keys, etc.

You can also pass user data when starting VMs via the API, e.g. via the nova command line when using the option --user-data FILE (as well as specifying meta data using the option --meta KEY=VALUE).

Password setting on Windows works differently than on Linux.

On the first boot, cloudbase-init always generates a random password. You actually need to provide an ssh key that is then used to store your password in encrypted form.

You can retrieve it by providing your private key to the web interface. It is recommended to generate a separate SSH key pair for the purpose of retrieving the passwords.

It is possible to get the encrypted password using the command nova get-password and then do some openssl magic to decrypt it.

Unlike on Linux, you don't need to use the "User Data Injection" field by selecting "User Defined Configuration" to have password handling. You can use it, of course, for other user data that you want to feed to cloudbase-init -- if you do, be aware that opening it also creates the first line for file injection that you need to delete if you don't want to inject a file.

You can also create a user with a password by injecting user-data:

Please replace USERNAME and PASSWORD with the desired settings. The user-data is again accessible to any local user of the VM, so beware of the security implications.

The public images from T-Systems' Image Factory received only one change: The setting of preserve_hostname was changed from true to false. If you have created a private image from one of our public Linux images or otherwise copied the configuration, we suggest you do the same change.

Note that we used the opportunity to clean up old public Linux images; due to the changes, these are no longer working perfectly. We keep them around as private images for debugging purposes though.

In case you have images without cloud-init, the password and hostname setting that previously magically worked will no longer do so. We recommend you consider enabling cloud-init. Modern linux distributions provide it right from their distribution repositories. For SLES11, you can use the home:garloff:OTC:cloudinit OBS repository.

Our public Windows images now all include cloudbase-init. If you have private images, they will likely not contain cloudbase-init. We recommend you install cloudbase-init. For your reference find our cloudbase-init configuration here:

The cloud-init enhancements make the usage of images on Open Telekom Cloud more flexible and brings it more in line with other cloud platforms. In the process, some legacy file injections could be cleaned up. This results in some changes on the user interface and images that you should be aware of.

The changes will take place on Jul 25, 16:00 to 18:30 CEST. Newly created VMs during this time slot may not receive meta-data which typically means that the user can not log in to these VMs. All other VMs are unaffected.