24 Jun
2024
24 Jun
'24
9:03 p.m.
Theodore Ts'o wrote in
<20240624135049.GA280025(a)mit.edu>:
|On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote:
|> Except you now have to do the additional step of extracting the
|> data from the binary logs and _then_ apply the regex filter you
|> were going to use in the first place, which makes the logs less
|> accessible. All of my systemd running machines still get rsyslog
|> plugged into it so it can deliver the logs to my central log host
|> (which then dumps them into PostgreSQL) - and to enable a quick
|> rummage in the local logs via less & grep.
|
|Well, no, not necessarily. You *could* just query the structured data
|directly, which avoids needing to do complex, and error-prone parsing
|of the data using complex (and potentially easy to fool regex's). If
...
|console logs. But we've since added an fsnotify schema to the
|upstream Linux kernel which sends a structured event notification
|which isn't nearly as error-prone, and which doens't require parsing
|to fetch the device name, etc. We didn't remove the old-style "print
...
|The bottom line is that while people seem to be ranting and raving
|about systemd --- and there are a lot of things that are terrible
|about systemd, don't get me wrong --- I find it interesting that
|legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
|in the past, when in fact, the "good old days" weren't necessary all
|that good --- and there *are* reasons why some engineers have
|considered plain text ala the 1970's Unix philosophy to not
|necessarily be the final word in systems design.
But that is the thing, and it has nothing to do with systemd vs
a normal syslog. I always wondered why things like fail2ban are
used to make active system decisions, including active firewall
setup, where daemons which *know* (to their extend) a state
transform it to string data, send it to syslog (or files), which
then gets parsed again. Christos Zoulas of NetBSD then came over
with blacklistd about a decade ago, with patches for OpenSSH and
postfix and some more, where at least authentication (failure)
events are collected at the core where they happen, and then sent
to the blacklistd, which has backends for certain firewalls. The
newest OpenSSH has something internal built-in that does not
report the event, as far as i know.
All those do not help against nonsense connections, like premature
forced breaks, or ditto with hanging on the port until the server
(or OS even) closes the connection, TLS setup failures,
downloading the same file a thousand times, etc etc.
A pity it is. The server knows, the firewall or a controller
needs to know. All that deep inspection shit of the past, and all
the guessing on connection count, interpolating connectivity
bandwidth, and what not, "done in the firewall", blind flight.
Noone jumped on that train that blacklistd started, even when
asked for such possibilities.
Sorry, i do not see why a binary "journal" log is any better than
a plain text file except that possibly programs can be addressed
more easily ... by their name.
Btw i hope for that new capability-for-namespaces thing that lwn
reported, that would be cool! (Btw with 6.1.93 i could not
"cryptsetup close" unmounted mediums that were mounted before
kvm driven virtual machines moved to inside cgroup namespaces
were started. Off-topic, of course.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)