A few days ago I blogged about how great logcheck was. And towards the end I mentioned that writing rules was one of the more annoying parts.
I have for a while been considering how that can be done easier, and while I don’t have my dream solution yet, I have spent a few evenings vibe-coding something that I believe will be helpful.
Logcheck regex helper
You can try it out at nyman.re/logcheck-helper/ right now, or keep reading to learn more about the motivation and possible future development.
Why is writing rules for logcheck hard?
First, it uses egrep (which is an alias for grep -E nowadays), which uses POSIX Extended Regular Expressions. It’s in my experience not the most user friendly regex. Then when you have written one, testing it requires that you do something like logcheck-test -r /etc/logcheck/ignore.d.server/custom -l /var/log/syslog|grep named, but you need to pick the right log and the right rule file.
So what I usually end up doing is writing very coarse matches, which isn’t optimal.
How to fix this
The main problem with logcheck is that it’s noisy, and in combination with writing new ignores being hard, it becomes noise very quickly and nobody reads them. To allow the end user to cut down on the noise, it must really easy to do so. One idea I’ve had is that the alert emails would have a [ignore] button for each line (or all) which will create ignore similar log lines in the future. It would then optionally sync those ignores to all servers so we don’t need to repeat ourselves.
But I am not there yet.
What is Logcheck Regex Helper
It’s a quick proof of concept that tries to help you write the regex. It explores my ideas around providing the user with a working regex, while still allowing them to customise it. In the current version, you can click on the patterns in the pattern-configurator to switch between the regex targeting any text, or that literal text.
This should allow the user to quickly get a decent rule, that can be modified for their use case.
Why vibe coding?
Because this is what it’s good at. Putting together a “simple” proof of concept and allowing for quick experimentation.
And this is all client-side, so there is no risk that it would create a vulnerability.
And what it produces is not critical in any way. If it produces dumb logcheck rules, you will hopefully spot it and worst case you probably just fail to ignore what you wanted ignored.
But the PoC is now deployed?!? So it’s in production?!
Yes. But only because it’s all client side. So there is no risk that bad code could cause issues… (for me).
If this had a server side, I would either sandbox it really hard or not publish it. Probably both.
Will you open source it?
It is open-source… like all client side web applications. It’s not even minified. But if someone asks nicely and would like to contribute or fork it, I will publish the repo. The license is 2-BSD so feel free to copy it.
Blaugust
This is another blaugust post, no editing or spell-checking. Sorry.