This will reduce the size of the src/pkg/utils/utils.go file and make it
easier to specify which part of the code base is maintained by whom.
https://github.com/containers/toolbox/pull/1639
This will reduce the size of the src/pkg/utils/utils.go file and make it
easier to specify which part of the code base is maintained by whom.
https://github.com/containers/toolbox/pull/1639
This will prevent any silly bug in getting the initialization stamp path
from breaking the communication protocol between the 'enter' or 'run'
commands on the host and the Toolbx container's entry point process.
https://github.com/containers/toolbox/pull/1633
The runtime directory is needed a few times during the course of
commonly used Toolbx commands. It's used at start-up for all commands
except 'completion' and 'init-container' to synchronize the invocation
of 'podman system migrate'. The entry point (ie., 'init-container')
uses it to read the generated Container Device Interface specification
and create the initialization stamp file. The 'enter' and 'run'
commands use it to write the CDI specification and twice to detect the
creation of the initialization stamp file.
Since the runtime directory is always the same within a process, there's
no need to repeatedly go through all the steps of parsing the user and
group IDs, creating the directory, setting its ownership, and logging
the name of directory. Once the directory is successfully created, it's
path can be cached and returned for subsequent use.
In case an error occurred while setting up the runtime directory,
subsequent attempts to get it will go through all the steps again. This
doesn't matter much in practice because toolbox(1) can't continue in the
absence of a working runtime directory.
https://github.com/containers/toolbox/pull/1624
The test suite uses its own separate local container/storage store to
isolate itself from the default store, so that the tests' interactions
with containers and images don't affect anything else. This is done by
using the CONTAINERS_STORAGE_CONF environment variable [1] to specify a
separate storage.conf(5) file [2].
Therefore, when running the test suite, the CONTAINERS_STORAGE_CONF
environment variable must be preserved when forwarding toolbox(1)
invocations inside containers to the host. Otherwise, the initial
toolbox(1) invocation on the host and the forwarded invocation running
on the host won't use the same local container/storage store.
This problem only impacts test cases that cover toolbox(1) code paths
that invoke podman(1).
[1] https://docs.podman.io/en/latest/markdown/podman.1.html
[2] https://manpages.debian.org/testing/containers-storage/containers-storage.conf.5.en.htmlhttps://github.com/containers/toolbox/issues/957https://github.com/containers/toolbox/pull/1052
Any system-wide customization to Bash's history facilities done through
a custom /etc/profile.d configuration snippet on the host operating
system gets lost inside the Toolbx container.
This is because Toolbx doesn't know what name to expect for the custom
/etc/profile.d snippet on the host, and, hence, can't give access to it
through a bind mount or symbolic link inside the container. The user
can definitely set up their own symbolic link inside the container to a
snippet inside /run/host/etc/profile.d. However, it's tedious to do
that for all containers, and the user may not even know that they are
missing the customization until they notice something wrong with the
history, which is shared across all containers and the host, and at that
point they might have already lost commands that they can't easily
reconstruct.
Therefore, it's worth trying to improve the situation by default.
This tries to preserve the environment variables used to customize
Bash's history facilities [1] across the host operating system and
Toolbx container. It assumes that the Bash start-up scripts inside the
container won't overwrite any of the propagated variables, which might
not always be the case [2].
[1] https://www.gnu.org/software/bash/manual/html_node/Bash-History-Facilities.htmlhttps://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html
[2] https://pagure.io/setup/pull-request/48https://github.com/containers/toolbox/issues/1359
This allows using the 'distro' option to create and enter Arch Linux
containers. Due to Arch's rolling-release model, the 'release' option
isn't required. If 'release' is used, the accepted values are 'latest'
and 'rolling'.
https://github.com/containers/toolbox/pull/1311
Operating system distributions like Arch Linux that follow a
rolling-release model don't have the concept of a release. The latest
snapshot is the only available release.
A subsequent commit will add built-in support for Arch Linux. Hence,
the code can no longer assume that every distribution will have a
matching release.
Note that just because an operating system distribution may not have the
concept of a release, it doesn't mean that it will accept an invalid
'release' option.
https://github.com/containers/toolbox/pull/1311
The VERSION_ID field in os-release(5) is optional [1]. It's absent on
Arch Linux, which follows a rolling-release model and uses the BUILD_ID
field instead:
BUILD_ID=rolling
A subsequent commit will add built-in support for Arch Linux. Hence,
the code to get the default release from the host operating system can
no longer assume the presence of the VERSION_ID field in os-release(5).
Note that the arch-toolbox image is tagged with 'latest', in accordance
with OCI conventions, not 'rolling' [2,3], which is the os-release(5)
BUILD_ID. Therefore, it will be wise to use 'latest' as the default
release on Arch Linux, to simplify how the default release matches with
the default image's tag. This means that a os-release(5) field can't be
used for the default release on Arch.
[1] https://www.freedesktop.org/software/systemd/man/os-release.html
[2] Commit 2568528cb7https://github.com/containers/toolbox/pull/861
[3] Commit a4e5861ae5https://github.com/containers/toolbox/pull/1308https://github.com/containers/toolbox/pull/1303
The URLs for the RHEL Toolbx images based on the Red Hat Universal Base
Images (or UBI) are a bit more complicated to construct, in comparison
to the URLs for Fedora's fedora-toolbox images. It's not enough to just
concatenate the registry, the image's basename and the release. Some
parts of the URL depend on the release's major number, which requires
custom code.
So far, the release's major number was hard coded to 8 since only RHEL 8
Toolbx containers were supported.
To support other RHEL major releases, it's necessary to have custom code
to construct the URLs for the Toolbx images.
https://github.com/containers/toolbox/issues/1065
It turns out that Viper's custom error implementations use non-pointer
receivers, whereas often people assume pointer receivers. This can
cause confusion when trying to use errors.As(...) with those errors [1].
Secondly, Viper may or may not throw ConfigFileNotFoundError depending
on its build tags.
[1] https://github.com/spf13/viper/issues/1139https://github.com/containers/toolbox/pull/1105
Currently, the container name and release are only validated if they
were specified as command line options. Neither the value of release
in the configuration file nor the container name generated from an
image are validated.
There's also a lot of repeated code in the command front-ends to
validate the container name and release. This opens the door for
mistakes. Any adjustment to the code must be repeated elsewhere, and
there are subtle interactions and overlaps between the validation code
and the code to resolve container and image names.
It's worth noting that the container and image name resolution happens
for both the command line and configuration file options, and generates
the container name from the image when necessary.
Therefore, validating everything while resolving cleans up the command
front-ends and increases the coverage of the validation.
This introduces the use of sentinel error values and custom error
implementations to identify the different errors that can occur while
resolving the container and images, so that they can be appropriately
shown to the user.
https://github.com/containers/toolbox/pull/1101
Currently, if an invalid or unsupported string is specified as the
distro on the command line or in the configuration file, then it would
silently fallback to Fedora. This shouldn't happen.
It should only fallback to Fedora when no distro was specified and
there's no supported Toolbox image matching the host operating system.
If a distro was explicitly specified then it should either be supported
or it should error out.
The test cases were resurrected from commit 8b6418d8aa.
https://github.com/containers/toolbox/issues/937https://github.com/containers/toolbox/pull/1080
The terms 'default' and 'fallback' are used to mean very specific
things in this context.
The 'default' values are those that are used when the 'create', 'enter'
and 'run' commands were used without any option. These values are
picked to match the host operating system.
However, if there's no supported Toolbox image matching the host
operating system, and no options were provided to the 'create', 'enter'
and 'run' commands, then the 'fallback' values are used as a last
resort.
Consistently using this terminology leads to a clear mental model and
makes the code easier to read.
This rough arrangement of the code was already being used for
'release', and has now been been extended to 'container name prefix'
and 'distro'. The suffix for the 'fallback' values was simplified to
'Fallback', instead of 'DefaultFallback'.
https://github.com/containers/toolbox/issues/937https://github.com/containers/toolbox/pull/1080
Figuring out the container name prefix for a given image only needs to
happen as part of resolving the final Toolbox container name from the
given command line and configuration options.
Fallout from c990fb43cahttps://github.com/containers/toolbox/pull/1098
Using a non-supported distribution via `--distro` resulted in a silent
fallback to the Fedora image which confuses users. When a faulty release
format was used with `--release` a message without any hint about the
correct format was shown to the user.
This separates distro and release parsing into two chunks that have
greater control over error reporting and provides more accurate error
reports for the user.
Fixes https://github.com/containers/toolbox/issues/937https://github.com/containers/toolbox/pull/977
pkg/utils has been in Go Toolbox since its birth. Along the way it
accumulated a number of functions where a few of them are purely CLI
related. Since the majority of functions in the package are related to
some "deeper" functionality in Toolbox, it makes more sense to move the
selected few to package cmd. This will make pkg/utils a bit leaner and
create a dedicated space for cmd utility functions to live in.
In the process the error creation functions no longer require the
executableBase argument to be passed to them.
https://github.com/containers/toolbox/pull/819
It looks like there are some oddities with Viper [1]. The errors can't
be examined with errors.As [2] and Viper doesn't actually throw
ConfigFileNotFoundError if a configuration file is not found. Secondly,
there's no way to find out if a key was actually specified in a
configuration file. The InConfig API doesn't return 'true' even if a
key was mentioned in a configuration file, and the IsSet API returns
'true' even if the key was only set via SetDefault in the code.
Some changes by Debarshi Ray.
[1] https://pkg.go.dev/github.com/spf13/viper
[2] https://blog.golang.org/go1.13-errorshttps://github.com/containers/toolbox/pull/828https://github.com/containers/toolbox/pull/851
A subsequent commit will add support for configuration files, which can
override the default toolbox image. Since this override affects all
commands, it effectively ends up adding a fourth option to the 'enter'
command, other than the existing options to change the distribution,
release and container. This makes it a lot more difficult to reason
when only 'toolbox enter --release N' is enough to enter the created
container.
https://github.com/containers/toolbox/pull/828https://github.com/containers/toolbox/pull/851
Debarshi Ray
Ondřej Míchal
Dominique Polek
Jens Petersen
Ievgen Popovych