Death of a Dictator

I had a long post written up about the execution of Saddam Hussein. I decided at the last minute to not click the “Submit” button. But, my friend Niran wrote up an eloquent post that says it much more clearly.

One thing I’d add is this: I’m truly curious about the proportion of the American population that think Saddam was executed as part of the War on Terror, or to grant democracy in Iraq. His execution had nothing to do with either (no WMDs have ever been found, and execution by a foreign power – even through a fledgling local puppet government – is no way to instill democracy).

Trouble with cron.php in a Drupal multisite configuration

I’m running a couple of servers full of Drupal sites hosted in a multisite configuration (one copy of Drupal used to host dozens of sites, each with their own sites/sitename directory. I’d been using sympal_scripts to automatically run Drupal’s cron.php script for each site in order to keep search indexes up to date and run other routine maintenance functions as expected. It’s easy enough to drop a curl http://server/site/curl.php into a crontab, but as you start adding sites to the server, it becomes unwieldy to maintain a current crontab of sites to cron.

Sympal_scripts attempts to read through the scripts directory, poking through each site and loading Drupal for each one in order to fire off the appropriate cron.php. It’s been adding records to the Drupal watchdog table, so I expected it to be working just fine. Except it hasn’t actually been running cron.php – it’s been failing silently.

Looks like there’s something funky in the way Drupal refers to the $base_url variable for the site. It’s set in each settings.php file, so it should be as simple as returning the content of a string variable. But it’s borking, and returning the name of the directory containing the site’s settings.php file.

Say I’ve got a server, myserver.com, with a bunch of sites all configured to be served as subdirectories of that server’s main website, such as myserver.com/site1 and myserver.com/site2

Each site has a respective directory within the Drupal installation’s sites directory, such as myserver.com.site1 and myserver.com.site2 (the / are converted to . for use in the directory name because / would be invalid in a directory or filename).

When Drupal is initialized by sympal_scripts/cron.php, it’s getting $base_url values of http://myserver.com.site1 and http://myserver.com.site2.

So, when it goes to fire off the cron task, it’s using urls like: http://myserver.com.site1/cron.php

It works fine on sites configured to run on their own domain, as the domain matches the site directory.

WTF? The http:// shows that it’s reading the value within each settings.php file (or does it?), but why is it retaining the .site1 rather than /site1?

Failing that, is there a better way to reliably run cron.php on a bunch of hosted sites? I’m thinking of writing a script that crawls the sites directory and pulls out the $base_url values for each site and then fires off a curl base_url on the lot of them.

It’d be really cool if Drupal’s own cron.php had a command-line version, capable of operating on any (or all) configured sites. Any ideas?

Skype says: Use your nothing, or lose it forever!

Just got a funny automated email from Skype, reminding me to use up my Skype credits before they expire. But I’ve used up my credits long, long ago…

Hi there dlnorman ,

It appears that you haven't used any of your Skype Credit for a while now.
Skype expires inactive credit balances and you have 30 days left to take
action to keep your credit.

Your account details:

Skype Name: dlnorman
Balance: CAD 0.00
Expiry date: 2007-01-29 00:00:00+01

I’ll be sure I use that credit up. Maybe I’ll call nobody, for zero minutes. That should just about do it. Phew!