Mr N

Just upgraded the server software from Plesk 8.2 to Plesk 8.3. The upgrade installed over a new version of Horde which over wrote all my changes made in Training SpamAssassin, Horde, IMAP, Plesk user configuration, so I just added them back in. Reminder to self, I must tell the Horde team about the changes, so I don’t have to keep changing it on each update! After the upgrade, the installer stopped SpamAssassin and the POP3 service, so I had to start them by hand. As a Unix bod I loath having to reboot a machine after an upgrade, but felt that in this case (because 2 of the services weren’t quite right) I’d better bounce the machine just to make sure it came up properly before the little darlings get to work on Monday and find that everything has stopped working! Some time later, I discovered that the awstat program which calculates the web logs has a problem. It analyses the log every day, building up a picture of what has been going on. The problem is that you can no longer compare previous month’s results. The Monthly History section spans a year but only shows the current month’s information. I am working on a solution which, I’ll blog when I work out what it is!

When moving from Ensim to Plesk I noticed that all my PHP programs stopped working. Every relative pathed file I had added to a require() statement error'ed with the message:

open_basedir restriction in effect

I added the current directory ('.') to PHP's include_path but it didn't make any difference. After an awful lot of trial and error I worked out that the include_path was being ignored and the open_basedir was being used instead. This is different from the PHP documentation.

The PHP configuration has this whole idea of **Local Value** and **Master Value** and unfortunately they do not inherit. If the **Local Value** is specified and it does not include any of the **Master Value**'s then those **Master Value**s will not be counted (and vice-versa). Bummer, because Plesk specifies the open_basedir in the configuration specific file for each domain. Double bummer because every time you change a configuration option for your domain Plesk overwrites these configuration files, so it means that any changes that you make in there will be lost.

Luckily, Plesk have built in some protection to allow users of virtual hosts to use site specific options for PHP and/or Apache.

Apache's domain specific configuration file for your domain is located in:

/var/www/vhosts/your.domain/conf/httpd.include

It contains a line to include another virtual host's specific file. In here we can add the voodoo to take away our require / open_basedir problem by including the current directory in the search path.

Go to the conf directory and create a file called vhost.conf. Use your favourite editor (and if that is not vi or notepad2, you ought to be ashamed of yourself!) to add the following contents:

  
    php_admin_flag engine on
    php_admin_flag safe_mode on
    php_admin_value open_basedir "/var/www/vhosts/example.com/httpdocs:.:/php:/tmp"
  
  
    php_admin_flag engine on
    php_admin_flag safe_mode on
    php_admin_value open_basedir "/var/www/vhosts/example.com/httpdocs:.:/php:/tmp"
  

The new open_basedir contains:

1. /var/www/vhosts/your.domain/httpdocs and /tmp because they where in the **Master Value**.
2. . for the current directory which solves my relative path problems.
3. /php because it contains all the PHP functions which are common to more than one domain. There is another problem with Plesk, **Safe Mode**, shared include path directories and user permissions, but that's a blog for another time! If anyone asks nicely then, I'll write it up.

After making the changes restart the web server, and all should be well.

The documentation of require on the PHP website is incorrect with regards to require()'s behaviour. It says require() is just like include(), but it isn't. include() takes the include path from the PHP variable include_path, but require() does not. It takes it from the open_basedir variable.

I bought one of those Ubuntu PC's that Dell are selling. It is the only PC Dell sell where you don't have to pay Micro$oft tax. Ubuntu is fine for a desktop but this was going to be a server. So popped on Fedora Core 8.

I added another bigger hard drive and noticed that there are only 2 drive bays and 2 5 1/4" drive bays which is ok for a desktop but not great if you want to load it with massive hard drives!

I booted the PC and it went straight into booting the Ubuntu. It did not even notice that there was a bootable DVD in the drive. So restarted the PC and went into the BIOS. Not bad - the BIOS lets you just boot from a different device without having to set it to permanently check the optical drives.

Graphical menu popped up and I selected the Install Fedora Core 8. It started loading drivers. The second driver I tried to load hung the machine. It sticks on "loading ata_piix driver...". Took a while to find a reference to the problem but it looks like it has been happending since Fedora Core 4! Here is the snippet from the Fedora Forum:

Some older motherboards tend to opt for the cheap way of piggy backing the sata/ide ICH6 channels on the same channel as the IDE/SCSI channels. When the ata_piix module tries to read the storage on these channels it throws a wobbly.

Try changing your sata ports to the last 2 on the motherboard, usually sata port 4 or 5 / 6 or 7. These two are usually the only 2 that are dedicated ICH6 ports.

Motherboards that are affected are ASUS running JMicron and others with the same chipsets.

Changed the SATA connections on the motherboard from 1 & 2 (for HDD 1 & 2) and 3 (for DVD) to DVD on 2 and the HDD's on 4 & 5. Rebooted again. Hurray that huddle was over.

After that most things seemed to work ok.

White is such a strong colour to spend all day staring at. The default background for a Window's desktop is system white. Almost all applications use the system background for their background - I suppose that's what it's for! I prefer a softer colour for mine. So, if you think white is too harsh then try this soft blue: R:196 G:234 B:253 - and see how much more relaxing the screen can be.

KDE and Gnome have it right they start with a couple of soft pastel colours.

If you read a lot of Java API documentation then you will see that the page is actually coloured white so changing the system backdrop won't change it. I prefer a soft green for my bed time reading. You can change the colour my editing the documentation style sheet.

The style sheet is located in: DocRoot/api/stylesheet.css

Edit the file to change the colours from white in the body to slightly dark green:

body { background-color: #668866 }

Edit the file to change the colours from white in the body to slightly lighter green:

TableRowColor { background: #779977 }

And then sit back to enjoy a more pleasant user experience.