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>
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
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.
