Suppose we want to perform the same customization with Ubuntu. Ubuntu pre-seed files run a single line of commands rather than a block as used in kickstart; hence, they lend themselves better to either simple tasks, or indeed to downloading a script for more complex operations. We could embed the sed command in our pre-seed file by adding the following line at the bottom:

d-i preseed/late_command string in-target /bin/sed -i 's/#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config

Suppose, however, we have a much more complex script to run, and that trying to write it all on one line would make it difficult both to read and manage—instead, we could change the preceding command, to download a script from a chosen place and run it, as follows:

d-i preseed/late_command string in-target wget -P /tmp/ http://192.168.201.1/ubuntu-config/run.sh; in-target chmod +x /tmp/run.sh; in-target sh -x /tmp/run.sh

Note here that we are using wget (which was installed earlier in the build process) to download a file called run.sh from the /ubuntu-config/ path on our web server. We then make it executable and run it. In this way, far more complex command sequences can be run at the end of the build process, just prior to the first reboot.

In this manner, incredibly complex, bespoke operating system builds can be installed remotely, over the network, without any human intervention at all. The use of kickstart and pre-seed files also means that the process is scripted and repeatable, which is an important principle for us to adhere to.