http://askubuntu.com/questions/636837/are-there-examples-of-custom-installation-scripts/636867#636867
cloud-init is essential to maas operation.
maas *uses* cloud-init and maas provides the user who provisions a system the
ability to use cloud-init.
cloud-init reads 'user-data' and interprets and acts on it as described in [1]
== MAAS use of cloud-init ==
When MAAS does operations on a node it uses an "ephemeral environment".
The "ephemeral environment" is an Ubuntu environment that is booted with
with a read-only iscsi root device. To allow for writable space, it uses
overlayfs [2]. The end result is that the ephemeral environment feels very
much like "normal ubuntu".
MAAS runs code in this ephemeral environment for node enlistment,
commissionging and curtin based install. The mechanism that MAAS uses to run
this code is by passing user-data to cloud-init.
Generically the ephemeral environment whether booted for enlistment,
commissioning or curtin install is a cloud-instance that runs some code for
MAAS. That code consists of the necessary operations to achieve the purpose
including code to execute shutdown or reboot.
== MAAS and curtin ==
During curtin install, maas actually passes all of curtin and curtin config
through user-data into the ephemeral environment. This has the nice feature
that an of curtin on the maas regional controller means new installs
immediately use the new curtin. No update of the ephemeral environment is
necessary.
Curtin consumes 'config' from maas that tells it what to install. The config
that is provided to curtin is rendered via /etc/maas/preseeds/curtin_userdata
on the maas regional controller.
The curtin config file is yaml structured data.
One thing a user is likely to want to do is run additional commands after the
install has been done. This could be used for installation of other packages,
or other modifications to the environment. To achieve this goal, curtin
provides 'late_commands'.
The 'late_commands' dictionary is executed in C locale sorted order by key
name. Thus, '00_cmd1' runs before '00_cmd2' and '01_cmd1'.
To run a command inside the target root, use:
late_commands:
my_command: ['curtin', 'in-target', '--', 'my-command', 'my-options']
outside_command: ['find', '/']
If the value of an entry is a string, curtin will pass that string to 'sh' for
interpretation. If it is a list, no shell interpretation will occur.
== MAAS and d-i ==
The other Ubuntu installation mechanism that maas offers d-i. Customization
such to be done is done via '/etc/maas/preseeds/preseed_master' on the maas
region controller. This file is a d-i preseed file. For more documentation on
d-i, see [3]
== User's use of cloud-init ==
As stated earlier, MAAS provides cloud-init with a datasource. When the user
deploys a system via maas, they have the opportunity to provide 'user-data'
that cloud-init then will consume as described at [1].
This is how juju hooks itself into the first boot on MAAS. From JuJu's
perspective, the MAAS node boot is no different than on EC2 or Azure. It
simply starts a system and provides some user-data to cloud-init.
The user's use of cloud-init user-data should not be confused with MAAS's use.
MAAS uses cloud-init to perform the install, but after the install, the *users*
provided user-data is consumed by cloud-init in the newly booted system.
The user can provide user-data in the 'start' operation via API or MAAS's cli
tool. That looks like this:
maas <user> node start <uuid> user_data=<data> distro_series=<name>
...
--
[1] https://help.ubuntu.com/community/CloudInit .
[2] http://blog.dustinkirkland.com/2012/08/introducing-overlayroot-overlayfs.html
[3] https://wiki.debian.org/DebianInstaller/Preseed