Technology is continuously evolving. There are regular changes in platforms running syslog-ng: old technologies disappear, and new technologies are introduced. While we try to provide stability and continuity to our users, we also need to adapt. Python 2 reached its end of life a year ago, CentOS 6 in November 2020. Using Java-based drivers has been problematic for many, so they were mostly replaced with native implementations.
From this blog you can learn about recent changes affecting syslog-ng development and packaging.
Python 2
Python 2 officially reached its end of life on 1st January, 2020, so well over a year ago. Still, until recently, compatibility with Python 2 has been tested continuously by developers. This testing was disabled when syslog-ng 3.31 was released. What it means, is that if anything is changed in Python-related code in syslog-ng, there is no guarantee that it will work with Python 2.
Packaging changes started even earlier. Distribution packages changed from Python 2 to Python 3 support already years ago, similarly to unofficial syslog-ng packages for openSUSE/SLES and Fedora/RHEL. While request for Python 3 support was regular, nobody asked for Python 2 after the switch. The last place supporting Python 2 as an alternative was DBLD, syslog-ng’s own container-based build tool for developers. The support there was also stopped for Fedora/RHEL, right before the 3.31 release.
CentOS 6
RHEL 6/CentOS 6 had been the most popular syslog-ng platform for many years. Many users liked it due to the lack of systemd. But all good things come to an end, and RHEL 6 (and thus CentOS 6) reached its end of life in November 2020.
Unofficial syslog-ng RPM packages for the platform were maintained on the Copr build service. Their policy is removing packages 180 days after a platform reaches its End of Life (EoL). I do not know the exact date, but around the end of April all RHEL 6/CentOS 6 repositories will be removed from Copr.
Note: if you still need those packages somewhere, create a local mirror for yourself. I do not have a local backup or a build and test environment anymore.
CentOS 7 ARM
RHEL 7 for ARM also reached its EoL in January. While CentOS 7 keeps supporting ARM, the Copr build service removed support for this platform and will remove related repositories, just as it did for CentOS 6. If you need those packages, you have time till the end of June to create a local mirror of them.
Java-based destination drivers
A long time ago, using Java to extend syslog-ng was the best direction to go. Client libraries for popular technologies were unavailable in C, but they were readily available in Java, for example for Elasticsearch and Kafka. Unfortunately, using Java also has several drawbacks, like increased resource usage and difficult configuration. Also, Java-based destination drivers could not be packaged as part of Linux distributions. So, as soon as native C-based clients became available, people switched to them. Only HDFS is not supported by any other means, but nobody seems to use it anymore – at least in the open source world.
What does it mean for you? Java-based drivers are still regularly tested by the syslog-ng development team. On the other hand, even the unofficial openSUSE/SLES and Fedora/RHEL packages dropped support for them. Java support is still there, as some people developed their own Java-based drivers. If you really need these drivers, use syslog-ng 3.27 from the unofficial RPM repositories or compile syslog-ng yourself. Unofficial Debian/Ubuntu packages still include Java-based drivers and on FreeBSD you can still build them in the sysutils/syslog-ng port.
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.
