Search results

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.

This behavior may be attributed to a daily operated system union-mandated break ;) The 403 errors are likely false positives. Do you have any backup processes scheduled for that time? Another other possibility here might be with log rotation - have you checked the server-level error logs to...

Or if you're impatient: Log into Plesk as admin. Go to Tools & Settings > Services Management. Click Restart the service icon next to Web Server (Apache) Then refresh your browser to see if your document root update is properly updated.

That implies that @Pleskie will have to migrate by CentOS 8 EOL whereas @Pleskie might buy more time to see how the OS battle shakes out with either CentOS 7 or Ubuntu.

If you absolutely had to make a decision in the very short term, you might want to stick for CentOS 7 for the moment since it effectively has a longer runway than CentOS 8 (this puts you into the Rocky Linux path). CentOS 8 would force your hand within a year so CentOS 7 (or if you really had...

Did you post on the thread at Reports

Very apropos, especially for such an abstract issue!