• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Plesk 12.0.18 Update #68 and Fail2ban 0.9.3 problem

G

gbotica

Regular Pleskian
Hi,

I have 2 servers running Plesk 12.0.18 update #68, CentOS 6.7.

Since the Plesk autoupdater installed fail2ban 0.9.3 I can no longer access the main Fail2Ban "Banned IP addresses" page in Plesk. The page never loads, and eventually times-out.

I can get to the Plesk Fail2Ban settings page, and also the Jails, logs, Filters and Trusted IP's page.

If I try and click into the details overview page for a specific Jail, I get the same problem -- page never loads, eventually times-out.

I have tried restarting the Plesk server -- no difference. I've checked logs, but cannot see anything that seems related to this.

I have this exact same issue on both my Plesk 12.0.18 servers.

From the command line, Fail2Ban appears to be working fine, I can get status and all is OK, I can reload and restart Fail2Ban -- all OK. Also, iptables -L also appears to show Jails are actually working OK. So, it's just the actual Plesk pages that are broken.

I should add that I have disabled the -w option for action.d/iptables-common.conf, as per the suggestion in the Fail2Ban 0.9.3 changelog (https://github.com/fail2ban/fail2ban/blob/master/ChangeLog), since I have iptables v1.4.7, and this apparently does not support the -w option. This does not appear to affect the issue with the Plesk Fail2Ban pages not loading.

Is anyone else experiencing this? Any ideas for a fix?
 
Hi gbotica,

sometimes it is wise to switch to debug - log - level, in order to investigate possible issues in the Plesk error - logs. Please follow:

After following the suggestions, you are now able to investigate "/usr/local/psa/admin/logs/panel.log", the Plesk Control Panel - log - file and if you need help with it, please post corresponding errors, issues, failures, problems from your log.
 
Hi,
Thanks so much for your suggestion. I tried a full server reboot, and now have these logs to share...

These were generated after a server restart, when I get back to this, I'll switch on Plesk debug logging as you suggest and see if there is more information. Thanks again for your help.

From: /var/log/sw-cp-server/error_log

Code: 
2015/10/19 10:57:11 [error] 772#0: *53 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXX.XX.XXX.XX, server: , request: "GET /admin/server-protection/ban-list HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock", host: "XXXX.XXXX.XX.XX:8443", referrer: "https://XXXX.XXXX.XX.XX:8443/admin/home/admin"

From: /var/log/plesk/panel.log

Code: 
[2015-10-19 10:38:27] ERR [panel] SQLSTATE[HY000] [2002] No such file or directory:
0: Abstract.php:144
    Zend_Db_Adapter_Pdo_Abstract->_connect()
1: Mysql.php:109
    Zend_Db_Adapter_Pdo_Mysql->_connect()
2: Abstract.php:459
    Zend_Db_Adapter_Abstract->query(string 'SET sql_mode = ''', array)
3: Abstract.php:238
    Zend_Db_Adapter_Pdo_Abstract->query(string 'SET sql_mode = ''', array)
4: Mysql.php:19
    Db_Adapter_Pdo_Mysql->query(string 'SET sql_mode = ''')
5: Abstract.php:93
    CommonPanel_Application_Abstract::initDbAdapter()
6: Helper.php:150
    Plesk\Session\Helper::initStorage()
7: auth.php:308
    AutoPrepend->initUserSession()
8: auth.php:219
    AutoPrepend->run()
9: auth.php:690
[19-Oct-2015 10:38:27 Pacific/Auckland] Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory
file: /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php
line: 144
code: 2002
trace: #0 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect()
#1 /usr/local/psa/admin/externals/Zend/Db/Adapter/Abstract.php(459): Zend_Db_Adapter_Pdo_Mysql->_connect()
#2 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET sql_mode = ...', Array)
#3 /usr/local/psa/admin/plib/Db/Adapter/Pdo/Mysql.php(19): Zend_Db_Adapter_Pdo_Abstract->query('SET sql_mode = ...', Array)
#4 /usr/local/psa/admin/plib/CommonPanel/Application/Abstract.php(93): Db_Adapter_Pdo_Mysql->query('SET sql_mode = ...')
#5 /usr/local/psa/admin/plib/Session/Helper.php(150): CommonPanel_Application_Abstract::initDbAdapter()
#6 /usr/local/psa/admin/plib/auth.php(308): Plesk\Session\Helper::initStorage()
#7 /usr/local/psa/admin/plib/auth.php(219): AutoPrepend->initUserSession()
#8 /usr/local/psa/admin/plib/auth.php(690): AutoPrepend->run()
#9 {main}
--
#0 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:dbname=ps...', 'admin', '$AES-128-CBC$jm...', Array)
#1 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect()
#2 /usr/local/psa/admin/externals/Zend/Db/Adapter/Abstract.php(459): Zend_Db_Adapter_Pdo_Mysql->_connect()
#3 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET sql_mode = ...', Array)
#4 /usr/local/psa/admin/plib/Db/Adapter/Pdo/Mysql.php(19): Zend_Db_Adapter_Pdo_Abstract->query('SET sql_mode = ...', Array)
#5 /usr/local/psa/admin/plib/CommonPanel/Application/Abstract.php(93): Db_Adapter_Pdo_Mysql->query('SET sql_mode = ...')
#6 /usr/local/psa/admin/plib/Session/Helper.php(150): CommonPanel_Application_Abstract::initDbAdapter()
#7 /usr/local/psa/admin/plib/auth.php(308): Plesk\Session\Helper::initStorage()
#8 /usr/local/psa/admin/plib/auth.php(219): AutoPrepend->initUserSession()
#9 /usr/local/psa/admin/plib/auth.php(690): AutoPrepend->run()
#10 {main}

[2015-10-19 10:38:27] ERR [panel] SQLSTATE[HY000] [2002] No such file or directory:
0: Abstract.php:144
    Zend_Db_Adapter_Pdo_Abstract->_connect()
1: Mysql.php:109
    Zend_Db_Adapter_Pdo_Mysql->_connect()
2: Abstract.php:459
    Zend_Db_Adapter_Abstract->query(string 'SET sql_mode = ''', array)
3: Abstract.php:238
    Zend_Db_Adapter_Pdo_Abstract->query(string 'SET sql_mode = ''', array)
4: Mysql.php:19
    Db_Adapter_Pdo_Mysql->query(string 'SET sql_mode = ''')
5: Abstract.php:93
    CommonPanel_Application_Abstract::initDbAdapter()
6: Helper.php:150
    Plesk\Session\Helper::initStorage()
7: auth.php:308
    AutoPrepend->initUserSession()
8: auth.php:219
    AutoPrepend->run()
9: auth.php:690
[19-Oct-2015 10:38:27 Pacific/Auckland] Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory
file: /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php
line: 144
code: 2002
trace: #0 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect()
#1 /usr/local/psa/admin/externals/Zend/Db/Adapter/Abstract.php(459): Zend_Db_Adapter_Pdo_Mysql->_connect()
#2 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET sql_mode = ...', Array)
#3 /usr/local/psa/admin/plib/Db/Adapter/Pdo/Mysql.php(19): Zend_Db_Adapter_Pdo_Abstract->query('SET sql_mode = ...', Array)
#4 /usr/local/psa/admin/plib/CommonPanel/Application/Abstract.php(93): Db_Adapter_Pdo_Mysql->query('SET sql_mode = ...')
#5 /usr/local/psa/admin/plib/Session/Helper.php(150): CommonPanel_Application_Abstract::initDbAdapter()
#6 /usr/local/psa/admin/plib/auth.php(308): Plesk\Session\Helper::initStorage()
#7 /usr/local/psa/admin/plib/auth.php(219): AutoPrepend->initUserSession()
#8 /usr/local/psa/admin/plib/auth.php(690): AutoPrepend->run()
#9 {main}
--
#0 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:dbname=ps...', 'admin', '$AES-128-CBC$jm...', Array)
#1 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect()
#2 /usr/local/psa/admin/externals/Zend/Db/Adapter/Abstract.php(459): Zend_Db_Adapter_Pdo_Mysql->_connect()
#3 /usr/local/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET sql_mode = ...', Array)
#4 /usr/local/psa/admin/plib/Db/Adapter/Pdo/Mysql.php(19): Zend_Db_Adapter_Pdo_Abstract->query('SET sql_mode = ...', Array)
#5 /usr/local/psa/admin/plib/CommonPanel/Application/Abstract.php(93): Db_Adapter_Pdo_Mysql->query('SET sql_mode = ...')
#6 /usr/local/psa/admin/plib/Session/Helper.php(150): CommonPanel_Application_Abstract::initDbAdapter()
#7 /usr/local/psa/admin/plib/auth.php(308): Plesk\Session\Helper::initStorage()
#8 /usr/local/psa/admin/plib/auth.php(219): AutoPrepend->initUserSession()
#9 /usr/local/psa/admin/plib/auth.php(690): AutoPrepend->run()
#10 {main}
 
Hello,

I have enabled Plesk panel debug as suggested.

I have also followed instructions as per: http://kb.odin.com/120312

My /usr/local/psa/admin/conf/php.ini file had no entry for 'pdo_mysql.default_socket' at all, so I added it:

pdo_mysql.default_socket = /var/run/mysqld/mysqld.sock

I checked everything else as per the article and all checked out OK the path to mysql socket is: /var/run/mysqld/mysqld.sock

However, it doesn't seemed to have made any difference, on a complete server reboot the same error gets written to the panel.log file:

http://pastebin.com/xsTSQAV3

I've noticed that if I monitor the panel.log file, and try go into the Plesk Panel Fail2Ban page, lines like this start being generated every second or so:

Code: 
[2015-10-19 13:27:56] DEBUG [util_exec] [5624390c81576] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '58'
[2015-10-19 13:27:56] DEBUG [util_exec] [5624390c81576] Finished in 0.0238s, Result: TRUE

Even if I then click on some other link in the Panel, these continue to be written to the panel.log, only restarting Plesk servers stops them.

I've also noticed that if I restart fail2ban (which takes a while), during the restart I can access the Plesk Fail2Ban "Banned IP's" page. Once Fail2ban has started up again, the problem reoccurs.

I've been trying to find a away to just comptely flush out all by currently banned IPs (in case that's somehow contributing) but I can't find any method to do so, I can only unban 1 IP at a time.

