• John Walker posted an update in the group Group logo of UpdatesUpdates 3 months, 2 weeks ago

    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
    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:
        tar: ./wp-login.php: Cannot open: File exists
        tar: ./wp-settings.php: Cannot open: File exists
        tar: ./wp-signup.php: Cannot open: File exists
        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/ 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.