Otherwise, it breaks 'podman start ...' in Podman commit
52df1fa7e054d577 [1]. Even though the podman regression was fixed in
commit 21bc766ee3829776 [2], it's prudent to also fix the toolbox
script to be more correct.
This problem isn't localized to a single command, but spans across
'create' and 'enter'. If a customized toolbox image created by the
'create' command has volumes for host bind mounts, then it will break
'podman start ...' in the 'enter' command. Therefore, users need to be
encouraged to recreate both their customized toolbox images. This is
currently done through the --verbose debug logs to avoid needless
noise because the regression was restricted to development snapshots
of podman.
Toolbox containers created from images built by broken Podman versions
between commits 52df1fa7e054d577 and 21bc766ee3829776, and broken
toolbox scripts prior to this commit, will continue to not start.
Those toolboxes and their corresponding customized images need to be
re-created with at least one of the components, either podman or this
script, fixed.
Note that 'podman inspect --type container ...' doesn't have a Go
template field for "Image". However, "ImageName" gracefully falls back
to the ID for images without a human-readable name, which is arguably
better than always using an ID.
As suggested by Daniel J Walsh and Giuseppe Scrivano.
[1] https://github.com/containers/libpod/commit/52df1fa7e054d577
[2] https://github.com/containers/libpod/commit/21bc766ee3829776https://github.com/containers/libpod/issues/2441https://github.com/debarshiray/toolbox/issues/62
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
Currently, 'toolbox list' doesn't handle errors thrown by any of the
functions used by it. If something fails, it will send the error
message to the standard error output and continue trying to list other
things.
Instead, it's better to ensure that all the internal functions have
succeeded before listing anything. If there's an error, print the error
message but don't mix it with attempts to list other things so that
the failure mode is cleaner and it's more obvious that something went
wrong.
Listing toolbox containers involves parsing the output of 'podman ps'
and rearranging the columns into a table. Parsing and rearranging
output is inherently brittle, and there's no guarantee that podman
itself won't fail. Therefore, it's prudent to sprinkle some error
handling.
Listing toolbox images involves parsing the output of 'podman images'
and rearranging the columns into a table. Parsing and rearranging
output is inherently brittle, and there's no guarantee that podman
itself won't fail. Therefore, it's prudent to sprinkle some error
handling.
Unsetting the IFS variable doesn't disable field splitting. It makes
the shell behave as if the default field separators (ie. <space>,
<tab> and <newline>) are in play. See:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
The original reason for unsetting IFS was to disable field splitting,
which was clearly wrong. Moreover, there was no need to worry about it
in the first place, because none of the command substitutions being
performed involve multiline output where field splitting would have
become relevant.
Fallout from 5e4e63a11b
... detected by https://www.shellcheck.net/.
The opening solid bracket (ie. [) is actually a command like any other.
It expects it's final argument to be the closing bracket (ie. ]). Thus,
the redirection needs to be after the trailing bracket.
Fallout from 80f25c6924
A truly seamless developer experience requires erasing the divide
between the host and the toolbox container as much as possible.
Currently, various tools don't work at all when used from inside the
toolbox because they expect to be run on the host. eg., flatpak,
podman, and the toolbox script itself. This puts a significant enough
cognitive burden on the developer. At the very least, the human
operator needs to keep track of the context in which those commands
are being issued.
To make things better, the toolbox script has been made aware of the
context in which it is running. If it detects that it's running inside
the toolbox container, denoted by a 'podman exec ...' parent process
and the presence of /run/.containerenv, then it tries to forward its
own invocation to the host over D-Bus using 'flatpak-spawn --host' [1].
This uses the HostCommand method on the org.freedesktop.Flatpak D-Bus
service underneath to do the forwarding.
The process offering the org.freedesktop.Flatpak service doesn't have
some variables, like COLORTERM and TERM, set in its environment, and
their absence hinders the use of interactive shells. This is addressed
by tunneling the same set of environment variables that are also passed
to podman.
[1] http://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-spawnhttps://github.com/debarshiray/toolbox/pull/54
A subsequent commit will leverage this to tunnel the same environment
variables over D-Bus when the toolbox script forwards its own
invocation over 'flatpak-spawn --host'. This is necessary because the
process offering the underlying org.freedesktop.Flatpak D-Bus service
used by 'flatpak-spawn --host' doesn't have some variables, like
COLORTERM and TERM, set in its environment, and their absence hinders
the use of interactive shells.
Instead of keeping two separate hard coded lists, one for
flatpak-spawn and another for podman, it's better to use the same set
for both to avoid silly and weird bugs.
https://github.com/debarshiray/toolbox/pull/54
Shell scripts are archaic enough by themselves. For the sake of
readability it's better to stick to a smaller subset of features
that's already being widely used, instead of introducing slightly
different ways of doing the same thing.
Unless there's a pressing user-visible reason to introduce tr(1), it's
better to keep using sed(1).
It's common practice to track down a process while developing. This
could be a process that's repeatedly crashing, or something that's
misbehaving by using up too many resources. Being able to seamlessly
look at what's happening on the host makes for a better developer
experience.
The toolbox doesn't intend to provide a segregated security domains,
so this is fine.
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
Using "$0" leads to printing the entire path to the fedora-toolbox
script, which adds visual noise to the output. Command line tools like
GNU Coreutils and Git remove any leading directory components from
the path, which seems like a reasonable trade-off between aesthetics
and verbosity.
https://github.com/debarshiray/fedora-toolbox/pull/50
