2009-06-04

php-imap extension == evil

The Problem

The PHP IMAP extension relies on University of Washington's libc-client IMAP library which appears to be written by kindergarteners. After some review of the source code, UW's IMAP client library appears to have extensive, serious security and stability problems at very fundamental levels.

I'm seeing segfaults (buffer overflows) performing simple operations like fetching attachments. Some attachments work fine but others fail; larger files especially. There are bug reports and CVE entries related to similar issues. However, upgrading to the supposed "fixed" versions of everything does not make any difference for my specific issue. It does fix some other issues related to this. (i.e. the exact same programming errors that appear to affect thousands of lines of code in the UW client.)

The Solution

Use one of the many native IMAP class library. My choice would be Zend_Mail as we use Zend Framework extensively here at work. Zend_Mail supports a number of other mail protocols in addition to IMAP. MIME type support is likely much better than other options. The other logical choice would be Pear Net_IMAP.

Labels: , , ,

- posted by David L Norris @ 18:14 [Permanent link]
2009-03-11

Red Hat Enterprise Linux Cluster Suite 5.2 Relocate Problems

Gist of it all
So, I've been fighting mind bending failover problems on our new compute cluster at work for the past week. I can summarize the solution to service failover problems in one sentence:
Don't use Red Hat's cluster service scripts, evar.

How it actually works
Apache's script (apache.sh) in RHEL 5.2 sends a TERM signal to Apache, waits N seconds (0 by default for Luci/Ricci, 20 for sys-config-cluster) and then proclaims that Apache has failed to shutdown if its still running. This type of failure is fatal for the cluster service.

How it should work
The standard apache init scripts (/etc/rc.d/init.d/httpd) do the right thing, more or less. The parent process is sent the TERM signal, waits 10 seconds and if its still running sends the KILL signal. That may seem harsh but this is a web server for crying out loud. There's no real chance of data corruption if you KILL the web server. If something goes horribly wrong and Apache needs to move to another machine I'm quite happy with Billy Bob having to retype a form or resume his download. That affects only Billy Bob. Bringing down the service for the entire world, in comparison, seems like a very bad solution.

Rant
Red Hat has spent years developing this clustering software. Its fairly good and seems reasonably well written. Its a shame they only spent 5 minutes writing the service scripts. The stock init scripts are infinitely better written but won't work in a clustered environment.

Solution
So, my advice, spend 20 minutes and write your own userscript for each service. If a service is important enough to be on a cluster you can afford to spend the time to write your own script to start and stop it. If you don't know how to write shell scripts and you're managing a cluster then do everyone a favor and seek employment at McDonalds.

Howto
User scripts for the cluster are simply LSB compliant init scripts. I advise you to not waste much time trying trying to hack the /etc/rc.d/init.d scripts to work within the cluster. You can do so but you'll end up stripping out most of it. You may wish to source the /etc/rc.d/init.d/functions file, though. But you will need to pass the pid filename to every single function you call. (Read the functions script to see which options to pass to each function. daemon, killproc, and status functions are most useful for starting, stopping and checking status respectively.)

Labels: , , ,

- posted by David L Norris @ 16:58 [Permanent link]