Commit 6c86cabbe5 changed the command line interface to behave
a lot similar to that of github.com/coreos/toolbox, which makes things
easier for those switching over from it. Make it conditional so that
only those OS distributors who truly need it may enable it, and
restore the previous behaviour as the default.
The tests were updated to test the default behaviour that the vast
majority of users would be seeing. Ideally, the test suite would be run
twice with the migration path turned off and on. However, that would
require a more intrusive surgery of the test suite and likely make it
slower. It might not be worth the hassle because of the small number
of users who should be using the migration path.
Note that the copyright and license notices really must use C++-style
// line comments, because build constraints can only be preceded by
blank lines and other line comments. C-style /* */ block comments can't
precede the build constraints.
This reverts commit ca899c8a56 and parts
of commit 3aeb7cf288.
[1] go help buildconstraint
https://pkg.go.dev/cmd/go#hdr-Build_constraintshttps://github.com/containers/toolbox/pull/951
This will be used by the subsequent commit to highlight some of the
more common commands that new user is likely to be interested in, when
none has been specified.
https://github.com/containers/toolbox/pull/951
Commit 6c86cabbe5 changed the command line interface to behave
a lot similar to that of github.com/coreos/toolbox, which makes things
easier for those switching over from it.
However, it makes things confusing for the vast majority of users who
have never used coreos/toolbox. The Toolbox CLI aims to be friendly to
new users by being self-documenting and offering a smooth onboarding
experience. It's jarring to new users when 'toolbox', without any
commands specified, suggests that it needs to perform a big download.
It's difficult to document two different sets of CLIs, and if the
manuals don't mention the second behaviour, then it just leaves the
users even more confused.
Hence, it will be good to keep the migration path for coreos/toolbox
behind a build-time option, so that only those OS distributors who
truly need it may enable it without impacting others. Fortunately,
coreos/toolbox doesn't have any manuals, which means that there's no
need to conditionalize the documentation.
This commit merely adds the build-time option. Subsequent commits will
use this to actually conditionalize the code.
https://github.com/containers/toolbox/pull/951
Some downstream distributors like RHEL don't have patchelf(1). Relying
on patchelf(1) during the build will make it difficult for such
downstreams to distribute Toolbox.
Fortunately, the path of the dynamic linker (ie., PT_INTERP) is
hardcoded in the ABI specification of each architecture [1]. This means
that Toolbox's build system can keep it's own architecture to dynamic
linker mapping, and specify it during the build through the GNU ld
linker's --dynamic-linker flag, as opposed to using a tool like
patchelf(1) to change the path of the dynamic linker in the built
binary to the one inside /run/host. Currently, the list of
architectures covers the ones that Fedora builds for.
[1] https://sourceware.org/glibc/wiki/ABIListhttps://github.com/containers/toolbox/pull/942
Now that there's a website at https://containertoolbx.org/ it makes
more sense to link to it instead of linking back to the same location
where the README.md resides.
The Toolbox repository was moved to the 'containers' organization some
time ago already[0]. Containers marked with the label:
com.github.debarshiray.toolbox=true
will remain supported but new containers will not be created with it.
https://github.com/containers/toolbox/pull/510
[0] de5e5df9b7
We need to know if the latest changes in the libc (that is dynamically
linked to the binary) causes problems in containers based on older
releases of Fedora.
The estimate of the version numbers is very crude and does not follow
the upstream schedule. That should not be a problem, though.
A part of an existing test has been reused and made into a helper
function to implement this.
This increases the run time of the test suite on Rawhide which already
takes longer than the same test suite on released versions of Fedora.
Make up for it by increasing the timeout by 2 minutes.
https://github.com/containers/toolbox/pull/899
The 'die' function is a remnant from times before the system tests
rewrite. It served for writing an error message and then failing
the test. Since the rewrite it is no longer present. Instead, simply
use 'false' in case a caching step fails.
Fallout from da6b6a7c5a6e5e284e6642c29159a872ceec94e2
https://github.com/containers/toolbox/pull/899
This will pair with a future change to `shell.Run()` so that we capture
the child process stderr.
But actually this change on its own is enough since `shell.Run()`
provides an error message when the invoked command was not found or when
some other unknown error has happened.
Before:
Error: failed to remove password for user walters`
After:
Error: failed to remove password for user walters: passwd(1) not found`
which helps immediately pinpoint the problem.
I didn't try to go through and change *all* the `shell.Run()`
invocations, but if accepted I may do it (or someone else can).
https://github.com/containers/toolbox/pull/945
Currently, the entry point of a Toolbox container runs updatedb(8) on
start-up, which can be very I/O intensive. This might be a hindrance
when troubleshooting performance problems on a host, or when
re-creating containers somewhat more frequently.
Users can install the mlocate RPM and restart their containers to
enable locate(1).
Only the images for currently maintained Fedoras (ie., 34, 35 and 36)
were updated.
https://github.com/containers/toolbox/pull/938
There's no need to specify a CMD in a Toolbox image because it's
specified by 'toolbox create', through 'podman create', when creating a
container.
A CMD was specified [1] because the Fedora Container Guidelines
requires it [2]. The idea behind the guidelines is that the right
thing should happen when one runs:
$ podman run <image>
However, that only makes sense for images targeting single service
containers. Toolbox containers and images are different - they are not
meant to be used like that to run a single one-off service.
Conceptually, 'running' a Toolbox container is expected to provide the
user with a reasonable interactive command line experience. Arguably,
that means offering something like /bin/bash, not /bin/sh.
Also, note that when the CMD was introduced [1], Toolbox containers
were actually created, through 'podman create', with /bin/sh as their
entry points. So, it did make some sense. However, things have changed
since then [3]. The entry point is now 'toolbox init-container'. It's
not possible to mention it in the Toolbox image because the
/usr/bin/toolbox binary isn't present in the image, and it's not meant
to be present.
Therefore, today, /bin/sh is simply not the right fit for a Toolbox
image's CMD. A better option would be /bin/bash.
Note that the fedora base images have their CMD set to /bin/bash, which
is inherited by the fedora-toolbox images.
So, there are two options. Either repeat the same CMD in the
fedora-toolbox images and satisfy the guidelines, or take some
liberties and let the CMD be inherited from the fedora base images.
This commit takes the latter option. People tend to use the
fedora-toolbox images as the starting point for other custom Toolbox
images, sometimes for other operating system distributions. It's
better to keep them minimal to avoid implying extra requirements. In
this case, the CMD is an abstract concept, and the actual entry point
is 'toolbox init-container' as specified by 'toolbox create'.
Specifying /bin/bash might discourage people from creating custom
images that are only meant to have /bin/zsh.
Also, note that the current CMD was actually '/bin/sh -c /bin/sh', not
/bin/sh. Unless a CMD is specified as an array of command line
arguments, it's passed as a single argument to '/bin/sh -c' [4]. So,
this:
CMD foo bar
... is the same as:
CMD [ "/bin/sh", "-c", "foo bar" ]
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
This reverts commit 5cc2678a36.
[1] Commit 5cc2678a36
[2] https://docs.fedoraproject.org/en-US/containers/guidelines/creation/
[3] Commit 8b84b5e460https://github.com/containers/toolbox/pull/160
[4] https://docs.docker.com/engine/reference/builder/#cmdhttps://github.com/containers/toolbox/issues/885
Instead of typing out two function names to set up the test environment,
type out only one. We never know if a new set up function will show up.
https://github.com/containers/toolbox/pull/818
This allows to run the test suite without having to worry about blasting
the whole local state of Podman.
This is done by creating a configuration file with a custom path for the
storage of Podman and specifying the config file using an env var.
The used location for the temporary storage is located either under
XDG_CACHE_HOME and if the one is not defined, $HOME/.cache is used
instead. The data are namespaced. This follows the XDG Base Directory
Specification[0]. Other locations could be /tmp or /run but those
locations usually use tmpfs and that filesystem can not be used by
Podman[1] due to missing features in tmpfs.
https://github.com/containers/toolbox/pull/818
[0] https://specifications.freedesktop.org/basedir-spec/latest/index.html
[1] https://github.com/containers/podman/issues/10693#issuecomment-863007516
Currently, on Fedora, a nested instance of Z shell inside a Toolbox
container renders the PS1 like this:
\[\]⬢\[\][\u@\h \W]\$
Notice that Z shell doesn't like that the terminal escape sequences
for the foreground colour are wrapped in '\[' and '\]' [1], and doesn't
understand the special characters like '\u' and '\h'.
This is fixed by making the PS1 specific to the shell. The prompt for
Z shell is based on the default prompt used on Fedora, just like the
one for Bash.
Note that this only affects nested instances of Z shell because of the
way the start-up scripts for Z shell are written on Fedora. Toolbox
invokes top-level shell as a login shell, and for those the PS1 set by
profile.d/toolbox.sh is overwritten by the operating system's default
in /etc/zshrc. See:
https://bugzilla.redhat.com/show_bug.cgi?id=2026749
[1] Commit bc1a816ea3https://github.com/debarshiray/toolbox/issues/190https://github.com/containers/toolbox/pull/936
All these tools were only used by the POSIX shell implementation. The
Go implementation never used them.
Note that the test suite still invokes id(1) inside a container.
However, it's not a user-visible requirement, and hence is not a hard
requirement for Toolbox images.
https://github.com/containers/toolbox/pull/934
The util-linux package was added to ensure the presence of the mount(8)
command. Currently the package is already pulled in by various
dependencies. Therefore, it doesn't increase the size of the image, but
serves as a safeguard against any inadvertent changes.
Note that starting from Fedora 35 onwards, the fedora base images no
longer have mount(8), which increases the importance of this change.
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
https://github.com/containers/toolbox/issues/929
It's true that the fedora base images no longer come with
coreutils-single, but they used to, and the ubi base images still do.
Therefore, it's worth being extra defensive about this.
It's better to make the build system execute one extra redundant
command than expose users to a bug because of a change that snuck in
unnoticed.
Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.
This reverts commit 033ed71ec1.
https://github.com/containers/toolbox/pull/931
When running rootless, files and directories bind mounted from the
host operating system can have their ownership listed as
nobody:nobody. This is because the UIDs and GIDs that actually own
those locations are not available inside the container.
Some distribution packages are particular about the file ownerships of
some of these locations. eg., Fedora's filesystem, flatpak and
libvirt-libs RPMs. Encountering nobody:nobody as the owner can fail
package management transactions involving such packages leading to
unforeseen consequences.
Therefore, configure RPM to leave these locations alone.
https://github.com/containers/toolbox/pull/640
The location for public shared libraries can change from one operating
system distribution to another. eg., while Fedora uses /usr/lib and
/usr/lib64, depending on the hardware architecture, Debian uses paths
like /usr/lib/x86_64-linux-gnu. Therefore, it's best not to assume
anything and ask the toolchain.
https://github.com/containers/toolbox/pull/923
Unlike the following test this one tests using the content of the
toolbox(1) manual page in man. man has to be present in PATH for this
test to be relevant.
Also, this changes the text used to test the output. The current text
can be found in the added short help message and that causes the test
to pass even though it should not. Instead, look for the text in the
"header" of the manual page.
https://github.com/containers/toolbox/pull/837
Fedora CoreOS systems do not have the man command installed. Running
toolbox --help on such a system results in a "man(1) not found" error.
As a compromise for systems without man, we added a simple help text
showing the most commonly used toolbox commands and an URL that direct
users to the Toolbox website where they can find the manuals in Markdown
format.
Fixes#713https://github.com/containers/toolbox/pull/837
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
These tests need to be implemented in the future but they require some
magic with socat or similar tools as entering a container is creating
a new subshell and that is hard to monitor from a bash script. Better
not to forget then.
https://github.com/containers/toolbox/pull/915
The path of the dynamic linker (ie., PT_INTERP), as specified in an
architecture's ABI, often starts with /lib or /lib64, not /usr/lib or
/usr/lib64. eg., it's /lib/ld-linux-aarch64.so.1 for aarch64 and
/lib64/ld-linux-x86-64.so.2 for x86_64.
Unfortunately, until very recently [1], only the host's /usr was
present inside a toolbox container's /run/host, not /lib or /lib64.
Therefore, simply prepending /run/host to the /usr/bin/toolbox
binary's existing PT_INTERP entry wouldn't locate the host's dynamic
linker inside the toolbox container. This broke backwards compatibility
with every container out there, except the ones created with the
current development version in Git.
To restore backwards compatibility, the /lib and /lib64 symbolic links
must be resolved to their respective locations inside /usr.
The following caveats must be noted:
* With glibc, even the basename of the path of the dynamic linker as
specified in an architecture's ABI, is a symbolic link to a file
named ld-<glibc-version>.so. However, this file can't be used as
the PT_INTERP entry, because its name will change when glibc is
updated and the PT_INTERP entry will become invalid until the
/usr/bin/toolbox binary is rebuilt.
* On Debian, a path like /lib64/ld-linux-x86-64.so.2 doesn't resolve
to something inside /usr/lib64. Instead it ends up inside
/usr/lib/x86_64-linux-gnu through a series of symbolic links:
- /lib64 -> usr/lib64
- /usr/lib64/ld-linux-x86-64.so.2
-> /lib/x86_64-linux-gnu/ld-2.28.so
- /lib -> usr/lib
* It's assumed that a symbolic link with the basename specified in
the ABI lives in the same directory as the actual dynamic linker
binary named ld-<glibc-version>.so.
Fallout from 6063eb27b9
[1] Commit d03a5fee80https://github.com/containers/toolbox/pull/827https://github.com/containers/toolbox/issues/821
