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
Until now, the Arch Linux image was being published at
quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image
to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes
the location to quay.io/toolbx/arch-toolbox:latest.
Build and push when there are changes in the 'images/arch' directory
or in the GitHub workflow itself, as well as at 00:00 every Monday.
[1] Commit 2568528cb7https://github.com/containers/toolbox/pull/861https://github.com/containers/toolbox/pull/1308
Since Sericea is an official variant of Fedora, it should have an
official welcome message like the other ones.
https://github.com/containers/toolbox/pull/1293
Signed-off-by: Jakub Sierżęga <jakub.sierzega@comarch.com>
Until now, the Ubuntu images (versions 16.04, 18.04, 20.04, 22.04 and
22.10) were published at quay.io/toolbx-images/ubuntu-toolbox:22.04,
etc.. This changes the location to quay.io/toolbx/ubuntu-toolbox:22.04
and builds an image for Ubuntu 23.04 that was added recently [1].
Build and push when there are changes in the `images/ubuntu` directory
or in the GitHub workflow itself, as well as every other week (7th and
21st days of a month to be precise).
The toolbox(1) code and the system tests will be switched to the new
location after the first round of images are available.
[1] Commit 3cfb6bf888https://github.com/containers/toolbox/pull/1292https://github.com/containers/toolbox/pull/483
Signed-off-by: Ievgen Popovych <jmennius@gmail.com>
This is the definition of the arch-toolbox image for Arch Linux that
plays well with Toolbx.
Today, it's published at quay.io/toolbx-images/archlinux-toolbox:latest,
but the name of the published image will be changed to arch-toolbox [1]
to match the os-release(5) ID on Arch Linux. The convention of naming
the Toolbx images according to the os-release(5) ID is deeply ingrained
in the Toolbx code base. It will be better to keep things simple by
continuing that practice, instead of adding a one-off exception.
Maintenance of this image has been passed to Morten Linderud.
[1] https://github.com/toolbx-images/images/pull/82https://github.com/containers/toolbox/pull/861
This was recently introduced with `ubuntu-advantage-tools` and it tries
to poke at some system services introducing annoying delay and messages.
Even if the services are present (on Ubuntu host) and systemd is
accessible (rootful container) - that wouldn't be appropriate still.
https://github.com/containers/toolbox/pull/1291
Signed-off-by: Ievgen Popovych <jmennius@gmail.com>
This partly reflects the value of the 'maintainer' LABELs of the current
images. Oliver is the original author, but he has lots of other duties
these days, and wanted me to help him co-maintain the images.
Note that the toolbox image definitions for RHEL do need a maintainer
who is a Red Hat employee. Otherwise they won't be able to actually
build and publish the images at registry.access.redhat.com.
https://github.com/containers/toolbox/pull/1288
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
