#1 permits use with daemontools style logs


The following patch makes fail2ban able to parse the timestamp in TAI64N format (which is used with daemontools logs). The required configuration options that must be used in the appropriate place in the fail2ban.conf file are the following two:

timeregex = @[0-9a-f]{24}
timepattern = tai64n

(BEGIN PATCH -- based on fail2ban v0.5.2)

--- logreader.py.old 2005-08-28 15:02:58.000000000 -0500
+++ logreader.py 2005-08-28 15:32:10.000000000 -0500
@@ -189,7 +189,12 @@
Pattern should describe the date construction of
- date = list(time.strptime(value, self.timepattern))
+ seconds_since_epoch = 0
+ if self.timepattern.lower() <> "tai64n":
+ date = list(time.strptime(value, self.timepattern))
+ else: # if the parsed value is in TAI64N format
+ seconds_since_epoch = value[9:17] # chop out part of format which represents seconds since epoch
+ date = list(time.gmtime(int(seconds_since_epoch,16)))
if date[0] < 2000:
# There is probably no year field in the logs
date[0] = time.gmtime()[0]


  • Mark Edgington

    Mark Edgington - 2005-08-28

    Logged In: YES

    I guess an uploaded patchfile is better since the formatting of the description field by sourceforge leaves a little something to be desired...

  • Mark Edgington

    Mark Edgington - 2005-08-29

    logreader.py diff file -- updated 2005.08.29

  • Cyril Jaquier

    Cyril Jaquier - 2005-09-05
    • status: open --> open-accepted
  • Cyril Jaquier

    Cyril Jaquier - 2005-09-05

    Logged In: YES

    Will be added in next release. Just one question:

    Attached patch says seconds_since_epoch = value[2:17] but
    copied/pasted one says seconds_since_epoch = value[9:17].
    Which one is correct?

    Thank you

  • Mark Edgington

    Mark Edgington - 2005-09-05

    Logged In: YES

    The attachment is better to use. Both will work, but the non-
    attachment version is only good for the next 50 or so years,
    and since we know that fail2ban will be used for the next
    5000 years, it makes much more sense to use the version in
    the attachment.

    Actually though, it seems right now that python itself
    (time.gmtime()) is not able to handle any values larger than
    0x7FFFFFFF, which corresponds to the year 2038.

  • Cyril Jaquier

    Cyril Jaquier - 2006-01-03
    • status: open-accepted --> closed-fixed
  • Cyril Jaquier

    Cyril Jaquier - 2006-01-03

    Logged In: YES

    Added in CVS HEAD. Will be in 0.6.1


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks