Alien Pastures

My thoughts on Slackware, life and everything

Tag: container

Using the Slackware Community Forge

May 16, 2026 / / 10 Comments

I wanted to share some news with you. After weeks of hard work and being forced to learn new tech from scratch, the Slackware Community Forge, a git software forge, is now available at https://forge.slackware.nl/ .
It’s not just a git repository server but also a Docker container registry!

 

What the Forge?

I created this Forge as an autonomous and European based alternative to the popular git forges like Github and Gitlab. I have  (well not only I, but a lot of people have) issues with the fact that Github is owned by Microsoft, is fully proprietary and enforces the Microsoft CoPilot AI in weird and unacceptible ways (even though it was ‘by accident’, the tendency and the intent is clear). And Gitlab recently moved office to the US which makes them subjugated to the US administration. Also, Gitlab recently announced their commitment to AI and at the same time will fire 30% of their workforce because of it.
The Slackware  Community Forge is not connected to any form of AI, and it is powered by Forgejo, a fully open source software governed by a European company. meant to be used for hosting free, Open Source and Open Standards Software (OSOSS).

I am not principally opposed to US based companies and their software.  I worked at IBM, use software from Red Hat and my friend Patrick Volkerding runs the US based Slackware Linux company. But I do have concerns about the dangers of potentially having my data controlled by US based entities. Even if my data is encrypted so that content cannot be accessed, the US administration can still request that my own access to my own data is revoked.
My Slackware Cloud Server series of articles is meant to help you (individuals, groups, communities or companies) to implement self-hosted variants of online services that are under your own control, to prevent the risk of losing access to your data, or having your data being monetized by training AI models or by selling it to advertisement platforms.
I invite you to also read those articles!

Now, the Forge.

The Slackware Community Forge is a web-based familiar  interface to manage your own git repositories, use CI/CD runners to validate the changes to your code. The site offers workflows to generate release tarballs. There’s also command-line access via SSH connections using SSH keys.

The CI/CD workflows make use of Slackware Docker images. They are available for stable Slackware release 15.0 and for -current at the time of writing this. Those images come in both 32bit and 64bit flavors. The Slackware Docker images are kept up to date with the changes in Slackware: the images are automatically re-generated when an update to the Slackware ChangeLog.txt is detected.

Of course you can download and use these Docker images locally, the Docker registry is public and does not require an account to download from. For the Slackware “base” images which are really small, the registry URL is https://forge.slackware.nl/slackware/-/packages/container/slackware/versions . The Forge also offers Slackware “builder” images of nearly 2 GB in size, offering all the build tools you would need to compile your project; their registry URL is https://forge.slackware.nl/slackware/-/packages/container/slackware-builder/versions .

If you access the registry via Docker, the hostnames ‘forge.slackware.nl‘ and ‘registry.slackware.nl‘ will both work.

As an example, if you have Docker installed and want to test the image for 64bit Slackware-current, you can run:
$ docker run --rm registry.slackware.nl/slackware/slackware:current bash -c "cat /etc/os-release"
...
Unable to find image 'registry.slackware.nl/slackware/slackware:current' locally
current: Pulling from slackware/slackware
Digest: sha256:74a1caaababd145d40196ee29207c8c0a10602f39463a5077ea1bbe9f05a54d6
Status: Downloaded newer image for registry.slackware.nl/slackware/slackware:current
NAME=Slackware
VERSION="15.0"
ID=slackware
VERSION_ID=15.0
PRETTY_NAME="Slackware 15.0 x86_64 (post 15.0 -current)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:15.0"
HOME_URL="http://slackware.com/"
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
VERSION_CODENAME=current

The Slackware Community Forge accepts users and organizations that have a relationship to the Slackware ecosystem. If you work on a project that matters to Slackware users, or users of Slackware derivatives, you are invited to request an account. Send an email to forge@slackware.nl from the email address that you want to have associated with your Forge account. I will also need your First and Lastname and the login userID that you want to use.
I will send you the temporary password in reply.

Once you receive your credentials, browse to https://forge.slackware.nl/ and click “Sign In”.
On the sign-in page, click “Sign in with Keycloak”:

This will redirect to the Keycloak server which is the Identity Provider that handles the Single Sign On for Slackware Community Services:

