As part of the Silverblue effort, we are working on some tools to provide users with pet toolbox containers. This is similar to coreos/toolbox, except that we are using buildah, podman, etc. and are aiming to run rootless.
The idea is to:
Create a container that’s tailored to the user’s host environment - same user name and UID, shared HOME and XDG_RUNTIME_DIR, etc.; and is optimized for an interactive CLI experience that’s at par with the host.
Have a simple command that can be used as SHELL on the locked down Silverblue host to get an actual shell inside the RPM-based container.
To simplify creating this container, I’m planning to have a more generic fedora-toolbox image hosted on the Fedora registry that doesn’t have any of the user-specific bits, but takes care of adding all the necessary RPMs to bring the stock fedora image closer to the Silverblue host in terms of the CLI. I wonder if you’d have any comments on the recipe for this image.
Here’s the Dockerfile:
FROM docker://registry.fedoraproject.org/fedora:28
ENV NAME=fedora-toolbox VERSION=28 RELEASE=1
LABEL com.redhat.component="$NAME" \
name="$FGC/$NAME" \
version="$VERSION" \
release="$RELEASE.$DISTTAG" \
summary="Base image for creating Fedora toolbox containers"
RUN sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf
RUN dnf -y upgrade
RUN dnf -y swap coreutils-single coreutils-full
COPY extra-packages /
RUN packages=; while read -r package; do packages="$packages $package"; done \
<extra-packages; \
dnf -y install $packages
RUN rm /extra-packages
Here’s the list of packages (ie. extra-packages) that get added to the stock fedora image:
bash-completion
bzip2
diffutils
findutils
git-core
hostname
iputils
jwhois
keyutils
less
lsof
man-db
man-pages
mlocate
mtr
openssh-clients
passwd
pigz
procps-ng
sudo
time
traceroute
tree
vte-profile
wget
which
words
xz
zip
Ok, I have removed the release label and the RELEASE environment variable locally.
I am happy to embed the list of package names in the Dockerfile itself, if that’s better. I used a separate text file because I thought it would be easier to tweak the list, but I am not very attached to it.
@rishi , do you know if fedora-toolbox will work on Atomic host fc29?
Or is it Silverblue only?
I keep getting failed to create container errors on fc29
I have
runc version 1.0.0-rc5+dev
commit: ff195010cbfd3c62a98a3fd2f7a1e1594afdda1a
spec: 1.0.1-dev
$ fedora-toolbox -v create
error looking up container "fedora-toolbox-bpabon:29": no container with name or ID fedora-toolbox-bpabon:29 found: no such container
invalid host path, must be an absolute path ""
/usr/bin/fedora-toolbox: failed to create container fedora-toolbox-bpabon:29
So I look at my list of containers:
$ buildah containers
CONTAINER ID BUILDER IMAGE ID IMAGE NAME CONTAINER NAME
16f58f8915fd * 032b427fbbf7 registry.fedoraproject.org/f29/fedora-toolbox:latest fedora-toolbox-working-container
I can’t seem to create the toolbox container.
Oh!, I just read the Dockerfile at the beginng of the post!
I will try to buildah with this file and see what happens.
Hi, I’m having the same issue in my machine however I don’t have any buildah or podman images. I executed “toolbox -v create” in a freshly-installed Fedora 30 Silverblue PC. Any additional tips? Thanks. (Please refer to attached screenshot below. Another screenshot is provided in a different Reply post below)
Maybe try this… sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers
If you have already created the container but cannot enter it, that will help. If you are having difficulty creating the toolbox container you could also remove the local container storage with sudo rm -r ~/.local/share/containers . It seems to be a libpod issue.
For what it is worth mentioning, all containers on Silverblue are intended to run rootless, so sudo is never needed to create or enter them. Sudo can be used inside of the toolbox container though if necessary, like when installing things with dnf. Buildah is the container creation tool used in Silverblue and Podman is the container manager, plus skopeo for monitoring your running containers. All of this is intended to be used rootless in most use cases.
