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

[Kay Sievers]

On Thu, Nov 8, 2012 at 8:31 AM, William Douglas
<william.douglas at intel.com> wrote:
> "Kok, Auke-jan H" <auke-jan.h.kok at intel.com> writes:
>>
>> 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.

Right, we already planned to have "message activation" in systemd. It
will probably its own unit type, called ".msgid", or something. The
details are not entirely clear, it's just a bunch of ideas that
moment.

We need to sort out a few things, like what happens at startup, to
prevent the "30 daemons" to see all the old messages again and again
and getting activated for them. How to properly wake up an already
running daemon when a new message arrives. How to handle re-activation
for services which exit at idle.

Thanks,
Kay