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.
Please see the list of build-time dependencies.
By default, the rkt build will download a CoreOS PXE image from the internet and extract some binaries, such as
bash. However, some packaging environments don't allow internet access during the build. To work around this, download the CoreOS PXE image before starting the build process, and use the
--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:
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.
Please see the list of run-time dependencies.
Ownership and permissions of rkt directories
In general, subdirectories of
/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-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 (
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-admin groups is that the person who makes administrative changes would likely be different than the unprivileged user who is able to fetch.
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.