toolbox/images/fedora/f36
Debarshi Ray 1fc50176c9 images: Avoid unexpected DNF behaviour when reinstalling or swapping
The RPM packages in the base 'fedora' image can be older than the those
currently available in the DNF 'updates' repository [1], but at the same
time newer than those available in the DNF 'fedora' repository [1].  The
first part happens because the base image isn't updated as often as the
individual packages, so the 'updates' repository can have newer RPMs.
The second part happens because the base image does get updated after a
stable Fedora has been released, and hence can have newer RPMs than the
'fedora' repository.

This is complicated by the fact that packages can get pulled directly
from Fedora's Koji build system into the base 'fedora' image before
they make it to one of the well-known repositories like 'fedora' or
'updates' [1].  These packages are marked as having come from the
koji-override-0 repository.

All that combined can lead to unexpected behaviour when DNF is invoked
to reinstall or swap the RPM packages in the base image.  Some examples
below.

The base fedora:36 image contains glibc-minimal-langpack-2.35-20.fc36
that came from koji-override-0, while 'fedora' and 'updates' have
glibc-all-langpacks-2.35-4.fc36 and glibc-all-langpacks-2.35-22.fc36
respectively.  This leads to:
  STEP 8/15: RUN dnf -y swap glibc-minimal-langpack glibc-all-langpacks
  Last metadata expiration check: 0:00:03 ago on Wed Feb  1 12:37:04...
  Dependencies resolved.
  ======================================================================
   Package                   Arch      Version          Repository
  ======================================================================
  Installing:
   glibc-all-langpacks       x86_64    2.35-4.fc36      fedora
  Removing:
   glibc-minimal-langpack    x86_64    2.35-20.fc36     @koji-override-0
  Downgrading:
   glibc                     x86_64    2.35-4.fc36      fedora
   glibc-common              x86_64    2.35-4.fc36      fedora

That's unexpected.  Instead of upgrading all the glibc sub-packages to
the latest version from 'updates', it's downgrading them to the older
version from 'fedora'.

Similarly, the base fedora:36 image has bash-5.2.9-2.fc36.x86_64 from
koji-override-0, and there is bash-5.2.15-1.fc36.x86_64 in 'updates'.
This leads to:
  STEP 10/15: RUN dnf -y reinstall $(<missing-docs)
  Last metadata expiration check: 0:00:06 ago on Wed Feb  1 12:37:04...
  Package acl available, but not installed.
  No match for argument: acl
  Installed package bash-5.2.9-2.fc36.x86_64 (from koji-override-0) not
    available.

That's unexpected.  Instead of upgrading bash to the latest version from
'updates', it's simply skipping the 'reinstall', which means that the
documentation that was stripped out in the base image doesn't get
restored.

Updating all the RPM packages in the base 'fedora' image to match the
contents of the 'updates' repository before making any changes to the
image's package set will avoid such unexpected behaviour.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

[1] https://docs.fedoraproject.org/en-US/quick-docs/repositories/

https://github.com/containers/toolbox/pull/1226
2023-02-01 19:17:14 +01:00
..
Containerfile images: Avoid unexpected DNF behaviour when reinstalling or swapping 2023-02-01 19:17:14 +01:00
extra-packages Added new packages to images f36 AND f35 2022-09-14 07:00:57 -04:00
missing-docs images: add findutils and sudo to missing docs for f36+ 2022-10-13 07:18:06 -04:00
README.md images: Add fedora-toolbox image definition for Fedora 36 2021-11-19 03:27:45 +01:00

Toolbox logo landscape

Zuul Daily Pipeline

Arch Linux package Fedora package

Toolbox is a tool for Linux operating systems, which allows the use of containerized command line environments. It is built on top of Podman and other standard container technologies from OCI.

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 install tools for debugging in the usual way.

