Last week my site was sort of completely nuked. Was entirely my fault, for the record, but on the bright side it also gave me a chance to rethink how the whole site should be set up.
What happened
Per suggestions from friends, I was looking into other systems to set up my blog with. One such system recommended by several is Astro, a JavaScript-ish framework with a preconfiguration for blogs.
The deployment procedure is what you will expect of something NodeJS based – one-liner to build everything into a static setup, to be placed into your webserver directory.
As I’m not running with any dedicated website hosting provider, I get to do the full manual, as in, building locally and dumping the results into somewhere under /var/www/html manually.
First challenge: transferring a folder over the Internet is… a bit of a mess. That’s a simple one. Just do the whole thing on the server itself. With SSH-aware IDEs this is not that much different from fully local.
The main issue: the deployment itself. In my current configuration with httpd, everything under /var/www/html would have apache:apache ownership, with 755 or 644 access controls. While I have my own user added to the apache group for convenience in other aspects of server management, it is still not sufficient for writing into the directory without some privilege change. It isn’t possible, either, to just do everything under that user, which won’t interact well with IDEs, and would lead to entirely different issues in system management1.
I ended up setting up a dedicated build directory under /var/www/html, with 775 access controls and all web access denied in httpd’s configuration. This allows me to develop as the real user, but still have it accessible easily enough as apache. Then I just set up the project’s config to deploy to its upper directory.
On the next deployment, the build script dutifully carried out its job, starting with… clearing the deployment folder.
And then there no longer is a script to execute. Nor is there anything left to serve for httpd.
How it should be done
Thankfully, I was able to retrieve most of the contents from a WordPress export, which was used to create the Markdown files as part of the migration.
Due to some plugins on the last installation, the WordPress database ended up too complicated for me to work with, so I dropped it and did a full reinstall2. The import went through without much of a fuss, and with some manual adjustments, we are back to what you are seeing right now.
In hindsight, the entire situation can probably be avoided by setting up some sort of CI/CD automation, but again it isn’t easy without a dedicated web hosting service.
Moving forward
For the foreseeable future, the main part of this blog will still be under WordPress. While I still have some issues with some features around it, the CMS aspect does still prove useful to me.
At the same time, I will be exploring other SSG solutions. The aforementioned Astro deployment will be moved here, but do expect it to be less up-to-date, since currently I’m just manually moving stuff across. Astro can also directly serve as a frontend for WordPress, which would evidently close that gap, and is definitely an interesting option to look into.
On the other hand, localization. I’ve always planned to make my site multilingual, which WordPress supports but… doesn’t make it easy, as in it works on the last installation but tends to break in various places. It’s probably worth a separate post in itself, but for now let’s just say I’m moving it to a lower priority here. It should be easier for Astro, though.
Summary
Long story short, I broke the site and got it back up, creating a good chance for me to put in some long awaited changes. Could probably expect them to trickle in over the next year.
Footnotes
- In my setup, the default home directory for
apacheis/usr/share/httpd, which is755 root:root. This is enough to break almost anything user-level. That and SELinux, which tends to not like mixing user stuff with webserver stuff… ↩︎ - Fun fact by the way: Despite having WordPress shipped in its supported distros, OCI officially recommends using a direct tarball instead. ↩︎
Leave a Reply