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
It connects to the host's PackageKit instance, and tries to install the
packages on the host instead of inside the toolbox container. Remove it
unless there's a proper solution.
https://github.com/debarshiray/toolbox/issues/158
The shadow-utils package was added to the base toolbox images to ensure
the presence of the useradd(8) command. Currently the package is
already pulled in by various dependencies. Therefore, it doesn't
increase the size of the base image, but serves as a safeguard against
any inadvertent changes.
Currently the toolbox script identifies toolbox images and containers
by checking whether the com.redhat.component label matches
"fedora-toolbox". However, as per the Fedora Container Guidelines [1],
the com.redhat.com label should match the Red Hat Bugzilla component
name where bugs against the image should be reported. This means that
images derived from the base fedora-toolbox image would likely end up
overwriting it.
One option would've been to mandate that all toolbox images have the
"fedora-toolbox-" prefix in their names. However, it's better to avoid
putting limitations on how images can be named. The "fedora" name
wouldn't anyway work for images based on other distributions, and not
all images are going to use the Red Hat bugzilla for tracking bugs.
It's better to use a tag that's uniquely associated with the toolbox
project, and isn't tied to a particular distribution or bug tracker.
[1] https://fedoraproject.org/wiki/Container:Guidelines
For a locally built squashed fedora-toolbox:29 image [1], the size
reported by 'podman images' goes from 630 MB to 425 MB.
[1] Using: buildah bud --squash ...
There's no easy way to introspect the Kerberos configuration from the
command line. eg., the credential cache type being used, or the value
of the socket_path setting that denotes which socket the KCM service
will listen on. Therefore, it's assumed that the former is KCM if the
socket's path can be parsed from the sssd-kcm.socket unit.
Given the immutable nature of Podman containers, the toolbox container
and its corresponding image will have to be re-created if the host OS
is sufficiently re-configured.
The krb5-libs package was added to the base toolbox images to ensure
the presence of the /etc/krb5.conf.d directory with the correct
permissions. Currently, the package is already pulled in by various
dependencies. Therefore, it doesn't increase the size of the base
image, but serves as a safeguard against any inadvertent changes.
https://github.com/debarshiray/toolbox/pull/74
This is necessary for the toolbox script to work inside the toolbox
container [1]. Having the flatpak-spawn command, provided by the
flatpak-xdg-utils package, readily available in the base image makes
for a better out of the box experience.
The flatpak-xdg-utils package is not available on Fedora 28. Given
that Fedora 28 is getting close to the end of its life cycle, it's
probably not worth doing all the paperwork to offer the package there.
[1] Commit 5b3d234c9ehttps://github.com/debarshiray/toolbox/pull/54
The "fedora" prefix was used because this project was specifically
incubated to make it easier to hack on Fedora Silverblue. That and the
mix of upstream technologies (ie., Buildah and Podman) made it uniquely
"Fedora".
However, over time it has gotten clear that other groups, currently
Fedora downstreams like RHEL, are interested in it too. It won't be
surprising if in future it transcends the Fedora universe altogether.
Moreover, this project was inspired by coreos/toolbox [1]. There are
good reasons and enough interest to have a unified toolbox project
that addresses the needs of both Fedora CoreOS and Silverblue.
Therefore, it is best to drop the "fedora" prefix and call the whole
thing just "toolbox".
No extra effort was made to retain compatibility with the older name
due to the project's young age. Its userbase is limited to the earliest
of early adopters, and the benefits of a clean break outweigh the
loss of compatibility.
The OCI images and the toolbox container still retain the "fedora"
prefix to disambiguate them from their counterparts from other
operating systems.
[1] https://github.com/coreos/toolboxhttps://github.com/debarshiray/toolbox/issues/8
It would be good to have Dockerfiles for multiple Fedora versions, and
possibly even other operating systems like Red Hat Enterprise Linux or
CentOS, so that people can use the toolbox on different host OSes.
In the future, it would be nice to have multiple toolbox containers
corresponding to different OSes exist side by side. One could then
have a Fedora 29 environment on a Fedora 28 host and so on.