Toolbox solves this problem by providing a fully mutable container within which one can install their favourite development and debugging 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 toolbox environment is based on an OCI image. On Fedora this is the fedora-toolbox image. This image is used to create a toolbox container that seamlessly integrates with the rest of the operating system by providing 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..

Installation

Toolbox is installed by default on Fedora Silverblue. On other operating systems it's just a matter of installing the toolbox package.

Usage

Create your toolbox container:

[user@hostname ~]$ toolbox create
Created container: fedora-toolbox-33
Enter with: toolbox enter
[user@hostname ~]$

This will create a container called fedora-toolbox-<version-id>.

Enter the toolbox:

[user@hostname ~]$ toolbox enter
⬢[user@toolbox ~]$

Remove a toolbox container:

[user@hostname ~]$ toolbox rm fedora-toolbox-33
[user@hostname ~]$

Dependencies and Building

Toolbox requires at least Podman 1.4.0 to work, and uses the Meson build system.

The following dependencies are required to build it:

  • meson
  • go-md2man
  • systemd
  • go
  • ninja

The following dependencies enable various optional features:

  • bash-completion

It can be built and installed as any other typical Meson-based project:

[user@hostname toolbox]$ meson -Dprofile_dir=/etc/profile.d builddir
[user@hostname toolbox]$ ninja -C builddir
[user@hostname toolbox]$ sudo ninja -C builddir install

Toolbox is written in Go. Consult the src/go.mod file for a full list of all the Go dependencies.

By default, Toolbox uses Go modules and all the required Go packages are automatically downloaded as part of the build. There's no need to worry about the Go dependencies, unless the build environment doesn't have network access or any such peculiarities.

Distro support

By default, Toolbox creates the container using an OCI image called <ID>-toolbox:<VERSION-ID>, where <ID> and <VERSION-ID> are taken from the host's /usr/lib/os-release. For example, the default image on a Fedora 33 host would be fedora-toolbox:33.

This default can be overridden by the --image option in toolbox create, but operating system distributors should provide an adequately configured default image to ensure a smooth user experience.

Image requirements

Toolbox customizes newly created containers in a certain way. This requires certain tools and paths to be present and have certain characteristics inside the OCI image.

Tools:

  • getent(1)
  • id(1)
  • ln(1)
  • mkdir(1): for hosts where /home is a symbolic link to /var/home
  • passwd(1)
  • readlink(1)
  • rm(1)
  • rmdir(1): for hosts where /home is a symbolic link to /var/home
  • sleep(1)
  • test(1)
  • touch(1)
  • unlink(1)
  • useradd(8)
  • usermod(8)

Paths:

  • /etc/host.conf: optional, if present not a bind mount
  • /etc/hosts: optional, if present not a bind mount
  • /etc/krb5.conf.d: directory, not a bind mount
  • /etc/localtime: optional, if present not a bind mount
  • /etc/machine-id: optional, not a bind mount
  • /etc/resolv.conf: optional, if present not a bind mount
  • /etc/timezone: optional, if present not a bind mount

Toolbox enables sudo(8) access inside containers. The following is necessary for that to work:

  • The image should have sudo(8) enabled for users belonging to either the sudo or wheel groups, and the group itself should exist. File an issue if you really need support for a different group. However, it's preferable to keep this list as short as possible.

  • The image should allow empty passwords for sudo(8). This can be achieved by either adding the nullok option to the PAM(8) configuration, or by add the NOPASSWD tag to the sudoers(5) configuration.

Since Toolbox only works with OCI images that fulfill certain requirements, it will refuse images that aren't tagged with com.github.containers.toolbox="true" and com.github.debarshiray.toolbox="true" labels. These labels are meant to be used by the maintainer of the image to indicate that they have read this document and tested that the image works with Toolbox. You can use the following snippet in a Dockerfile for this:

LABEL com.github.containers.toolbox="true"

The label com.github.debarshiray.toolbox="true" was used in previous versions of toolbox but is currently deprecated.