-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/08/2012 01:18 PM, Douglas, William wrote: > On Thu, Nov 8, 2012 at 8:54 AM, Kay Sievers <[email protected]> wrote: >> On Thu, Nov 8, 2012 at 8:31 AM, William Douglas >> <[email protected]> wrote: >>> "Kok, Auke-jan H" <[email protected]> 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 > [email protected] files. Each message event would just do a run with their > cursor as the identifier. _______________________________________________ > systemd-devel mailing list [email protected] > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > setroubleshoot would be interested in this also, since it would eliminate the need to run with the audit daemon. But journal needs to be getting audit data.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcBCUACgkQrlYvE4MpobNa/gCdHkTSLU4AC/1PRce6zm/0ZwEB X8gAoLYRinLAPafNQc+cDHqxLz+Kk3pE =fDOK -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