Once you enter your userid and the temporary password you received. you are asked to create a new permanent password.
When the login is complete and you have memorized your new password, you will be directed back from Keycloak to the Forge. There you will be asked whether you want to register a new account or link your account to an existing local account.
Your account only exists in Keycloak, so you select “Register new account” and then Forgejo will create an account in its own database which it will link to your actual Keycloak identity:

You are now ready to start using the Forge in earnest.

Pushing your commits to your repository

Your account lives in the Keycloak Identity Provider (IP). Forgejo’s web interface offers the “Sign in with keycloak” button but when you push your commits to your repository via the commandline interface or via https, Forgejo will not recognize your credentials (it will only recognize local accounts). This is a fundamental aspect of how OIDC authentication works in Forgejo, and it cannot be “fixed” to make Keycloak passwords work for “git push”. This is by design. The OIDC flow requires a browser redirect. There is no way to retrofit it into a non-interactive git credential prompt.
There’s two solutions to this issue:

1: Add a SSH key to your Forge account.

This is recommended for any developer doing regular git work and who wants to access their repositories over a SSH connection.
Assuming that you already have a SSH public/private key pair on your computer called “/home/your_username/.ssh/id_ecdsa_forgejo” that you want to use with the Forge, add that public key in Forgejo:

  • ‘Settings > SSH / GPG keys > Manage SSH keys’ (or browse directly to https://forge.slackware.nl/user/settings/keys)
  • Click ‘Add key’
  • Copy the ASCII text of your public key into the provided field that says:
    Begins with “ssh-ed25519”, “ssh-rsa”, “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “sk-ecdsa-sha2-nistp256@openssh.com”, or “sk-ssh-ed25519@openssh.com”
  • Give your key a name so that you can recognize it when you add more
  • Click ‘Add key’ again.

Then on your local computer:

  • Add  the following lines to your ~/.ssh.config file (create the file if it does not yet exist and do a “chmod 600” on the file or else ssh will simply refuse to use it):
Host forge.slackware.nl
  Port 2222
  User git
  ServerAliveInterval 20
  IdentityFile /home/your_username/.ssh/id_ecdsa_forgejo
  • Change directory to the clone of your remote repository, and add the remote as follows (it’s a one-time setup, works forever, for all your repositories, and there are no passwords involved at all.):
$ git remote set-url origin forge.slackware.nl:your_username/your_repository.git

All you need to do to push your commits to the remote repository is a:

$ git push origin

No credentials need to be entered at all.
And if this is the first time you connect to the Forge via SSH, you need to accept its SSH server key to continue. This is also a one-time action.

2: Forgejo API token

This works well for  HTTPS workflows or in environments where SSH is blocked. The API token (aka Access token) takes the place of a regular password.
If you had already cloned your repository, the “origin” URL definition in the “.git/config” file inside that repository will look like this:

[remote "origin"]
    url = https://forge.slackware.nl/your_username/your_repository.git
    fetch = +refs/heads/*:refs/remotes/origin/*

You generate an API token as follows:

  • Login to Forgejo
  • Go to ‘Settings > Applications > Access token’ (or go directly to https://forge.slackware.nl/user/settings/applications)
  • Click ‘New access token’
  • Give the token a descriptive name, make it access to ‘All’
  • Select the permissions you want this token to have; at least that should be:
    • Repository: “read and write”
  • Click ‘generate token’
  • Copy and store the token string in a safe place; this token string can not be retrieved later. If you forget it, you can simply create a new token and use that instead.

Then use the token as the password for HTTPS connections:

$ git push origin
Username for 'https://forge.slackware.nl': your_username
Password for 'https://your_username@forge.slackware.nl':
Everything up-to-date

At the “Username” prompt enter your Forgejo username, and at the “Password” prompt enter your API token.

To avoid typing the API token every time, you can store it in git’s credential helper:

$ git config --global credential.helper store

Then do one successful push. Your credentials are saved to the file ~/.git-credentials with mode ‘0600’ which means that only you can read the contents, which look like this:

https://your_username:APITOKEN@forge.slackware.nl

Documentation

In the “forge-docs” repository of the Slackware organization in Forge, you can find:

Finally…

I hope you will appreciate this new service and also start migrating your Github / Gitlab repositories to the Slackware Community Forge.
Try the CI workflows and report any issues you encounter! Note that I am the single administrator and moderator. Be gentle.

 

My commitment is to run this Forge as a stable and long-term service to the Slackware community. I’ve written admin documentation and in time will look for more administrators. Let’s first see if this initiative is going to be used at all 😉

Have fun! Eric

My Docker packages for Slackware-current

January 7, 2022 / / 39 Comments

I have been using Docker for a while now, it’s being used to provide services to friends and family.
I was always intimidated by the large amount of packages that were needed to get Docker and docker-compose up and running, and I did not have experience with Docker at the time (almost two years ago) so I decided to go the easy route and use the SlackBuilds.org scripts when I first needed to run a Docker container. I wrote a blog about that even, it explained how to run an Outline server to allow journalists to do their work in repressive countries but the article also shares the details how to build the Docker packages and run the daemon.

If you want to read some background information about Docker’s strength and what its use-cases are, I encourage you to start reading here: https://docs.docker.com/get-started/overview/ .
Essentially, Docker uses Linux kernel and filesystem capabilities to isolate an application and its dependencies from the host computer it is being executed on. Docker provides powerful means to connect multiple containers via internal (virtual) networking and can expose ports to the network outside of your container. It enables you to run applications reliably without having to worry about the underlying Operating system. You can even run Docker on a MS Windows computer but your containerized application running inside Docker will not be aware of that.
This is sometimes called ‘light-weight virtualization’ because unlike real virtualization solutions like QEMU, Virtual Box or VMWare, the containerized application still runs on your host’s kernel. This is why you can run a 32-bit container image on a 64-bit (Linux 64-bit kernel has that capability to  execute 32-bit binaries) host but you cannot run  a 64-bit image on a 32-bit host kernel.

Now that I am more familiar with Docker, have been running multiple services in containers for more than a year, and have created and published my own images (more about that later) I decided to create my own set of Docker packages. Having pre-built packages will make it a lot easier for people to start exploring the usefulness of Docker containers.

One thing upfront: I have significantly decreased the total amount of packages you need to run Docker.
I have combined the SlackBuilds.org packages ‘docker’, ‘docker-cli’, ‘docker-proxy’ and ‘tini’ into a single package called ‘docker’ and also added ‘docker-buildx’ to that docker package. Also, the re-write of docker-compose from Python to Go has the benefit that the run-time package dependencies for ‘docker-compose’ have been reduced from thirteen to zero.

Starting with my Docker packages

As stated in the subject: the packages I created are for Slackware-current only. If you want to compile this yourself on Slackware 14.2, I cannot guarantee success since I did not try compiling them there myself – but in any case you’ll have to build and install libseccomp from SlackBuilds.org, this is part of -current but not 14.2.

What you need from my repository to run Docker is: runc, containerd, docker and docker-compose. Four packages – that’s it.
If you want to be able to (re-)compile these packages, you will additionally need google-go-lang. After installing google-go-lang you need to logoff and login again (or run the command “source /etc/profile.d/go.sh” in your terminal) to give Google’s version of Go preference over the GCC version of Go that’s probably already installed on your computer.

The ‘docker’ package installation script will add a couple of lines to “/etc/rc.d/rc.local” and “/etc/rc.d/rc.local_shutdown” to make Docker start on boot and properly stop during shutdown of the computer. The docker rc script “/etc/rc.d/rc.docker” will initially be installed without the execute bit, so if you actually want to start using Docker you have to make the script executable. This is a one-time action. Future package upgrades will honor the executable status of that script.

# chmod +x /etc/rc.d/rc.docker

You can start the Docker daemon now if you don’t want to waste time with a reboot:

# /etc/rc.d/rc.docker start

The package installation will also trigger the creation of a new group called ‘docker’. If you want to be able to run and manage your Docker images and containers as your own non-root user account, you need to add your user account to this ‘docker’ group and then logoff/login again, and restart the docker deamon. Otherwise, all Docker operations can only be executed by the root user.

# gpasswd -a <your_useraccount> docker
# /etc/rc.d/rc.docker restart

After doing all the prep work, your account added to the ‘docker’ group and the daemon running, it’s time for a first test. Run the following command:

$ docker run hello-world

You’ll see the following output:

Unable to find image 'hello-world:latest' locally 
latest: Pulling from library/hello-world 
2db29710123e: Pull complete 
Digest: sha256:2498fce14358aa50ead0cc6c19990fc6ff866ce72aeb5546e1d59caac3d0d60f 
Status: Downloaded newer image for hello-world:latest 

Hello from Docker! 
This message shows that your installation appears to be working correctly
...

What you will have validated here is the proper functioning of your Docker installation:

  1. The Docker command-line client contacted the Docker daemon.
  2. The Docker daemon downloaded (or ‘pulled‘) the “hello-world” image from the Docker Hub.
  3. The Docker daemon created a new container from that image which runs the executable that produces the output you could read on your terminal just now.
  4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.

The “hello-world” image is of course trivial, but there are many more with real-life use-cases which you can find on  Docker Hub, https://hub.docker.com/. You can download these images freely but if you want to upload (or ‘push’) an image which you created yourself, you’ll have to create an account on Docker Hub. Free acccounts allow the creation of one single private repository and unlimited public repositories.

Slackware Docker images

I have a repository on Docker Hub where I share my base images for stable Slackware versions (that’s the 14.2 release right now). Go get them at https://hub.docker.com/r/liveslak/slackware/tags . These “base images” are roughly 55 MB compressed, which means they are really basic. They are created using a script (create_slackware_docker_image.sh) which takes its inspiration both from the liveslak scripts and of Vincent Batts‘ work on Docker images for Slackware. Essentially, the script installs some packages into a package root, uses tar to put all of that in a tarball and loads the tarfile into Docker which will then make it into an actual image for you. That image wille be called “slackware:base_x64_14.2” (unless you specified a different architecture and release of course) and that’s what I uploaded to the Docker Hub.
My tiny Slackware docker-images are not really meant to be used as-is. Instead, they can act as the foundation for Slackware-based Docker images that you might want to build yourself – any Docker image starts with some existing base image and adds new layers on top. Base images like mine above don’t inherit from a lower-level image and are a special case, read more here: https://docs.docker.com/develop/develop-images/baseimages/

Now let’s pull that Slackware base image from the Hub and peek inside!

$ docker run -ti liveslak/slackware:latest /bin/bash -l

The “-ti” parameters tell docker to assign a pseudo-tty and run an interactive session on your terminal.
The convention for the image name is “username/imagename:tag” which shows that “liveslak” is the user who hosts the image on Docker Hub; “slackware” is the name of the image and it has a tag “latest” which means: just give me the latest version that I can get. For the slackware image, this means you get the 64-bit variant (I also have a 32-bit image) of Slackware 14.2.
The “/bin/bash -l” at the end is the command which Docker should run after bringing the container online. Remember, the base image contains nothing but a small amount of installed Slackware packages and does not start any application by itself. More complex Docker images may run all kinds of applications, some in the background and some meant to be interacted with such as the bash shell.

Running the above command yields this result:

Unable to find image 'liveslak/slackware:latest' locally 
latest: Pulling from liveslak/slackware 
6c721e5d29bd: Pull complete 
Digest: sha256:352219d8d91416519e2425a13938f94600b50cc9334fc45d56caa62f7a193748 
Status: Downloaded newer image for liveslak/slackware:latest 
root@b0264b9e59ff:/#

And we end up at the command prompt of our running container. The container user is ‘root’, it’s the only user in that base image. You do not have to enter a password.
Let’s play a bit:

root@b0264b9e59ff:/# ls /var/log/packages/ | wc -l
77
root@b0264b9e59ff:/# cat /etc/os-release 
NAME=Slackware 
VERSION="14.2" 
ID=slackware 
VERSION_ID=14.2 
PRETTY_NAME="Slackware 14.2" 
ANSI_COLOR="0;34" 
CPE_NAME="cpe:/o:slackware:slackware_linux:14.2" 
HOME_URL="http://slackware.com/" 
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" 
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
root@b0264b9e59ff:/# exit
logout
$

Suppose you want want to download and use the 32-bit Slackware 14.2 base image instead. Then you would run:

$ docker run -ti liveslak/slackware:base_ia32_14.2 /bin/bash -l

Here ends my very brief introduction to Docker on Slackware. Let me know what you think of this! Is there anything you would like to see explained in more detail?
Eric

Update 2022-jan-13: I have added packages for Slackware 14.2 (32bit and 64bit) to my repository.

© 2026 Alien Pastures

Theme by Anders Noren — Up ↑