Over time, the building of bespoke/customized packages has become much easier too, this blog post explains it all. Premium Edition and commercial support from One Identity (the company which acquired Balabit):.Downstream products, for example the open source SC4S to feed syslog data to Splunk using syslog-ng:.Production docker image (for docker-compose or Kubernetes deployment):.List of binary packages for various enterprise/community Linux distributions & BSDs:.Debian packages produced by the project itself:.There are a number of options today to pick from, should you want to use the latest and greatest: We worked hard in the past years to resolve this issue and today syslog-ng is not only available in source format. Even though 20 years ago, building your own kernel or application was an essential part of a sysadmin’s job on any UNIX, this is not true any more.Īlso, it was a lot easier to build syslog-ng in 2001, today we have so many integrations that pulling all the build dependencies (and the right versions) is far from trivial. Solution: state of the art binaries to pick fromīuilding the latest version of syslog-ng for your enterprise distro on your own is not for the faint of heart. They would fix security issues, should they be reported, but otherwise they will just continue to use what they have. Just as log management is not a central focus for the OS, neither is it for the support team behind the OS. The support from the OS vendor for the logging component is questionable at best and is restricted only for the most basic use-cases, not cases where syslog-ng would play an important role in one’s infrastructure. So even though more recent versions of syslog-ng includes functionality or fixes they need, they stick to the old version and try to work around any issues they find. Some claim that upgrading syslog-ng would violate their support terms, causing the entire OS to become unsupported. Often, the sysadmin responsible for log management is not even allowed to upgrade. Unfortunately they deploy syslog-ng as a part of the OS and expect the OS vendor to provide support. So even though distributions helped initial syslog-ng adoption, they have become a bottleneck in delivering new releases to users.Įnterprise users (and products that embed Linux and syslog-ng) pick an OS version and plan with it for ~10 years.
Neither matters their actual version number. Whether that log daemon is syslogd, rsyslog or syslog-ng does not really matter. They each need some kind of log daemon, but that’s it. I considered this a great success.įor none of these distributions however is log management a central question. There are similar stories with syslog-ng included in products or an OS release, usually with pretty old versions.ĭue to the early adoption of syslog-ng, it was included in a number of Linux distributions and BSDs/UNIXes, even became default in some of them. syslog-ng is included in BMW i3 vehicles, this video shows the listing of open source components on the infotainment screen, The BMW Open Source DVD contains syslog-ng 3.4.7, a whooping fresh release from December 2013. This release was originally published 5th August 2014, roughly 8 years ago, and happens to be part of EPEL7. I often get questions about syslog-ng 3.5.6. addressing new use-cases) and on the support perspective (e.g. This is needed for both the feature front (e.g. With that I said I still think that being able to regularly push out updates to deployments is an important bottleneck to solve for any product to be sustainable. Swapping out technologies every now and then on a whim would mean that the project never reaches the goals it was set out to achieve. Deploying a log management and processing infrastructure from scratch can literally take years just one time. Maintaining this change velocity in the log management space is not feasible. New hypes and incompatible rewrites are published at a pace which makes the JavaScript ecosystem difficult to follow. No product is able to improve and cover new ground in a situation like this…īeing ancient is a relative term: for instance, in the JavaScript world it is considered ancient if you are using a framework that was initially released two or more years ago. It has become difficult for me to get these deployments to more recent versions.
I find that a lot of syslog-ng deployments are lagging behind and are using ancient versions.
0 kommentar(er)
