WordPress. We love it. We know not everyone feels the same way. There are obvious reasons, one of which is the regular news (though not as regular as it used to be) of a plugin containing a vulnerability. Needless to say, that kind of news sucks. You have to admit though that WordPress has come a long way to make such things less sucky with an impactful auto update process. Unfortunately, the only kind of update which is beyond WordPress’s sphere is the back end, i.e. the AMP stack.
In the case of our blog, the AMP stack was beginning to buckle under patching to keep up with the requirements for WordPress. Patching can only take you so far until other constraints are met and a decision is needed to start fresh. That time came recently and because of that, migration plans for the services on that infrastructure followed. These are the kinds of changes you’d rather deal with deliberately than keep working around indefinitely. We do love an end of life on servers and the challenges that it brings, don’t we?
Tools Galore
Luckily, for many years now, infrastructure has largely been managed by Ansible, and during migration planning that is coupled with Vagrant. Both tools make server testing and management a breeze and allow changes to be exercised safely before anything goes live.
Vagrant provides easy, repeatable testing of infrastructure changes. Model the setup, make a change, rebuild, see how that works and then tear down. Throw in Ansible, or other tools such as Chef, Puppet and Terraform that abstract away micro changes, so that once a script is done, duplication and customisation can be applied. For example, AMP stacks always have the same structure but different content. If they are all going to be the same then a template that provides that structure can be duplicated with parameters for those customisations such as domain name, etc.
In this case, a decision to switch the distro family impacted the number of changes. Once again, Ansible hides many of those idiosyncrasies specific to distros and the only manual considerations tend to be that the location of config files or binaries might have moved elsewhere. All simple to implement.
After a few test cycles came deployment, then restoring the database and content to the new box and flipping the DNS. Everything behaved as expected and the process was, thankfully, all nice and smooth. It already feels snappier on the admin side.
Sitting back satisfied with a job well done, a mailbox went ping. Then we see a message on the security news feed that brought back some memories…
Shrinking Certificates
A news article (https://security.googleblog.com/2025/12/https-certificate-industry-phasing-out.html) caught our attention that reminded us of one back in April 2025 (https://www.theregister.com/2025/04/14/ssl_tls_certificates). Both brought to mind the migration away from 1-3yr SSL certificates down to just a month over the next couple of years. Yeah. We have a few of those and while most are managed by Ansible deployment, some aren’t. This isn’t going to go away and, having just finished one migration, it’s not something we want to keep revisiting unnecessarily.
Easy then. Let’s bite the bullet and just switch to the obvious solution and go with Certbot and Let’s Encrypt. It is an obvious choice really; they have over 60 million sites including big names like SAP and Volvo using them. This is clearly where things are heading, and it makes sense to align with that now. A few minutes later, everything was installed and we watched as certificate negotiation occurred and the existing SSL certificate was replaced. Yes, very easy.
Now to sort out the rest of the fleet…