2020 August 13
The scheduled RSS feed update ran normally at 23:30 UTC, so I committed the WP RSS Aggregator version 4.17.7 update (Build 489) and published to GitHub. The /server/log/access_log had grown to 6.2 GB, having last been cycled on 2019-10-16. I cycled it, creating cycle 4. After backing up the compressed cycle 4 log file to ~/w/Ratburger_AWS/HTTPlogs on Juno, I left it in /server/log/History, since we have abundant space on that file system (10% full). Made a mirror backup to Juno. Made a backup AMI: Ratburger Backup 2020-08-13 ami-0c62f4d109dc5e947 / snap-07a5c2ba27710c2f9 /server snap-05ce2736042448d3c Installed all pending update packages: 52 in total, 14 for security including a new kernel. Ran a Garback to preserve firewall settings and the muzzle list across the reboot. Rebooted at 12:59 UTC. The system came up normally after the reboot. We are now running on kernel 4.14.186-146.268.amzn2.x86_64. The system had been up for 42 days. After the reboot, both the IPv4 and IPv6 firewall rules were restored automatically. At 13:40, installed the WordPress 5.5 update. When I tried to extract the update kit under my account, I got: ./wp-login.php tar: ./wp-login.php: Cannot open: File exists ./wp-settings.php tar: ./wp-settings.php: Cannot open: File exists ./wp-signup.php tar: ./wp-signup.php: Cannot open: File exists ./xmlrpc.php tar: ./xmlrpc.php: Cannot open: File exists tar: .: Cannot utime: Operation not permitted I thought this might be a file busy problem, so I stopped HTTPD but that did not fix the problem. I extracted the archive as root, and that completed OK. I then restarted HTTPD and it seemed to come up normally. The Dashboard reports us as running on WordPress 5.5. What is going on with the tar extracts into the ~/rb directory (which is actually /server/pub/www.ratburger.org/web) is a mystery. On 2019-12-13, I encountered the same problem and attributed it to that directory's ownership having been set to root:root. I changed it back, but when I went to do the extract this time, it had been changed back to root:root and hence failed again. When I extracted the archive as root, tar changed the directory back to REDACTED:REDACTED, so it's correct now. But when and how it got changed to root:root since the last time it worked and today is an enigma. As always, the update reset the permissions on the akismet plug-in to 755. I reset: chmod 700 ~/plug/akismet Since I deleted the useless new themes before preparing the kit this time, I didn't have to reset their permissions to keep them from showing up in the Themes panel. Ran the Site Health report (Dashboard/Tools/Site Health), which reported nothing other than the usual noise about our having disabled their absurdly insecure "background updates" and the garbage which supports that. It appears that my global disabling of automatic updates (see 2019-08-22) keeps the new plug-in and theme automatic updates from slithering into view. At least, no automatic update column appears in the Plug-in administration page. After ten hours, there haven't been any problems reported with WordPress 5.5 or anything amiss in the error_log. I went ahead and committed the changes (Build 490) and published to GitHub.