I'm still at a loss as to what the issue is, it doesn't appear to be the mysql socket setting missing, as adding it to '/usr/local/psa/admin/conf/php.ini' hasn't really made any difference.

Thanks again for your assistance.
 
Hi gbotica,

Log - investigations:
the error "ERROR:f2bmng:Timeout of 10 seconds has been reached. Lock 'service.fail2ban' is already owned by another process with pid <unknown>" points to an incomplete fail2ban - installation ( or a previous Plesk upgrade might be unsuccessfully finished ). Please consider to re-install the fail2ban package.

/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --remove-component fail2ban

/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --install-component fail2ban

... or use the Plesk Control Panel, please.​


To flush all iptables at once, you would use the command: iptables -F
 
Hi again,

Thanks, yes -- I'll try a reinstall.

I know how to flush iptables, what I can't figure out is how to reset fail2ban's database, there doesn't seem to be anyway to do this.

Thanks again.
 
Hi,

Well, I'm not having much luck. Here's what I've done:
  1. removed fail2ban with plesk installer, via command line
  2. removed /etc/fail2ban/
  3. remove /var/log/fail2ban.log
  4. restarted server
  5. installed fail2ban with plesk installer, via command line
  6. I now have a completely fresh Fail2ban 0.9.3
  7. All settings, jails etc all at default as per installation, EXCEPT:
  8. Created /etc/fail2ban.local with logtarget = /var/log/fail2ban.log (it defaults to SYSLOG)
