Fedora, CentOS contextualization

Product Support
1

I am probably missing something important, but I have troubles configuring contextualization for Fedora and CentOS. The documentation states that CentOS is expected to work correctly:

CentOS
Works correctly for cloud-init >= 0.7.4.

but this is definitely not my case.

For Fedora 23 (cloud-init-0.7.6-5.20140218bzr1060) I had to disable NetworkManager and use the static /etc/init.d/network-based configuration (I am OK with it), but there are still problems: firstly, cloud-init-local.service is run in parallel with /etc/init.d/network, which means that network initialization is often finished before the contextualization image is even read: 1311655 – cloud-init under OpenNebula works only after reboot. With some systemd magic described in the abovementioned bugzilla, it sets up networking correctly, but adds ssh keys to newly created “fedora” user only instead of root. Using cloud-init also adds about 20-25 seconds to the OS boot time. After that, the following warning is printed:

util.py[WARNING]: Getting data from <class 'cloudinit.sources.DataSourceOpenNebula.DataSourceOpenNebula'> failed

For CentOS 7 (cloud-init-0.7.5-6.el7) the situation is even worse. The cloud-init-local finishes, but cloud-init does not, and spills the following messages to the console:

url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [-3059/120s]: request error [('Connection aborted.', error(113, 'No route to host'))]

It looks like it thinks it is running under EC2. It sets up networking correctly (again, after modifying the dependencies in cloud-init-local.service and after disabling NetworkManager and using /etc/init.d/network instead), but then waits forever. Only after “systemctl stop cloud-init.service”, the .ssh/authorized_keys files are populated, again allowing access to the “fedora” user, not root.

I have also tried to remove the .ssh/authorized_keys file and reboot the VM, but after the reboot, it does not get recreated.

The documentation mentions that the contextualization file starts with #cloud-config. This is not the case for me - my context.sh looks like this:

cat /mnt/context.sh

# Context variables generated by OpenNebula
DISK_ID='1'
ETH0_DNS='dns1 dns2'
ETH0_GATEWAY='my-gw'
ETH0_GATEWAY6='my_gw6'
ETH0_IP='my_ip'
ETH0_IP6='my_ip6'
ETH0_MAC='02:f1:2b:c0:00:04'
ETH0_MASK='255.255.255.0'
ETH0_NETWORK='my_netaddr'
NETWORK='YES'
SSH_PUBLIC_KEY='ssh-rsa AA...nw== me@myhost1
ssh-rsa AA...KQ== me@myhost2
'
TARGET='hda'

Is there any comprehensive HOWTO on using cloud-init with OpenNebula and Fedora or CentOS VMs? Thanks!

2

Hi Yenya!

To make cloud-init work with OpenNebula we applied the attached patches:
sudoers.patch (61 Bytes)
DataSourceOpenNebula_074.patch (532 Bytes)
DataSourceOpenNebula_075.patch (89 Bytes)

The DataSourceOpenNebula_074.patch is for cloud-init 0.7.4 and the DataSourceOpenNebula_075.patch is for 0.7.5 one.
Apart from that there is no need in the following section in /etc/cloud/cloud.cfg file (otherwise the contextualization won’t work):
disable_ec2_metadata: True datasource_list: ['OpenNebula'] datasource: OpenNebula: dsmode: net parseuser: nobody

These steps have been successfully tested against pure SL 6.7 with cloud-init package 0.7.4. installed from EPEL repo.

3

We should probably delete the cloud-init section from our documentation. There was some effort to make cloud-init work with OpenNebula but there’s a huge problem with network configuration. Most other cloud/VM managers rely on DHCP for network configuration instead of static network configuration and cloud-init is not very friendly with that. We’ve tried to add some patches to make this network configuration work but seems that the projects don’t like them or are not interesting.

TL;DR - Use our context packages. CentOS packages may work in Fedora. If they don’t tell us.

4

OK, I have tried to use the one-context-4.10.0-1.noarch.rpm package from GitHub. There are several problems with it:

  • 99-execute-scripts probably contains a security hole with insecure temporary directory name (use mktemp -d for temporary directories instead of hard-coded names).

  • network is not set up during boot: according to “systemctl status vmcontext” the /etc/init.d/vmcontext is started during boot (and, for example, swap space on a volatile disk gets correctly activated by it), but the /etc/sysconfig/network-scripts/ifcfg-eth0 file is not created:

    systemctl status vmcontext

    vmcontext.service - LSB: OpenNebula contextualization script
    Loaded: loaded (/etc/rc.d/init.d/vmcontext)
    Active: active (exited) since Mon 2016-04-11 11:08:05 CEST; 37s ago
    Docs: man:systemd-sysv-generator(8)
    Process: 415 ExecStart=/etc/rc.d/init.d/vmcontext start (code=exited, status=0/SUCCESS)
    Apr 11 11:08:00 fedora23 systemd[1]: Starting LSB: OpenNebula contextualization script…
    Apr 11 11:08:00 fedora23 vmcontext[415]: /etc/rc.d/init.d/vmcontext: line 65: type: vmtoolsd: not found
    Apr 11 11:08:03 fedora23 vmcontext[415]: Restarting network (via systemctl): [ OK ]
    Apr 11 11:08:05 fedora23 systemd[1]: Started LSB: OpenNebula contextualization script.

    ls /etc/sysconfig/network-scripts/ifcfg-eth0

    ls: cannot access /etc/sysconfig/network-scripts/ifcfg-eth0: No such file or directory

  • when I run /etc/init.d/vmcontext start manually, the network configuration gets created (almost) as expected.

  • when the virtual network is set up to assign both IPv4 and IPv6 addresses, the IPv4 address from context.sh is ignored unless CONTEXT_FORCE_IPV4=yes is added to the context variables. I don’t think it is correct - when both addresses are provided by context.sh, both should be enabled.

  • when the IPv6 address is provided, the interface should not use IPv6 autoconfiguration. This can be done by adding IPV6_AUTOCONF=no to the /etc/sysconfig/network-scripts/ifcfg-eth0 file. The 00-network script should do that.

  • the vmcontext service should have an explicit dependency on the network.service, so that the configuration is created before the networking is started. Restarting /etc/init.d/network from the inside of “/etc/init.d/vmcontext” is rather ugly.

5

Further testing revealed that /etc/init.d/vmcontext tries to run vmtoolsd, because /dev/disk/by-id/CONTEXT does not exist. When I log in from the VNC session, the abovementioned symlink does exist, but is about 1.2 seconds newer than the start up time of /etc/init.d/vmcontext (taken from “systemctl status vmcontext”). I think vmcontext should be rewritten as a systemd unit file with proper dependencies.