I’ve been thinking about this thread quite a bit. I made the point above that I enjoy having a daily report, in addition to what I said elsewhere, it’s nice to get just because you know the system is still working, i.e. if you stop getting the emails that is also something to investigate. The counterpoint has also been made along the way tho that complacency could in fact set in and the emails might become something never read. Therefor when a problem occurred it could be missed because the emails are not being reviewed anymore. Valid point.
On the other hand a script that is normally silent unless in alarm condition could in fact be circumvented by a sly hacker, or broken by unrelated causes. The alarm doesn’t work then either. And since no email output means things are good we could miss the alarm here as well.
Building a better mousetrap:
User A: Build “the script” as a “report” on a hidden URL of the main site, protected by .htaccess and/or some other means, but built to be served by apache as a private portion of the site. That report could be simple or complex and human readable if the site owner should navigate to the page (Debugging and/or just a random check on the site).
User B: On the same machine, different machine, or even a different host. This user serves no websites and exists only to run a second script via CRON. This second script makes an http request to the URL of the script built on user A thus causing the “check” to occur, output from the first script is collected. This second script then scans the text received for a series of several things that must be present AND absent and either declares “alarm” or “no alarm”. On “alarm” or time out/error (no output received) then “alarm output” is generated, else (i.e. “no alarm”) exit quietly.
The next thing to avoid is dependency on email solely for the “alarm output” generated. The entire output collected by the user B script could in fact be emailed as the first line of notification, but since we know that email is unreliable and/or might be delayed there should also be a second method employed of notifying the site owner. My suggestion for the second method would be to have the script ALSO use the twitter API to send a “direct message” type tweet to the site owner (by default i.e. the user has not unchecked the option in their twitter settings, receipt of this type of tweet will also cause twitter to generate yet another email notification sent from twitter). With all of these notification methods employed the message to check on the site because an alarm condition exists should be quickly received even if mail the primary email is delayed or lost.
Just a few thoughts, it’s starting to become more complex but seems to be a better way since the hacker would be unable to stop the cronjob from running, and if the script in USER A was in fact tampered with the alarm would most like be triggered anyway because the user B script would be actually analyzing the output of the User A script.