Newly created fail2ban.log has:

Code: 
2015-10-19 23:35:28,285 fail2ban.server [3924]: INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.3
2015-10-19 23:35:28,287 fail2ban.database [3924]: INFO Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'

Even before I actually start fail2ban via the Plesk Panel, the panel.log starts getting these entries again, every few seconds:

Code: 
[2015-10-19 23:46:58] DEBUG [util_exec] [5624ca2200d57] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '97'
[2015-10-19 23:46:58] DEBUG [util_exec] [5624ca2200d57] Finished in 0.01614s, Result: TRUE
[2015-10-19 23:47:02] DEBUG [util_exec] [5624ca26f0726] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '85'
[2015-10-19 23:47:03] DEBUG [util_exec] [5624ca26f0726] Finished in 0.01908s, Result: TRUE
[2015-10-19 23:47:08] DEBUG [util_exec] [5624ca2c0b24c] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '88'
[2015-10-19 23:47:08] DEBUG [util_exec] [5624ca2c0b24c] Finished in 0.0153s, Result: TRUE
[2015-10-19 23:47:13] DEBUG [util_exec] [5624ca310cd8e] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '14'
[2015-10-19 23:47:13] DEBUG [util_exec] [5624ca310cd8e] Finished in 0.01421s, Result: TRUE
[2015-10-19 23:47:18] DEBUG [util_exec] [5624ca36065b9] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '41'
[2015-10-19 23:47:18] DEBUG [util_exec] [5624ca36065b9] Finished in 0.01501s, Result: TRUE
[2015-10-19 23:47:23] DEBUG [util_exec] [5624ca3b0adfc] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '26'
[2015-10-19 23:47:23] DEBUG [util_exec] [5624ca3b0adfc] Finished in 0.01342s, Result: TRUE
[2015-10-19 23:47:28] DEBUG [util_exec] [5624ca401a90d] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '30'
[2015-10-19 23:47:28] DEBUG [util_exec] [5624ca401a90d] Finished in 0.01547s, Result: TRUE
[2015-10-19 23:47:33] DEBUG [util_exec] [5624ca450b574] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '65'
[2015-10-19 23:47:33] DEBUG [util_exec] [5624ca450b574] Finished in 0.01495s, Result: TRUE
[2015-10-19 23:47:38] DEBUG [util_exec] [5624ca4a106bd] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '49'
[2015-10-19 23:47:38] DEBUG [util_exec] [5624ca4a106bd] Finished in 0.01353s, Result: TRUE
[2015-10-19 23:47:43] DEBUG [util_exec] [5624ca4f100e2] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '59'
[2015-10-19 23:47:43] DEBUG [util_exec] [5624ca4f100e2] Finished in 0.0157s, Result: TRUE
[2015-10-19 23:47:48] DEBUG [util_exec] [5624ca5409d6c] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '70'
[2015-10-19 23:47:48] DEBUG [util_exec] [5624ca5409d6c] Finished in 0.01516s, Result: TRUE

