Now I’m all for people publshing warnings about security issues, but they really should at least read the official documentation to check their information first.

In this case, to summarise the documentation:

• AddHandler is used for server-side content handling – it associates a handler with the specified content
• AddType is used for determining the Content-Type in relation to the client request (ie. the default Content-Type identified to the browser)
• BOTH obey multiple extensions, but a response can only have one Content-Type while a file can be handled by multiple Handlers.

This means that while, when using AddType, “test.php.gif” no longer works, “test.php.something” will (assuming .something doesn’t have an associated Type), because .php is the last extension encountered which has an associated Type. So the so called “fix” doesn’t really fix the problem at all.

Additionally, when using AddType, instead of the default Content-Type being text/html, it becomes “application/x-httpd-php”, which is technically incorrect and may result in your website not being viewable in browsers or by search engine bots.

If you really want to make it so that only files ending with .php are handled by PHP, then you should use SetHandler instead of AddHandler. In fact, this is what the current official PHP documentation recommends.

There’s an article on Gentoo Wiki that explains this new feature from a users point of view and how to tailor it to your individual tastes.

Turns out this isn’t quite the case. There’s a 5 year old bug in Gentoo’s Bugzilla about this known issue and it appears to be down to the way run-crons manages its lock / last run files. I’m already running a run-crons patched for recursive directory scanning on some of my systems, so it wasn’t that big a step to basically do away with Gentoo’s supplied script altogether.

Now I’m running “run-crons-in” – a much simplified script that simply relies on the cron daemon itself for timing (which is how it should be, in my opinion). Here’s my script:

#!/bin/bash
# 2009-10-27 Complete rewrite of run-crons
# This version is designed to be called using @hourly @daily @weekly or @monthly
# With, for example: run-crons-in daily
#
# This version assumes:
# - We don't care if a previous script is still running
# - The cron daemon handles all timing in a sensible manner
# - Therefore no locking is necessary

AJB_DEBUG=0
AJB_TIMES=1
AJB_PTIMES=1
AJB_TIMEFORMAT='%Y-%m-%d %T'
BASE=$1

AJB_STARTTIME="`date +\"${AJB_TIMEFORMAT}\"`"
[ $AJB_TIMES -eq 1 ] && echo "Start time: ${AJB_STARTTIME}"

run_recursive() {
        CRONDIR="$1"
        [ $AJB_DEBUG -eq 1 ] && echo "Executing cron scripts in directory: $CRONDIR"
        for SCRIPT in $CRONDIR/* ; do
                if [[ -x $SCRIPT && ! -d $SCRIPT ]]; then
                        [ $AJB_DEBUG -eq 1 ] && echo "Executing cron script: $SCRIPT"
                        AJB_PSTARTTIME="`date +\"${AJB_TIMEFORMAT}\"`"
                        [ $AJB_PTIMES -eq 1 ] && echo "Script start time: ${AJB_PSTARTTIME}"
                        $SCRIPT
                        AJB_PSTOPTIME="`date +\"${AJB_TIMEFORMAT}\"`"
                        [ $AJB_PTIMES -eq 1 ] && echo "Script stop time: ${AJB_PSTOPTIME}"
                fi

                if [[ -d $SCRIPT ]]; then
                        run_recursive $SCRIPT
                fi
        done
}

CRONDIR="/etc/cron.${BASE}"

test -d "$CRONDIR" || echo "Directory does not exist or is not a directory: ${CRONDIR}"
set +e
test -d "$CRONDIR" && run_recursive "$CRONDIR"

AJB_STOPTIME="`date +\"${AJB_TIMEFORMAT}\"`"
[ $AJB_TIMES -eq 1 ] && echo "End time: ${AJB_STOPTIME}"

As you can see, it’s fairly basic – altho I’ve added some extra output for timing and debugging, simply because I felt like it. I’m currently testing this long term to ensure it works as expected, but hopefully I’ll adopt this for all my systems within a couple of months.

The full /etc/crontab entries are now:

@hourly   root    /usr/local/sbin/run-crons-in hourly
@daily    root    /usr/local/sbin/run-crons-in daily
@weekly   root    /usr/local/sbin/run-crons-in weekly
@monthly  root    /usr/local/sbin/run-crons-in monthly

(Yes, I realize that, at least by the man page, those are all going to run at midnight, but daily is the only set of scripts that ever does anything really stressful on the system I’m currently testing on, and it’s a quad core, and I really don’t care otherwise I wouldn’t be testing cron daemons on it)

I’m also taking the opportunity to use cronie in place of vixie-cron. There’s little documentation for this project, but as far as I can see it’s a drop-in replacement for / fork of vixie-cron from redhat that’s actively maintained.

I did take a quick look at the other cron daemons in the portage tree, but cronie appears to be the only one that’s actively maintained.

/usr/bin/python /usr/share/doc/trac-${TRAC_VER}/contrib/trac-post-commit-hook -p "$TRAC_ENV" -r "$REV"