Some users tend to put random throwaway files in /tmp, so having that
location shared across the host operating system and toolbox containers
makes it a more pleasant user experience.
One nice side-effect of this is that it also makes the local file
system socket in /tmp/.X11-unix used by X11 clients available to
toolbox containers. So far, X11 clients inside toolbox containers used
the local abstract socket. However, since GNOME 3.38, Mutter no longer
listens on the abstract socket and only uses the file system socket to
start the Xwayland server [1]. Therefore, this makes it possible to
run X11 clients inside toolbox containers running on a GNOME 3.38 host.
[1] Mutter commit e2123768f635ee89
https://gitlab.gnome.org/GNOME/mutter/-/issues/1289https://github.com/containers/toolbox/issues/562
This prevents devices from losing properties that would otherwise be
set on the host operating system. It's useful when developing software
like PipeWire that uses libudev to enumerate devices.
https://github.com/containers/toolbox/issues/468
The redirectPath function used to error out when handling directories,
if the path inside the container was initially absent. There's no real
reason for this, and some containers failed to start because the
/media directory was absent from them. This can happen as a
consequence of Fedora's filesystem RPM failing 'dnf update'
transactions inside containers:
$ toolbox enter f33-to-upgrade
$ dnf --assumeyes --enablerepo=fedora --disablerepo=rawhide update
<...>
Failed:
filesystem-3.14-2.fc32.x86_64
filesystem-3.14-3.fc33.x86_64
Error: Transaction failed
Therefore, it's better to not worry about the path being initially
absent, and be more forgiving and robust.
https://github.com/containers/toolbox/issues/539
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
... and other hybrid set-ups where the host and container OSes aren't
the same.
The entry point of a toolbox container already runs as root:root.
Therefore, there's no need to run it with an additional group.
Interactive shells spawned by 'sudo su -' both inside the container
and on the host don't run with such an additional group either. They
run just as root:root.
This prevented toolbox containers from starting up on Fedora CoreOS
hosts, because CoreOS has both the 'sudo' and 'wheel' groups but the
fedora-toolbox images only have the 'wheel' group. Therefore, it
ended up calling 'podman create --group-add sudo ...', and since the
'sudo' group was missing from the image, the container failed to start.
The --group-add flag was added in commit 4bda42d414 when the
entry point ran as $USER as specified in the user-specific customized
image. The additional group was specified to retain consistency with
interactive shells run as $USER.
Since then, things have changed. There's no longer any user-specific
customized image and commit f74400f450 made the entry point run
as root:root. The --group-add flag should have been removed as part of
those changes.
https://github.com/containers/toolbox/issues/423
It tries to loosely mimic ncurses to look up a terminfo entry for the
current terminal, as mentioned in the terminfo(5) manual. Unlike
ncurses, it doesn't handle TERMINFO_DIRS, though, to avoid parsing an
array of directories for the sake of simplicity.
Every line of code in this file is part of the interactive shell's
start-up sequence, which makes it a trade-off between correctness and
speed. Therefore, the purpose of this warning is not to exhaustively
catch all possible corner cases, but to serve as a convenience in the
majority of cases. Ultimately, if someone is using an exotic terminal
set-up, then a missing warning is a minor price to pay in order to not
slow things down for the vast majority of users who don't.
Based on code written by Mert Alp Taytak:
https://github.com/containers/toolbox/pull/515https://github.com/containers/toolbox/issues/505
Currently toolbox containers can get misconfigured if some
configuration files on the host are absolute symbolic links to some
other location.
For example, when systemd-resolved is used to manage /etc/resolv.conf
on the host, and if the file is an absolute link to
/run/systemd/resolve/stub-resolv.conf, then /etc/resolv.conf ends up
being invalid inside the container. This happens because the
container's /etc/resolv.conf points to /run/host/etc/resolv.conf, which
in turn points to /run/systemd/resolve/stub-resolv.conf, but that's
absent from the container.
This is, of course, not a problem with relative symbolic links. If the
host had a relative link to ../run/systemd/resolve/stub-resolv.conf,
then it would continue to work inside the container.
One solution would have been to use flatpak-session-helper to maintain
a copy of the host's /etc/resolv.conf in
$XDG_RUNTIME_DIR/.flatpak-helper/monitor. However, that doesn't work
when toolbox(1) is run as root.
The other option is to prepend the destination of the absolute symbolic
link with /run/host to make it resolve inside the container. It might
not work with funky links, but it's enough for the common case where a
an administrator changed the host's /etc/resolv.conf into a sane, but
absolute, symbolic link.
Properly configured hosts should anyway use relative symbolic links,
because they don't need to be adjusted in such scenarios. That's also
what Fedora and Ubuntu do, by default.
Thanks to Tudor Roman for raising a concern about relative symbolic
links.
Based on Martin Pitt's work on the POSIX shell implementation:
https://github.com/containers/toolbox/pull/380https://github.com/containers/toolbox/issues/187
This is based on the output of 'gcc -dM -E - </dev/null' on a ppc64le
system. For what it's worth, the _CALL_ELF macro is defined as 1 on
the big endian variants of the architecture.
The original intention in commit 6ad9c63180 was to support the
architectures that Fedora builds for, and it doesn't care about PowerPC
variants that aren't ppc64le [1].
[1] https://fedoraproject.org/wiki/Architectures/PowerPChttps://github.com/containers/toolbox/pull/536
The /usr/bin/toolbox binary is not only used to interact with toolbox
containers and images from the host. It's also used as the entry point
of the containers by bind mounting the binary from the host into the
container. This means that the /usr/bin/toolbox binary on the host must
also work inside the container, even if they have different operating
systems.
In the past, this worked perfectly well with the POSIX shell
implementation because it got intepreted by whichever /bin/sh was
available.
The Go implementation also mostly worked so far because it's largely
statically linked, with the notable exception of the standard C
library. However, recently glibc-2.32, which is used by Fedora 33
onwards, added a new version of the pthread_sigmask symbol [1] as part
of the libpthread removal project:
$ objdump -T /usr/bin/toolbox | grep GLIBC_2.32
0000000000000000 DO *UND* 0000000000000000 GLIBC_2.32
pthread_sigmask
This means that /usr/bin/toolbox binaries built against glibc-2.32 on
newer Fedoras pick up the latest version of the symbol and fail to run
against older glibcs in older Fedoras.
One way to fix this is to disable the use of any C code from Go by
using the CGO_ENABLED environment variable [2]. However, this can
negatively impact packages like "os/user" [3] and "net" [4], where the
more featureful glibc APIs will be replaced by more limited
equivalents written only in Go.
Instead, since glibc uses symbol versioning, it's better to tell the
Go toolchain to avoid linking against any symbols from glibc-2.32.
This was accomplished by a few linker tricks:
* The GNU ld linker's --wrap flag was used when building the Go code
to divert pthread_sigmask invocations from Go to another function
called __wrap_pthread_sigmask.
* A static library was added to provide this __wrap_pthread_sigmask
function, which forwards calls to the actual pthread_sigmask API in
glibc. This library itself was not linked with --wrap, and
specifies the latest permissible version of the pthread_sigmask
symbol from glibc for each architecture. Currently, the list of
architectures covers the ones that Fedora builds for.
* The Go cmd/link linker was switched to external mode [5]. This
ensures that the final object file containing all the Go code gets
linked to the standard C library and the wrapper static library by
the GNU ld linker for the --wrap flag to kick in.
Based on ideas from Ondřej Míchal.
[1] glibc commit c6663fee4340291c
https://sourceware.org/git/?p=glibc.git;a=commit;h=c6663fee4340291c
[2] https://golang.org/cmd/cgo/
[3] https://golang.org/pkg/os/user/
[4] https://golang.org/pkg/net/
[5] https://golang.org/src/cmd/cgo/doc.gohttps://github.com/containers/toolbox/issues/529
The 'removeImage' function should go into 'pkg/podman' because it wraps
around Podman's command. Because it no longer has access to the commands
- toolbox rmi - parameters it has a new forceDelete parameter.
https://github.com/containers/toolbox/pull/519
The 'removeContainer' function should go into 'pkg/podman' because it
wraps around Podman's command. Because it no longer has access to the
commands - 'toolbox rm' - parameters it has a new forceDelete parameter.
https://github.com/containers/toolbox/pull/519
Having some contributing guidelines is good!
I wrote of this mostly from top of my head (but I took inspiration from
projects like Podman or Atom). Maybe some parts are not very clear.
Podman doesn't mount a tmpfs at /tmp by default - it needs to be
separately requested. However, doing it as part of 'podman create ...'
won't add a tmpfs at /tmp for existing toolbox containers. Therefore,
it's best done as part of the entry point.
The mount options are the same as used by systemd (see tmp.mount) to
provide a tmpfs at the host's /tmp.
For what it's worth, the mount flags do differ slightly from the host.
The host has:
$ findmnt --output OPTIONS,PROPAGATION /tmp
OPTIONS PROPAGATION
rw,nosuid,nodev,seclabel shared
The container has:
$ findmnt --output OPTIONS,PROPAGATION /tmp
OPTIONS PROPAGATION
rw,nosuid,nodev,seclabel,uid=100000,gid=100000 private
The uid and gid options don't show up on the host because both are 0,
and hence skipped by the tools.
https://github.com/containers/toolbox/issues/513
Users, who prefer shells other than Bash, tend to get confused when
Toolbox presents a Bash prompt to them. It would be better to be more
upfront about what the problem is, so that users can self-support
themselves.
https://github.com/containers/toolbox/issues/18
Every time Podman changes their JSON API Toolbox breaks horribly. That
is caused by the combination of decoding the JSON purely by hand and by
the complete lack of type assertions to make the process stable.
I previously didn't know that unmarshalling with Go works on the 'do
the best job it can' logic (thank you Owen!). This makes the need to
check for subtle changes in the names of fields go away and type
checking a bit more bearable (marking the questioned field as
interface{} and then immediatelly type switch).
If even now an existing field does not hold an expected value the field
will remain blank.
To take this a bit further, I created two types (toolboxImage and
toolboxContainer) that are used by both functions for returning the
list of images and containers. Instead of using getters for properties
that need some checks or adjustments this uses a custom unmarshaling
function (Owen's idea; thanks!).
The work around populating the two new types is a bit hacky
(marshalling and already unmarshalled JSON - that was unmarshalled to
[]map[string]interface{} - that is then unmarshalled to either
toolboxImage or toolboxContainer. This is done to prevent a major
refactoring before the 0.1.0 release. This should be changed for the
0.2.0 release.
https://github.com/containers/toolbox/pull/503
Rewritten version of Toolbox supports newer syntax for entering a
container: `toolbox enter <name-of-container>`. This new workflow should
be shown in the hint after creating a container with `toolbox create`.
https://github.com/containers/toolbox/issues/489
The Go implementation did not highlight running containers because it
uses a special table writer from 'text/tabwriter' that does not
support colored output [0].
The trick used here is to use ANSI SGR terminal escape sequences [1]
on every line output by the table writer, including headers, and make
the escape sequences use the same number of characters. eg., even
though it's idiomatic to use "\033[0m" to reset the SGR attributes,
such as color; each non-colored line is prefixed with "\033[0;00m" to
ensure that it has the same number of characters as "\033[1;32m", which
is used for bold green output.
Therefore, not only are the non-colored lines wrapped in a redundant
pair of ANSI SGR terminal escape sequences, they are carefully crafted
to match the escape sequences for colored output.
Tested on VTE and xterm.
[0] https://github.com/golang/go/pull/35017
[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parametershttps://github.com/containers/toolbox/pull/494
For some reason running 'toolbox run echo Hello World' in the tests in
the environment of Zuul is causing problems. Bats saves the output of
ran command to $output that can be then checked if it contains the right
output. This variable sometimes holds in this case the right output
("Hello World") but more often it is blank, causing the tests to fail.
I don't know the culprit, so for now I'm commenting out the checks to
make the CI pass again.
https://github.com/containers/toolbox/issues/410
Not all tests are the same and the ones we're currently running are
system tests. Also the mention of 'podman-stable' is not that important
because we're using the version in the 'stable' stream of Fedora
releases.
https://github.com/containers/toolbox/pull/508
In the Go implementation, when the 'rm' and 'rmi' commands fail to
remove a container or image, they don't use a non-zero exit code.
There's currently no nice fix for this. So, the tests have been
adjusted as a temporary measure.
https://github.com/containers/toolbox/pull/507
