Instead of requiring every Aimee OS project to carry around a full
Portage configuration tree, including patches, saved configurations,
etc., we now support a "layered" configuration system. Aimee OS core
provides a base configuration that includes all settings, patches, etc.
common for all Aimee OS projects. At build time, this base
configuration is combined with the project's configuration, which need
only specify USE flags, etc. for that specific project. This should
make maintenance across multiple projects easier, and make getting a new
project started _significantly_ less cumbersome.
GRUB is needed for all machines that run Aimee OS. The Raspberry Pi
firmware, of course, is only needed to run Aimee OS on a Raspberry Pi.
Thus, the former should be listed in the global `build.packages` file,
while the latter should be built only for projects targeting Raspberry
Pis.
The 17.0 profiles are deprecated. Let's use the project's configured
profile at this stage, so as not to have to rebuild stuff because we
change USE flages, etc. once we set it later.
The modern profiles are all "merged-usr" by default now, so we do not
need that explicit step anymore.
Since this is the last vestige of the "host" Portage configuration
directory, we can remove it entirely by setting `USE=symlink` as an
environment variable. This should be safe, since there are not many
other packages besides kernel sources that use this USE flag, and
they're not likely to be pulled in with this `emerge` invocation.
`build.packages`, `installonly.packages`, and `busybox.symlinks` are now
optional in the `$CONFIGDIR`. If they do exist, they are combined with
the same files in the Aimee OS source.
None of these are necessary anymore. They do not apply cleanly to
current versions of ebuilds in Gentoo's repository, causing builds to
fail.
Going forward, I think it will be better to maintain patched ebuilds in
the Aimee OS repository, rather than patching them at build time.
Instead of building host tools along with the target packages, we now
rely on the build container to contain everything we need to build Aimee
OS. The _aimee-os.org/build/build-{target}_ image (tentative name)
includes a cross-compilation toolchain and all of the tools that were
originally listed in `host-tools.packages`.
Projects can now set a `buildvm` variable in their `config` file to
specify a unique name for their build VMs. This allows multiple
projects to have running VMs simultaneously.
If a project does not provide a name, the build VM will be called
`aimeebuild`.
The default SELinux policy does not allow passing generic USB devices
and unallocated TTYs to containers. This prevents the Zigbee and ZWave
USB dongles from being usable by their respective container processes.
`systemd-network-generator`, which parses network configuration from the
kernel command line and generates configuration for *systemd-networkd*,
creates a configuration file with priority 90. This conflicts with our
default network configuration at the same priority, so the configuration
from the kernel command line never gets used. By reducing our default
priority to 95, we ensure that the generated configuration file is read
first and thus overrides the defaults.
The `semanage.sh` script starts an interactive shell in an alternate
mount namespace where `/etc/selinux` and `/var/lib/selinux` are
bind-mounted from the target filesystem. This allows SELinux management
commands like `setsebool`, `semodule, `semanage`, etc. to work on the
target policy, since not all of them directly support working on an
alternate policy.
Very large packages cannot be built with `PORTAGE_TMPDIR` on a tmpfs
mount, unless the VM has a tremendous amount of RAM. The performance
improvement is negligible anyway, so let's not bother.
It turns out that QEMU microvms have a very limited number of I/O ports
available for e.g. attached disks and shared filesystems. To conserve
ports, we'll use a single volume for both distfiles and binpkgs cache
directories.
The `ocivm.sh` script mounts the source directory at `/tmp/src`, since
we use `/tmp/build` as the output directory. For consistency, the
`start-container.sh` script, although it's mostly unused anymore, now
does the same.
`genimage` does not align partitions appropriately by default, but
simply packs them one-after-another based on their size. This is easy
enough to fix by setting the `align` property in the `hdimage` block.
These SELinux policy rules allow containers to log directly to
syslog/the systemd journal via the `/dev/log` socket. To enable this,
simply mount the socket into a container's mount namespace, e.g. `-v
/dev/log:/dev/log`.
When creating writable paths in the `/etc` subvolume, the `setup_etc`
function needs to create intermediate directories before copying
existing files from the root filesystem. Without this step, `cp` will
fail with a "no such file or directory" error, referring to the
destination path.
We're going to use *nginx* as the reverse proxy in front of Home
Assistant, as well as the web consoles for Zigbee2MQTT and ZWaveJS2MQTT.
It will provide TLS termination for all of these applications.
Since *nginx* will not start without a certificate and private key file
for HTTPS, the *gen-nginx-cert.service* systemd unit generates a
self-signed certificate if one does not already exist. This ensures
that *nginx* can start by default, but still allows the administrator to
replace the certificate with a trusted one later.
The *nginx* container image has symlinks at `/var/log/nginx/error.log`
and `/var/log/nginx/access.log`, pointing to `/dev/stderr` and
`/dev/stdout`, respectively. The intent here is to send all log
messages to the container runtime. Unfortunately, when the the
container is managed by Podman from a systemd unit, the standard output
and standard error streams are connected to the systemd journal via a
UNIX socket. As a result, the `/dev/stdout` and `/dev/stderr`
pseudo-files cannot be "opened" like normal files or pipes. Thus, to
forward nginx's logs to the systemd journal correctly, we have to do a
bit of trickery. For the error log at least, setting `error_log stderr`
works well; nginx simply writes messages to the existing file
descriptor. Unfortunately, the access log has no such mechanism. For
that, we use nginx's syslog capabilities. The `/dev/log` socket is
bind-mounted into the container, and nginx is configured to connect to
it.
Aimee OS variants can now supply a `semange.mods` file in their
configuration directories. This file contains SELinux customizations,
in the format produced by `semanage export`. Variants can use this
mechanism to set SELinux booleans, change user/login mappings, and other
SELinux policy customization. At build time, the base `selinux.mods`
file in the source directory is combined with the variant's file, if it
exists, and the resultant customizations are applied in a single
transaction.
Files and directories that have restrictive permissions and/or are now
owned by *root:root* require `cp` to have additional process
capabilities in order to copy them to the writable filesystem.
The `mksquashfs` command accepts a `-pf` argument, which specifies a
file that defines "pseudo files." Each line in the file defines some
file path and an operation to perform on that path *in the generated
filesystem image*. This allows, e.g. creating files, changing their
permissions, etc. that cannot be done in the source directory for
whatever reason.
Aimee OS now allows a variant to provide a pseudo file definition file
for `mksquashfs` by creating a `squashfs.pseudo` file in its
configuration directory.
We'll use BURP for backups, just like the old Home Assistant server.
Note that Portage cannot correctly set the ownership of files when
installing to an alternate $ROOT. To work around this, we replace the
`fowners` function for the *app-backup/burp* ebuild with a no-op, and
then set the permissions of the relevant files using SquashFS
pseudo-file definitions. Relatedly, we're omitting the files and
directories used by the server-side of BURP.
The `systemd_tmpfiles_manage_all` SELinux boolean allows
systemd-tmpfiles to manage any file, not just the (very small) subset
allowed by the default SELinux policy. Since we're using
systemd-tmpfiles to create directories and subvolumes for our
applications, we need this setting enabled.
The default Home Assistant configuration does not allow running a
reverse proxy in front of the application. To enable this, the
`use_x_forwarded_for` and `trusted_proxies` options have to be set.
Since we want `/var/lib/homeassistant` to be a Btrfs subvolume, we can't
simply include the necessary files in the correct location in the rootfs
image. Instead, we must define "copy tree" (`C`) actions for
`systemd-tmpfiles` to copy them from `/usr/share/factory`.
Unfortunately, `systemd-tmpfiles` considers `v` and `C` actions
conflicting, and thus will not copy the directory contents recursively.
Each file has to be listed explicitly.
The default SELinux policy for Podman only allows it to relabel certain
files, such as `user_home_t`, to `container_file_t`. This effectively
precludes mounting arbitrary directories from `/var` into containers.
When troubleshooting issues with the *init-storage* service, it is
helpful to be able to see the output from it directly on the system
(serial) console. If the initialization fails in certain situations, it
may be impossible to see the output otherwise. For this to work,
though, the unit has to be activated after the systemd journal has
started.
If the data volume is a partition (rather than a whole disk device), the
`init-storage` script will now attempt to resize it to use all
unallocated space on the disk. This only works if it is the last
partition on the disk. This situation is common when writing the
`sdcard.img` file directly to a disk that is larger than 4 GiB.
Apparently `FEATURES` and/or `EMERGE_DEFAULT_OPTS` set in `make.conf` do
not seem to apply to packages pulled in as `BDEPEND` dependencies and
installed in `/` instead of `/usr/${target}`. This causes binary
packages to not be built/used for those packages. Passing `--buildpkg`
(`-b`) and `--usepkg` (`-k`) on the command line ensures that binary
packages are built for everything.
Variants no longer need to specify the full contents of the
`squashfs.exclude` file. The "base" file in the source directory gets
combined with the one from the config directory (if it exists).
There's really no sense in having binary packages for
*sys-boot/raspberrypi-firmware*, since there is no "source" to build.
Having binary packages just wastes space.
By default, `systemd-tmpfiles` will create normal directories instead of
Btrfs subvolumes unless `/` is already a subvolume. According to
[Lennart][0], this has to do with subvolumes being too "heavy-weight,"
whatever that means.
Fortunately, we can override this nonsense with an environment variable.
[0]: https://github.com/systemd/systemd/pull/1915
Somewhat expectedly, attempting to avoid installing *app-admin/setools*
by listing it in `/etc/portage/profile/package.provided` proved more
trouble than it's worth.
Custom builds of Aimee OS can now specify additional paths under `/etc`
that should be writable. This is accomplished by populating a file
named `/etc/aimee-os/writable-etc` with a list of paths. Each line must
indicate the type of file (regular file: `f`, directory: `d`) and the
*relative* path under `/etc`.
It seems the bug that caused udev rules to be installed in the wrong
location has been fixed. As such, we need to make this corrective
action step conditional, only moving rules files if any are found in the
wrong place.
Dustin