Over three years ago I created a post for creating an Ubuntu 16.04 template for use in a lab environment. I’ve been using that template, with very minor updates, ever since. Ubuntu 16.04 LTS (Long Term Support) will stop receiving maintenance updates in just over a year, so I plan to start moving to 18.04 LTS. More information on Ubuntu release cycles can be found here: https://ubuntu.com/about/release-cycle.
To begin, we will download the ubuntu-18.04.3-server-amd64.iso file from http://cdimage.ubuntu.com/releases/18.04/release/ and upload it to a datastore. Next we will create a new virtual machine, entering names and selecting host/datastore/virtual hardware compatibility levels appropriate for our infrastructure. Select OS Linux>Ubuntu Linux x64. The default network adapter should be vmxnet3, but I changed the SCSI controller from the default LSI Logic Parallel to PVSCSI. For the template, I stuck with 1vCPU, 1GB RAM, and 16GB disk (in a future post we will cover growing the filesystem if additional space is needed). We will select ‘Datastore ISO File’ and browse to the ubuntu-18.04.3-server-amd64.iso file we uploaded earlier, and then confirm that ‘Connect At Power On’ is selected for the CDROM.
With the VM created, we will power it on and open the console, the installer should have begun automatically. For the install, I mostly selected defaults, except the following:
- User account to be created: template-admin
- Partition disks: Guided – use entire disk (without LVM). When using guided with LVM the volumes embed the template hostname, which will change on deployment. We can still grow the filesystem without LVM, and other LVMs can be setup in the future, so we will continue without LVM for now.
- Install security updates automatically. (Setup Landscape in the future?)
- Select the box to add openssh server
When complete the installer will disconnect (eject) the CDROM. This is a good time to edit the VM settings to switch back to ‘Client Device’ so that no CD is attached to the resulting templates once deployed.
Login as the local user created during install. For example, template-admin. The IP address for ens192 (the default network adapter) should appear. We can now SSH in so the following commands can be copied/pasted. First we will set a password for root:
template-admin@ubuntu:~$ sudo passwd root [sudo] password for template-admin: Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Switch to the root user, this will save a bit of time as we can run as this user without specifying sudo for each command. Once we are running as root, we will make sure the system is up to date.
Note: if we use the command ‘su -‘ with a trailing hyphen, the system will put us in the /root folder. If we do not include the trailing hyphen then we will remain in the current directory of the session that issued the su command.
su - apt update && apt -y upgrade apt clean && apt -y autoremove --purge
Instead of using local accounts, we will join our Ubuntu systems to Active Directory using the BeyondTrust AD Bridge Open Edition. The process is described here: https://repo.pbis.beyondtrust.com/apt.html. Specifically we will run:
wget -O - http://repo.pbis.beyondtrust.com/apt/RPM-GPG-KEY-pbis|sudo apt-key add - sudo wget -O /etc/apt/sources.list.d/pbiso.list http://repo.pbis.beyondtrust.com/apt/pbiso.list sudo apt-get update sudo apt-get install pbis-open
Joining the domain will take a small handful of commands, so we will create a shell script for the template to help with future domain joins. We will put this script in the root users profile directory, so we can launch it simply after customization with ./joinad.sh. Launch a text editor such as nano joinad.sh and paste in the following text:
# The following line has the OU, Domain Name, User Account, and Password of a user with permissions to create computer objects. /opt/pbis/bin/domainjoin-cli join --ou "LAB Servers/Services" lab.enterpriseadmins.org svc-windowsjoin VMware1! /opt/pbis/bin/config AssumeDefaultDomain true /opt/pbis/bin/config LoginShellTemplate /bin/bash /opt/pbis/bin/config HomeDirTemplate %H/%U /opt/pbis/bin/config RequireMembershipOf "lab\\domain^users" /opt/pbis/bin/update-dns
Save the file, then make it executable
chmod +x joinad.sh
When executing the above script, a DNS record is created. In the past I’ve had issues with that record eventually being scavenged/deleted by the DNS server. To ensure that the DNS record is occasionally updated, I like to add a task to crontab. We can do this in the template by running crontab -e which will allow us to select a default editor. Once inside the editor we can add a single line like the following:
1 1 * * 0,3 /opt/pbis/bin/update-dns
This will schedule a task to run at 1:01 every Sunday and Wednesday. For reference, I did stumble on a great site to validate your crontab syntax at https://crontab.guru/.
The last AD related configuration to make is to add a domain group to the /etc/sudoers file, so that certain users can use sudo to run commands as root. To do this, we edit the /etc/sudoers file and add a line similar to:
%lab^linux^sudoers ALL=(ALL) ALL,!ROOTONLY
This will allow members of the AD group LAB Linux Sudoers to be able to execute commands such as sudo whoami. After entering their password, they should see that they are running a command as root.
By default, netplan uses a client ID for DHCP assignments. When using DHCP we want to use a MAC address as an identifier. I found two sources to describe this, first https://bugs.launchpad.net/netplan/+bug/1759532, which links to this parent bug: https://bugs.launchpad.net/netplan/+bug/1738998. The recommendation is to change the netplan yaml config file to include dhcp-identifier: mac. We will do this in a text editor by running nano /etc/netplan/01-netcfg.yaml. The resulting file should look similar to this:
network:
version: 2
renderer: networkd
ethernets:
ens192:
dhcp4: yes
dhcp-identifier: mac
Note: this yaml file uses white space as a deliminator. The dhcp4 and dhcp-identifier lines have 6 leading spaces (there are 2 for ethernets, 2 more for ens192, and 2 more for the property we added).
We could apply this with netplan apply, but doing so will likely result in a new IP address assignment from DHCP and a disconnect from SSH. I really only need the setting for the future, so I’ll leave this for the next reboot.
While working on this template, the VM console was at the login screen, and I accidentally hit the CTRL+ALT+DELETE button in the vSphere HTML5 client… and the VM immediately rebooted. I tried this a couple of times, and a bit of research confirms it is a default behavior. I want to disable that in my template, so I used the instructions here: https://www.linuxbuzz.com/disable-reboot-ctrl-alt-del-ubuntu-debian/. Since we are already switched to the root user, we don’t need to specify sudo for each line and can run these two commands:
systemctl mask ctrl-alt-del.target
systemctl daemon-reload
For time keeping we’ll use timesyncd, so we’ll edit the config file and add our NTP servers. We’ll remove the comment from the NTP line and add our servers, separated by spaces. We can edit the file with any text editor, such as nano /etc/systemd/timesyncd.conf. After changing the file, we’ll want to make these servers active, which we can do with the following restart command:
systemctl restart systemd-timesyncd.service
Install the Log Insight agent. I have previously downloaded the Log Insight agent installers and placed them on an internal web server. The web server does not support .deb files, so I simply added a .zip to the end of the file name. After downloading, we will need to rename the file back to the original name:
cd /tmp
wget http://www.example.com/vmware-log-insight-agent_8.0.0-14743436_all_192.168.45.80.deb.zip
mv vmware-log-insight-agent_8.0.0-14743436_all_192.168.45.80.deb.zip vmware-log-insight-agent_8.0.0-14743436_all_192.168.45.80.deb
dpkg -i vmware-log-insight-agent_8.0.0-14743436_all_192.168.45.80.deb
Check the configuration file to ensure it has the settings you want, for example with nano /var/lib/loginsight-agent/liagent.ini. In my case I decided to enable central_config and auto_update properties.
I used part of a script here: https://jimangel.io/post/create-a-vm-template-ubuntu-18.04/ to make sure new openssh-server keys are generated after template deployment. You should check out the original post for additional optional settings you may want to change at first boot, like a randomly generated hostname. The below text can be run from the shell:
#add check for ssh keys on reboot...regenerate if neccessary
cat << 'EOL' | sudo tee /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
test -f /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server
exit 0
EOL
# make sure the script is executable
chmod +x /etc/rc.local
There are a handful of cleanup items we will want to run anytime we crack open the template for updates. Those commands are listed below:
rm -rf /tmp/*
rm -rf /var/tmp/*
rm -f /etc/ssh/ssh_host_*
history -c
shutdown -h now
Add a description to the VM note/annotation field. This will be cloned when the VM is updated, so it will give you an idea of the starting point for all subsequent VMs. For example, I added the following text:
2020-01-19: Ubuntu 18.04 Template, Open-VM-Tools 11.0.1, pbis-open, Log Insight Agent
Convert template-Ubuntu1804 to a template. We now have an Ubuntu 18.04 template that is ready for use.
