More updates

 RedHat released RHEL 6.0 Beta 2 recently, so it was about time to check those updates out.

RedHat released RHEL 6.0 Beta 2 recently, so it was about time to check those updates out. Especially as I hadn't been able to do any coding in the last couple of weeks. Unfortunately I discovered that a straight YUM update to the new release wasn't possible, as they encourage people to do a fresh install from the new ISO to also test the newer installer. However, as I didn't want to throw a perfectly fine build environment away, I simply adjusted my existing build to use the new (different) YUM repository of their Beta 2.

The upgrade went mostly fine, except that my box didn't boot with the new 2.6.32-37 kernel, so I switched back to the previous 2.6.32-19 instead.

The next issue was that PHP had been upgraded from PHP-5.3.1 to PHP-5.3.2, which required a recompilation of sausalito-i18n, but that was no big deal.

In between someone on the BlueOnyx mailing list has pointed out that Hisao had already added suPHP support to BlueQuartz 5200R, so I looked at that code and merged it with our own. It took a while to get it to work, especially as "straight" PHP itself also refused to work for one reason or other on my development box. Eventually that was sorted out as well and I started tweaking the suPHP support to match our needs on BlueOnyx.

The great thing about suPHP is that it solves one of the old permission issues we've always had. Whenever a PHP script created a file, that file was created as user "apache". Which made it then impossible for the siteAdmin to change that file by FTP. suPHP fixes that, as it runs the PHP scripts as the user who owns the script. Therefore files created by a PHP script that runs as user will also be owned by that user.

There are also a couple of security benefits that come with suPHP, as we now can more precisely restrict access of PHP scripts.

The only drawback of the current integration is: The /web folder of a site must be owned by a siteAdmin (and not "nobody" as before), or suPHP will throw a permission error. This still needs to be fixed by extending the GUI in a way that it explains this drawback and that it allows you to choose a siteAdmin who whould own the /web folder.

The way suPHP is implemented now it'll also be possible to (more or less) seamlessly integrate it into 5106R as well. That is due to the fact that you can - in two stages - enable PHP (with the usual "old" behaviour") and - if you like - you can then enable suPHP on top of that as well. So this feature can be released for 5106R without breaking anything, as suPHP will "an extra gimmick" that can be enabled, but which is off by default. 

Furthermore I decided it was time to drop the old "safe_mode" related GUI switches away. PHP-5.3 has deprecated safe_mode anyway. To retain downward compatability of the respective module base-vsite.mod I built in a detection mechanism that allows to utilize the safe_mode related PHP switches on 5016R, while it hides and ignores them on 5107R and 5108R.

One of the next candidates for such a hiding will be "Register Globals", but it stays in for now.

All in all this was a nights worth of coding and debugging with not so much to show, but at least there is some progress.