Using the word 'containerized' gives the false impression of heightened
security. As if it's a mechanism to run untrusted software in a
sandboxed environment without access to the user's private data (such as
$HOME), hardware peripherals (such as cameras and microphones), etc..
That's not what Toolbx is for.
Toolbx aims to offer an interactive command line environment for
development and troubleshooting the host operating system, without
having to install software on the host. That's all. It makes no
promise about security beyond what's already available in the usual
command line environment on the host that everybody is familiar with.
https://github.com/containers/toolbox/issues/1020
Mention that Toolbx is meant for system administrators to troubleshoot
the host operating system. The word 'debugging' is often used in the
context of software development, and hence most readers might not
interpret it as 'troubleshooting'.
https://github.com/containers/toolbox/pull/1182
The previous commit added a means to generating the completion scripts
and this one plugs that into the build system.
A new build option 'install_completions' has been introduced. Set to
'True' by default.
Completions for bash and fish use pkg-config for getting the preferred
install locations for the completions. If the packages are not
available, fallbacks are in-place.
The 'completion' subdir has been kept to work around the ideology of
Meson that does not allow creating/outputing files in subdirectories nor
using the output of custom_target() in install_data().
https://github.com/containers/toolbox/pull/840
Now that there's a website at https://containertoolbx.org/ it makes
more sense to link to it instead of linking back to the same location
where the README.md resides.
All these tools were only used by the POSIX shell implementation. The
Go implementation never used them.
Note that the test suite still invokes id(1) inside a container.
However, it's not a user-visible requirement, and hence is not a hard
requirement for Toolbox images.
https://github.com/containers/toolbox/pull/934
Since /etc/machine-id is bind mounted into the toolbox container from
the host operating system, it doesn't make sense to make it mandatory
for images to have that file. Apparently, (some?) Arch Linux images
don't have /etc/machine-id.
Since a missing containerPath for a directory is handled the same way,
there's no reason not to do the same for regular files. It will make
life a bit easier for those creating toolbox images for different
distributions.
https://github.com/containers/toolbox/pull/710
Without this I get an error:
```
$ meson -Dprofile_dir=/etc/profile.d builddir
The Meson build system
Version: 0.55.3
Source dir: /home/user/toolbox
Build dir: /home/user/toolbox/builddir
Build type: native build
Project name: toolbox
Project version: 0.0.97
meson.build:1:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', 'icc']
The follow exceptions were encountered:
Running "cc --version" gave "[Errno 2] No such file or directory: 'cc'"
Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc'"
Running "clang --version" gave "[Errno 2] No such file or directory: 'clang'"
Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc'"
Running "icc --version" gave "[Errno 2] No such file or directory: 'icc'"
A full log can be found at /home/user/toolbox/builddir/meson-logs/meson-log.txt
```
Using the word 'unprivileged' confuses readers because it means
different things to different people. eg., it can mean 'rootless' or
'sandboxed', which are quite different things. It becomes even more
confusing given the ongoing work to make 'sudo toolbox ...' work.
It's nice to mention that Toolbox is targetted at Linux operating
systems and that it relies on standard container technologies from OCI.
https://github.com/containers/toolbox/pull/597
Since Podman 2.0.5, containers that were created with
'podman create --userns=keep-id ...' automatically get the user added
to /etc/passwd [1]. However, this user isn't as fully configured as it
needs to be. The home directory is specified as '/' and the shell is
/bin/sh.
Note that Podman doesn't add the user's login group to /etc/group [2].
This leads to the following error message when entering the container:
/usr/bin/id: cannot find name for group ID 1000
It's expected that this will be fixed in Podman itself.
Therefore, the entry point needs to call usermod(8) to update the user,
instead of using useradd(8) to create it.
[1] Podman commit 6c6670f12a3e6b91
https://github.com/containers/podman/pull/6829
[2] https://github.com/containers/podman/issues/7389https://github.com/containers/toolbox/issues/523
Toolbox is being increasingly used outside the Fedora universe. Endless
OS already uses it, and there's some interest in using it on Arch
Linux, Red Hat Enterprise Linux and Ubuntu. Therefore, it's a good
idea to clearly document what's necessary for a smooth Toolbox user
experience on a given operating system distribution.
Note that this might not match the current reality of the code, which
is predominantly developed, tested and used on Fedora. This is a step
towards formally specifying what an OS distributor is expected to
provide. The code can then be iteratively improved to match the
specification.
https://github.com/containers/toolbox/pull/300
Toolbox is being used with Endless OS, which is an OSTree based
operating system built out of Debian packages, not RPMs; and in the
Fedora universe, CoreOS is being increasingly treated as a primary
use-case for Toolbox alongside Silverblue.
https://github.com/containers/toolbox/pull/299
This works by configuring the toolbox container after it has been
created, instead of before. The toolbox script itself is mentioned as
the entry point of the container, which does 'exec sleep +Inf' once the
initialization is done.
A new command 'init-container' was added to perform the initialization.
It is primarily meant to be used as the entry point for all toolbox
containers, and must be run inside the container that's to be
initialized. It is not expected to be directly invoked by humans, and
cannot be used on the host.
As a result, the default name for the toolbox containers is now
fedora-toolbox-<version-id>, not fedora-toolbox-<user>-<version-id>.
For backwards compatibility, 'toolbox enter' and 'toolbox run' will
continue to work with containers using the old naming scheme.
https://github.com/debarshiray/toolbox/pull/160
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
