Search results

Could you please provide a log excerpt of the 403 error where it states the rule ID? Please also show which IDs were excluded.

As the error indicates a JavaScript issue, it might be caused by cached data. Clearing the browser cache could be enough to solve it.

Does the subscription have permissions to manage mail accounts?

@ksa616 The website can continue to work, but there won't be updates to PHP, Apache, Nginx etc. Mail can continue to work, but if something doesn't, you'll be on your own on the operating system level. No statistics either. SSL will continue to work until a renewal is up. Backup: No it will not...

Your last option will be official Plesk support. They will for sure be able to solve this issue for you. To sign-in to support please go to https://support.plesk.com If you bought your license from a reseller, your reseller should provide support for you. If the reseller does not provide...

Yes it works. However, I am sure that the plesk.conf file on my installation where it failed was an authentic file that was not previously modified by us here, yet it seems that it was not updated automatically upon Plesk upgrade to 18.0.63.

Great, thank you!

This console command will help to give you a live insight where the load in your server happens: MYSQL_PWD=`cat /etc/psa/.psa.shadow` watch "uptime && echo "\ " && ps aux | sort -nrk 3,3 | head -n 20 && echo "\ " && mysqladmin proc status -u admin"

According to another post, the "recidive" jail has been replaced by two new jails "plesk-one-week-ban.conf" and "plesk-permanent-ban.conf". We're using custom software and definitions that partly rely on the "recidive" chain and .conf. I'd like to know more what the two new confs do, whether...

Technically, you can exclude Cloudflare IPs from Fail2Ban in the /etc/fail2ban/jail.local file. To exclude them, simply add them to the [DEFAULT] section's ignoreip directive. Example: [DEFAULT] ignoreip = 34.147.110.144/28 ... and so on ... 127.0.0.1/8 ::1 The subnets that Cloudflare uses...

Has the case Question - Problems on Roundcube v1.67 after upgrade been checked and can you confirm that there are no issues on the Plesk side with an upgrade to 18.0.63 in combination with a Roundcube update?

After reading the above post we have disabled Plesk auto-updates on our servers ... I suggest submitting the case as a ticket to Plesk support so that they can check whether it is a general issue with Roundcube. There is a Roundcube security update in the pipeline, and it would not be good if a...

Good to know. Indeed, Almalinux measures and displays the CPU load differently from CentOS. The same load on Alma 8 for the "last minute" drives the number up by factors compared to what CentOS measures or displays. This can have an extreme impact on tools that monitor server performance or...

"allowhardlink" is an important setting. Plesk, please do not remove it. @enerspace It will be worth asking official Plesk support on this as this seems to be a case where a check directly on your server is required.

.user.ini should not be a requirement by Wordfence. If specific webspace configurations are required, these can also be set in the panel's GUI.

The problem can be that path traversal is done by a malicious PHP script, and the directory where the cron files are stored can be reached. New cron files can be written to it. These will then show up as new cron jobs in the scheduler. The newer the PHP version, the less danger there is. In PHP...

A true dealbreaker, isn't it? We've some surveillance on our servers here that I'm willing to share. Simply create a cronjob that auto-checks whether users use legitimate values and let that job run every few minutes, e.g. /usr/bin/grep "php_value\[memory_limit\] = "...

Probably permissions of the path are wrong. The document root of a website should be owned by <username of subscription>:psaserv and have permissions 0750. The files and directories in the document root directory should be owned by <username of subscription>:psacln. The directories located in...

Would it not be a better approach to examine what the website scripts are doing and specifically where they spend most of the execution time instead of increasing server resources?

What is meant by "going down"? Is there a lot of activity in the Apache logs between midnight an 4 am? Why is PHP-FPM suspected as a root cause?