This is the full definition of the UBI-based toolbox image published for
RHEL 9.1 [1] at registry.access.redhat.com/ubi9/toolbox:9.1. Note that
the Dockerfile used to build this image was already available to the
public [2], but didn't include all the files necessary to build it.
However, this has some minor deviations from the published image. The
FROM line has been changed to registry.access.redhat.com/ubi9:9.1 so
that it can be built outside Red Hat's build system and always points to
the desired RHEL version. The extra-packages file doesn't have
gnupg2-smime because it doesn't seem to be actually part of the UBI RPM
repositories, and it's not clear how it works inside Red Hat's build
system. Otherwise, 'podman build' fails with:
STEP 11/14: RUN dnf -y install $(<extra-packages)
...
Last metadata expiration check: 0:00:23 ago on Tue Feb 7 18:50:13...
...
No match for argument: gnupg2-smime
...
Error: Unable to find a match: gnupg2-smime
Error: building at STEP "RUN dnf -y install $(<extra-packages)": while
running runtime: exit status 1
[1] https://catalog.redhat.com/software/containers/ubi9/toolbox/61532d7dd2c7f84a4d2ed86b
[2] https://catalog.redhat.com/software/containers/ubi9/toolbox/61532d7dd2c7f84a4d2ed86b?container-tabs=dockerfilehttps://github.com/containers/toolbox/pull/1232
The canonical copy of README.md contains banners and labels in the
header that aren't useful when the file is shipped as part of the
images. Hence, those were removed.
Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.
https://github.com/containers/toolbox/pull/1231
It turns out that at least since Fedora 30 [1], the gnupg2 package has
been part of the fedora base image, because it's required by the dnf
package:
dnf -> python3-dnf -> python3-libdnf -> libdnf -> gpgme -> gnupg2
Hence, the need to restore the gnupg2 documentation that was stripped
out in the base image.
Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.
[1] It's difficult to find out if the gnupg2 package wasn't part of the
fedora base image before Fedora 30, because those images are no
longer available from registry.fedoraproject.org.
https://github.com/containers/toolbox/pull/1228
Building an OCI image leads to so much spew that it's hard to notice if
something unexpected happened, and as seen in the previous commit [1],
unexpected things do happen.
Therefore, this adds a built-in test to ensure that the desired files
are actually present in the final image. Right now it only checks the
presence of some representative manuals to ensure that the packages
listed in the 'missing-docs' file really do get reinstalled, and the
documentation that was stripped out in the base image really does get
restored.
Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.
[1] Commit 1fc50176c9https://github.com/containers/toolbox/pull/1226https://github.com/containers/toolbox/pull/1226
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
Noticed today that `man xargs` was returning the POSIX manpage instead
of the one shipped by `findutils`.
Signed-off-by: Jonathan Lebon <jonathan@jlebon.com>
The following packages have also been added to Fedora 38 image:
mesa-dri-drivers
mesa-vulkan-drivers
vulkan-loader
Fixing up fedora 38 image to match the changes made earlier on fedora 37.
Signed-off-by: Nieves Montero <nmontero@redhat.com>
This new packet allows the user to set a locale inside the
toolbox and make locale dependent commands work
https://github.com/containers/toolbox/issues/60
Signed-off-by: Nieves Montero <nmontero@redhat.com>
The following packages have also been added to images f36 and f35:
mesa-dri-drivers
mesa-vulkan-drivers
vulkan-loader
https://github.com/containers/toolbox/pull/1124
Signed-off-by: Nieves Montero <nmontero@redhat.com>
The following packages have been added to the
image to make OpenGL and Vulkan work:
mesa-dri-drivers
mesa-vulkan-drivers
vulkan-loader
https://github.com/containers/toolbox/issues/1110
Signed-off-by: Nieves Montero <nmontero@redhat.com>
Currently, the entry point of a Toolbox container runs updatedb(8) on
start-up, which can be very I/O intensive. This might be a hindrance
when troubleshooting performance problems on a host, or when
re-creating containers somewhat more frequently.
Users can install the mlocate RPM and restart their containers to
enable locate(1).
Only the images for currently maintained Fedoras (ie., 34, 35 and 36)
were updated.
https://github.com/containers/toolbox/pull/938
There's no need to specify a CMD in a Toolbox image because it's
specified by 'toolbox create', through 'podman create', when creating a
container.
A CMD was specified [1] because the Fedora Container Guidelines
requires it [2]. The idea behind the guidelines is that the right
thing should happen when one runs:
$ podman run <image>
However, that only makes sense for images targeting single service
containers. Toolbox containers and images are different - they are not
meant to be used like that to run a single one-off service.
Conceptually, 'running' a Toolbox container is expected to provide the
user with a reasonable interactive command line experience. Arguably,
that means offering something like /bin/bash, not /bin/sh.
Also, note that when the CMD was introduced [1], Toolbox containers
were actually created, through 'podman create', with /bin/sh as their
entry points. So, it did make some sense. However, things have changed
since then [3]. The entry point is now 'toolbox init-container'. It's
not possible to mention it in the Toolbox image because the
/usr/bin/toolbox binary isn't present in the image, and it's not meant
to be present.
Therefore, today, /bin/sh is simply not the right fit for a Toolbox
image's CMD. A better option would be /bin/bash.
Note that the fedora base images have their CMD set to /bin/bash, which
is inherited by the fedora-toolbox images.
So, there are two options. Either repeat the same CMD in the
fedora-toolbox images and satisfy the guidelines, or take some
liberties and let the CMD be inherited from the fedora base images.
This commit takes the latter option. People tend to use the
fedora-toolbox images as the starting point for other custom Toolbox
images, sometimes for other operating system distributions. It's
better to keep them minimal to avoid implying extra requirements. In
this case, the CMD is an abstract concept, and the actual entry point
is 'toolbox init-container' as specified by 'toolbox create'.
Specifying /bin/bash might discourage people from creating custom
images that are only meant to have /bin/zsh.
Also, note that the current CMD was actually '/bin/sh -c /bin/sh', not
/bin/sh. Unless a CMD is specified as an array of command line
arguments, it's passed as a single argument to '/bin/sh -c' [4]. So,
this:
CMD foo bar
... is the same as:
CMD [ "/bin/sh", "-c", "foo bar" ]
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
This reverts commit 5cc2678a36.
[1] Commit 5cc2678a36
[2] https://docs.fedoraproject.org/en-US/containers/guidelines/creation/
[3] Commit 8b84b5e460https://github.com/containers/toolbox/pull/160
[4] https://docs.docker.com/engine/reference/builder/#cmdhttps://github.com/containers/toolbox/issues/885
The util-linux package was added to ensure the presence of the mount(8)
command. Currently the package is already pulled in by various
dependencies. Therefore, it doesn't increase the size of the image, but
serves as a safeguard against any inadvertent changes.
Note that starting from Fedora 35 onwards, the fedora base images no
longer have mount(8), which increases the importance of this change.
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
https://github.com/containers/toolbox/issues/929
It's true that the fedora base images no longer come with
coreutils-single, but they used to, and the ubi base images still do.
Therefore, it's worth being extra defensive about this.
It's better to make the build system execute one extra redundant
command than expose users to a bug because of a change that snuck in
unnoticed.
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
This reverts commit 033ed71ec1.
https://github.com/containers/toolbox/pull/931
Due to docker rate limiting we can not rely in docker.io for
retrieving the images.
This was detected when executing our tests for podman fedora
gating pipeline. Our busybox image was not downloaded and
one of the list tests was failing.
A while ago, 'podman build' stopped supporting COPY with relative
symbolic links [1]. Therefore, these image definitions can't be used
without first temporarily removing the symbolic links, which is
annoying.
The downside is that the copies of README.md now has to be separately
updated, which isn't that big of a hassle compared to the problem that
it fixes.
[1] https://github.com/containers/buildah/issues/1952https://github.com/containers/toolbox/pull/723
Since Fedora 33, `nano` is the default editor[0]. It needs to be
included in the fedora-toolbox image to have the standard Fedora
experience inside the container.
[0] https://fedoraproject.org/wiki/Changes/UseNanoByDefault
The nss-mdns plugin for the GNU Name Service Switch (or NSS)
functionality of the GNU C Library is necessary to resolve the .local
mDNS domain. The plugin talks to the Avahi daemon running on the host
to resolve the names.
https://github.com/containers/toolbox/issues/209
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
It's necessary to propagate the XAUTHORITY environment variable from
the host when an X11 client is run as 'sudo <some-client>'. If an X11
client is started inside a 'su -' session, then xauth(1) needs to be
present so that pam_xauth.so can add a new XAUTHORITY environment
variable to the 'su -' session.
https://github.com/containers/toolbox/pull/572
The gvfs-client package is necessary for GIO-based processes inside
toolbox containers to use the GVfs backend and volume monitor daemons,
and it comes preinstalled on Fedora Silverblue and Workstation.
Only the images for currently maintained Fedoras (ie., 31, 32 and 33)
were updated.
https://github.com/containers/toolbox/pull/466
This fixes the following build failure:
atomic_reactor.util - Package chkconfig available, but not installed.
atomic_reactor.util - No match for argument: chkconfig
atomic_reactor.util - Package dbus-daemon available, but not
installed.
atomic_reactor.util - No match for argument: dbus-daemon
atomic_reactor.util - Package rpm-plugin-systemd-inhibit available,
but not installed.
atomic_reactor.util - No match for argument:
rpm-plugin-systemd-inhibit
...
...
...
atomic_reactor.util - ERROR - {'errorDetail': {'code': 143,
'message': "The command '/bin/sh -c dnf -y reinstall
$(<missing-docs)' returned a non-zero code: 143"}, 'error': "The
command '/bin/sh -c dnf -y reinstall $(<missing-docs)' returned a
non-zero code: 143"}
The older com.github.debarshiray.toolbox label is still used in most
places as an alias for the new name for the sake of simplicity and
compatibility; except in 'create', where the new label is explicitly
specified in addition to the older one to help popularize it via newly
created toolbox containers.
The older com.github.debarshiray.toolbox label should eventually be
dropped, but before that, the even older use of com.redhat.component
for tagging needs to be phased out. The com.github.debarshiray.toolbox
label was introduced in commit 0ab6eb7401, as part of Toolbox
0.0.8, right before the release of Fedora 30 [1]. Therefore,
com.redhat.component needs to stay at least until Fedora 29 is
supported.
[1] https://fedoraproject.org/wiki/Releases/30/Schedulehttps://github.com/containers/toolbox/pull/293
