[systemd-devel] Journal API demo application: "tallow" - a fail2ban replacement

[William Douglas]

"Kok, Auke-jan H" <auke-jan.h.kok at intel.com> writes:

> Hi folks,
>
> I wrote a demo application that uses the journal API to scan for SSH
> bruteforce logs in the journal, called "tallow".

Since Auke is on vacation now (and would *never* read email or work on
projects on vacation ;) ) and has finally put this could out there, I
want to ask about getting a general event response processor in the
journal/systemd.

In order to avoid 30 daemons each doing an inotify on the journal for
their message of interest to pass by, I think having a simple .log-event
type unit file be used by the journal would be a nice to have feature.
An example of what I'm thinking of would be the following to run a
processing script for each core dump:

[Event]
MessageID=fc2e22bc6ee647b6b90729ab34a250b1 (or SD_MESSAGE_COREDUMP)

[Service]
type=oneshot
ExecStart=/usr/sbin/core-processor %data %pid


Where Event can contain any journal field, conditions are done as normal
ie ConditionFileExists and friends (including allowing ! prefixes).
For the ExecStart line %data and %pid are examples of passing journal
fields though I'm definitely looking for opinions on how this could best
be done as it doesn't seem right to have them in the [Service] group but
having some kind of ExecArguments in [Event] seems odd too.

Anyway I'd like to hear people's opinions on why this feature is
unneeded and what other way I should be doing this or maybe even this is
a good idea and with some refinement could get merged in to systemd.

-- 
William Douglas, Intel Open Source Technology Center