A subsequent commit will leverage this to make 'toolbox enter' smarter.
It will suggest creating a new toolbox container if none is present,
or fallback to an existing container if only one is present.
https://github.com/debarshiray/toolbox/issues/128
A subsequent commit will leverage this to make 'toolbox enter'
smarter. It will suggest creating a new toolbox container if none is
present, or fallback to an existing container if only one is present.
https://github.com/debarshiray/toolbox/issues/128
This reduces the side-effects of functions, and makes them more modular
and flexible.
A subsequent commit will leverage this to make 'toolbox enter' smarter
by automatically offering to create a new toolbox if none is present.
https://github.com/debarshiray/toolbox/issues/128
Currently, there's no easy way to get the size of the impending
download. Skopeo doesn't offer the size of the OCI image [1] and it's
debatable whether another 23 MB binary ought to be pulled in as a
dependency just for this.
Given that the default fedora-toolbox images are the only base images
available via a public repository, the size of the download is hard
coded to reflect the approximate size of the fedora-toolbox images.
These images are between 451 MB and 483 MB, so 500 MB should be a
reasonably suggestive approximate that shouldn't negatively surprise
users.
[1] https://github.com/containers/skopeo/issues/641https://github.com/debarshiray/toolbox/issues/134
Make using toolbox a bit more convenient by properly completing its
options. The completions should be complete (that is, there are
completions for all the commands and options shown in --help),
but no attempt is made to filter out conflicting options (for
example "toolbox rm --all my-container").
https://github.com/debarshiray/toolbox/pull/133
Commit 5b3d234c9e had made the toolbox script work inside a
toolbox container, but most people didn't get to use it because it
needed extra effort to get access to the script inside the container.
One either had to grab the Toolbox sources or had to install the RPM.
Both options were inconvenient - the former needed knowing too many
technical details, while the latter would drag in dependencies like
Buildah and Podman that don't work inside the toolbox container.
This makes it easier to use the toolbox script inside a toolbox
container by bind mounting the script from the host inside the
container and keeping track of the path using the TOOLBOX_PATH
environment variable. The environment variable ensures that running
'toolbox create' from inside a toolbox container would continue to
bind mount the same script from the host that was used to create the
current container and is available inside it.
Compatibility with existing toolbox containers is broken when using
the script within a container because it insists on the TOOLBOX_PATH
environment variable being set inside. This might not be that big of a
deal because using the toolbox script inside a toolbox container wasn't
very convenient, and hence likely not used widely. In case of
complaints, this can be relaxed by falling back to "$0" when forwarding
the command to the host, but unless that happens it's better to keep
things simple to avoid a larger test matrix.
Based on an idea from Colin Walters.
https://github.com/debarshiray/toolbox/pull/126
The shadow-utils package was added to the base toolbox images to ensure
the presence of the useradd(8) command. Currently the package is
already pulled in by various dependencies. Therefore, it doesn't
increase the size of the base image, but serves as a safeguard against
any inadvertent changes.
This removes the need for separate code paths for environment
variables that are likely to be absent from the environment. eg.,
DBUS_SYSTEM_BUS_ADDRESS.
In theory, any environment variable can be unset from the environment,
and a variable that's set to the null or empty string (ie., "") is
different from one that's completely absent. Therefore, this is a
positive change regardless of whether the code path is used for
DBUS_SYSTEM_BUS_ADDRESS or not.
https://github.com/debarshiray/toolbox/issues/104
A subsequent commit will generate the name of the toolbox container
from that of the user-specific customize image, instead of just using
the same exact string. This is necessary because, unlike OCI images,
names of OCI containers can't have a colon in them [1]. Knowing that
the user-specific customized image always has a tag will make things
simpler.
Buildah and Podman are going to use 'latest' as the placeholder when no
tag is specified, and this what is explicitly mentioned when the base
toolbox image is referred to by its non-human-readable ID.
Fallout from 56c3cfc27c
[1] Podman commit 449b8ab7b14fcc0d
https://github.com/containers/libpod/pull/2793https://github.com/debarshiray/toolbox/issues/106
Instead of overwhelming the user with the entire reference
documentation, highlight some of the more common commands that a new
user is likely to be interested in. This is concise enough to not annoy
seasoned users who might have just committed a typo.
This should smoothen the onboarding experience by making the commands
self-documenting.
https://github.com/debarshiray/toolbox/issues/59
When '--all' is applied then first query the images with an old label,
then with the new label, combine them and process them.
When the exact image name is specified, then we need to check
whether the image has the new or old label and only then remove it.
https://github.com/debarshiray/toolbox/pull/101
When '--all' is applied then first query the containers with an old label,
then with the new label, combine them and process them.
When the exact container name is specified, then we need to check
whether the container has the new or old label and only then remove it.
https://github.com/debarshiray/toolbox/pull/101
First we need to get the containers with an old label and then with the
new label. We have to change the format of the query to only include the
name of the containers and not the other informations like 'created' as
they could make a problem when removing the duplicates with uniq. When
we have the final list of containers we pass them to
containers_get_details() where we obtain the final details for them.
https://github.com/debarshiray/toolbox/pull/101
Now that toolbox containers no longer use a separate PID namespace [1],
the entry point specified in 'podman create ...' doesn't act as PID 1
inside the toolbox container. It's just a process that's spawned by
'podman start' to denote the state of the container. This opens the
possibility of using something even more lightweight, such as
'sleep +Inf'.
sleep(1) takes 64 kB compared to the 432 kB taken by /bin/sh.
This wouldn't have been possible with a separate PID namespace. In that
case, the entry point would also become PID 1, and since the only
signals that can be sent to a PID 1 are those for which it has
explicitly installed handlers, this would cause various problems.
[1] Commit 67522f0ad7https://github.com/debarshiray/toolbox/pull/108
Otherwise https://www.shellcheck.net/ would complain:
Line 678:
$kcm_socket_bind \
^-- SC2086: Double quote to prevent globbing and word splitting.
See: https://github.com/koalaman/shellcheck/wiki/SC2086
These variables can't be double quoted. They contain command line
arguments and should expand as either null or separate argument
strings. Quoting them would cause them to expand as arguments that are
either the empty string (ie., "") or all the individual arguments would
get clubbed into a single argument (ie. "--env=COLORTERM=truecolor
--env=DBUS_SESSION_BUS_ADDRESS=...").
https://github.com/debarshiray/toolbox/pull/83
Even if one of the filters, either c.gh.debarshiray.toolbox or
c.rh.component, returns an empty list then the merged list of image
names would have an element that's an empty string. Some versions of
Podman (eg., 1.1.2) throw an error if an empty string is passed as the
image reference, while newer versions (eg., the snapshots leading to
1.2.0) will ignore the empty string and list all images. Therefore, in
the former case 'toolbox list' will error out; and in the latter case,
depending on whether only one of lists was empty or both, it will
either have duplicate entries or rightly return an empty output.
Fallout from 459763be82
Commit 0ab6eb7401 introduced the com.github.debarshiray.toolbox
label as a better way to identify toolbox containers and images. It
might be necessary to support creating toolbox containers from base
toolbox images that are not appropriately labeled. eg., this would
allow users to use newer versions of the toolbox script with older base
images to debug problems that are only seen in those versions of the
images.
While no change has been made, yet, to either enforce the presence or
override the absence of the com.github.debarshiray.toolbox label it is
prudent [1] to ensure that artifacts produced by 'toolbox create' are
adequately labeled regardless of what labels the input base image had.
[1] https://en.wikipedia.org/wiki/Robustness_principlehttps://github.com/debarshiray/toolbox/pull/91
Commit 0ab6eb7401 introduced the com.github.debarshiray.toolbox
label as a better way to identify toolbox containers and images. Images
having that label should be included in 'toolbox list'.
Since 'podman images' re-formats the creation time (ie., {{.Created}})
into a human-readable form (eg., 34 seconds ago), successive
'podman images' invocations might have slightly different strings for
the same image. This becomes a problem for images that have both the
com.github.debarshiray.toolbox and com.redhat.component tags. If they
have slightly different entries for the creation time, sort(1) and
uniq(1) won't consider them as the same entry.
Moreoever, specifying multiple filters will only match images that have
both tags, instead of images that have either one of them. This will
break compatibility with older images that didn't have the
com.github.debarshiray.toolbox label.
Therefore, the images are queried as two separate lists without the
creation time. The creation time is queried in a separate step once the
two separate lists of images have been merged into one. To ensure some
human-understandable ordering, the lists are merged based on the image
names, not the image IDs.
https://github.com/debarshiray/toolbox/pull/91
Currently the toolbox script identifies toolbox images and containers
by checking whether the com.redhat.component label matches
"fedora-toolbox". However, as per the Fedora Container Guidelines [1],
the com.redhat.com label should match the Red Hat Bugzilla component
name where bugs against the image should be reported. This means that
images derived from the base fedora-toolbox image would likely end up
overwriting it.
One option would've been to mandate that all toolbox images have the
"fedora-toolbox-" prefix in their names. However, it's better to avoid
putting limitations on how images can be named. The "fedora" name
wouldn't anyway work for images based on other distributions, and not
all images are going to use the Red Hat bugzilla for tracking bugs.
It's better to use a tag that's uniquely associated with the toolbox
project, and isn't tied to a particular distribution or bug tracker.
[1] https://fedoraproject.org/wiki/Container:Guidelines
