Recently, someone suggested I should check out Alpine Linux and prepare a syslog-ng container image based on it. While not supported by the syslog-ng project, an Alpine-based syslog-ng container image already exist as part of the Linuxserver project.
Other images
The syslog-ng project already provides a Debian-based syslog-ng image. It has well over 50 million downloads. It is available on the Docker Hub. You can find more information about it at https://hub.docker.com/r/balabit/syslog-ng
The majority of syslog-ng users run syslog-ng on RHEL or a compatible operating system. Talking to these users, I found they were not so happy that we use a different OS as a base. I am now working on an RHEL-based syslog-ng container image. Well, almost :-) RHEL UBI (universal base image) based images can only be built on RHEL. CentOS, Alma Linux and Rocky Linux users would not be able to rebuild the image themselves. So, instead of RHEL UBI, I will use a compatible image for a wider reach. Most likely, you will be able to switch it to RHEL UBI with minimal changes, but I have not tested it yet.
Why (not) Alpine?
If you use Alpine as a base OS, the resulting container image is usually a lot smaller than with other operating systems. Alpine has a strong focus on security. So why do many enterprises avoid Alpine Linux? Firstly, there is no commercial entity behind Alpine (Debian has the same “problem”). Second, it is a new OS to learn, both from the user and from the package building perspective. And last but not least, there were some security problems in the container base images that people still remember after years.
The small size of the base image seems to outweigh the perceived problems for admins not needing to run RHEL & clones on their infrastructure. These users are now looking for Alpine Linux based images, as they require a lot less storage or RAM.
Linuxserver
The Linuxserver project provides many container images based on Alpine Linux. One of those is for syslog-ng. You can find it, along with a lot of useful information, at https://github.com/linuxserver/docker-syslog-ng. I tested the image and ran into a few problems. In this blog, I would like to share some of the workarounds I found while testing the image.
The problems also depend on whether you use Docker or Podman. Within the container, syslog-ng runs as a non-root user. You can set the UID/GID on the command line, and it works fine with Docker. If you set the ownership of the log directory to this on the host, syslog-ng inside the container can use it.
Podman is normally a drop-in replacement for Docker, but in this case, it is a bit more difficult. There is no one-on-one usermapping, so the values set on the command line are not helpful. You can work around it by starting a shell (bash) within the running container. The output of “ps” shows you the username running syslog-ng. Change to the /var/ directory, and change the ownership of the log directory accordingly.
Running as a regular user also means that only ports above 1024 can be used by syslog-ng. You can use port mapping to work around this problem, so from the outside, it looks like syslog-ng is running on a port below 1024.
Check the README on GitHub for the command line options and where to map the configuration or log directories.
What is next?
Share your experiences with this syslog-ng container image with us on GitHub. Open a new discussion at: https://github.com/syslog-ng/syslog-ng/discussions
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.