We don't yet understand why, but it is clear that there are some important mariadb/mysql packages being removed! My guess is that the security update depends on newer versions of these packages, but they aren't being provided by the security repo, so the old versions are simply being removed.

Once we confirm a workaround, we'll need to consider what to do next to properly fix it. We'll probably discuss with Debian security team on how they do things to ensure that our auto security update mechanism is compatible. It may be that we need to reconsider how we install security updates. Or perhaps they will be willing to change the way that they do things. Another possibility is that we could include the required packages in our security repo, but that is probably my least favourite response. Either way, we need to fix the immediate issue and look to how we can ensure it doesn't happen again in the future!

I would definitely recommend re-enabling security updates.

I'm sure you know how to do that (or could guess - simply move the cron-apt file back), but just in case:

mv /root/cron-apt /etc/cron.d/cron-apt

Whilst this issue has demonstrated that they are not 100% foolproof, they have an extremely good track record. On balance IMO they provide significantly more value than potential harm. FWIW I watch the Debian security tracker fairly closely and they release at least 3 or 4 security updates a week (often many more). Obviously every TurnKey server doesn't rely on all of them (many are for GUI programs, so do not affect any TurnKey servers) but regressions are rare and severe breakages are extremely rare.

IIRC this is the 4th problematic security update to affect TurnKey in nearly 10 years, albeit the 2nd most significant one. FTR, the worst was a cron breakage back around 2010, which broke cron (and therefore automatic updates) on all appliances! That one was due to a poorly tested cron update which was our final straw with Ubuntu and finalised our decision to move to Debian. The others were fairly specific, one was a Java update that uninstalled Jenkins (only affected the Jenkins appliance) and a Samba update (that only affected the Samba based appliances, e.g. Domain controller, Fileserver ,etc.). These other 2 were somewhat similar to this, but a little different and obviously affected a lot less users.

As hinted in the blog post, I plan to use this situation as a spring board to work with Debian to reduce the likelihood of future issues. Exactly what that will look like I'm not yet sure, but it may possibly include us tweaking our default configuration. If that happens, ideally I'll look to do that via a pushed security update (so everyone gets it automatically). Although we'll need to do some careful and considered testing before we push that to ensure that it doesn't break anything! If/when we get to that, volunteers for testing would be warmly welcomed! Please feel free to put up your hand! :)

Firstly, if you haven't already, I would strongly advise you to register for a TurnKey website user account. FWIW, I sent out an email notification to all subscribers immediately after posting the blog post.

Next up, yes, if you experience an issue "out of the blue" such as this, we'd really appreciate it if you let us know. At the very least, assuming that we can recreate the issue, then we can assist you to resolve it. And probably more importantly, if it's a bug, then we can develop a workaround/fix, improve future appliances and in cases such as this, alert other users to the issue. Everybody wins! :)

FWIW if you were using TKLBAM to generate automatic daily offsite backups, you could have restored yesterday's backup to a new server (restores to the same version should work flawlessly, restores to same major version should also generally work flawlessly) and you'd be off and racing! ;) (Sorry for the shameless self promotion there...)

Anyway... Regarding your specific issue, so the DB appears to be working ok, but WordPress still isn't right? Is it still giving an error noting that it can't connect to the database? Or is it now giving a new/different error?

If it's still a DB connection issue, perhaps re-configuring the WordPress DB connection may fix the issue?

You could manually reset the password of the 'wordpress' MySQL user account and ensure that WordPress was using that same password. Although if you didn't want to try that manually, here's a script to do it for you (FWIW, I've taken the relevant parts from the TurnKey WordPress firstboot "secrets" regeneration script. You could simply re-run that script in it's entirety, although TBH I'm not sure of what other implications that might have?! (It might make things worse as the firstboot scripts are only intended to run on firstboot). If you try that, I'd urge you to ensure that you have a current backup of all your files and your DB, just in case. If you just update the WordPress DB user password, it's highly unlikely to make things worse.

So to regenerate the WP DB password and update the WP conf to use the new password, paste this directly into your commandline (i.e. in an SSH session):

updateconf() {
    CONF=/var/www/wordpress/wp-config.php
    sed -i "s/\(.*\)$1\(.*\)');/define('$1', '$2');/;" $CONF
}
PASSWORD=$(mcookie)
updateconf 'DB_PASSWORD' $PASSWORD
/usr/lib/inithooks/bin/mysqlconf.py --user=wordpress --pass="$PASSWORD"

If that doesn't work, I suggest that you start a new thread for your issue and give some more specific details about the error you are getting. The tail of your Apache log might also be useful (i.e. tail -30 /var/log/apache2/error/log). I'll respond ASAP. (PS new threads require you to be logged in).