The rea­son why this blog was not acces­si­ble to some peo­ple

I got noti­fied that my blog was not acces­si­ble for a while. Seems that at least recent fire­fox ver­sions some­how changed their behav­ior in what is send in the HTTP-header. This caused an Apache Redi­rect­Match rule to trig­ger, which denies access to some parts of the blog for some users.

The WP-login, WP-dash­board, and logged-in users where not affect­ed by this, so if you have some cus­tom rules which deny access to your blog, make sure you make a test of your blog when logged-out.

Send to Kin­dle

Cheap process mon­i­tor­ing (no addi­tion­al soft­ware required)

I have an old sys­tem (only the hard­ware, it runs -cur­rent) which reboots itself from time to time (most­ly dur­ing the dai­ly periodic(8) run, but also dur­ing a lot of com­pil­ing (por­tup­grade)). There is no obvi­ous rea­son (no pan­ic) why it is doing this. It could be that there is some hard­ware defect, or some­thing else. It is not impor­tant enough to get a high enough pri­or­i­ty that I try hard to ana­lyze the prob­lem with this machine. The annoy­ing part is, that some­times after a restart apache does not start. So if this hap­pens, the solu­tion is to login and start the web­serv­er. If the web­serv­er would start each time, near­ly nobody would detect the reboot (root gets an EMail on each reboot via an @reboot crontab entry).

My prag­mat­ic solu­tion (for ser­vices start­ed via a good rc.d script which has a work­ing sta­tus com­mand) is a crontab entry which checks peri­od­i­cal­ly if it is run­ning and which restarts the ser­vice if not. As an exam­ple for apache and an inter­val of 10 min­utes:

*/10 * * * *    /usr/local/etc/rc.d/apache22 status >/dev/null 2>&1 || /usr/local/etc/rc.d/apache22 restart

For the use case of this service/machine, this is enough. In case of a prob­lem with the ser­vice, a mail with the restart out­put would arrive each time it runs, else only after a reboot for which the ser­vice did not restart.

Send to Kin­dle