It was New Year’s Eve, doing routine maintenance on my cylindrical 12-core Mac Pro (Late 2013) and checking how all my webserver applications were doing when something unusual happened.
In the process of updating a few pages for 2021, Rapidweaver (the software that creates the pages of my main website) alerted an update from version 8.6.2 to 8.7, which was mostly additional support for the latest macOS, “Big Sur” or version 11.
Although, RW have safety provisions -in case of incompatibilities- to either ‘Skip This Version’ as well as ‘Remind Me Later’, I went ahead and did the update.
No problems there and I continued to open up the file (.rw8) …and, bam! Another update prompt came up on the screen. This time, a plugin (or, API – application program interface) within Rapidweaver called Stacks, prompted me that there’s a new version, from V4.0.4 to V4.1.3 (Build #5361). Again, and how stupid of me, I went ahead and did the update.
The Stacks V4.1.3 update came to haunt me as I found out later that majority of the web pages no longer worked. This had happened before (from Stacks 3 to Stacks 4) and I can’t seem to learn my lesson from the past. Ouch!
But, this is not to conclude that the Stacks V4.1.3 update would create problems for all Rapidweaver 8.x users. It all depends on the RW theme and plugin(s) you’re using.
But, hey, no problem. I have an ever-dependable-for Mac-only backup in Carbon Copy Cloner – I had been using this backup software since time immemorial. I had scheduled the backup to run early Sunday of every week and that should contain the exact replica of my entire main boot SSD before I did those updates!
So, I launched System Preferences > Startup Disk > switched to the backup SSD, and restarted the Mac Pro. And, the backup worked, as usual, like a champ. Problem solved??? Well, not so fast.
While all my web pages now worked- at least, while I re-tested under RW- after I reverted to prior versions using the backup SSD, this time, a bigger issue came up – my website is no longer accessible on the Web!
How is this possible? Aren’t backups, especially a cloned version, bit-by-bit copies of their originals? A bit alarmed now because of the looming task of debugging the entire webserver application, I hied off to the kitchen to brew a full carafe of my favorite blend.
To maintain my presence on the Web, I switched over to an older version of my website that runs on a Mac mini, then tackled the issue: why did the backup webserver on the Mac Pro fail to connect to the Internet when the source drive worked? Everything else worked properly on the backup drive except the ability of my AMP (Apache-MySQL-PHP)-based webserver to connect to the Web.
Here’s what I did to troubleshoot the issue:
1). Checked the router, access points & all settings (especially port forwarding) — OK.
2). Checked the IP gateway/Dynamic DNS -the one that renders your dynamic IP address given by your ISP to a static IP address needed to host a website at your choice location- for incorrect settings. At no-ip.com, I fiddled with different domain name resolver configurations —only to find out that my previous setting was correct. All OK.
3). Reviewed all the steps when I configured the AMP-based webserver via Brew – no problems, all OK.
So, what’s wrong?
Before I resign my fate to begin 2021 with long hours recoding my webserver for macOS Big Sur (and, yes, I need to buy a new M1 processor-based Mac since my 2016-bought “trashcan” Mac Pro (Late 2013) may be compatible only in 2 or 3 more future macOS releases), I tried again to stop, start and restart the webserver using Terminal.
Again, no issues until I tried to diagnose for any error when Apache starts via the Terminal command:
tail -f /usr/local/var/log/httpd/error_log
The error log revealed a few script errors with the WordPress login –all related to PHP handling.
Those errors are understandable as my WordPress site is also tied to my main website – https://www.marcoscarpio.com, as an offsite page within Rapidweaver.
Finally, it dawned on me why I didn’t run the MOST BASIC of all Apache commands in Terminal.
And, there it was, right in front of my 28” LED monitor:
AH00526: Syntax error on line 46 of /usr/local/etc/httpd/extra/httpd- vhosts.conf:
SSLCertificateFile: file ‘/etc/letsencrypt/live/www.marcoscarpio.com/fullchain.pem’ does not exist or is empty
Although, I was fully aware that the secure version (https) of my website is due to the free SSL certificates from Let’s Encrypt -which you have to renew every 90 days- it did not dawn on me that you MUST either renew or request a reissue of those certificates – after you switched over to your backup web server!!!
At Let’s Encrypt Community Board, I got this good explanation:
“The distinction between copying all of
/etc/letsencrypt (with symlinks) and just copying
fullchain.pem is that in the former case, you can run
certbot renew on the new system to renew the certificates, while in the latter case Certbot will not be able to renew the copied-over certificates. So it’s not a distinction about whether the certificates will work on the new system (just copying these two files is sufficient for that), but specifically about whether
certbot renew on the new system will know they’re present and be able to renew them (copying the whole
/etc/letsencrypt tree is recommended in this case)”.
Let’s Encrypt utilizes an easy-to-use client called Certbot to simplify the issuance of SSL certificates (yes, they’re free) on a variety of webserver software of various OS platforms. If you had tried to install (and, maintain) your own SSL certificates —well, that’s another blog entry in itself.
Long story short: Let’s Encrypt Certbot won’t automatically sync the certificates it had issued on your web server that’s located on your main hard drive and your backup hard drive.
New Year. New lesson. But, it’s always good to learn.