2019 July 13
Again with the fixes to fixes, plus a little grey lie. Just four days after the release of version 1.5.0, along comes version 1.5.1 of the WP Mail SMTP plug-in. According to the change log, this contains a single fix to a flub in 1.5.0 which could result in sending duplicate mail messages. In fact, this is a minor part of the update, which is actually mostly a revision to how they generate nags to users to "upgrade" to the paid "PRO" version. We have no local code in this plug-in, so I simply applied the update kit. As you may know, in the WordPress world people can't decide whether to use hyphens or underscores in names, but this plug-in takes it to another level. Its root directory contains files named: wp-mail-smtp.php wp_mail_smtp.php wp-mail-smtp-0.11.2.php Got that? The last one is from an obsolete version of the plug-in which is loaded if the site is running on version 5.2 of PHP, which dates from November 2006 and has been out of support since January 2011; such is the world of WordPress. After installing the update, I sent a test message which was received correctly. Committed the version 1.5.1 update to WP Mail SMTP (Build 333) and published to GitHub. Performed a: service iptables save service ip6tables save to preserve the firewall rule changes across the next reboot. Made a mirror backup to Juno. Saved a copy of the current muzzle list: cd /server/var/muzzle super muzzle >muzzle_2019-07-13.txt Made a backup AMI: Ratburger Backup 2019-07-13 ami-0df9b06768b30cc18 / snap-06ca6aedd0f4efe19 /server snap-0e9e3f937aea42059 Saved copies of the current iptables block lists: super service iptables save service ip6tables save cd /server/bin/gardol_wp cp -p /etc/sysconfig/iptables iptables_save_2019-07-13 cp -p /etc/sysconfig/ip6tables ip6tables_save_2019-07-13 chown REDACTED:REDACTED *_2019-07-13 chmod 444 *_2019-07-13 Prepared the firewall un-block candidates list: cd /server/bin/gardol_wp perl gargol.pl which reported: IPv4: 2551 blocked IPv6: 294 blocked Gardol_wp log: 6223 unique entries loaded. 2832 candidates written to candidates.sh. Backed up the candidates list as candidates.sh_2019-07-13 just in case we want to review whether some offenders come back subsequently. OK, big gulp--apply the un-block list. Note that if something horrible happens we can always restore the tables saved before this step. super sh -x candidates.sh After this step, we count the number of blocked sites: muzzle | wc -l 2525 Looks good. Now re-ran gargol.pl to see how it evaluates the situation. It now finds just 10 candidates, presumably sites which just went over the age threshold. Moved the iptables and candidates archive files to /server/var/gardol: mv candidates.sh_* iptables_save_ ip6tables_save_ server/var/gardol Saved the now-pruned iptables block list to preserve across the reboot. service iptables save service ip6tables save Now the length of these tables are: 2245 /etc/sysconfig/iptables 293 /etc/sysconfig/ip6tables Installed all pending update packages: 37 in total, 19 for security including a new kernel and php. Rebooted at 12:50 UTC. The system had been up for 62 days. The system came up normally after the reboot. We are now running on kernel 4.14.128-112.105.amzn2.x86_64. After the reboot, both the IPv4 and IPv6 firewall rules were restored automatically. Deregistered (deleted) backup AMIs older than January 1, 2019. There's no way we're going back to them now, and we have redundant backups of all of the material on them in the Bacula incremental and full backup tapes. Ratburger Backup 2018-07-03 ami-0a3ff85c36758e1b7 Ratburger Backup 2018-07-08 ami-0bdd7acb0ce78e5fd Ratburger Backup 2018-07-19 ami-036feb159214ae345 Ratburger Backup 2018-07-28 ami-0da6d4724661cf067 Ratburger Backup 2018-08-14 ami-0533bbca8ab2c2ba8 Ratburger Backup 2018-08-20 ami-0e130deabd7e219da Ratburger Backup 2018-09-09 ami-09fd29334f2828745 Ratburger Backup 2018-09-30 ami-0412d6a191293a650 Ratburger Backup 2018-11-04 ami-096557fd643d87c88 Ratburger Backup 2018-11-11 ami-051d9feb21ee9a0ce Ratburger Test t3 running ami-06c53a5f12bfc5e3c Ratburger Backup 2018-11-12 ami-03cebc20760a03941 Ratburger Backup 2018-12-08 ami-005cd7136ef673706 Ratburger Backup 2018-12-10 ami-02ea2c0370610b95b Deleting an AMI does not delete the snapshots created when it is made. I deleted the following snapshots associated with AMIs deleted above. Some had already been deleted in an earlier sweep of old snapshots in which I neglected to expunge the AMIs which created them. snap-0b13d7ae6d55c1d70 8 Gb ami-0bdd7acb0ce78e5fd snap-0d6c1b5a8cc121681 128 Gb ami-0bdd7acb0ce78e5fd snap-069228cb2bda5fba5 8 Gb ami-036feb159214ae345 snap-0cad19dcf921cddc1 128 Gb ami-036feb159214ae345 snap-0b40d76212c9591f2 8 Gb ami-0da6d4724661cf067 snap-09a7480e9ae806b7b 128 Gb ami-0da6d4724661cf067 snap-07e92bd205ebde6eb 8 Gb ami-0533bbca8ab2c2ba8 snap-089b8f27d9b1a5089 128 Gb ami-0533bbca8ab2c2ba8 snap-0fe87d142d65d59b0 8 Gb ami-09fd29334f2828745 snap-0afd794dffde4d5ce 128 Gb ami-09fd29334f2828745 snap-06c6445d6fb829857 8 Gb ami-0412d6a191293a650 snap-098852865bb958ca3 128 Gb ami-0412d6a191293a650 snap-0e07cedf298b95adf 8 Gb ami-096557fd643d87c88 snap-0d7d6b46b6272d155 128 Gb ami-096557fd643d87c88 snap-0f0e906efe705e100 8 Gb ami-051d9feb21ee9a0ce snap-0d5d9e508b826da7b 128 Gb ami-051d9feb21ee9a0ce snap-0c12d09f82269bb4b 8 Gb ami-06c53a5f12bfc5e3c snap-0df69e7a209fe7440 128 Gb ami-06c53a5f12bfc5e3c snap-0197cf386801a8102 8 Gb ami-03cebc20760a03941 snap-0a59526bf00fd13ef 128 Gb ami-03cebc20760a03941 snap-08e6c09f4499ed9b9 8 Gb ami-005cd7136ef673706 snap-08515542bda6af362 128 Gb ami-005cd7136ef673706 snap-03fe9397e0f88a828 8 Gb ami-02ea2c0370610b95b snap-0a48f5efe1d3deea5 128 Gb ami-02ea2c0370610b95b Note that since snapshots are incremental, the storage charges for these snapshots are not necessarily proportional to the size of the file systems from which they were generated.