5ed2442214
This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS #11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Just like Flatpak, the singleton 'p11-kit server' process is not terminated when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS #11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS #11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 https://github.com/flatpak/flatpak/commit/66b2ff40f7caf3a7 https://github.com/flatpak/flatpak/pull/1757 https://github.com/p11-glue/p11-kit/issues/68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] https://github.com/containers/toolbox/pull/1652 https://github.com/containers/toolbox/issues/626 |
||
|---|---|---|
| .github | ||
| data | ||
| doc | ||
| images | ||
| playbooks | ||
| profile.d | ||
| src | ||
| test | ||
| .codespellexcludefile | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .zuul.yaml | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| GOALS.md | ||
| NEWS | ||
| NEWS.old | ||
| README.md | ||
| SECURITY.md | ||
| gen-docs-list | ||
| meson.build | ||
| meson_options.txt | ||
| meson_post_install.py | ||
| toolbox | ||
README.md
Toolbx is a tool for Linux, which allows the use of interactive command line environments for software development and troubleshooting the host operating system, without having to install software on the host. It is built on top of Podman and other standard container technologies from OCI.
Toolbx environments have seamless access to the user's home directory, the Wayland and X11 sockets, networking (including Avahi), removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc..
This is particularly useful on OSTree based operating systems like Fedora CoreOS and Silverblue. The intention of these systems is to discourage installation of software on the host, and instead install software as (or in) containers — they mostly don't even have package managers like DNF or YUM. This makes it difficult to set up a development environment or troubleshoot the operating system in the usual way.
Toolbx solves this problem by providing a fully mutable container within
which one can install their favourite development and troubleshooting tools,
editors and SDKs. For example, it's possible to do yum install ansible
without affecting the base operating system.
However, this tool doesn't require using an OSTree based system. It works equally well on Fedora Workstation and Server, and that's a useful way to incrementally adopt containerization.
The Toolbx environment is based on an OCI
image. On Fedora this is the fedora-toolbox image. This image is used to
create a Toolbx container that offers the interactive command line
environment.
Note that Toolbx makes no promise about security beyond what's already available in the usual command line environment on the host that everybody is familiar with.
Installation & Use
See our guides on installing & getting started with Toolbx and Linux distro support.
