This is a lot more clear and explicit than TOOLBOX_PATH, which is more
of an implementation detail to bind mount the toolbox script inside the
toolbox container.
https://github.com/debarshiray/toolbox/pull/142
When there aren't any toolbox containers, 'toolbox enter' will offer to
create a new container matching the same parameters passed to the
command.
If 'toolbox enter' was invoked with the default parameters, and
there's just one toolbox container available, then it will fall back
to it.
https://github.com/debarshiray/toolbox/issues/128
A subsequent commit will 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.
There's won't be any need for the command suggestion when a toolbox
container gets created by the 'toolbox enter' command itself. The
suggested command would be the same as the one the user would have had
entered.
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
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
