The base fedora-toolbox images for Fedoras 28, 29 and 30 are now
available from registry.fedoraproject.org. Hence it's no longer
mandatory to build them locally. If they are built locally, then the
local images will be preferred over the ones from the registry.
https://pagure.io/releng/issue/7874
Hard coding 'fedora-toolbox' instead of $0 was necessary to get a
pleasant layout while keeping the code simple. It's not a big deal
because once there's a build system in place most people will type
'fedora-toolbox', instead of the full path to the script.
Normally, registry.fedoraproject.org will be used. The newly added
--candidate-registry flag can be used to change the default and query
candidate-registry.fedoraproject.org instead.
This doesn't matter right now, but a subsequent commit will make
changes to accommodate command-specific options, where this will start
to matter. After all, the case statement is running against $op, not
$1, so this the right thing to do anyway.
Fallout from 678bdbaf4e
It would be good to have Dockerfiles for multiple Fedora versions, and
possibly even other operating systems like Red Hat Enterprise Linux or
CentOS, so that people can use the toolbox on different host OSes.
In the future, it would be nice to have multiple toolbox containers
corresponding to different OSes exist side by side. One could then
have a Fedora 29 environment on a Fedora 28 host and so on.
Assuming a host UID of 1000, the UID mapping inside the user namespace
created by rootless podman for the toolbox container was:
0 1000 1
1 100000 65536
... which was the same as seen from the host:
0 1000 1
1 100000 65536
Therefore, when running with an UID of 1000 inside the container, it
got mapped to UID 100999 on the host. That means, for example, files
created by the user inside the container end up looking funny from the
host.
This is addressed by creating another user namespace that's a child of
the initial user namespace created by rootless podman. Assuming a host
UID of 1000, the UID mapping inside this child namespace is:
1000 0 1
0 1 1000
1001 1001 64536
... which when seen from the host is:
1000 1000 1
0 100000 1000
1001 101000 64536
This means that UID 1000 inside the child namespace is mapped to the
same UID 1000 on the host via the intermediate namespace created by
rootless podman. UIDs 0 to 999 inside the child namespace are mapped
to UIDs 100000 to 100999 in the host.
This change requires this runc pull request to work:
https://github.com/opencontainers/runc/pull/1862
As suggested by Giuseppe Scrivano.
The working container and its name is a temporary and internal detail
of the 'create' command. It's not something that someone would want to
manually tweak.
Since 'local' is not mandated by POSIX, use a subshell for the
function instead.
This is a step towards making the commands more parametrized so that
one can use different toolbox containers.
When used as PID 1, /bin/sh takes 3248 kB compared to the 4136 kB
taken by /bin/bash. It's not a lot, but is memory that can be saved
for free.
As a nice side-effect, this unbreaks 'create' with podman-0.9.1 because
'podman create ...' doesn't work without a command.
https://github.com/containers/libpod/issues/1452
This adds a --verbose flag which will prevent the error stream of the
child commands from being redirected to /dev/null. The intermediate
file descriptor is arbitrarily hard coded as 42 because shell
variables and redirection don't appear to play well together.
