[Nottingham] fail2ban on Gentoo - fail2ban version 0.9.0-r1 working ok

[Martin]

Folks,

To answer my own posting:


On 16/08/14 21:30, Martin wrote:
> Folks,
> 
> OK, so I've sort of have fail2ban working...
> 
> 
> In brief, you can run it whereby it uses one of Pyinotify, Gamin, or
> file polling to check for when a list of log files have been updated.
> 
> All well and good except I get from the fail2ban log:
> 
> For Pyinotify:
> gentoo Error in FilterPyinotify callback: _strptime_time

That looks to have been a problem of one or both of:

Running fail2ban version 0.8.13

and/or or coincidentally not recompiling the Python libraries.


Adding into /etc/portage/package.use:

# required by net-analyzer/fail2ban-0.9.0-r1[python_targets_python2_7]
#=dev-lang/python-2.7.7                 sqlite
#
# required by net-analyzer/fail2ban-0.9.0-r1[python_targets_python3_3]
#>=dev-lang/python-3.3.5-r1:3.3         sqlite
#
dev-lang/python                         sqlite


Adding into /etc/portage/package.accept_keywords:

net-analyzer/fail2ban           amd64 ~amd64


And then running an "emerge -vDu fail2ban" recompiled both python and
fail2ban (new version 0.9.0-r1). Rerunning fail2ban gives in the
fail2ban log:

INFO    Initiated 'pyinotify' backend


> For Gamin:
> WARNING Could only initiated 'polling' backend whenever 'gamin' was
> requested

Not retried that one again yet.

Various old posts list problems for pyinotify for becoming lost after
logrotate has rotated any log files being monitored, and for also not
meaningfully reporting all access errors. To be checked further...

Similarly, various old posts suggest Gamin to be the better file
monitor. Yet... fail2ban for "backend = auto" runs through the sequence
pyinotify, then gamin, and then uses polling as a last resort. That
suggests pyinotify is the favoured method...


> Meanwhile the polling works fine except that I see fail2ban using
> continuously 25% of all four CPU threads available.

fail2ban reads through the *entire* log files when first started using
100% of one CPU core/hyperthread. Can be slow if you have big logs.

Thereafter... I'm seeing a much more reasonable 1% utilisation of one
CPU core/hyperthread.


> All on 3.14.17-gentoo with dnotify, inotify and fanotify kernel configs
> enabled.

Comments welcomed!


Anyone got any notable/good/apt filters and jail configs?


Cheers,
Martin


-- 
- ------------------ - ----------------------------------------
-    Martin Lomas    - OpenPGP (GPG/PGP) Public Key: 0xCEE1D3B7
- martin @ ml1 co uk - Import from   hkp://subkeys.pgp.net   or
- ------------------ - http:// ml1 .co .uk/martin_ml1_co_uk.gpg