Prior to starting Fail2ban, I can access the Banned IP Addresses page OK, as soon as I start it, the page breaks, as per earlier -- just times-out.

Also, once it's started I can't stop Fail2Ban via the Plesk Panel. If I uncheck it and click save, the page never reloads -- just hangs.

So, I have to stop fail2ban with /etc/init.d/fail2ban stop, then restart Plesk. Only then do the above lines stop be generated in panel.log.

If I start Fail2ban again, the lines start writing to panel.log again:

Code: 
[2015-10-19 23:56:05] DEBUG [util_exec] [5624cc4522942] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '92'
[2015-10-19 23:56:05] DEBUG [util_exec] [5624cc4522942] Finished in 0.01113s, Result: TRUE
[2015-10-19 23:56:10] DEBUG [util_exec] [5624cc4a1e7ec] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '37'
[2015-10-19 23:56:10] DEBUG [util_exec] [5624cc4a1e7ec] Finished in 0.0104s, Result: TRUE
[2015-10-19 23:56:15] DEBUG [util_exec] [5624cc4f1cc54] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '73'
[2015-10-19 23:56:15] DEBUG [util_exec] [5624cc4f1cc54] Finished in 0.01093s, Result: TRUE
[2015-10-19 23:56:20] DEBUG [util_exec] [5624cc5424824] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '38'
[2015-10-19 23:56:20] DEBUG [util_exec] [5624cc5424824] Finished in 0.01019s, Result: TRUE

Actually, now it appears that those lines are writing to panel.log, even when fail2ban is stopped...

