Resolved Reloading iptables on reboot in Plesk 17.0.17

[Mike2017]

Hello,
I recently migrated my VPS from Plesk 12 to Plesk Onyx (I am now running Plesk Onyx v17.0.17 update #21 on Ubuntu 14.04.5 LTS). I have a number of custom rules in iptables and, previously, I just had iptables-persistent installed - it was auto loading on reboot iptables stored in /etc/iptables/rules.v4 and /etc/iptables/rules.v6 files. Unfortunately, this doesn't seem to work any longer in Plesk Onyx: I installed iptables-persistent without problems but when I run iptables-save > /etc/iptables/rules.v4, I get the error message "-bash: /etc/iptables/rules.v4: No such file or directory".

As I have a shell script to update iptables (to block bad bots and some ip ranges), I decided not to waste my time and just added the shell script to crontab. Something like:
@reboot /var/www/vhosts/xyz.com/drop-bots.sh
This didn't work either even though I tried all possible variations of this:
@reboot bash /var/www/vhosts/xyz.com/drop-bots.sh
@reboot bash /home/var/www/vhosts/xyz.com/drop-bots.sh
...

Finally, I tried just to add the shell script to /etc/init.d/ and, obviously, I didn't forget to change permissions with chmod +x /etc/init.d/drop-bots.sh
Same result, iptables don't get updated after reboot...

Now, I'm totally puzzled as neither of these 3 solutions worked in Plesk 17
Needless to say, "bash /var/www/vhosts/xyz.com/drop-bots.sh" works fine from the command line and updates the iptables just as intended... Any thoughts/suggestions?

 

[UFHH01]

Hi Mike2017,

Finally, I tried just to add the shell script to /etc/init.d/ and, obviously, I didn't forget to change permissions with chmod +x /etc/init.d/drop-bots.sh
Same result, iptables don't get updated after reboot...

Did you probably forgot the command:

update-rc.d drop-bots.sh defaults

... and does your *.sh - script starts with:

#!/bin/bash

COMMANDS TO BE EXECUTED

 

[Mike2017]

Thanks for the quick response, @UFHH01. You were right, I forgot "update-rc.d drop-bots.sh defaults", and it made the script run... on the first reboot but not subsequent reboots. Also, unfortunately, even on the first reboot when it worked, my script was executed on startup before fail2ban, so directives from fail2ban jails were added to iptables above "drop bots" -related lines, as a result blocking didn't work. I assume there is not much I can do here...?

 

[UFHH01]

Hi Mike2017,

hm... normally Fail2Ban doesn't interfere, as it set bans into own jails. Could you pls. explain in detail, where you see some conflicts? Maybe we could help as well with your own script if you provide it?

 

[Mike2017]

Hi @UFHH01 ,
Actually, it only worked once, upon the first reboot. After I followed your suggestion and used "update-rc.d drop-bots.sh defaults" command, my script was executed at startup and required lines were added to iptables (though, after fail2ban lines). After rebooted again I didn't see anything added there. So I decided to start it clean and:
1. Run sudo update-rc.d -f drop-bots.sh remove
2. Removed the drop-bots.sh file from /etc/init.d/
3. Copied the drop-bots.sh file to /etc/init.d/ again
4. Run chmod +x /etc/init.d/drop-bots.sh
5. Run sudo update-rc.d drop-bots.sh defaults
6. Run reboot

To my surprise, nothing was added to iptables this time, so it looks like my script drop-bots.sh didn't run on startup.
Now, I am totally confused

Mike

 

[UFHH01]

Hi Mike2017,

To my surprise, nothing was added to iptables this time, so it looks like my script drop-bots.sh didn't run on startup.
Now, I am totally confused

To investigate issues/errors/problems when you reboot your server, pls. start with investigating your depending logs ( i.e.: "/var/log/messages" or/and "kern.log" on Debian/Ubuntu - based systems ). Pls. note, that your current issue/error/problem is not related to any Plesk product and component and a discussion on that behalf should be done at: => Home > Forum > General Discussion > Open Topics

 

[Mike2017]

The problem has been now resolved and I was able to use iptables-persistent for the purpose of reloading custom iptables (same as I used it with Plesk 12). Unfortunately, I cannot point out what had solved the problem (it's either a recent patch or something that I did to the server) but after I uninstalled and reinstalled iptables-persistent today the problem was gone. Thanks to @UFHH01 for taking time to respond to my question.