How it works?
In a high level when the virtual machine first boots up and gets rebooted to be customized due to the dynamic vCenter customization specs that gets created based on the fact we are using the assignment static property ( assignment: static ) within the blueprint code as you see in the screenshot below, I am making sure that during that time, Cloud-init is in a disabled state.
After the customization reboot the virtual machine once, there is a Cron Job that I created on the template that execute at startup after a 90 sec of sleep which is enough time for the virtual machine to be customized, rebooted and connected to the network without running the Cron Job as of yet. After the initial reboot and pass the 90sec mark now the Cron Job execute a shell script that enables cloud-init and initializes it running all the needed cloud-init modules. ( init, Config and Final)
Note: Feel free to increase the 90 sec if you feel you need more time as the virtual machine being customized.
The End result, the virtual machine is now customized with an updated host-name and an IP from our targeted static IP pool configured for the network its connected to without having to hack the Cloud Config code any further to setup things like the host-name or even configure the network itself, and more importantly without conflicting with cloud-init which what the problem was all along.
Let’s get started, Eh!
Template Preparation Steps
- Build a new Ubuntu 16.04 or 18.04 virtual machine from the certified ISO
- Ubuntu 16.04 64-bit PC (AMD64) server install image
- Ubuntu 18.04 64-bit PC (AMD64) server install image
- Once the virtual machine is up and running update the list of available packages and install any new available version of these packages that you have to update your template.
sudo apt-get update && sudo apt-get -y upgrade
-
- Install Cloud-init for Ubuntu 16.04. Ubuntu 18.04 have cloud-init pre-installed so you can skip this step
sudo apt-get -y install cloud-init
- Configure OVF as your Datasource, then save and exit
sudo dpkg-reconfigure cloud-init
- Enable traditional Guest OS Customization GOSC Script by editing /etc/cloud/cloud.cfg file and adding
disable_vmware_customization: true
- Ensure network configuration is disabled in /etc/cloud/cloud.cfg, by adding or un-hashing the following if it exists:
network:
config: disabled
If a cloud-init network config is not found and no disable option is specified then cloud-init will default to a fallback behavior which is to use DHCP if you happen to reboot the server.
By specifying the “disabled” option we are telling cloud-init not to try and do anything with the network on each subsequent startup which allows the guest OS to use the config that was originally applied to the machine on first run.
- Set Temp not to clear, by editing /usr/lib/tmpfiles.d/tmp.conf and adding the prefix # to line 11.
#D /tmp 1777 root root –
- Configure Open-vm-tools to start after dbus.service by editing /lib/systemd/system/open-vm-tools.service file and adding the following under the [Unit] section.
After=dbus.service
- Reduce the raise network interface time to 1 min by editing /etc/systemd/system/network-online.targets.wants/networking.service file and changing: ( This not applicable on Ubuntu 18.04 )
TimeoutStartSec=5min to TimeoutStartSec=1min
- Disable cloud-init on First Boot and until customization is complete by creating this file /etc/cloud/cloud-init.disabled
sudo touch /etc/cloud/cloud-init.disabled
- Create a script your_script.sh in a known location that will be called by a Cron Job that will create later to enable and initialize cloud-init after the customization reboot. The script should contain the following commands:
sudo rm -rf /etc/cloud/cloud-init.disabled sudo cloud-init init sleep 20 sudo cloud-init modules --mode config sleep 20 sudo cloud-init modules --mode final
- Configure the script to be an executable
sudo chmod +x your_script.sh
- Create a Cron Job that will run after 90 sec of sleep at boot by typing crontab -e and entering the following:
@reboot ( sleep 90 ; sh /Script_path/your_script.sh )
- Copy the content below for the Template Cleaning script and create your_clean_script.sh. You can replace cloudadmin with your own user that you setup when you installed the Ubuntu OS
#!/bin/bash # Add usernames to add to /etc/sudoers for passwordless sudo users=("ubuntu" "cloudadmin") for user in "${users[@]}" do cat /etc/sudoers | grep ^$user RC=$? if [ $RC != 0 ]; then bash -c "echo \"$user ALL=(ALL) NOPASSWD:ALL\" >> /etc/sudoers" fi done #grab Ubuntu Codename codename="$(lsb_release -c | awk {'print $2}')" #Stop services for cleanup service rsyslog stop #clear audit logs if [ -f /var/log/audit/audit.log ]; then cat /dev/null > /var/log/audit/audit.log fi if [ -f /var/log/wtmp ]; then cat /dev/null > /var/log/wtmp fi if [ -f /var/log/lastlog ]; then cat /dev/null > /var/log/lastlog fi #cleanup persistent udev rules if [ -f /etc/udev/rules.d/70-persistent-net.rules ]; then rm /etc/udev/rules.d/70-persistent-net.rules fi #cleanup /tmp directories rm -rf /tmp/* rm -rf /var/tmp/* #cleanup current ssh keys #rm -f /etc/ssh/ssh_host_* #cat /dev/null > /etc/hostname #cleanup apt apt-get clean #Clean Machine ID truncate -s 0 /etc/machine-id rm /var/lib/dbus/machine-id ln -s /etc/machine-id /var/lib/dbus/machine-id #Clean Cloud-init cloud-init clean --logs --seed #cleanup shell history history -w history -c
- Configure the Template Cleaning script to be an executable as well
sudo chmod +x your_clean_script.sh
- Make sure you can switch to user root by editing the fine /etc/ssh/sshd_config and changing PermitRootLogin to yes
PermitRootLogin yes
- Set a password for root
sudo passwd root
Note: The reason for the above is to be able to execute the clean script with no issues as I personally had issues executing the clean up script with sudo working with the Ubuntu 18.04. you can always revert it back once the cleanup template is executed.- Execute the Template Cleaning Script.
sudo ./Script_path/your_clean_script.sh
- Shutdown the virtual machine and turn it into a template.
Thank you for the very interesting article !
But when you say “Enable traditional Guest OS Customization GOSC Script by editing /etc/cloud/cloud.cfg file and adding: disable_vmware_customization: true”
isn’t it “false” instead of “true” ?
This got me very confused ^^”
Thank you !
LikeLike
Thank you for the feedback.
I have struggled with that one my self . But thats how it works apparently. I did have to do bit of research to make sure i m setting the right property, if you do the same will find the same answer i found. If you find anything different please do share. 🙂
Thank You
Maher
LikeLike