On the database server of my search engine project, /etc/ssh/sshd_config said PasswordAuthentication no. The server accepted password logins anyway, and a bot on the internet was guessing the root password around the clock. Every attempt failed, but only because the password held, not because the setting did.
CaRMen, the small CRM I run for myself, had unit and controller tests from early on, but nothing that drove an actual browser against the actual frontend until October. Setting up Playwright properly — @playwright/test instead of plain playwright, a Chromium-only project, role-based locators, a shared login helper — took one evening.
Part 3 ended on an assumption: that the authority score behind every ranking was right. Authority comes from PageRank, computed over the whole link graph, and it's the part of this search engine that has never fitted comfortably anywhere.
The script that drafts and schedules articles for this site starts a self-hosted LanguageTool server for each run, so every draft gets a grammar check before it's published. On 15 October, on the LFS laptop it now runs on, I found that LanguageTool hadn't started at all, and nothing in the script's output said so.
I wrote a piece in September about this site's average Google Search Console position falling from the 14-20 range to 7.8-9.4, right as a dozen new articles went live.
I run a small CRM for myself called CaRMen — a Symfony 7 API Platform backend with a React frontend. In August I had to bump api-platform/core from ^3.3 to ^4.0, not because I wanted the new major version, but because composer's own security-advisory audit flagged every 3.3.x and 3.4.x release in a row. There was no patched 3.x left to stay on.
My PHP projects don't run PHP on the host. This site runs in DDEV, CaRMen runs in a docker compose stack, and whatever PHP the host has is irrelevant to both.
This site runs Drupal's cron every 15 minutes from a crontab on the server, with the output appended to a log file in my home directory. For about twelve days in September, almost every one of those runs tried to send me an email, failed, and wrote two lines about it to that log. Nobody read the log. The emails were security update notifications.
A reindex that was scheduled purely as insurance, against a problem that almost certainly wasn't going to happen this time, finished with a real, measurable bonus nobody had gone looking for: nearly a third of the database's total index storage disappeared, cleanly, as a side effect of doing something that was never actually about storage in the first place.
I went looking for this laptop's crontab to write a comparison with systemd timers, and there wasn't one. No crontab binary, no /etc/cron.d, no cron daemon running at all — crontab -l just says command not found.