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

[Douglas, William]

On Thu, Nov 8, 2012 at 8:54 AM, Kay Sievers <kay at vrfy.org> wrote:
> 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.
>

Awesome!

> 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.
>

Yes start up is interesting. I imagine an admin would probably want to
be able to take action on messages that have happened before the
journal and message activation are online. Is the BOOT_ID field useful
for determining where to start processing these messages? Seems like
it might be good to take an optional AfterJournal=Bool so some units
could by pass on those earlier messages too.

The already running daemon's I expect to have have a socket available
for getting these messages, though I guess a SIGUSR# could work if
there isn't need for much in the way of data transfer.

For run once type processing, re-activation could work more like
daemon at .service files. Each message event would just do a run with
their cursor as the identifier.