Code: 
[2015-10-20 00:04:05] ERR [panel] pm_Exception: Module context is not defined.
file: /usr/local/psa/admin/plib/pm/Context.php
line: 61
code: 0
trace: #0 /usr/local/psa/admin/plib/pm/Context.php(139): pm_Context::_checkInitialization()
#1 /usr/local/psa/admin/plib/pm/Settings.php(20): pm_Context::getModuleInfo()
#2 /usr/local/psa/admin/plib/modules/heavy-metal-skin/library/EventListener.php(14): pm_Settings::get('skin')
#3 [internal function]: Modules_HeavyMetalSkin_EventListener->handleEvent('cp_user', 0, 'cp_user_login', Array, Array)
#4 /usr/local/psa/admin/plib/interfaces/InterfacesManager.php(137): call_user_func_array(Array, Array)
#5 /usr/local/psa/admin/plib/ActionLog.php(609): InterfacesManager::callImpls('EventListener', 'handleEvent', Array)
#6 /usr/local/psa/admin/plib/ActionLog.php(364): ActionLog->_callEventListeners()
#7 /usr/local/psa/admin/plib/Application/Web.php(294): ActionLog->submit()
#8 /usr/local/psa/admin/htdocs/login_up.php3(67): Plesk\Application_Web->registerSession('admin', 'LWJtn4RgZZ3e_qR...')
#9 {main}

[2015-10-20 00:04:06] DEBUG [util_exec] [5624ce2654208] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '82'
[2015-10-20 00:04:06] DEBUG [util_exec] [5624ce2654208] Finished in 0.01052s, Result: TRUE
[2015-10-20 00:04:06] DEBUG [util_exec] [5624ce26c958e] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '71'
[2015-10-20 00:04:06] DEBUG [util_exec] [5624ce26c958e] Finished in 0.01091s, Result: TRUE
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce2704166] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '10'
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce2704166] Finished in 0.01114s, Result: TRUE
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce2761b6d] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '26'
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce2761b6d] Finished in 0.01036s, Result: TRUE
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce27a0d7b] Starting: filwrpr /usr/local/psa/admin/bin/filwrpr '18'
[2015-10-20 00:04:07] DEBUG [util_exec] [5624ce27a0d7b] Finished in 0.01032s, Result: TRUE


I just uninstalled the Skins and Color Schemes extension as I see that mentioned in the log above, but still no luck, now nothing I do stops the panel.log getting those filwrpr lines.

So, no I'm really stuck ... no idea what to try next.
 
On further investigation it appears that the Starting: filwrpr ... lines start writing to panel.log as soon as I log into the panel, if I log out they stop. Fail2Ban server isn't even running now.
 
Hi gbotica,

please wait for an answer of an Odin team member and their possible suggestions, because I can't reporoduce your issue.
 
OK, thanks very much for your help so far.

Odin Support: can you help? I have 2 Plesk 12.0.18 CentOS 6.7 servers with this same issue?
 
Last edited:
Hi gbotica,

roadrash said:
CentOS 6 will not go beyond version IPtables 1.4.7
Whereas F2B v0.9.3 uses functions that are only available from at least IPtables 1.4.20
I had the same errors as you see (the -w switch thing)

I first tried downgrading with yum. Wouldn't work unfortunately.

Best way to go (worked for ALL of our Centos 6 servers):

- stop fail2ban (service fail2ban stop), or disable the service through Plesk Panel
- backup your own custom f2b rules
- remove fail2ban: yum remove fail2ban (or: use the Plesk autoinstaller through Plesk Panel to remove the f2b addon)
- verify that all of the f2b things are gone.
- VERY important: make sure that you exclude fail2ban from all of your yum repos (in: /etc/yum.repos.d/ ).
- test it: yum install fail2ban (it should tell you that fail2ban cannot be found. That is OK! )
- Then login into the Plesk installer again and add the fail2ban again.

After that you can check that the Plesk-repo was used by following command:

yum info fail2ban
Output should contain following line: From repo: PLESK_12_5_30-dist
(if you are on Plesk 12.5)

Hope this helps you too.
Click to expand...

... please report back, if the suggestions work for you.
 
