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
- OSTree systems aren't fully immutable, you *can* install things
we just discourage it
- fedora-toolbox can (and should!) be used on non-OSTree based
systems as well
https://github.com/debarshiray/fedora-toolbox/pull/43
Simplify the prompt. Most people are going to use the Fedora package.
Hence, the prompt doesn't need to reflect the fedora-toolbox Git tree
as the current directory.
Silverblue, and rpm-ostree more generally are moving to
HOME=/var/home/$USER and make the /home symlink just a compatibility
feature. See:
https://github.com/projectatomic/rpm-ostree/pull/1726
Matching what the host does will reduce weird side-effects. Propagate
$HOME into the container to avoid mismatches in /etc/default/useradd,
and if the host has /home as a symlink to /var/home, do the same for
the toolbox.
https://github.com/debarshiray/fedora-toolbox/pull/34
Currently, the non-root interactive shells were being spawned with a
full set of capabilities. This led to unexpected root-like behaviour
for non-root users. All capability sets, except the Permitted (or
CapBnd) set, should be cleared to match the usual state of a host
interactive shell for non-root users.
It doesn't look like podman offers a way to forward CapBnd from the
host without touching the other sets. If '--privileged' is used with
'podman create', then it forwards CapBnd but also initializes the
others to have a full set of capabilities. If it's not used, then it
doesn't touch anything other than CapBnd, but only forwards a subset
of the host's CapBnd, which means that using sudo to attain elevated
privileges inside the toolbox won't give the full set of capabilities
as on the host.
It might be so that having a smaller CapBnd actually doesn't matter.
However, until that's proven true, it's safer to insist on having
'--privileged' forward the full set, and then clear up the other sets
on our own.
https://github.com/debarshiray/fedora-toolbox/issues/16
