Toolbox and docker image

I have SilverBlue 32 installed. I’m working on a site which uses Jekyll and then deploying to gitlab pages. For local serving in my development environment I have created a toolbox container and installed jekyll through DNF. This is working well.

I noticed that the jekyll project has an official docker image:
The documentation for that image is rather opaque:
I have been able to pull this down with Podman. I have not been able to do much with it, though. I’m having trouble getting it to behave. Does anyone have experience with changes necessary to go from dockerhub images to podman containers or toolbox?

1 Like

Only fedora images work with toolbox as far as I know. When it comes to regular containers from docker hub, for the ones that I have tested, I just replace docker with podman and everything works.

1 Like

It does look like images for toolbox need to have specific flags set for specific reasons.

For this docker image I need to mount a volume with the git repository of the jekyll page I’m wanting to serve. It then serves that on; Using -P I can bind that to some port on the host.

I have run into some strange behavior with my ~/.cache. It keeps getting ownership changed to funky things. I wouldn’t expect that to be podman related, but it seems to be.

On my system i use an alias for docker alias docker='podman', I have been able to run most docker images I have tried with no changes to the command line. The toolbox container is setup sharing the user environment and has a high level of privilege provided. If you think something is amiss with your ~/.cache dir ownership, you should probably raise an issue at so you can have it resolved, or at least make the team aware of the problem.

User file permissions and containers get pretty messy. I often avoid docker/podman for applications that work with files in my home directory because of this.

At least in the case of podman as a non-root user, it will run in a different user namespace by default. You can pass --userns=keep-id to podman create to workaround this. Even then you would also need to create a user inside the container with your user id and use that user. It looks like the docker image you are using anticipated this and you can set the JEKYLL_UID environment variable to your user’s uid.

1 Like

I’ll give that a try and see how it behaves.

Toolbox is (at least for now) meant to be used with appropriate images. In the future, we’d like to add support for binary shims that would allow invoking binaries on the host from inside of a toolbox container. This should make the workflow much easier.

I don’t have experience with images like the one you mentioned but from what I heard just replacing docker with podman should be sufficient in most cases. The feature parity should be very high. If you think there’s something amiss, report it (as jakfrost mentioned) in the silverblue bugtracker or directly in Podman’s bugtracker.

1 Like

While this isn’t Docker related, we use with toolbox and Jekyll over at the Cockpit project.

The Cockpit Project website is built with Jekyll and I wrote some simple toolbox scripts to normalize toolbox container creation and running the site locally.

As it installs just the dependencies needed for installing Jekyll via gems (locally cached in the website checkeout’s .gem directory), it’s a more flexible approach, as you can version the gems compltely independent of what Fedora provides. (We also have a script for updating the gems after installation too.)

Our website itself is built with GitHub pages and people have their own forks (with building turned on) for previewing. We rely on the toolbox containers mainly for testing things locally (generally for stuff that is more than just content updates) and use our forks for sharing previews of proposed content changes in pull requests.

I understand this doesn’t directly answer your question, but seeing how someone else works with Jekyll in containers might be interesting. :wink:


Hi all, I am also working with FS 32. My issue is like that put forward by burdickjp but in the opposite sense. Indeed I have not had problems when running containers. I have a lot of software installed in my default container. As far as I understand if I want to run this container in another computer, one of the most convenient solutions consists of pushing the image of this container into duckerhub. I am going to put quite an innocent question: can I run my default container after doing so, or it is convenient to make a copy of that image before? And in such a case, what is the easiest way to copy an existing image? Actually tutorials are sometimes rather opaque when they come to practical questions. And this software may be of great help in schools, by the way.

Podman, in fact, runs in the UID of the user who runs it.

Technically podman commit can take your container and turn it into an image, which could be copied to another host. But in practice this is rarely how docker/podman are used, and I think you could find in the long run this is more confusing than helpful. If you are interested in learning the best practice for creating images, you may want to look into how to write a Dockerfile.

Are you sure about that? I think that with rootless podman by default (with a new user namespace), the UID will be mapped according to /etc/subuid.

1 Like

Yes I am since that is a file that you setup a range of UID’s for the user. Check out this Dan Walsh blog about it

1 Like

I was recently taking a new stab at this and it seems Jekyll’s docker image has some capabilities which help in this direction.
As shown here: jekyll-docker/entrypoint at master · envygeeks/jekyll-docker · GitHub

if you pass the environment variable JEKYLL_ROOTLESS it will run the process with UID and GID of 0, which makes this work without requiring any userns stuffs. This is my current startup script:

podman run \
     --rm \
     -it \
     --volume="$PWD:/srv/jekyll" \
     -p 4000:4000 \
     --env JEKYLL_ROOTLESS=1 \
     jekyll/jekyll \
     jekyll serve