Overview of syslog-ng RPM repositories

Last week I posted about my new syslog-ng-stable RPM repositories. I tried to explain the use case and how it relates to my other repos, nonetheless I got some questions. So, in this blog I provide you an overview of syslog-ng RPM repositories: why to have unofficial packages at all and what are the advantages and disadvantages of the different unofficial repositories I provide.

Distro packages vs. unofficial repositories

Most Linux distributions – like openSUSE or Fedora – include a syslog-ng package in their official repositories ready to install. Some others – like SLES and RHEL – include it in semi-official repositories, like SLES Backports and EPEL. What is the use case for unofficial repositories?

Unless you use the rolling version of a distribution, like openSUSE Tumbleweed or Fedora Rawhide, you will be using an old version of syslog-ng. In some extreme cases, like RHEL 7, it means a six years old syslog-ng release, missing many features – like multi-threading – which are taken now for granted. Even if the included syslog-ng version is up-to-date, it might miss a few features – like the Java and Kafka destinations – due to missing or too old dependencies in the distribution.

If you are lucky or just have a simple use case, the syslog-ng package included in the distro is sufficient for you. If you need one of the features missing from the distribution package, consider the unofficial syslog-ng repositories.

What “unofficial” means? While I am a Balabit/One Identity employee, these are not official repositories. They are provided as is, with a best effort level of support.

Git snapshot repositories

In an ideal world, I build packages from syslog-ng git master snapshots every week. In practice it depends on the pressure on me, but I try at least twice a month.

What is it good for? For me it is good as I can spot any changes in syslog-ng requiring a change in packaging immediately. Doing the release packages is much easier this way. Also, any compile related problems surface quickly before the release (see my “Keeping syslog-ng portable” blog). For the user it is an easy way to test new features or bug fixes.

What are the possible problems? It is software under development. Even with automated tests running before each commit, there is a larger chance for running into bugs than at releases. Some people use these packages in production but unless you really need to (new feature or fix for a fatal bug), I recommend using it only for testing.

Learn more about my git snapshot repositories and how to install syslog-ng from them at https://www.syslog-ng.com/community/b/blog/posts/rpm-packages-from-syslog-ng-git-head/

Versioned syslog-ng repositories

For many years – especially after syslog-ng changed to a rolling release model – users I talked to asked for up-to-date RPM packages. They also asked for a separate repository for each new release to avoid surprises (a new release might accidentally or even intentionally break old features) and to be able to use a given release if they want to (“if it works, do not fix it”). That is how my unofficial RPM repositories were born.

Ever since my git snapshot repositories were born, I first build a new syslog-ng release there and then copy the results to a new versioned repository – like syslog-ng45 for the currently latest syslog-ng 4.5 version.

Compared to the (semi)official distro packages, you have the advantage of using a more recent and fully featured syslog-ng package. As the repo is versioned, there are no surprises on updates.

On the negative side, as the repositories are versioned when you need to upgrade to a more recent syslog-ng version you need to use a new repository.

Learn more about my versioned syslog-ng repositories and how to install syslog-ng from them at https://www.syslog-ng.com/community/b/blog/posts/installing-latest-syslog-ng-on-rhel-and-other-rpm-distributions

Next to (semi)official distro packages, this is the most popular way of installing syslog-ng on RPM distros right now.

The syslog-ng-stable repositories

Recently some long-time syslog-ng users and members of the Splunk community started to ask for a repository, which always has the latest syslog-ng version available. Most users still prefer to use separate repositories. That is how I came up with the idea for the syslog-ng-stable repository: I push a new release to this new rolling repo from the latest versioned syslog-ng repository only after at least a week of delay. This is enough to spot most major problems. Once the delay is over and everything seems to be OK, I can push the latest release to the syslog-ng-stable repo. If there is a bigger problem, I can skip the release in the stable repo or wait for a fix.

While the extra week might help to avoid most problems, there is still a chance for unpleasant surprises. These packages are ready for production use, but use them with extra care and do not forget to do in-depth testing before updating your central syslog-ng server!

Learn more about the syslog-ng-stable repositories and how to install syslog-ng from them at https://www.syslog-ng.com/community/b/blog/posts/introducing-the-syslog-ng-stable-rpm-repositories

While these repositories are just a few months old there are already hundreds of users for it. I wonder how popularity of the different repositories will change over time.

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.