The phrase 'using a custom image' is awkward because it makes it sound
as if the image plays an important role in 'enter' and 'run'. That's
not true.
Also, titles are sweeter when they are shorter.
https://github.com/containers/toolbox/pull/1281
Signed-off-by: Nils Lindemann <nilslindemann@tutanota.com>
When a specific Toolbx container is selected by name for 'enter' and
'run', it's not necessary that the container was created using a custom
image. The container could have also been created using one of the
built-in images.
Secondly, the phrase 'using a custom image' is awkward because it makes
it sound as if the image plays an important role in 'enter' and 'run'.
That's not true.
Finally, titles are sweeter when they are shorter.
https://github.com/containers/toolbox/pull/1281
Signed-off-by: Nils Lindemann <nilslindemann@tutanota.com>
These are the definitions of the ubuntu-toolbox images for Ubuntus
16.04, 18.04, 20.04, 22.04 and 22.10 that play well with Toolbx. Such
as, password-less sudo, able to resolve its own hostname, SELinux is
masked off, etc.. At the moment, these are already published at
quay.io/toolbx-images/ubuntu-toolbox:22.04 and such.
https://github.com/containers/toolbox/pull/483https://github.com/containers/toolbox/pull/1284
Signed-off-by: Ievgen Popovych <jmennius@gmail.com>
fmt.Scanf [1] is fragile when it comes to space-separated input. It
stores successive space-separated values into successive arguments as
determined by the format string. This breaks with untrusted input that
can have an unknown number of space-separated values.
Here are some examples:
$ toolbox create
Image required to create toolbox container.
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]: no no not at all
$ no not at all
bash: no: command not found...
$ toolbox create
Image required to create toolbox container.
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]: foo bar
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]: Download registry.fedoraproject.org/fedora-toolbox:39
(294.8MB)? [y/N]:
Instead this is what should happen:
$ toolbox create
Image required to create toolbox container.
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]: no no not at all
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]: foo bar
Download registry.fedoraproject.org/fedora-toolbox:39 (294.8MB)?
[y/N]:
Fallout from 936f22ff15
[1] https://pkg.go.dev/fmt#Scanfhttps://github.com/containers/toolbox/pull/1279
It's quite obvious what the corresponding code is doing, and it isn't
any harder to understand than the rest of the code that's not commented.
https://github.com/containers/toolbox/pull/1282
This is a quick sanity check with 'podman images' to ensure that all the
images are in place before running 'list'. Other tests already do this,
so this change makes these two tests consistent with the rest.
https://github.com/containers/toolbox/pull/1273
This is the 'simple' case of having a well-known Toolbx image (ie.,
not a copy, not an image without a name, not a non-Toolbx image). It's
good to ensure that the default image works as expected with 'list'
before moving on to more complex scenarios.
https://github.com/containers/toolbox/pull/1278
Currently, some of the names of the tests were too long, and had
inconsistent and verbose wording. This made it difficult to look at
them and get a gist of all the scenarios being tested. The names are
like headings. They shouldn't be too long, should capture the primary
objective of the test and be consistent in their wording.
https://github.com/containers/toolbox/pull/1276
Currently, some of the names of the tests were too long, and had
inconsistent and verbose wording. This made it difficult to look at
them and get a gist of all the scenarios being tested. The names are
like headings. They shouldn't be too long, should capture the primary
objective of the test and be consistent in their wording.
https://github.com/containers/toolbox/pull/1271
Toolbx was conceived to address the needs of Fedora Linux. Even though
it works on host operating systems outside the Fedora family, it hasn't
treated them with the same importance as Fedora Linux and derivatives
like Red Hat Enterprise Linux. Subsequent commits will change that by
adding first-class support for host operating systems beyond the Fedora
universe. eg., Arch Linux and Ubuntu.
The current Toolbx maintainers, Ondřej Míchal and myself, are Fedora
developers and don't have the bandwidth to drive changes and track down
bugs in OSes outside the Fedora family. Therefore, maintenance of some
parts of the code base will be delegated to contributors from those
other OS communities.
This is a step in that direction by clearly specifying which part of the
code base is maintained by whom.
https://github.com/containers/toolbox/pull/1268
Currently, some of the names of the tests were too long, and had
inconsistent and verbose wording. This made it difficult to look at
them and get a gist of all the scenarios being tested. The names are
like headings. They shouldn't be too long, should capture the primary
objective of the test and be consistent in their wording.
https://github.com/containers/toolbox/pull/1265
This uses 'skopeo inspect' to get the size of the image on the registry,
which is usually less than the size of the image in a local
containers/storage image store after download (eg., 'podman images'),
because they are kept compressed on the registry. Skopeo >= 1.10.0 is
needed to retrieve the sizes [1].
However, this doesn't add a hard dependency on Skopeo to accommodate
size-constrained operating systems like Fedora CoreOS. If skopeo(1) is
missing or too old, then the size of the image won't be shown, but
everything else would continue to work as before.
Some changes by Debarshi Ray.
[1] Skopeo commit d9dfc44888ff71a6
https://github.com/containers/skopeo/commit/d9dfc44888ff71a6https://github.com/containers/skopeo/issues/641https://github.com/containers/toolbox/issues/752
Signed-off-by: Nieves Montero <nmontero@redhat.com>
Bind mounting the locations at runtime doesn't really have anything to
do with whether /run/host/etc is present inside the Toolbx container.
The only possible exception could have been /etc/machine-id, but it
isn't, because the bind mount is only performed if the source at
/run/host/etc/machine-id is present.
This is a historical mistake that has persisted for a long time, since,
in practice, /run/host/etc will almost always exist inside the Toolbx
container. It's time to finally correct it.
Fallout from 9436bbece0https://github.com/containers/toolbox/pull/1255
The --monitor-host option was added to the 'init-container' command in
commit 8b84b5e460 to accommodate Podman versions older than 1.2.0
that didn't have the '--dns none' and '--no-hosts' options for
'podman create'. These options are necessary to keep the Toolbx
container's /etc/resolv.conf and /etc/hosts files synchronized with
those of the host.
Note that Podman 1.2.0 was already available a few months before
commit 8b84b5e460 introduced the --monitor-host option. The
chances of someone using an older Podman back then was already on the
decline, and it's very unlikely that a container created with such a
Podman has survived till this date.
Commit b6b484fa79 raised the minimum required Podman version to
1.4.0, and made the '--dns none' and '--no-hosts' options a hard
requirement. The minimum required Podman version was again raised
recently in commit 8e80dd5db1 to 1.6.4. Therefore, these days,
there's no need to separately use the --monitor-host option of
'init-container' for newly created containers to indicate that the
Podman version wasn't older than 1.2.0.
Given all this, it's time to stop using the --monitor-host option of
'init-container', and assume that it's always set. The option is still
accepted to retain compatibility with existing Toolbx containers.
For containers that were created with the --monitor-host option, a
deprecation notice will be shown as:
$ podman start --attach CONTAINER
Flag --monitor-host has been deprecated, it does nothing
...
https://github.com/containers/toolbox/pull/617
So far the minimum required Podman version was 1.4.0, based on what used
to be available in RHEL 7. These days, Podman 1.6.4 is old enough to be
in RHEL 7.9. Hence it's time to bump the baseline.
https://github.com/containers/toolbox/pull/1253
This is meant to roughly replicate the build environments used by
downstream distributors to build toolbox(1). These can be restricted in
odd ways compared to a fully featured environment where toolbox(1) is
actually going to be used. eg., the inability to use podman(1) in the
case of Fedora or not having subordinate user and group ID ranges in the
case of openSUSE.
It's important to ensure that toolbox(1) can be built by downstream
distributors without any unnecessary hassle.
https://github.com/containers/podman/issues/17657https://github.com/containers/toolbox/issues/1246
Ever since commit bafbbe81c9, the shell completions are generated
while building Toolbx using the 'completion' command. This involves
running toolbox(1) itself, and hence validating the subordinate user and
group ID ranges.
Unfortunately, some build environments, like openSUSE's, don't have
subordinate ID ranges set up. Therefore, it's better to not validate
the subordinate ID ranges when generating the shell completions, since
they are generated by Cobra itself and subordinate ID ranges are not
involved at all.
Note that subordinate ID ranges may be needed when the generated shell
completions are actually used in interactive command line environments.
The shell completions invoke the hidden '__complete' command to get the
results that are presented to the user, and, if needed, the subordinate
ID ranges will continue to be used by podman(1) as part of that.
Some changes by Debarshi Ray.
https://github.com/containers/toolbox/issues/1246https://github.com/containers/toolbox/pull/1249
