Due to docker rate limiting we can not rely in docker.io for
retrieving the images.
This was detected when executing our tests for podman fedora
gating pipeline. Our busybox image was not downloaded and
one of the list tests was failing.
Using the current working directory for cache is not a good solution
since the test files may reside in a location that is unwritable (e.g.,
/usr/share). The `BATS_RUN_TMPDIR` variable should point to a location
that is sure to be writeable from the test suite.
https://github.com/containers/toolbox/pull/850
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
The 'toolbox run' command has one downside: all newlines contain
a carriage return (CR). This is caused by the unconditional use of the
--tty option in `podman exec`[0]. In these particular tests this can be
worked around by not printing a newline at all.
Another quirk around partial is to check the last line of the output.
[0] https://github.com/containers/podman/issues/9718https://github.com/containers/toolbox/pull/843
The output of `podman build` has changed a bit. Each line of log
describing the build is now in the format of:
- STEP i/n: msg
instead of:
- STEP i: msg
where i is the current step and n the maximum number of steps.
The exact format is not important for the purpose of testing Toolbox, so
we may fallback to partial string testing.
Also the latest step ("COMMIT") seems to no longer be considered a step,
so just check for the word.
https://github.com/containers/toolbox/pull/846
Having the entire host file system hierarchy mounted inside a toolbox
container gives the containers a more complete environment that's
resilient against future changes in the layout of the file system
hierarchy and the need for giving access to new paths to support new
use-cases. Otherwise, one would have to create a new container to get
access to any path that lies outside the /boot, /etc, /run, /tmp, /usr
and /var directories.
As a nice side-effect, this also simplifies the bind mount handling
code.
https://github.com/containers/toolbox/pull/827
Turns out the braces do not need to be escaped.
The equivalent code in the POSIX shell implementation was:
echo "$image" | grep "^[a-f0-9]\{6,64\}$"
There the braces had to be escaped because it was using grep(1) with
basic regular expressions (ie., without the --extended-regexp flag),
where the meta-characters ?, +, {, |, ( and ) lose their special
meaning unless they are escaped.
However, that was grep(1), and this is Go's regexp package.
Fallout from dd947016b3https://github.com/containers/toolbox/pull/825
The regexp.MatchString [1] API returns an error only when the regular
expression is faulty, and the boolean return value tells if a match was
found. In this case, the regular expression is baked into the code as a
string literal. So, unless there's a programmer error, it should always
be valid.
Fallout dd947016b3
[1] https://golang.org/pkg/regexp/#MatchStringhttps://github.com/containers/toolbox/pull/825
When installing to a non-system-wide prefix as a non-root user, the
tmpfilesdir path defined by systemd might not be accessible. Overriding
the path helps to prevent the installation from failing.
https://github.com/containers/toolbox/pull/717
This makes 'toolbox', without any commands specified, behave a lot like
'toolbox enter'. When there aren't any toolbox containers, it will
offer to create a new container matching the same parameters passed to
the command. If there's just one toolbox container available, then it
will fall back to it.
This makes the command line interface a lot similar to that of
github.com/coreos/toolbox, which makes things easier for those
switching over from it.
Some changes by Debarshi Ray.
https://github.com/containers/toolbox/pull/811
SELinux is always meant to be disabled. The exact location of the code
is a historical accident and isn't meant to imply that SELinux might
be optionally enabled.
https://github.com/containers/toolbox/pull/814
Avoid phrases like "shortcoming of container configuration", because
it makes one wonder why a known shortcoming is even being used or not
being fixed. Immutability also has its advantages for certain
use-cases, and it's beyond the scope of this manual to have a full
blown discussion about the pros and cons of OCI containers. Interested
readers can research that on their own.
https://github.com/containers/toolbox/pull/814
This builds upon commit ea452d7ced.
The configuration of a toolbox container is a higher level topic than
the entry point, and the entry point is mentioned as one part of it.
Therefore, putting the section on toolbox set-up earlier in the text
makes it nicely flow from the DESCRIPTION section into the Entry Point
sub-section.
Emphasize the user-visible features of a toolbox container, and not
the underlying implementation details, and avoid using too much jargon
about container technology.
https://github.com/containers/toolbox/pull/814
It was a deliberate decision to have entry point documented in both
toolbox-create(1) and toolbox-init-container(1). For technical
documentation it's sometimes good to repeat the same thing if it's
sufficiently important. Either to refresh the user's memory or to draw
their attention to it. Having to traverse too many references can get
disorienting. eg., parts of README.md are already repeated in
toolbox(1).
In this case, the entry point is very directly related to the create
command because the command sets it up, and unlike HTML documents,
it's awkward to follow links from manuals.
This reverts parts of commit ea452d7ced.
https://github.com/containers/toolbox/pull/814
The DESCRIPTION already explains the details of the set-up on Fedora,
so there's no need to be so specific here. Plus, conceptually, it's not
meant to be Fedora-specific. Fedora is just an example and happens to
be the most well-supported one at the moment, but that will change.
https://github.com/containers/toolbox/pull/814
