Activity

  • John Walker posted an update in the group Group logo of UpdatesUpdates 1 month, 1 week ago

    2019 July 9

    Created a dedicated lightweight document in the root server
    tree:
        https://www.ratburger.org/health_check.php
    to serve as an endpoint for AWS Route 53 health checks. It loads
    no other documents, is less than 1K in size, yet exercises PHP
    and php-fpm in order to successfully run.  This provides a
    sanity check that we're up without imposing the load of a full
    start-up of WordPress.  I've included some sample code to show
    how to return bad HTTP status code based on additional checks we
    might wish to add, such as verifying access to the MySQL
    Ratburger database.
    
    Reconfigured the AWS Route 53 health check to use the new
    lightweight endpoint.  Tested it in normal and simulated failure
    modes.  The CPU load shown in "top" is much lower than we saw
    with the home page health check.  I'll monitor CPU credit over
    the next few hours to make sure it's not eroding.
    
    Configured a new alarm, RatburgerHealth, which monitors the
    Ratburger HTTPS health check.  The notification condition is the
    same as for FourmilabHealth: 10 consecutive one minute
    indications of health < 1.0.  The notification target is
    presently set to FourmlabHealth, namely me, but this can be
    changed if we want to alert additional people.
    
    Committed the health_check.php file (Build 328).
    
    Updated the Really Simple SSL plug-in to version 3.2.3.  This is
    a minor collection of updates which don't affect anything we
    do.  We have no local code in this plug-in.  After installing
    the update I checked the settings and everything looked all
    right.
    
    Updated the WP RSS Aggregator plug-in to version 4.14.  This is
    a fairly major update with 113 files modified, 156 files deleted
    (!), and 28 files added.  Many of the deletions were actually to
    move files around in the directory structure.  Fortunately, we
    have no local code in this plug-in, so it's just a matter of
    running the ./chk (which found no problems other than the
    expected squawks in JavaScript files because nodejs doesn't
    support import or export statements) and then applying the
    update kit, including the deletions.  After applying the update
    I checked the administrator pages and the Podcasts page and
    nothing looked amiss.
    
    Updated the WP External Links plug-in to version 2.32.  This is
    a two-line fix (ignoring the mass of nonfunctional cruft it
    takes to deliver a plug-in to its users) documented as "security
    fixes".  I have no idea what they're doing, and they don't see
    fit to explain it to their users.  We have no local code in this
    plug-in, so I simply applied the update kit.  This plug-in has
    no configuration, so I tested it simply by verifying that links
    in posts I know don't have the target="_blank" attribute indeed
    open in a new tab.
    
    Updated the WP Mail SMTP plug-in to version 1.5.0.  This is a
    medium-scale update with 68 files modified, 8 deleted, and 29
    added.  Many of the changes were cosmetic, but a few affected
    the Gmail handler, which we use, but none in ways which seem to
    require changes on our part.  We have no local code in this
    plug-in.  After applying the changes I looked around in the
    configuration and everything appeared OK, then sent a test
    E-mail which arrived succeessfully.
    
    So, one day, four plug-ins updated, two hours of administrator
    time consumed, with precisely zero benefit to the site or its
    users.  Smells like WordPress to me!
    
    I'm going to let these plug-in updates mellow overnight to see
    if something starts to stink.  Since each is confined in its own
    directory, there is no difficulty committing them separately
    once we're confident they're here to stay.
    
    Meanwhile, the health check seems to be behaving well.  There
    hasn't been a problem in a probe since the simulated failures I
    deliberately introduced around 12:00 UTC, and there has been no
    impact on our CPU credit from processing the probes.  The alarm
    is in place, reporting OK, and has not triggered.