Issue Issue with WP / WP Toolkit: wp-config.php suddenly empty without other suspicious activities

[B_P]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

18.0.70 Update 1 Web Pro Edition

Hi all,

Today I figured out that one of the subscriptions on my server has an error, namely that WP is not working correctly any more.
WP toolkit reports that the page is damaged and provides the additional hints (translated from German to English):

WP Toolkit has found WP files under the following path: /var/www/vhosts/<customername>/<docroot>

This WP page does not seem to work. Try to restore the page from a backup or remove redundant files.

Additional details: "Error: Strange wp-config.php file: wp-settings.php is not loaded directly."

When looking into the folder, the file wp-config.php is completely empty.

 

[Sebahat.hadzhi]

Hello, @B_P . The website might be compromised. If you have a backup copy, I would suggest trying to restore one. If not, what I can suggest is coping the content of the wp-config-sample.php into wp-config.php and updating the database connection details according to domains > examle.com > Databases > Connection info.

 

[jopple]

Thanks for the info, Sebahat. I’m seeing the same issue on one of my subscriptions, too. wp-config.php is suddenly blank, and no other obvious signs of compromise. I’ll try the workaround with wp-config-sample.php for now and see if it helps get things running again. Curious if anyone figured out what might have caused this in the first place? It would be good to prevent it from going forward.

 

[Sebahat.hadzhi]

I would recommend you to review the access logs of the website in order to determine if there were any abnormal activities. Also, performing a full scan of the affected websites is not a bad idea. And the essentials, such as ensuring WP core, themes, and plugins are all up to date, resetting your WordPress admin passwords.

 

[B_P]

@Sebahat.hadzhi today, it happened again on 3 sites. Interestingly, the weekly full Plesk backup was running at the same time (and longer than expected).
Looking at the details, the backup process was set to only start if at least 50 GB of free space are given and backups are set to be split into files of 3 GB. Nevertheless, I saw messages in /var/log/syslog that disk ran full.
Assumption: could it be the case that there is some plesk process (WP Toolkit?) that might try to recreate wp-config.php files and fails (resulting in an empty file?

 

[Sebahat.hadzhi]

Hello, @B_P . Neither Plesk nor WP-Toolkit should interfere with the website files. You can temporarily detach the affected website(s) from WP-Toolkit to further monitor the situation. However, I doubt the issue is caused by it. The most common reason for such issues is website exploit. Do you have malware scanner running on the server and does the same have an automatic clean-up enabled? I would also advise on checking the website logs for any abnormal activities - specifically the Apache and Nginx logs.

 

[B_P]

@Sebahat.hadzhi I tend to disagree. WP-Toolkit does obviously interfere with the website in different places. E.g., when you check for file integrity (and reinstall files), etc.).
But I assume this was not the issue. On the affected sites, we also use Solid Security – Password, Two Factor Authentication, and Brute Force Protection (iThemes Security /WP Solid Security). It seems that their plugin has a wp-cron job, which ensures that wp-config.php and .htaccess files have the correct content. I assume that this process does not work as expected when running out of disk space.

And the problem of running out of disk space is caused by Plesk backups: https://support.plesk.com/hc/en-us/...elected-objects?page=1#comment_35089716095255

https://support.plesk.com/hc/en-us/articles/12377651296791-How-to-prevent-Plesk-backups-from-consuming-all-free-disk-space?page=1#comment_35089729163671

We enabled daily backups (weekly full backups + incremental backups) to an external SFTP server and set backups to split up across files of max. 3.2 GB. However, the backup process does not seem to respect this (https://support.plesk.com/hc/en-us/...rver-with-Plesk?page=1#comment_35089557861783) and first creates ONE file of the largest subscription. Problem: if the size of this subscription is larger than the remaining free disk space, you end up in an unusable system.

 

[Sebahat.hadzhi]

@Sebahat.hadzhi I tend to disagree. WP-Toolkit does obviously interfere with the website in different places. E.g., when you check for file integrity (and reinstall files), etc.).

You are absolutely right. However, WP-Toolkit should not initiate the integrity check unless manually started.

Regarding the backup process, it is recommended to have available local storage equal to the largest two subscriptions, because while the first backup is being transferred, the second is being generated, thus consuming local storage. To monitor whether the issue originates due to lack of storage, you can try temporarily enabling "Start the backup only if your server has the sufficient amount of free disk space" in Tools & Settings > Backup Manager > Settings. (Not ideal suggestion, as backups might not be generated if the available space is indeed insufficient).

 

[B_P]

You are absolutely right. However, WP-Toolkit should not initiate the integrity check unless manually started.

Regarding the backup process, it is recommended to have available local storage equal to the largest two subscriptions, because while the first backup is being transferred, the second is being generated, thus consuming local storage. To monitor whether the issue originates due to lack of storage, you can try temporarily enabling "Start the backup only if your server has the sufficient amount of free disk space" in Tools & Settings > Backup Manager > Settings. (Not ideal suggestion, as backups might not be generated if the available space is indeed insufficient).

@Sebahat.hadzhi I'm sorry to disagree. But
a) From a resource-saving perspective (only use as many resources as required), it is not sustainable to require so much empty disk space just for backups.
b) I would agree that you need to have enough disk space as 2x the chunk size of the backup file (i.e., in my case 6.4 GB).
c) The problem is that your documentation is imprecise (it does not explain that always one single backup file of the largest subscription is created). In addition, it is not really clear why this behavior is chosen since the policy (and user decision) is to split up EVERY backup into chunks of X MB. So WHY does the backup process create one large backup file given that I as administrator indicated that every backup file shall be split up into smaller files?

 

[Sebahat.hadzhi]

The problem is that your documentation is imprecise (it does not explain that always one single backup file of the largest subscription is created).

There's an article that describes how the back process works in detail:

1. First, a backup file of the largest Plesk Domain (database, mailbox, website content) is created locally as a temporary archive in /var/lib/psa/dumps.
2. Then this created archive is transferred to the remote storage in parts of 100MB without additional compression.
3. Simultaneously with the upload of the backup part to the remote storage, creation of the next subsequent archive is starting.

In addition, it is not really clear why this behavior is chosen since the policy (and user decision) is to split up EVERY backup into chunks of X MB.

The "chunks" are in reference to the transfer process rather than locally splitting the compressed file itself.

So WHY does the backup process create one large backup file given that I as administrator indicated that every backup file shall be split up into smaller files?

I consulted with our team on why exactly is the system configured in such a manner and it is with consideration to robustness to network/remote storage issues. The main goal is to minimize scenarios in which some part of backup is refused during the transfer, which would then lead to the need to backup the data again, to resend it. That would also leads to additional RAM and CPU resource consumption, which is not ideal.

If you believe there's room for improvement, I would like to encourage you to share your feedback on features.plesk.com