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.

This is useful to me as I torrent on a remote server and download the files over SFTP/FTPS. Very occasionally something can go awry and I have the desire to hash check the files to see if it was an error with the original or something in my copy that perhaps occurred during transit.

With cfv, I can instead simply store the .torrent file alongside the files and then, when I want to check the files, run “cfv -f foo.torrent“

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"


date -d "1970-01-01 `grep @world /var/log/emerge.log | tail -n 1 | sed -e 's/:.*//'` sec" +"%Y-%m-%d %T %z"

Obviously you may want to modify this slightly (for example, to ignore –pretend), but I hope this will give anyone looking to script this sort of information a good starting point.

For people who use the –ask option, you’ll want to use the following, which filters out occasions where “emerge –ask @world” was run, but the user then cancelled the actual merge (answered with “no”). As you can see I also split out the command which greps the timestamp to use, for easier reading:

TIMESTAMP=`grep @world /var/log/emerge.log -A1 | grep '>>>' | tail -n1 | sed -e 's/:.*//'`
date -d "1970-01-01 ${TIMESTAMP} sec" +"%Y-%m-%d %T %z"


Also note that this version relies on users using the set notation (@world instead of just world) – but once 2.2 is out everyone will be doing that anyway (and I think set notation does work for current stable portage for the built-in sets).

This is a great way to get an idea of what different development teams are currently working on and where they need help.

Direct links to the original thread and project homepages can be found on the above mentioned article. There’s a forum thread at http://forums.gentoo.org/viewtopic-t-763205.html

For those that don’t know, EAPI is basically a specification of features available in the package manager. This allows Gentoo to support multiple package managers (Portage, Paludis, Pkgcore, etc) and still move the packaging format forward in a sensible manner.

It was initially suggested that a given set of packages (the trinary of Portage, Bash and Python seems to be the key, in my experience) and their required dependencies should be held back in terms of EAPI required to install.

At the end of the day, I think Gentoo needs to decide how old a system can get before an upgrade can no longer be officially supported. Currently I reckon you need to upgrade at least @system once a year to be able to upgrade without running into too many major issues. I also suspect that the maximum period that many users, particularly those in business environments, would like to have is longer than this (18 to 24 months).

As a method to determine how old a system can get before it is no longer sanely upgradeable, it was proposed that installs be set up, starting at about 1 year old (2008.0 could be used for this as it’s now almost a year old) and jumping back in set periods (perhaps 3 to 6 months). You then try to upgrade these installs to current stable, noting down the problems you encounter and how to resolve them.

Using the notes generated from the above tests, you can then, I think, set a benchmark for how old a system can be before it can no longer be sanely upgraded. In addition, it would be great if some (possibly (semi) official) documentation could be provided on the best manner to upgrade from each of the tested points (it may well be possible to generalise this documentation).

Once you have this information, you can then determine how old an EAPI needs to be supported and what intermediate versions of essential packages may need to provided. The exact method for then handling old systems can then be worked out. There are several possibilities, which include:

a) Hold back certain packages in terms of EAPI

b) Provide multiple revisions of certain packages at different EAPI levels (exactly how you’d version these was not discussed, but I suspect you could have EAPI 0 (or whatever the oldest “supported” EAPI is) as -r0 and EAPI 2 (or whatever the current EAPI is) as -r1.

Edit: I’ve also posted a poll on the forums to help gauge how long some users need the “supported upgrade” period to be.