Search results

Igor might have been referring to bug reports in the special sub-section of this forum (not support requests). Submitting bug reports via the forum does not require a valid support license.

For clarification, this isn't so much of a redirection issue but rather the websites are bound to the wrong IP.

Did you restart Apache?

It's by far a better practice to have your development environment match your production rather than the other way around.

And with that Frankenstein lives!

"Wonderfully Attentive Plesk?"

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.