packaging rkt
This document aims to provide information about packaging rkt in Linux distributions. It covers dependencies, file ownership and permissions, and tips to observe packaging policies.
Build-time dependencies
Please see the list of build-time dependencies.
Offline builds
By default, the rkt build will download a CoreOS Container Linux PXE image from the internet and extract some binaries, such as systemd-nspawn
and bash
. However, some packaging environments don't allow internet access during the build. To work around this, download the Container Linux PXE image before starting the build process, and use the --with-coreos-local-pxe-image-path
and --with-coreos-local-pxe-image-systemd-version
parameters. For more details, see the configure script parameters documentation.
Bundling with systemd
Most Linux distributions don't allow the use of prebuilt binaries, or reuse of code that is already otherwise packaged. systemd falls in this category, as Debian and Fedora already package systemd, and rkt needs systemd.
- Debian Policy Manual, section 4.13 Convenience copies of code
- Fedora Packaging Guidelines
- Fedora Packaging Committee
The configure script's --with-stage1-flavors
option can be set to host
to avoid rkt's dependency on systemd in these environments:
./configure --with-stage1-flavors=host
The stage1-host.aci
archive generated by this build will not contain bash, systemd, or any other binaries from external sources. The binaries embedded in the stage1 archive are all built from the sources in the rkt git repository. The external binaries needed by this stage1-host.aci
are copied from the host at run time. Packages using the --with-stage1-flavors=host
option must therefore add a run-time dependency on systemd and bash. Whenever systemd and bash are upgraded on the host, rkt will use the new version at run time. It becomes the packager's responsibility to test the rkt package whenever a new version of systemd is packaged.
For more details, see the configure script parameters documentation.
Glide
rkt uses Glide to maintain a copy of dependencies in its source repository.
Run-time dependencies
Please see the list of run-time dependencies.
Packaging Externals
Ownership and permissions of rkt directories
In general, subdirectories of /var/lib/rkt
, and /etc/rkt
should be created with the same ownership and permissions as described in the directory list.
Any rkt package should create a system group rkt
, and rkt-admin
. The directory /var/lib/rkt
should belong to group rkt
with the setgid
bit set (chmod g+s
). The directory /etc/rkt
should belong to group rkt-admin
with the setgid
bit set (chmod g+s
).
When the ownership and permissions of /var/lib/rkt
are set up correctly, members of group rkt
should be able to fetch ACIs. Members of group rkt-admin
should be able to trust GPG keys, and add additional configurations in /etc/rkt
. Root privilege is still required to run pods.
The motivation to have separate rkt
, and rkt-admin
groups is that the person who makes administrative changes would likely be different than the unprivileged user who is able to fetch.
systemd units
A few example systemd unit files for rkt helper services are included in the rkt sources. These units demonstrate systemd-managed units to run the rkt metadata-service with socket-activation, the rkt api-service, and a periodic garbage collection service invoked at 12-hour intervals to purge dead pods.