Search results

This isn't a Plesk issue - You're barking up the wrong tree. This is the one that you want: fail2ban/fail2ban

Good to hear - I'm a happy camper if I'm supported until my own EOL :)

hmmm... Everyone raised their hands at once on this one - A bit obscure but have you read into this?

Checkout the HTTP server status module (be sure to restrict it to your IP) but if you're looking just to get a general idea of what's going on: See the top cpu load processes as they happen! # watch "ps aux | sort -nrk 3,3 | head -n 20" Find the process that the ID is attached to: # ls -la...

So your objective is manually setup a domain inside the vhosts structure manually? I'm not sure if this is really a Plesk question as you can do this via SSH just as you would without Plesk and I'm also not entirely sure about the long-term implications.

Instead of using the repair service, have you tried running this command? # find /var/www/vhosts/domaingeneratingtheerror.com/logs/ -type f -a -not -perm 644 -exec chmod 644 {} \;

This sounds awfully like a KB that I saw. Have you given that a look? # sed -i 's/ScoreboardFile.*/ScoreboardFile \/var\/run\/proftpd.scoreboard/' /etc/proftpd.conf

As a workaround for the moment, does the "Exclude log files" option still cause these files to throw the permission issue in the backup log?

SQL injection prevention should take place at the application layer; htaccess and nginix were never intended as effective defenses against injection attacks.

You might have an exposed endpoint or a script (such as the WordPress XML RPC file which is very popular with automated nefarious sniffing tools) that may be getting hit so regardless of handler, this behavior might occur over and over again. When the behavior occurs, check to see what files are...

From the little information provided, it's not looking like a Plesk issue. Have you tried disabling your firewalld daemon and then running that command? If that yields the same result, you may have an upstream port block.

Not a system cron utility but a software/CMS-initiated "poor man's" cron (i.e. a regularly scheduled WordPress task initiated by the CMS itself).

You mean as a domain alias? Or do you mean outside of Plesk's structure entirely?

It truly still remains to be seen how the mass-market data centers will handle it. They're ultimately the ones that have the power to shift adoption decisions for the small to medium shops.

If it's that regular, try first to check for a pattern - When the activity occurs, run this command several times to identify the top external connections with open connections: netstat -nt | awk '/^tcp/ {print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -n Are you certainly that...

Plesk is pretty generous about the additional PHP handler that you can install and goes back to PHP 5.3; have you tried installing it first via the Plesk add components feature so that you can make it available to a plan, subscription, or website?

If your data center environment allows for IP re-assignment and you'd prefer to take a slightly "safer" route, you can migrate to a new server (using its new IP), test a site on the new server by pointing to the "new IP", and then swap the IPs so that there isn't a DNS implication for website...

This sounds very similar to a KB that was updated a couple of months ago: Mail delivery does not work: do not list domain in BOTH mydestination and virtual_mailbox_domains Luckily the fix is pretty quick so please post back with your results!

To help others who might find themselves in the same situation, it would be helpful to provide the resolution!

If I recall correctly there was a thread similar to this a few years back as well but it's somewhat old so it may not be relevant to your setup.