So I have this site that compiles blocklists of malicious IP addresses based on CSF blocks. Every time CSF blocks an IP address or range, a script parses the report and saves the relevant information to a database.
Another script reads that database to create downloadable blocklists.
Yet another script uses it to put excepts on pages of the site.
Because the site is wholly database-dependent, it’s a handy test site for the migration tests I’ve been doing. The most recent migration onto my AlmaLinux test server worked fine, using any PHP version from 7.2 through 8. No errors in the logs, everything is fine.
I haven’t looked at it in a few days, but I decided to check it today because I upgraded the OS from RC to stable, and I was doing some final tests. One was to make sure that everything started up after a reboot. And after the reboot, none of the SQL-generated lists showed up on the test site. No errors, but no results.
I switched to another MySQL-driven test site, which was working fine. So I switched back to the blocklist site and spent a little over an hour trying to figure out why all the queries were coming up empty. Manually querying the SQL server returned no results, but threw no errors, either.
I was stumped.
Then I remembered that I have a rehabilitation script that runs as a cron job and deletes entries if the IP addresses have behaved themselves (meaning no further malicious acts were detected) for the past few days. Because it’s a testing server behind a firewall, there have been no malicious acts against it; so the rehabilitation script cheerfully rehabilitated everyone.
In other words, my code was working fine. There were just no miscreants left in the database.
On the positive side, at least I know that cron is working.
Richard