Templating Debian GNU/Linux (1/2)


Distributing pre-installed (Debian) GNU/Linux virtual machine templates requires some steps to create clean and secure templates. You should consider at least to:

  • drop local root password: fight against known default passwords and known password hashes
  • drop SSH host keys: prevent private key leaks and prevent MITM
  • drop various history files (~/.bash_history, ~/.lesshst, ~/.mysql_history, …): leaking commands issued, might contain sensitive data
  • drop /var/lib/ntp/ntp.drift: after deployment ntp would assume it already knows something sensitive about the hosts clock drift
  • drop /var/lib/dhcp/dh*.leases*: dhcp leases might leak informations on the network where the template was created
  • drop /var/mail/*: no useful content in most cases
  • drop/truncate files in /var/log/: leaks information about installation
  • drop /etc/udev/rules/70-persistent-*-rules: contains invalid device entries

This is simular to the in-band tool sysprep.exe on Microsoft Windows.

For GNU/Linux there is virt-sysprep from Red Hat which is not available on Debian. virt-sysprep prepares the VM image from outside the virtualization container. Therefore it is limited to setups supported by libguestfs.


When a new VM is deployed from a template some additional steps are required:

  • setup root password
  • generate SSH host keys
  • setup hostname
  • configure network settings

Parts of the required steps could be done by virt-customize. This is done from outside the virtualization container and requires libguestfs support again.

From the view of a (VMware) virtualization administrator it would be useful to configure basic network settings from outside of the VM, automate the generation of required crypto keys and ease the setting of a initial root password. To configure network settings from outside of a VM a interaction with the virtualization platform is required.

OVF environment

The Open Virtualization Format Specification (OVF Specificaton) released by the Distributed Management Task Force (DTMF). Chapter 11 of the specification defines the OVF environment which is a set of key-value data allowing software within VMs to retrieve data from the virtualization platform in a generic way.

The VMware vSphere platform supports providing the OVF environment file by a CD-ROM image or using the VMware guest tool stack:

# vmtoolsd --cmd 'info-get guestinfo.ovfenv'

This command provides the ovf-env.xml on STDOUT:

<?xml version="1.0" encoding="UTF-8"?>
      <Kind>VMware ESXi</Kind>
      <Vendor>VMware, Inc.</Vendor>
           Custom key-value data to be processed by the ovfdep package.
         <Property oe:key="hostname" oe:value="myhost1"/>
         <Property oe:key="dns-domain" oe:value="local"/>
         <Property oe:key="dns-search" oe:value="local"/>
         <Property oe:key="dns-nameservers" oe:value=""/>
         <Property oe:key="ifup-address" oe:value=""/>
         <Property oe:key="ifup-netmask" oe:value=""/>
         <Property oe:key="ifup-gateway" oe:value=""/>
         <Property oe:key="ntp-servers" oe:value=""/>
         <Property oe:key="ntp-servers" oe:value=""/>
           End of custom key-value data.
      <ve:Adapter ve:mac="00:50:56:66:66:66" ve:network="VM-Network" ve:unitNumber="7"/>

It is possible to configure OVF environment keys in VMware vSphere. The custom key-value data is provided within the PropertySection element of the ovf-env.xml structure.


I’ve developed ovfdep to support dehydration, rehydration and customization to ease the development and deployment of (Debian) GNU/Linux templates. Continue reading:

Comments !