60641d7411
Also see https://bugs.launchpad.net/cloud-images/+bug/2106729. Since Oracular[1]: Ubuntu’s systemd-networkd no longer sets UseDomains=true for managed network interfaces. In effect, this means that search domains configured in DHCP leases will not be reflected in /etc/resolv.conf by default. This change aligns Ubuntu’s default behavior with that of upstream. System administrators may choose to override this default on a global, or per-interface basis. See systemd.network 4 for details. The default in systemd is UseDomains=false. From systemd.network(5)[2]: DHCP= Furthermore, note that by default the domain name specified through DHCP is not used for name resolution. See option UseDomains= below. UseDomains= It is recommended to enable this option only on trusted networks, as setting this affects resolution of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain only as routing domain, rather than as search domain, in order to not have it affect local resolution of single-label names. It has been reported to us by few clouds that this breaks local name resolution. For instance, in Google Cloud Compute, users can no longer reach instances in the same zone[3] nor Google Cloud services[4] by their names. Arguably, the security concerns for having this option disabled are not valid in cloud environments. As one of our partners said: IIUC, the motivation to disable UseDomains by default is that a laptop might be used on an untrusted network where the domains provided by DHCP can be a security issue, directing users to places they don't intend. But it's not possible for a cloud instance to be connected to an untrusted network (barring a breached account). The way I'm looking at this is that DHCP option 119 exists for the express purpose of allowing a network administrator to configure the DNS search path for computers on that network. I understand there's a security concern if that network isn't a datacenter. But in the cloud there's no concern (in some clouds, it's not even possible for DHCP response packets to come from anywhere but the cloud's own DHCP). We should restore this setting in cloud images. [1] https://discourse.ubuntu.com/t/oracular-oriole-release-notes/44878 [2] https://manpages.ubuntu.com/manpages/plucky/en/man5/systemd.network.5.html [3] https://cloud.google.com/compute/docs/internal-dns [4] https://cloud.google.com/compute/docs/metadata/overview
TL;DR
In order to generate the hooks for a specific image target set, call the
make-hooks script, located in hooks.d as
./make-hooks --hooks-dir ../hooks <image_set>
where image_set is the name of a series file (e.g. "vagrant") without leading
path components. Do not check in the hooks folder, it is automatically
generated by auto/config during Live Build runs.
Hook placement and ordering
Scripts live in subfolders below the hooks.d folder. Currently the folders
chroot and base exist. The folder with the name extra is reserved for
private scripts, which are not included in the source of livecd-rootfs. The
scripts are not numbered, instead the order of their execution depends on the
order in which they are listed in a series file.
Series files are placed in subfolders hooks.d/base/series or
hooks.d/extra/series. Each series file contains a list of scripts to be
executed. Empty lines and lines starting with a # are ignored.
Series files in extra/series override files in base/series with the same
name. For example, if a series file base/series/cloudA exists and a series
file extra/series/cloudA, then the latter will be preferred.
A series file in extra/series may also list scripts that are located in the
chroot and base folders. In addition, series files can depend on other
series files. For example, the series files for most custom images look similar
to this:
depends disk-image
depends extra-settings
extra/cloudB.binary
Where disk-image and extra-settings may list scripts and dependencies which
are to be processed before the script extra/cloudB.binary is called.
ACHTUNG: live build runs scripts with the suffix ".chroot" in a batch separate from scripts ending in ".binary". Even if you arrange them interleaved in your series files, the chroot scripts will be run before the binary scripts.
Image set selection for Live Build
During a Live Build, enumerated symbolic links are generated based on the
contents of one or more series files. The series files are selected according
to the contents of the IMAGE_TARGETS environment variable. For example, in
order to trigger the build of squashfs and vagrant, list them in the
IMAGE_TARGETS variable as squashfs,vagrant. The separator can be a comma,
a semi-colon or whitespace.
The generation of the symbolic links is triggered from the auto/config script,
from where the contents of the IMAGE_TARGETS environment variable are passed
on to the make-hooks script.
Symlink generation
Since Live Build itself does not know about series files, a traditional hooks
folder is generated using the make-hooks script. The script takes as arguments
the names of the series files to be processed.
The script parses the series files and generates enumerated symbolic links for
all entries. Per default, these are placed into a directory named hooks next
to the hooks.d directory. This can be changed using the --hooks-dir
parameter.