Recently WordPress 3.0 has been released so I went ahead and upgraded my WordPress installation to that new version. How hard can it be?

Well, it was super-super-super simple… I’ve never experienced such a painless upgrade for any Web application I ever used. Just click one button, enter the FTP credentials and let WordPress upgrade itself. After upgrading WordPress prompts for a few changes (all written down here) and the whole thing just works. It is as simple as using an Apple product!

So congratulations dear WordPress, for the new, great release and the fact that you take care about your users!

PHP 5.3 has just been released!

I’m especially impressed by the namespaces and the great, JavaScript-like implementation of Closures – no new syntax to learn here. And the developers also show humor regarding the newly implemented goto support…

Overall a great release with long-awaited features and cleanups, let’s hope the providers update their installations quickly!

Read the full release notes.

Logwatch is a very flexible and customizable log watching system for lazy system administrators. It checks the logfiles regularly and sends custom mail reports – very useful and way better than daily manual checking of the logs.

Unfortunately the configuration for MySQL, PHP and the Apache error_log is missing; so let me share the configuration scripts:

Logwatch configuration for PHP
Interestingly there is no logwatch configuration for PHP error_log files – and all a search revealed are some outdated files which don’t work anymore. Here are the adopted files that allow you to get notified about PHP errors:

• logfiles_php.conf – place this file in /etc/logwatch/conf/logfiles/php.conf and adopt the path to the php error_log file (or just use the Apache error_log)
• services_php.conf – place this file in /etc/logwatch/conf/services/php.conf
• scripts_php – place this file in /etc/logwatch/scripts/php and make it executable

Logwatch configuration for MySQL
Also a configuration for MySQL is missing in the default configuration; here are the configuration files:

• logfiles_mysql.conf – place this file in /etc/logwatch/conf/logfiles/mysql.conf and adopt the path to the MySQL logfile
• services_mysql.conf – place this file in /etc/logwatch/conf/services/mysql.conf
• scripts_mysql – place this file in /etc/logwatch/scripts/mysql and make it executable

Logwatch configuration for Apache’s error_log
Now hat really made me wonder is the at the httpd access_log is monitored but the error_log is left out, so no details about errors are included in the logs. This configuration ignores PHP errors and includes all httd errors in the logwatch output:

• logfiles_http-error.conf – place this file in /etc/logwatch/conf/logfiles/http-error.conf and adopt the path to the httpd error_log file accordingly
• services_http-error.conf – place this file in /etc/logwatch/conf/services/http-error.conf
• scripts_http-error – place this file in /etc/logwatch/scripts/http-error and make it executable

To test that the individual scripts work use this command:

/usr/sbin/logwatch –detail high –print –service $SERVICE –range today –debug 0

Replace $SERVICE with either php, mysql or http-error and set debug to 5 if you want to see more (but not too much) debugging information.

All the logwatch configuration scripts for MySQL, PHP and the Apache error_log can be found here.

Update: There was an error in the scripts_mysql file, fixed now.

To have my data secured I run (almost) daily backups using a custom script to my NAS system. Over there, at the great, little Linux box, runs a script that does daily increments using rsnapshot. There is also another script that keeps a copy on an external WebDAV server up-to date.
Implementing this was not that simple – as the NAS itself does not support mounting WebDAV servers natively I had to use a PHP script, which required patching the PEAR WebDav Client (digest auth, block size, stat entries) but eventually I got it working at a reasonable speed (8k block size does not make sense for a HTTP based protocol!). The big benefits – my computers don’t have to run to upload the data, the NAS is doing that work and it is running 24/7 anyway.

End of story, zero maintenance required.

Until I tried to switch from Bingodisk to Apple’s iDisk.

For some reason the backup on the iDisk always included hidden files, despite the fact that they have not been changed and already existed on the disk. Some simple investigation has shown that the iDisk server simply did not return any file that started with a dot (.). But why?
Packet sniffing revealed that there are some differences between the PHP request and the one sent by OS X, but even after modifying the PHP code there were no hidden files included. Last difference – the mysterious X-Source-Id header – but adding that also had no impact. Eventually, after digging in the source code, I figured the change that is needed – as stated on top of the InitUserAgentHeaderValue function:

IMPORTANT: The user-agent header MUST start with the
product token “WebDAVFS” because there are WebDAV servers
that special case this client.

Clear, concise and exactly what I needed to do – as soon as I sent this header iDisk responded with a file listing including hidden files!
I still have no clue why iDisk makes this difference, but it is good to know how to be able to run full backups including hidden files over WebDAV!

The PHP development team would like to announce the immediate availability of PHP 4.4.9. It continues to improve the security and the stability of the 4.4 branch and all users are strongly encouraged to upgrade to it as soon as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last PHP 4.4 release.

Finally. PHP5 is out there since quite some time and finally the old, legacy version is gone. Hopefully all hosting providers out there will upgrade in the next few weeks so all users can start leveraging the new, great features of PHP5. It’s worth it and upgrading is really simple!