On 04/10/11 12:00, Patrick Ben Koetter wrote:
> * Arturo 'Buanzo' Busleiman <buanzo@...>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>> On 10/03/2011 07:58 AM, Patrick Ben Koetter wrote:
>>> How about an action that stores timestamp, IP, LOG and other data into a SQL
>>> (sqlite, postgres) database.
>>> A cron job could read from the database and create the reports we want.
>>> This way fail2ban would provide a more generic interface to share ban data.
>> I was thinking XML, sqlite as well. Also, we could add some nice example
>> reporting scripts for cron that could read them.
> There's a project at <http://sourceforge.net/projects/fail2sql/> which
> implements an action in php that logs ban data to MySQL. I wouldn't use it,
> because it is MySQL centric and add another scripting languaged. But maybe we
> can learn something from it.
> What's next? Do we need more discussion? Should we start planning? Are we
> ready to go?
I still don't see where this is going, or what is needed. Interaction
with an sql backend would be as easy as specifying an action like
banaction = echo INSERT INTO bans (ip, jail, logs) VALUES (<ip>, <name>,
<evidence>) | psql fail2ban
with an appropriate .pgpass file for the user running fail2ban. Sqlite
is even easier.
The only part that is missing, is that the evidence / log data is
currently not readily available from fail2ban.
Interacting with a sql backend directly from within fail2ban involves
including support for many (ok, some) backends and then maintaining
them, adding either configuration stuff to define the database scheme
(clumsy, verbose) or the need to commit to a specific predefined scheme
(never fits all use cases).
The extreme flexibility that fail2ban already offers to implement things
like this, makes it IMHO not worthwhile to implement a specific interface.