Dashboard error message:
https://pangea-systems.com/jas/pub/share/misc/Screenshot%20from%202018-04-30%2020-26-48.png
Upgrade attempt error message:
https://pangea-systems.com/jas/pub/share/misc/Screenshot%20from%202018-04-30%2020-27-28.png
In installed the “Healthcheck” plugin which yields the warnings:
PHP Version 7.1.8 - For performance and security reasons, we strongly recommend running PHP version 7.2 or higher.
cURL version Your version of cURL, 7.29.0, is lower than the recommended minimum version of 7.38. Your site may experience connection problems with other services and ww.wp.xz.cn
Scheduled events A scheduled event (tribe_aggregator_process_insert_records) has failed to run. Your site still works, but this may indicate that scheduling posts or automated updates may not work as intended.
Your installation of WordPress doesn't require FTP credentials to perform updates.
Some files are not writable by WordPress:
xmlrpc.php
wp-blog-header.php
wp-signup.php
index.php
wp-cron.php
wp-config-sample.php
wp-login.php
wp-settings.php
license.txt
wp-mail.php
wp-links-opml.php
wp-load.php
wp-includes/class-wp-user-query.php
wp-includes/l10n.php
wp-includes/date.php
wp-includes/images/blank.gif
wp-includes/images/down_arrow.gif
wp-includes/images/spinner.gif
wp-includes/images/media/interactive.png
wp-includes/images/media/default.png
...
Those files above are absolutely writable by the apache user. As shown above, httpd and php are running as apache.
I’ve done the below during troubleshooting thus far:
PERMISSIONS
The ‘wordpress’ directory was tar’d from the old server which didn’t have any permission problems and thus the perms were brought forward exactly as-was. The owner (apache) most certainly has recursive write access to everything as I’ve re-applied that just in case. I could check for user/group permissions though it would be a bit tedious, I’m not sure how it could have been changed and is it necessary?
The directories where plugins and WP itself are written to during the upgrade process are writable by the apache user (I showed the test result for that above). I have verified that those directories which it complains it can’t write to are 0777 and it still fails to write to them (see above). So, I am very dubious about there being a filesystem permission issue.
FTP USER
I have full access to the VM, so I didn’t need FTP and, since FTP is highly insecure, I don’t use it. To avoid configuring FTP I followed a few people’s suggestion to change wp-config.php:
/** direct access method **/
define('FS_METHOD', 'direct');
define('FTP_BASE', '/export/htdocs/wordpress/');
define('FTP_CONTENT_DIR', '/export/htdocs/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/export/htdocs/wordpress/wp-content/plugins/');
PHP
WP was complaining that the version of PHP I was running was old. I doubted this was the permission issue, but thought I’d investigate. Sure enough, the standard build for CentOS/RHEL is dated but stable and a lot of plugins want newer. I found a method to install PHP7 on CentOS7 here so I did this: https://linuxconfig.org/how-to-install-or-upgrade-to-php-7-on-centos-linux-server
This didn’t change anything.
APACHE
The only line I changed in the httpd.conf was the Servername directive – otherwise it’s stock CentOS7. I don’t know if you want me to copy/paste that here.
In /etc/httpd/conf.d I have a wordpress.conf directive, which is super simple:
# cat wordpress.conf
#Alias / /export/htdocs/wordpress
NameVirtualHost *:443
<VirtualHost *:80>
ServerName sailtracker.net
ServerAlias www.sailtracker.net
Redirect / https://www.sailtracker.net
</VirtualHost>
There also exist wordpress-le-ssl.conf for Let’s Encrypt SSL config which has:
# cat wordpress-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
SSLEngine On
ServerName sailtracker.net
ServerAlias www.sailtracker.net
DocumentRoot "/export/htdocs/wordpress"
<Directory /export/htdocs/wordpress>
AllowOverride Options
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
</IfModule>
</Directory>
<Directory /export/htdocs/wordpress/wp-content/uploads>
# Deny access to any php file in the uploads directory
<FilesMatch "\.(php)$">
Order Deny,Allow
Deny from all
</FilesMatch>
</Directory>
<Directory /export/htdocs/wordpress/wp-content/plugins/akismet>
# Deny access to any php file in the akismet directory
<FilesMatch "\.(php|txt)$">
Order Deny,Allow
Deny from all
</FilesMatch>
</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/sailtracker.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sailtracker.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/sailtracker.net/chain.pem
</VirtualHost>
</IfModule>
and the PHP-FPM conf:
# cat php-fpm.conf
AddType text/html .php
DirectoryIndex index.php
<FilesMatch \.php$>
SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>
…along with some other default conf files I didn’t modify from standard install package.
I re-run the upgrade attempt and there are no error messages in error_log, or ssl_error_log.
I do have some security-oriented plugins running (Wordfence, Sucuri Security) – could these have somehow caused a write issue? I have not tried to delete them yet as they have helped isolate malware in the past.
