Below are the contents of partman-recipe.txt, fetched by preseed/early_command. The format is rather sensitive to syntax errors. Also, the partition size algorithm is finicky. If you choose the numbers unfavourably, it may run for hours before coming to a final decision.

      
partman-auto/text/ssh_server_scheme ::

1 1 1 free
      $iflabel{ gpt }
      method{ biosgrub } .

2048 4096 200% linux-swap
      $lvmok{ }
      method{ swap }
      format{ }
      label{ lwpswap } .

20480 25600 30720 $default_filesystem
      $lvmok{ }
      method{ format }
      format{ }
      use_filesystem{ }
      $default_filesystem{ }
      label{ lwproot }
      mountpoint{ / } .

15360 20480 -1 $default_filesystem
      $lvmok{ }
      method{ format }
      format{ }
      use_filesystem{ }
      $default_filesystem{ }
      label{ lwpvar }
      mountpoint{ /var } .

4096 8192 10240 $default_filesystem
      $lvmok{ }
      method{ format }
      format{ }
      use_filesystem{ }
      $default_filesystem{ }
      label{ lwptmp }
      mountpoint{ /tmp } .

4096 8192 10240 $default_filesystem
      $lvmok{ }
      method{ format }
      format{ }
      use_filesystem{ }
      $default_filesystem{ }
      label{ lwphome }
      mountpoint{ /admin } .
      

When you reinstall a client, the Puppet server still has certificates for the old installation. So we run knockd on the server, and when the client knocks, the server throws away the certs. This is the client-side script that does the knocking, and it runs as part of the preseed/late_command:

# This makes the server delete your certificate
knock puppet.mydomain.com 9356 7511 3296
sleep 5
# Do it again, for good measure
knock puppet.mydomain.com 9356 7511 3296
      

We have scripts that create a user, add its ssh key, add the account to sudo.

Partman creates filesystems, but the ext2 utils create them better. So if the partitioner.sh script created C: (a dummy, to keep partition schems aligned), we script a filesystem onto it during the late_command.

Puppet can be run inside the debian installer. But if your catalog specifies any Upstart services (and given that this is Ubuntu Trusty, chances are that it does), then Puppet will fail to manipulate them, as upstart isn't well integrated into the installer like SysV is. So we need to divert Upstart before we can run Puppet:

# This is to protect Puppet. The upstart jobs it runs won't complain now

dpkg-divert --local --rename --add /sbin/initctl
ln -sf /bin/true /sbin/initctl
      

Only then can we configure and run Puppet. (Even so, Puppet needs to be made aware that it runs inside the installer, even if it manipulates SysV services. But that's beyond the scope of this document.)

set -e

cat <<EOF > /etc/default/puppet
# Defaults for puppet - sourced by /etc/init.d/puppet

# Enable puppet agent service?
# Setting this to "yes" allows the puppet agent service to run.
# Setting this to "no" keeps the puppet agent service from running.
START=yes

# Startup options
DAEMON_OPTS=""
EOF

cat <<EOF > /etc/puppet/puppet.conf
[main]
server      = puppet.mydomain.com
report      = true
splay       = true
pluginsync  = true
EOF

puppet agent --enable

# Unless you make every class aware of whether it's running inside the installer or not, Puppet will likely fail. That's ok.
puppet agent --test --waitforcert 10 || true

exit 0
      

And of course we revert the diversion of upstart after Puppet is done:

# Puppet has run, so its protection from upstart jobs can be undone

rm -f /sbin/initctl
dpkg-divert --rename --remove /sbin/initctl