Cloud-init has two stages that probe/discover a datasource (cloud-platform) and obtain information on that. They are 'local' and 'network'. The local phase is guaranteed to run before system networking comes up and can read networking configuration from the datasource.
For further documentation see http://cloudinit.readthedocs.io/en/latest/topics/boot.html Some cloud platforms provide network configuration information on a network resource. Thus, in order to get this network information, cloud-init has to configure some networking (ipv4 link local on DigitalOcean, dhcp on EC2) to get information. When it does this, it tears down the ephemeral networking that it set up, writes the system configuration and lets the system bring up the persistent/complete network info. EC2's network based metadata service (available on http://169.254.169.254) provides network information. In order to get a response from the meta-data service, the source address of request must be the address that is returned in a dhcpv4 request. The requirement is then to to do a dhcp request on a given network device. Rather than writing our own dhcp client, we chose to do this by utilizing dhclient and executing it in a way that it did not invoke hooks or otherwise have side affects on the system. In order to do that, we invoke like dhclient -1 -v -lf /tmp/my.leases -sf /bin/true That is to control where the lease_file is written and to not execute any scripts. Our invocation of dhclient causes issues with the default Ubuntu shipped dhclient apparmor profile as it does not allow execution of /bin/true. The solution we employed was to skip app armor constraint by copying /sbin/dhclient to a temporary file and execute it there. Other options were to * disable apparmor temporarily (which would leave scary warning messages in the log). * ship a wrapper around dhclient and a apparmor profile. Our most recent issue with the solution we used is bug 1717627. That was a result of using /run/cloud-init which is mounted noexec rather than /tmp/ (to fix bug 1707222). Lastly, the change from using dhclient to using systemd-networkd's dhcp client will cause a fair amount of fallout across Ubuntu. That will cause problems with cloud-init on Azure. Many things either relied on dhclient hooks or read its leases file. I've opened bug 1717983 to track that. Summary of generally involved bugs: * bug 1709772: Enable ipv6 support on EC2 * bug 1707222: usage of /tmp during boot is not safe may get files deleted. * bug 1717627: permission denied executing dhclient from /run * bug 1717983: cloud-init and other programs integrate with dhclient. ** Description changed: in the ec2 datasource, cloud-init runs dhclient from a tmp file in order to avoid apparmor restrictions and side affects. In a change for bug 1707222 we started using /run/cloud-init for tmpfiles. /run is mounted noexec. See example: - $ sudo /run/cloud-init/tmp/dhclient -1 -v -lf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhclient.pid eth0 -sf /bin/true sudo: unable to execute /run/cloud-init/tmp/dhclient: Permission denied + So, we need a tmp file in a place that allows execution. - So, we need a tmp file in a place that allows execution. + Related bugs: + * bug 1709772: Enable ipv6 support on EC2 + * bug 1707222: usage of /tmp during boot is not safe may get files deleted. + * bug 1717627: permission denied executing dhclient from /run -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1717627 Title: permission denied when executing dhclient in Ec2 datasource To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717627/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
