Techies live by two very wise philosophies:
- If it’s working, leave it alone
- If there’s a security update, install it
You might notice a paradox here. And therein lies the source of endless frustration. Plainly stated, you can’t install a security update unless you mess with a working system. So what to do?
Well, my personal plan of attack has been to check the patch notes before installing anything, and judge its relevance to my given application. For example, I put off updating my VPN software because the patched vulnerability was an old version of L2TP/IPsec–something I don’t use.
But the growing list of CVEs on my WordPress install started to concern me, some of which were alarming, like broken access restrictions with URL injection. Yikes. Still, I waited, because I really didn’t want to mess with it.
Then my server automatically updated its PHP packages (I thought I had disabled automatic updates), which brought my blog down. So begrudgingly, I used it as an excuse to finally update. I began the install process.
As it turns out, WordPress runs on PHP 5.6 (the scripting language which loads data from the SQL backend)–at least the package I have installed anyway. Other programs I run require PHP 7, so I have both installed. But the automatic PHP upgrade deactivated 5.6 in favor of 7, which not only broke the site, but prevented the install. I manually reactivated 5.6, which then triggered its own update, requiring me to patiently wait another hour while it completed.
PHP updated, I tried to load the installer again, but found out that the MariaDB (the open-source fork of SQL) version, version 5, had been stopped in favor of version 10–very similar to the PHP problem. So I reactivated version 5 and waited patiently while it updated.
These updates collectively maxed the server’s processing power, which then brought down the entire machine. Nothing’s more nerve-wracking than watching an eternally-spinning icon, devoid of any meaningful information like a status bar. But, patience and a lot of burning stomach acid later, the installs completed and the server came back online.
I started the WordPress install, and was prompted for MariaDB 5’s root password. I looked up my complex and randomly-generated password, pasted it in, and continued. Then I was prompted for MariaDB 10’s root password. Curious, why would it need both? Unfortunately, I have yet to find a solid answer, as the WordPress package installations and their associated communities vary widely across the web.
Then I was prompted for my database user account, which I input as well. The installation clocked for several minutes, then advised that I did not have access to the databases. Curious. I knew with certainty what my user password was. I considered that maybe the root password was different. To find out, I installed a database management interface and attempted to log into both databases as root. All attempts failed. So apparently I didn’t know the root’s password.
A brief web search revealed the default password to be blank, which bothered me immensely. Granted, it probably wasn’t as big a problem as I was thinking, since presumably only the localhost would have access to the database, but that still seems like a bit of a security hole, like say if malware made its way into the machine. Also, the management interface I had installed was Internet-facing, which meant that the moment I installed it, my databases were publicly accessible. Nothing private is in there, but still. Ah well, I used the interface to change the root passwords for both databases and reattempted the update with the correct credentials.
The install crashed and the logs said the update failed. I checked the install package, and its version matched the newest. Confused, I consulted the logs again, but this time it said that the install was successful. Finally some good news. I opened up the site.
The site loaded its front page, but without images. I refreshed the page, only to then find that the only data loading was in the browser’s cache. The page wasn’t there anymore. So I checked the web directory’s contents and was dismayed to see that the entire WordPress folder had been purged of data. The update had reinstalled anew, rather than updating.
I had taken the precautions of backing everything up, so I wasn’t completely distraught, but I began to fear that the WordPress package itself was beyond repair. I had previously considered 3rd party hosting solutions, and figured that this would be my final salvation. But first–I would use my automatic backup service to retrieve the last version from my Amazon Drive account, which was timestamped as that morning around 5AM.
The restore took about a half hour. I reloaded my site, and it worked! I admit I was surprised. I had surmised that the site solely operates through a conglomeration of PHP scripts which access the database, but if that were the case, then the file restore would have wiped out the upgrade–which after checking again, it hadn’t. So it was the package itself that got updated, not necessarily the script files.
I admit, I still have a long way to go to understanding this technology, but that was the original point of starting this blog. For now, I’ll remain content that my site is functioning at all.
–Simon