fail2ban ignores action.d config after server reboot

[thomaszbz]

I have applied the changes of #1006 on my server and set

#_whois_command = %(_whois)s
_whois_command = %(_whois_convert_charset)s

in the mail-whois-common.conf (or mail-whois-common.local alternatively).

That worked fine until I performed a server reboot.

How to reproduce

• Apply changes from ENH: Character detection heuristics for whois output via optional setting in mail-whois*.conf (Closes #1003) #1006 and use _whois_convert_charset
• reboot server
• let fail2ban ban some ip which contains non-ascii/non-utf-8 characters, like 179.111.212.221

Result: I get an attachment in the email again, which should be avoided via #1006 config

Then comes the strange part:

• restart fail2ban with service fail2ban restart
• let fail2ban ban the same ip again

Result: All is fine and I get a perfectly formatted email without attachment. This can only happen with the changes from #1006

As far as I can see, fail2ban ignores my config after a reboot, but it respects my config after restarting the fail2ban service.

Suggestion: There should not be a difference between reboot and restart of the service.

Please note that my fail2ban version is rather old: v0.8.6 which comes from debian wheezy.

The problem seems to be reproducable. I tried several times.

I also found out that performing a

service fail2ban stop && service fail2ban start

seems to be equivalent to

service fail2ban restart

in terms of this issue.

[thomaszbz]

Just to be sure: Without #1006, I get the attachment even after performing a

service fail2ban restart

which basically means that just restarting the fail2ban service does not solve the problems of #1003.

[thomaszbz]

Using debian start scripts, I can see that fail2ban should be the last service which is started on my system (S99)

#ls -lh /etc/rc3.d/*fail2ban
lrwxrwxrwx 1 root root 18 Dec 12 01:55 /etc/rc3.d/S99fail2ban -> ../init.d/fail2ban
#ls -lh /etc/rc5.d/*fail2ban
lrwxrwxrwx 1 root root 18 Dec 12 01:55 /etc/rc5.d/S99fail2ban -> ../init.d/fail2ban

For instance, I can't find a reason why fail2ban's behaviour is different after a server reboot.

[sebres]

Since 0.9.1 the loading of config files are totally revised, so I can no more track all changes since very old v0.8.6, what affects this problem.
Can you test a new master (debian) branch or at least sid (or experemental) from https://packages.debian.org/sid/fail2ban?

[thomaszbz]

As far as I can see debian jessie will be released with fail2ban 0.8.13, which would already be too old then. I could wait another 3 years until 0.9.1 hopefully makes it into debian stable.

[sebres]

We have no influence on debian maintainer, but you have an alternative to install a newer version of this package from another maintainers or even directly a master from github.

Just backup your configs in /etc/fail2ban, uninstall previous and install new version, profit...
There is also a version for debian (possibly a little bit out of date).

[thomaszbz]

A trustworthy upstream debian repository for debian stable and oldstable would be nice for that. I pretty much love the way PostgreSQL is rolling out their releases ages before distro maintainers do.

I see what I can do. However, setting up a test system just for that seems a bit of overhead to me. I don't want to run some setup program which potentially copies files somewhere, where I can't find them again for a clean uninstall (which a .deb would provide).

Can I somehow build a deb for wheezy from the git repository?

[yarikoptic]

I upload backports of fresh releases also to NeuroDebian, so check there - should be as trustworthy as upstream or stock Debian :-)

On April 7, 2015 9:30:15 AM EDT, Thomas Mayer notifications@github.com wrote:

A trustworthy upstream debian repository for debian wheezy and jessie
would be nice for that. I pretty much love the way PostgreSQL is
rolling out their releases ages before maintainers do.

I see what I can do. However, setting up a test system just for that
seems a bit of overhead to me. I don't want to run some setup program
which potentially copies files somewhere, where I can't find them again
for a clean uninstall (which a .deb would provide).

---

Reply to this email directly or view it on GitHub:
#1011 (comment)

Sent from a phone which beats iPhone.

[yarikoptic]

Re @sebres 's "We have no influence on debian maintainer" -- well -- we do, since it is the same yours truly me ;) But we might have limited to no influence over non-critical bugs in stable releases in stock debian repositories. It feels that the issue is of that kind, and in general should have been reported to the Debian maintainer (i.e. me) via reportbug in Debian. Since I think issue is not related to current recent releases which are also in debian stretch/sid, I am closing this issue. Feel welcome to follow up and possibly reopen if you think that there is something we could fix on our end at this point.