For many years, you could use the match() filter of syslog-ng to parse log messages with regular expressions. However, the primary function of match() is filtering. Recent syslog-ng versions now have a dedicated regular expression parser, the regexp-parser(). So, you should use match() only if your primary use case is filtering. Otherwise, use the regexp-parser for parsing, as it is a lot more flexible. You can read the rest of my blog at https://www.

The latest pull request to syslog-ng adds a really useful feature: the flip-parser(): https://github.com/syslog-ng/syslog-ng/pull/3971 It allows you to flip the message text, reverse it, or both. As I also reported a couple of minor problems related to UTF-8 character handling, this PR most likely will not be merged today. However, you can compile it yourself, or if you use openSUSE Tumbleweed, use my packages from the openSUSE Build Service. You can read the rest of my blog at https://www.

Session recording has been available in sudo for many years, however not many people are aware of it. Even less well-known is that you can save not just the terminal output, but also what the user types. That way you can analyze what the user is doing within a shell session. Recordings may also include user passwords, which is not always desirable. Version 1.9.10 of sudo allows you to hide passwords in session recordings if it recognizes a password entry.

There are multiple ways in syslog-ng to limit message rate. The throttle() option of syslog-ng destinations tries to make sure that all messages are delivered without exceeding a specified message rate. The rate-limit() filter introduced in syslog-ng 3.36 drops surplus log messages, making sure that a processing pipeline or destination is not overloaded with log messages. Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/the-difference-between-throttle-and-rate-limit-in-syslog-ng syslog-ng logo

Most of syslog-ng works perfectly well on MacOS; however, there is no native driver to collect local log messages. Due to this, in the past, the system() source did not work on MacOS, thus the default syslog-ng configuration failed to start. Version 3.36 of syslog-ng includes a workaround: it follows /var/log/system.log. You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/the-system-source-of-syslog-ng-now-also-works-on-macos syslog-ng logo

The March syslog-ng newsletter is now on-line: syslog-ng future: the path to syslog-ng 4 MQTT source Another use for the syslog-ng elasticsearch-http destination: Zinc Sending logs to Elastic Cloud using syslog-ng syslog-ng 3.36 is now available It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2022-03-syslog-ng-4-mqtt-source-zinc-elastic-cloud-3-36 syslog-ng logo

As explained in my previous post, we do have some features already in mind for syslog-ng 4, even though the work on creating a long term set of objectives for the syslog-ng project is not finished yet. One of the themes that I have working code for already, is typing. syslog-ng traditionally assumes that log data, even if it comes in a structured form (like RFC5424 structured data or JSON) is primarily textual in nature.

It has been possible to use wildcards in the sudoers file for many years. This can make configuration easier and more flexible, but it also introduces problems of its own. Regular expressions, introduced in in sudo 1.9.10, allow you to create more fine grained rules. From this blog you will learn about some of the problems when you use wildcards in your sudoers file, and how using regular expressions can resolve those problems.

Version 3.36 of syslog-ng brings us many interesting new features. There is now basic support for system() source on MacOS, TLS 1.3 ciphers can now be restricted, TLS keylog support was added, symlink creation to the latest file, and there are many new possibilities in syslog parsing. From this blog, you can learn about some of the new 3.36 features, and we will test symlink creation, which is a community-contributed feature.

Last week, the ivykis library, the most important core dependency of syslog-ng landed in EPEL 9 successfully. There are still plenty of dependencies missing, but this way, I could submit a slightly cut down version of syslog-ng to EPEL 9. Hopefully the rest of the dependencies will arrive in EPEL 9 as well. I plan to update the syslog-ng package as soon as the dependencies arrive. Luckily, these are only needed to enable some less frequently used syslog-ng destination drivers, no core functionality is affected.