I define syslog-ng, as an “Enhanced logging daemon with a focus on portability and high-performance central log collection”. One of the original goals of syslog-ng was portability: running the same application on a wide variety of architectures and operating systems. After one of my talks mentioning syslog-ng, I was asked how we ensure that syslog-ng stays portable when all the CI infrastructure focus on 64bit x86 architecture and Linux.
For many years, before a new pull request was merged to the syslog-ng master branch on GitHub, the code was compiled and tested by Travis – on Ubuntu, x86. Changes were merged only if all tests ran successfully. But this is only one operating system on one architecture. Luckily, not any more.
Recently Mac builds were added. While still x86, it is running on a completely different operating system. Automatic test cases are also executed for OS X binaries.
A few years ago I also started to do regular git snapshot builds for RPM distros. Of course, not from every commit, but at least two-three times a month. As the test framework used by syslog-ng is not packaged yet for RPM distributions, these are just compile tests, but they cover many different platforms.
On the operating systems side:
-
all active openSUSE Leap releases, Tumbleweed and SLES 12 & 15 from the SUSE world
-
all active Fedora releases, Rawhide, and CentOS 7 & 8 from the Red Hat family
This ensures that old operating systems are kept being supported and bleeding edge does not break syslog-ng. If there is a problem, it can be debugged and fixed before a release.
On the architecture side, syslog-ng is compiled not just on 64bit x86, but also on 32-bit x86 and ARMv7, and various 64bit architectures: AMD64, ARMv8, POWER and POWER little endian, and even s390. These are just compile tests, but I do occasional manual testing as well. Of course, that does not allow catching all problems, like an Aarch64 bug on Fedora Rawhide, when I do testing on a more conservative openSUSE Leap. If someone reports a problem and I have the hardware, I can still install the problematic OS and do some testing. I have a wide variety of ARMv7 development boards, but recently I do most of the testing on a SoftIron OverDrive box. It is Aarch64 and I received it as a courtesy of ARM.
Not this often, but I also test syslog-ng git snapshots on FreeBSD. Mostly on AMD64, but sometimes also on Aarch64. Just to make sure that one more operating system outside of Linux and OS X is regularly tested. Why FreeBSD? First of all, I keep using FreeBSD almost from the day it was born, even a few months earlier before I started to use Linux. And it is also the largest platform outside Linux where syslog-ng is used, including some appliances built around FreeBSD.
Travis announced support for ARM just recently: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support. It needed some extra work on the syslog-ng side, but now each pull request is also tested on ARM before merging. This is not just a simple compile test – as I do most of the time – but it includes unit tests as well.
Does this approach work? Yes, it seems to work. For example, syslog-ng compiles on all architectures supported by Debian. That also includes MIPS that I only tested with syslog-ng once. And I learned about a new architecture just by checking on which CPU architecture the BMW i3 is using to run syslog-ng :) It is the SuperH.
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.