I will try the uninstall and reinstall f2b 0.9.2 from Plesk repo today. Though, as mentioned on the other thread (http://talk.plesk.com/threads/fail2ban-problems-in-plesk-12-0-18-update-68.335009/#post-788590) f2b 0.9.3 itself is working fine on CentOS 6.7 / iptables 1.4.7 (the f2b changelog says that with the -w option disabled 0.9.3 and iptables 1.4.7 should be fine), it seems that the Plesk Panel just isn't compatible. Presumably Odin will release an update at some stage to support 0.9.3?
 
I have the same problem on a few dozen servers. plesk 12.0.18, centos 6.7
Its definitly the way plesk tries to read the banned -ip list, but more. There are not enough arguments to enter new ips to iptables.

Does someone have the 0.9.2 rpm or source rpm or know where to download it?


- if no ip is banned: al works file
- as soon as even only 1 ip as banned, it stops working, plesk cant get the list of banned ip adresses. the banned page keeps loading and loading.

This is the debug log: no anwser, no error, nothing

[2015-10-23 10:02:11] DEBUG [util_exec] [323c422899606e4cd17e3c5782b3e7a7][0] Starting: f2bmng --status, stdin:
[2015-10-23 10:02:11] DEBUG [util_exec] [323c422899606e4cd17e3c5782b3e7a7][0] Finished in 0.16151s, Error code: 0, stdout: is running
, stderr:
[2015-10-23 10:02:11] DEBUG [util_exec] [43e9b39df81686afc8376ebd8b75ae5e][0] Starting: f2bmng --get-options, stdin:
[2015-10-23 10:02:11] DEBUG [util_exec] [43e9b39df81686afc8376ebd8b75ae5e][0] Finished in 0.08888s, Error code: 0, stdout: {"usedns": "warn", "maxretry": "5", "ignoreip": "127.0.0.1/8 10.0.0.0/8", "bantime": "1800", "ignorecommand": "", "destemail": "[email protected]", "findtime": "600", "backend": "auto"}, stderr:
[2015-10-23 10:02:11] DEBUG [util_exec] [f7fb77c27cc2c1ab487a22d92505333a][0] Starting: f2bmng --get-banned-ips, stdin:

I left nothing out, after 5 minutes loading, this was the end of the log file.

fail2ban new -w option works with centos 6.7 / iptables 1.4.7 but isnt properly configured by plesk. My /var/log/messages says

Oct 23 10:03:34 res2 fail2ban.action[14146]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-plesk-proftpd[ \t]' -- stdout: ''
Oct 23 10:03:34 res2 fail2ban.action[14146]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-plesk-proftpd[ \t]' -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"
Oct 23 10:03:34 res2 fail2ban.action[14146]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-plesk-proftpd[ \t]' -- returned 1

The log is full of it

Oct 23 10:03:28 res2 fail2ban.action[14146]: ERROR iptables -w -D INPUT -p tcp -m multiport --dports 25,smtps,submission -j f2b-plesk-qmail#012iptables -w -F f2b-plesk-qmail#012iptables -w -X f2b-plesk-qmail -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"

Oct 23 10:03:29 res2 fail2ban.action[14146]: ERROR iptables -w -D INPUT -p tcp --dport 22222 -j f2b-SSH#012iptables -w -F f2b-SSH#012iptables -w -X f2b-SSH -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"

I did try unsinstall/re-install fail2ban to have a clean installation and configuration but that didnt help either.



regards
Jan
 
Hi Linulex,

Linulex said:
Does someone have the 0.9.2 rpm or source rpm or know where to download it?
Click to expand...
please use for example:


For Plesk 12.0.18 and CentOS 6.7 ( please use the official Fail2Ban - version 0.9.2 from the official Fail2Ban - github, if you don't want to use the Plesk - version 0.8.13 from http://autoinstall.plesk.com/PSA_12.../fail2ban/fail2ban-0.8.13-14052018.noarch.rpm ):

mkdir -p /root/addons/plesk/fail2ban
cd /root/addons/plesk/fail2ban
wget https://github.com/fail2ban/fail2ban/archive/0.9.2.tar.gz
tar -zxvf 0.9.2.tar.gz
cd fail2ban-0.9.2
python setup.py install

To be able to use the Plesk pre-configured jails and configuration files, you may use the Fail2Ban - files from Plesk 12.5.30 ( you will need to install "rpm2cpio" to do that ! ):

mkdir -p /root/addons/plesk/fail2ban/plesk_12.5.30
cd /root/addons/plesk/fail2ban/plesk_12.5.30
wget http://autoinstall.plesk.com/PSA_12...or-12.5.30-cos6.build1205150901.17.noarch.rpm
rpm2cpio plesk-fail2ban-configurator-12.5.30-cos6.build1205150901.17.noarch.rpm | cpio -i --make-directories

You can now copy the files from "/root/addons/plesk/fail2ban/plesk_12.5.30/etc/fail2ban" to "/etc/fail2ban":

cp -avr /root/addons/plesk/fail2ban/plesk_12.5.30/etc/fail2ban /etc/fail2ban

​
If you experience issues as described:
Linulex said:
Oct 23 10:03:28 res2 fail2ban.action[14146]: ERROR iptables -w -D INPUT -p tcp -m multiport --dports 25,smtps,submission -j f2b-plesk-qmail#012iptables -w -F f2b-plesk-qmail#012iptables -w -X f2b-plesk-qmail -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"

Oct 23 10:03:29 res2 fail2ban.action[14146]: ERROR iptables -w -D INPUT -p tcp --dport 22222 -j f2b-SSH#012iptables -w -F f2b-SSH#012iptables -w -X f2b-SSH -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"
Click to expand...
Please try to use the recommendation from https://github.com/fail2ban/fail2ban/issues/1122 / https://bugzilla.redhat.com/show_bug.cgi?id=1272681

Original /etc/fail2ban/action.d/iptables-common.conf
...
# Option: lockingopt
# Notes.: Option was introduced to iptables to prevent multiple instances from
# running concurrently and causing irratic behavior. -w was introduced
# in iptables 1.4.20, so might be absent on older systems
# See https://github.com/fail2ban/fail2ban/issues/1122
# Values: STRING
lockingopt = -w
...
Click to expand...

Change to:
...
# Option: lockingopt
# Notes.: Option was introduced to iptables to prevent multiple instances from
# running concurrently and causing irratic behavior. -w was introduced
# in iptables 1.4.20, so might be absent on older systems
# See https://github.com/fail2ban/fail2ban/issues/1122
# Values: STRING
lockingopt =
...
Click to expand...

If you experience any issues, please report back what you did and please add again possible errors from your logs.
 
Hi UFHH01

thanx for the reply, i fixed it in a much easier way. I was going to post it after i fixed all my servers

i "borrowed" the fail2ban.spec from 0.9.3.src.rpm and (re)build a 0.9.2 rpm. I attached it for whoever needs it.

i replaced /etc/fail2ban from a backup, restart fail2ban and ready

and added fail2ban* to epel repo ignore list.

About the -w option: i tried disabling it, the error went a way then but the list off banned ip list stil didnt open.
As i see it: its not my job to "fix" the fail2ban config by disabling stuff that works on the OS/iptables version that i use. Its plesk's job to provide the correct arguments.

I zipped the rpm and attached it, hope it get uploaded.

regards
Jan
 

Attachments

  • fail2ban-0.9.2-1.el6.noarch.zip
    358.3 KB · Views: 8
I have this same problem...
. Plesk v12.0.18_build1200140606.15 os_CentOS 6.6 (Final)
. fail2ban 0.9.3-1.el6

What did you break, and is there an eta for it to be fixed without having to do the hacks above?
 
Tantrumedia said:
without having to do the hacks above?
Click to expand...

Going back to a previous working version is not a hack but a standard practice if the new release is incompatible with existing software. specialy when the new version isn't a security update to plug a mayor hole. fail2ban 0.9.3 is a bugfix and new functionality release, not a security release so there is no harm in downgrading.

I hope your "os_CentOS 6.6" is a typo. current version is os_CentOS 6.7

regards
Jan
 
Hi Jan,

AFAIK fail2ban was working fine...
It was the recent update to Plesk that caused the problem?
Unless I've got things the wrong way around in my head of course...

As for running CentOS 6.6 rather than CentOS 6.7 as you said yourself,
"...is a bugfix and new functionality release, not a security release so there is no harm in downgrading." ;o)

I guess I'll have to put some time aside to do the fail2ban downgrade.
What will the situation be if the next fail2ban update happens to be a security one?

Cheers,
Tim.
 
You must log in or register to reply here.

Similar threads

P
Input plesk fail2ban missing some important filter rules
Replies
2
Views
582
PeterKi
P
PeopleInside
Resolved Unable to configure fail2ban for snappymail on Plesk
Replies
11
Views
2K
PeopleInside
PeopleInside
Z
Resolved How to recognize fail2ban filter
Replies
6
Views
1K
Zoo3
Z
claxman
Issue Anacron job 'cron.daily' on server.domain (Fail2Ban Automatic Closing Problem)
Replies
17
Views
2K
Hiljo_Lodewijk
H
M
Resolved transvhosts.pl fails to update apache default DocumentRoot
Replies
16
Views
2K
Peter Debik
P
Back
Top