A subsequent commit will add a new command to configure a toolbox
container after it has been created. This command is meant to run
inside the container without being forwarded to the host. Therefore,
just running inside a container doesn't mean that flatpak-spawn(1) is
mandatory.
This should help with toolbox containers created from images which
don't have flatpak-spawn(1) in them. eg., the fedora-toolbox base image
for Fedora 28.
https://github.com/debarshiray/toolbox/pull/160
Consolidate the code to forward commands to the host in one place
instead of doing it repeatedly for each command. This reduces the
levels of indentation in the code, making it easier to read.
https://github.com/debarshiray/toolbox/pull/160
A subsequent commit will add a new command to configure a toolbox
container after it has been created. This command is meant to be the
container's entry point, and will need to do things as root:root
relative to the user namespace.
Even though root:root is the default in 'podman create', explicitly
specifying it overrides any other value inherited from the
user-specific customized image. eg., older images had $USER as the
default user.
https://github.com/debarshiray/toolbox/pull/160
Commit 8127daa29e added the com.github.debarshiray.toolbox label
to the user-specific customized image generated by the 'create'
command, which gets inherited by toolbox containers using the image.
However, there might be really old images lying around in users' caches
that don't have the label, and in those cases the damage can be
limited by adding it directly to the newly created toolbox container.
Moreover, a subsequent commit will remove the need for the
user-specific customized image, and which will make this change
mandatory.
https://github.com/debarshiray/toolbox/pull/160
Even though buildah-unshare(1) does mention the need for the dashes,
the buildah-1.8 development builds do work without them. However,
buildah-1.7 is more pedantic and insists on having the dashes.
https://github.com/debarshiray/toolbox/issues/152
KCM is the only type of Kerberos credential cache that can seamlessly
work across the host and the toolbox container. In case the host isn't
using KCM, then Kerberos will error out inside the toolbox container,
which is fine.
https://github.com/debarshiray/toolbox/pull/162
Currently, the toolbox script depends on both the buildah and podman
commands. However, both are Go programs, and like all Go programs the
absense of shared libraries leads to bigger binaries. eg., the buildah
and podman binaries are approximately 22 MB and 48 MB respectively,
whereas the flatpak binary is a mere 1.4 MB.
Due to this, there's some nascent desire from the Endless OS folks to
reduce the dependency footprint of the toolbox script by replacing
Buildah with the corresponding Podman commands. This is a step in that
direction.
https://github.com/debarshiray/toolbox/pull/161
Currently, the toolbox script depends on both the buildah and podman
commands. However, both are Go programs, and like all Go programs the
absense of shared libraries leads to bigger binaries. eg., the buildah
and podman binaries are approximately 22 MB and 48 MB respectively,
whereas the flatpak binary is a mere 1.4 MB.
Due to this, there's some nascent desire from the Endless OS folks to
reduce the dependency footprint of the toolbox script by replacing
Buildah with the corresponding Podman commands. This is a step in that
direction.
https://github.com/debarshiray/toolbox/pull/159
Various users in the wild have reported errors about not being able to
walk up the process tree via /proc, and currently the PID of the
parent 'podman exec' process isn't used for anything. The original idea
was to explore killing the process or something when entering another
toolbox container while already being inside one, but that's not
implemented at the moment, and it was only a vague idea to begin with.
... as opposed to any random container.
This puts in place a minimum baseline as to what can be expected from
the environment when running inside a container.
... because of its likeness to the Toolbox logo. Note that the magenta
foreground colour is requested through a terminal escape sequence with
SGR parameters [1]. The specific colour code for magenta is 35.
The main body of the PS1 needs to be split out to prevent Bash from
complaining:
bash: printf: missing unicode digit for \u
[1] https://en.wikipedia.org/wiki/ANSI_escape_codehttps://github.com/debarshiray/toolbox/pull/150
This makes 'toolbox enter' similar to 'toolbox run $SHELL'.
The 'run' command is meant to spawn arbitrary binaries present inside
the toolbox container. Therefore it doesn't make sense for it to fall
back to /bin/bash, like it does for 'enter' if $SHELL is absent.
It's expected that users might use 'run' to create ad-hoc *.desktop
files. That's why it neither offers to create nor falls back to an
existing container like 'enter' does, because such interactions can't
happen when used in a *.desktop file. It's also a more advanced command
that new users are less likely to be interested in. Hence, this
shouldn't affect usability.
Some changes by Debarshi Ray.
https://github.com/debarshiray/toolbox/pull/76
The shell start-up scripts are where the PS1 is meant to be set. So
far, the absence of a toolbox-specific start-up script was being worked
around by setting the PS1 as part of the 'podman exec' invocation. This
came with certain limitations. eg., using su(1) or sudo(8) to get a
root shell can overwrite the PS1 set during 'podman exec' with a value
set by the operating system's existing start-up scripts depending on
which environment variables were being retained.
Now that the toolbox has it's own /etc/profile.d/toolbox.sh start-up
script, it's time to move the PS1 to its rightful home.
Since the start-up script and /run/.toolboxenv are present in older
toolbox containers, this change should be fully backwards compatible
and lead to a more robust PS1 without breaking older containers.
https://github.com/debarshiray/toolbox/pull/148
This is better than setting an environment variable like
TOOLBOX_CONTAINER with 'podman create' because, unlike environment
variables, it can't be unset later by commands like su(1) or sudo(8).
One nice side-effect of doing it inside 'toolbox enter' is that it
will automatically work with older toolbox containers.
A subsequent commit will switch to using the /etc/profile.d/toolbox.sh
start-up script to set the PS1 instead of doing it as part of the
'podman exec' invocation. Having the identification mechanism work with
older toolbox containers is important to avoid breaking the PS1 for
backwards compatibility.
This reverts commit c7b7fa1867https://github.com/debarshiray/toolbox/pull/148
Commit 97f4e072d5 made /etc/profile.d/toolbox.sh available inside
the toolbox container through a bind mount. However, it only works for
for toolbox containers created after that commit. Older containers
don't have the bind mount.
A subsequent commit will switch to using the /etc/profile.d/toolbox.sh
start-up script to set the PS1 instead of doing it as part of the
'podman exec' invocation. It's necessary to ensure that the start-up
script is available on older containers to avoid breaking the PS1 when
entering them.
https://github.com/debarshiray/toolbox/pull/148
Currently, the toolbox script depends on both the buildah and podman
commands. However, both are Go programs, and like all Go programs the
absense of shared libraries leads to bigger binaries. eg., the buildah
and podman binaries are approximately 22 MB and 48 MB respectively,
whereas the flatpak binary is a mere 1.4 MB.
Due to this, there's some nascent desire from the Endless OS folks to
reduce the dependency footprint of the toolbox script by replacing
Buildah with the corresponding Podman commands. This is a step in that
direction.
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
