A new help command has been added which either shows the toolbox(1)
manual or a manual page for a specific command. The '--help' flag is
now identical to the help command and can be placed after the COMMAND
segment in the list of command line arguments.
Due to a bizarre quirk in less(1) [1], the default pager used to render
manuals on most systems, the man(1) invocations need the standard error
stream to point to the controlling terminal, if any, to work. This
interferes with the global redirection of standard error to /dev/null
in the absence of the '--verbose' flag, and is worked around by
redirecting to standard output instead.
[1] It turns out that less(1) tries to open the controlling terminal
device /dev/tty to get to the keyboard for accepting input.
However, it doesn't have a controlling terminal when invoked via
D-Bus to render a manual on the host. It then strangely falls back
to using the standard error stream to get to the keyboard.
https://github.com/debarshiray/toolbox/pull/200
The Silverblue welcome message was being displayed incorrectly on
other OSTree based OS's (Fedora Atomic Host, Fedora CoreOS, etc).
Note that none of the stable Silverblue releases that have shipped so
far (ie., until Silverblue 30) have had 'silverblue' as the VARIANT_ID.
This makes the check a bit more convoluted that it should have been.
https://github.com/debarshiray/toolbox/pull/236
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
Toolbox containers created prior to commit 8db414ddc2 didn't have
/run/host/monitor inside them. Therefore, those containers were having
their /etc/localtime and /etc/timezone redirected to locations that
didn't exist.
Instead of selectively checking locations that were added later, it's
more manageable to handle all bind mounted target locations the same.
https://github.com/debarshiray/toolbox/pull/207
Creating /run/.toolboxenv in run(), outside the entry point, has the
advantage of automatically working with older toolbox containers.
However, at some point those containers are going to get end-of-lifed.
Then it would be nice to have this bit of initialization tucked away
inside the entry point.
https://github.com/debarshiray/toolbox/pull/206
Copying files into a running container is considered inherently hacky.
Rootful Podman can pause a container using 'podman cp --pause ...'
during the copy, but that's not possible when used rootless.
Secondly 'podman cp' has suffered from a series of regressions lately.
First there was the problem with how the --pause flag was handled [1],
and then /etc/profile.d/toolbox.sh was getting created as a
directory [2], not regular file, by:
$ podman cp \
--pause=false \
/etc/profile.d/toolbox.sh \
"$container":/etc/profile.d
Try to side-step all that by using $XDG_RUNTIME_DIR as a conduit to
share the file with the container and using plain cp(1) to place it in
the toolbox container's /etc/profile.d.
[1] Commit e715ff2f9bhttps://github.com/debarshiray/toolbox/pull/193
[2] https://github.com/containers/libpod/issues/3384https://github.com/debarshiray/toolbox/issues/196
It was working because 'toolbox_container' is a global variable.
However, given that the name of the toolbox container is already being
passed as an argument to the function, it's better not to use the
global variable.
Fallout from c492907c12https://github.com/debarshiray/toolbox/pull/201
This will let GNOME Terminal preserve the current toolbox container, if
any, when opening a new terminal. Since this is mainly beneficial to
users of an interactive shell inside a toolbox container, the escape
sequences are only emitted by 'toolbox enter', and not 'toolbox run'.
The OSC 777 escape sequence is taken from Enlightenment's Terminology:
https://phab.enlightenment.org/T1765
It's a VTE-specific extension until a standard escape sequence is
agreed upon across multiple different terminal emulators [1].
[1] https://gitlab.freedesktop.org/terminal-wg/specifications/issues/17https://github.com/debarshiray/toolbox/pull/199
The whole idea behind commit 66e982af72 was to set up $HOME and
/home to match the host. Therefore, it's pointless to check if /home
is a symbolic link or not inside the toolbox container. The state of
/home needs to be checked on the host, and then the toolbox container
adjusted accordingly.
One crucial difference is that the toolbox container is created before
its /home can be adjusted. Earlier, there was the user-specific
customized image, whose /home was adjusted first, and then the toolbox
container created from that. This boils down to the following
invocation happening before the symbolic link can be set up:
podman create --volume "$HOME":$HOME":rslave --workdir "$HOME" ...
As a result, on host operating systems like Fedora 29 where /home is a
symbolic link with $HOME pointing inside it, Podman populates /home
with the user's sub-directory inside the toolbox container. This
prevents the subsequent 'rmdir $HOME' from working, and consequently
kills the container's entry point.
Compare that to Fedora 30 and newer where this problem doesn't occur
because /home is a symbolic link but $HOME points inside the target
/var/home directory.
This is why $HOME is canonicalized before bind mounting it into the
container and the container's working directory is reverted back to the
default (ie. /).
Fallout from 8b84b5e460https://github.com/debarshiray/toolbox/issues/185
Rootless containers cannot be paused while data is copied into them.
The '--pause' flag used to default to 'true', but it would be silently
ignored until recently [1,2] when it got turned into an error in
podman-1.4.0. Therefore, it has to be explicitly toggled using
'--pause=false'. Otherwise, it would lead to:
toolbox: copying /etc/profile.d/toolbox.sh to container fubar
Error: cannot copy into running rootless container with pause set -
pass --pause=false to force copying
toolbox: unable to copy /etc/profile.d/toolbox.sh to container fubar
The '--pause' flag was latter changed to default to 'false' [3], but
it's good to be defensive and have this addressed from both sides.
Note that 'podman cp --pause false ...' doesn't work. It's necessary to
use the '=' because it gets confused trying to parse the
space-separated source and destination path arguments.
[1] Podman commit 48e35f7da70c24ed
https://github.com/containers/libpod/commit/48e35f7da70c24ed
[2] Podman commit 57d40939792719e6
https://github.com/containers/libpod/commit/57d40939792719e6
[3] Podman commit d40b450afdc9784a
https://github.com/containers/libpod/commit/d40b450afdc9784ahttps://github.com/debarshiray/toolbox/pull/193
This is relevant when running on hosts where the current user might
have been created long ago with an old version of shadow-utils, and
the host OS has been upgraded in-place ever since.
https://github.com/debarshiray/toolbox/issues/174
Things like the proprietary NVIDIA driver need access to devices
directly inside the /dev directory (eg., /dev/nvidia0 and
/dev/nvidiactl), and since such devices can come and go at runtime they
cannot be bind mounted individually. Instead, the entire directory
needs to be made available.
https://github.com/debarshiray/toolbox/issues/116
Most Debian based images use the 'sudo' group for sudo(8) access, while
Fedora uses the 'wheel' group. Hence check if either group exists
before attempting to add the user to it and fail otherwise.
https://github.com/debarshiray/toolbox/pull/167
The unary logical negation operator (ie. !) was getting associated with
the 'cd /etc' instead of the entire sequence. As a result, neither
/etc/hosts nor /etc/resolv.conf were getting symlinked.
Fallout from 8b84b5e460https://github.com/debarshiray/toolbox/pull/168
The prefixed spinner messages look odd because neither the download
confirmation prompts nor the hints on how to enter a container have
them. It's better to only prefix the debug and error messages so as to
disambiguate their origins.
https://github.com/debarshiray/toolbox/pull/164
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
A subsequent commit will create toolbox container names based on both
the base image and the user-specific customized image. This will make
it easier to read.
https://github.com/debarshiray/toolbox/pull/160
A subsequent commit will add a new command to configure a toolbox
container after it has been created. This command is meant to be the
container's entry point, which runs before /run/.toolboxenv gets
created. Given that the entry point will be set by 'toolbox create'
it's safe to assume that it's a toolbox container anyway.
https://github.com/debarshiray/toolbox/pull/160
A subsequent commit will add a new command to configure a toolbox
container after it has been created. This command is meant to run
inside the container without being forwarded to the host. Therefore,
just running inside a container doesn't mean that flatpak-spawn(1) is
mandatory.
This should help with toolbox containers created from images which
don't have flatpak-spawn(1) in them. eg., the fedora-toolbox base image
for Fedora 28.
https://github.com/debarshiray/toolbox/pull/160
Consolidate the code to forward commands to the host in one place
instead of doing it repeatedly for each command. This reduces the
levels of indentation in the code, making it easier to read.
https://github.com/debarshiray/toolbox/pull/160
A subsequent commit will add a new command to configure a toolbox
container after it has been created. This command is meant to be the
container's entry point, and will need to do things as root:root
relative to the user namespace.
Even though root:root is the default in 'podman create', explicitly
specifying it overrides any other value inherited from the
user-specific customized image. eg., older images had $USER as the
default user.
https://github.com/debarshiray/toolbox/pull/160
Commit 8127daa29e added the com.github.debarshiray.toolbox label
to the user-specific customized image generated by the 'create'
command, which gets inherited by toolbox containers using the image.
However, there might be really old images lying around in users' caches
that don't have the label, and in those cases the damage can be
limited by adding it directly to the newly created toolbox container.
Moreover, a subsequent commit will remove the need for the
user-specific customized image, and which will make this change
mandatory.
https://github.com/debarshiray/toolbox/pull/160
Even though buildah-unshare(1) does mention the need for the dashes,
the buildah-1.8 development builds do work without them. However,
buildah-1.7 is more pedantic and insists on having the dashes.
https://github.com/debarshiray/toolbox/issues/152
KCM is the only type of Kerberos credential cache that can seamlessly
work across the host and the toolbox container. In case the host isn't
using KCM, then Kerberos will error out inside the toolbox container,
which is fine.
https://github.com/debarshiray/toolbox/pull/162
Currently, the toolbox script depends on both the buildah and podman
commands. However, both are Go programs, and like all Go programs the
absense of shared libraries leads to bigger binaries. eg., the buildah
and podman binaries are approximately 22 MB and 48 MB respectively,
whereas the flatpak binary is a mere 1.4 MB.
Due to this, there's some nascent desire from the Endless OS folks to
reduce the dependency footprint of the toolbox script by replacing
Buildah with the corresponding Podman commands. This is a step in that
direction.
https://github.com/debarshiray/toolbox/pull/161
Currently, the toolbox script depends on both the buildah and podman
commands. However, both are Go programs, and like all Go programs the
absense of shared libraries leads to bigger binaries. eg., the buildah
and podman binaries are approximately 22 MB and 48 MB respectively,
whereas the flatpak binary is a mere 1.4 MB.
Due to this, there's some nascent desire from the Endless OS folks to
reduce the dependency footprint of the toolbox script by replacing
Buildah with the corresponding Podman commands. This is a step in that
direction.
https://github.com/debarshiray/toolbox/pull/159
