In order to correctly detect the spanish months it's mandatory to add their names in the dictionary table, as should be done with the rest of the supported languages (http://lh.2xlibre.net/values/abmon/)
Somehow on that elderly squeeze Debian sparc box, I got error that self.__notifier
was not defined. So first I did define it now in the constructor, but mystery remains
how come it was not defined -- wasn"t run() then run (where it is defined)?
Anyways -- conditioning on it being defined might be safer may be?
Not sure (need to go to sleep) if with this change but on this box I also run from time
to time either into stalling of fail2ban-testcases and refusing to exit normally or
======================================================================
ERROR: test_move_into_file_after_removed (testcases.filtertestcase.MonitorFailures<FilterPyinotify>(/tmp/monitorfailures_FilterPyinotifypcHmMJfail2ban))
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/yoh/deb/gits/fail2ban/testcases/filtertestcase.py", line 473, in tearDown
self.filter.stop()
File "/home/yoh/deb/gits/fail2ban/server/filterpyinotify.py", line 196, in stop
self.__notifier.stop()
File "/usr/lib/pymodules/python2.6/pyinotify.py", line 1315, in stop
threading.Thread.join(self)
File "/usr/lib/python2.6/threading.py", line 633, in join
raise RuntimeError("cannot join thread before it is started")
RuntimeError: cannot join thread before it is started
that is with pyinotify 0.8.9-1 so could quite be "related" to its age.
When a file is deleted, the watcher for it is automatically removed.
FilterPyinotify is detecting a new file being created with the same
name, and in turn attempts to remove the watch for the deleted file
(which has already been removed automatically).
Also, IN_IGNORED events are generated when a file is deleted, but these
weren't being caught, causing an non-existent file path to be passed to
FilterPyinotify._process_file (which caught the exceptions in
Filter.getFailures).
Previously was using `send` method, which uses `socket.send`. This does
not guarantee to send all data, and no check was in place to verify
whether all data was sent. Using asynchat built in `push` method,
ensures that all data is sent before closing the connection.
ignorecommand update man and fix protocol help
ENH: run ignore command only after internal list has been examined. Change interface on ignorecommand to take IP as environment variable and return true if it is to be banned
ENH: ignore IP command to take tagged command
DOC: man pages for ingorecommand
TST: add test cases for ignorecommand
* 'bf/syslog-format' of https://github.com/yarikoptic/fail2ban:
Changelog entries for the last changes
ENH: added optional [PID] matching in recidive.conf
ENH: reintroducing levelnameinto syslog msgs, time stamp and indentation in non-syslog msgs
BF/ENH: include [PID] into logging msgs, remove indentation from syslog messages
Conflicts:
ChangeLog
Otherwise leads to incorrect parsing of the log messages by syslog(-ng). See
http://bugs.debian.org/730202
I also removed %(levelname)-6s from syslog messages completely since they are
passed to the syslog and it is up to the configuration/admin to decide include
levels into the messages or not (I have checked that at least debug level indeed
goes to /var/log/debug)
otherwise years present in the freshly contributed by Dan apache regexes do not match
although should have. I had also to adjust failing now vsftpd test
Otherwise <HOST> regexp might swallow period in the sentence right after the address.
I have decided to enforce alphanumeric instead of switching to non-greedy +? ... because
I think it is closer to what we actually want here
This avoids duplication of code across fail2ban-regex and samples test
cases. This also now more neatly resolves the issue of double counting
date templates matches in fail2ban-regex.
In addition, the samples test cases now also print a warning message
that not all regexs have samples for them, with future plan to change
this to an assertion.
IMHO there is no good reason to capture only gaierror.
on my network it was consistent to error out with
======================================================================
ERROR: testIgnoreIPNOK (testcases.filtertestcase.IgnoreIP)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/yoh/deb/gits/fail2ban/testcases/filtertestcase.py", line 166, in testIgnoreIPNOK
self.assertFalse(self.filter.inIgnoreIPList(ip))
File "/home/yoh/deb/gits/fail2ban/server/filter.py", line 277, in inIgnoreIPList
ips = DNSUtils.dnsToIp(i)
File "/home/yoh/deb/gits/fail2ban/server/filter.py", line 625, in dnsToIp
return socket.gethostbyname_ex(dns)[2]
error: [Errno 11] Resource temporarily unavailable
with this commit tests would pass normally as they should
Previous code would store md5sum of an empty line as the one
identifying the monitored file. That file then was read and possibly
failures were found. Upon next "container.open()", md5 digest of now
present first line was compared against previous digest of an empty
line, which was different, thus file was assumed to be rotated and all
the log lines were read once again.
The History
-----------
In rare cases various tests failed somewhat consistently. Below you
can find one case in test_move_file where such failure really made no
sense -- we should have not had 4 failures by that point.
Fail2ban 0.8.10.dev test suite. Python 2.4.6 (#2, Sep 25 2009, 22:22:06) [GCC 4.3.4]. Please wait...
I: Skipping gamin backend testing. Got exception 'No module named gamin'
I: Skipping pyinotify backend testing. Got exception 'No module named pyinotify'
D: fn=/home/yoh/test/monitorfailures_FilterPoll9nUKoCfail2ban-0 hashes=d41d8cd98f00b204e9800998ecf8427e/d41d8cd98f00b204e9800998ecf8427e inos=5398862/5398862 pos=0 rotate=False
D: Adding a ticket for ('193.168.0.128', 1124013599.0, ['Aug 14 11:59:59 [sshd] error: PAM: Authentication failure for kevin from 193.168.0.128\n'])
D: Adding a ticket for ('193.168.0.128', 1124013599.0, ['Aug 14 11:59:59 [sshd] error: PAM: Authentication failure for kevin from 193.168.0.128\n'])
D: Closed <closed file '/home/yoh/test/monitorfailures_FilterPoll9nUKoCfail2ban-0', mode 'r' at 0x7f472b2efdc8> with pos 1231
D: fn=/home/yoh/test/monitorfailures_FilterPoll9nUKoCfail2ban-0 hashes=d41d8cd98f00b204e9800998ecf8427e/aeb4e73e6922a746d027eb365ece2149 inos=5398862/5398862 pos=1231 rotate=True
D: Adding a ticket for ('193.168.0.128', 1124013599.0, ['Aug 14 11:59:59 [sshd] error: PAM: Authentication failure for kevin from 193.168.0.128\n'])
D: Adding a ticket for ('193.168.0.128', 1124013599.0, ['Aug 14 11:59:59 [sshd] error: PAM: Authentication failure for kevin from 193.168.0.128\n'])
D: Closed <closed file '/home/yoh/test/monitorfailures_FilterPoll9nUKoCfail2ban-0', mode 'r' at 0x7f472b2ef558> with pos 1231
F
======================================================================
FAIL: test_move_file (testcases.filtertestcase.MonitorFailures<FilterPoll>(/home/yoh/test/monitorfailures_FilterPoll9nUKoCfail2ban))
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/yoh/deb/gits/fail2ban/testcases/filtertestcase.py", line 451, in test_move_file
"Queue must be empty but it is not: %s."
AssertionError: Queue must be empty but it is not: server.ticket.FailTicket: ip=193.168.0.128 time=1124013599.0 #attempts=4.
----------------------------------------------------------------------
N.B.1 I preserved here and in the code corresponding additional debug
print statements, which are commented out by default. sensible md5
digest was generated by using hexdigest() instead of current a bit
faster digest(). Running tests with all the debug output simply
breaks the race loose and failure doesn't trigger.
N.B.2 d41d8cd98f00b204e9800998ecf8427e is an md5sum of an empty
string, and aeb4e73e6922a746d027eb365ece2149 of the first line in that
file.
mtime alone is a poor measure here as many of our tests shown -- on older Pythons and some file systems
mtime might be reported only with precision up to a second. If file gets rotated fast, or there are new
modifications within the same second, fail2ban might miss them with Polling backend if judging only by
mtime. With this modification we will track also inode and size which are all indicative of a file
change.
David