You are here

homepages upgrade

Printer-friendly versionPrinter-friendly version

This document is only for historical interest. The homepages web service has now been upgraded and the temporary homepagessl7.inf service removed.

The web service is long overdue an upgrade to newer hardware and an updated OS (Scientific Linux 7 - the same as DICE desktop machines).

This upgrade is due to happen in less than a week (Tuesday 22nd of August). Various software packages will be updated, but the most notable on this service will be Apache (from 2.2 to 2.4) and PHP (from 5.3 to 5.6). This may mean any .htaccess files you have may need updated, and the way PHP runs will be different.

The new server is already up and running, and answering queries as It is serving the same data as the current service Note that the HTTPS version of is using a University signed certificate, rather than the QuoVadis one, so browsers may give a warning when trying to connect to the HTTPS SL7 version. When the SL7 version becomes the live version of homepages, then it too will have a proper QuoVadis certificate.

When the upgrade happens, will point at the new server. You should NOT publicise/link to the "homepagessl7" URL as it will be removed once the upgrade is complete.

To aid debugging I've created a CGI to show you the most recent apache error log entries containing your username (UUN), hence why you may find yourself redirected to, so you can Cosign.

Note that each service has error logs for HTTP and HTTPS connections, follow the link on the above pages to switch between the two.

Below is a list of some of the main changes and what you can do ahead of time to prepare for the change.

Apache 2.4 changes

Apache provide a fairly comprehensive guide to the diffences bewteen 2.2 and 2.4 - The main differences being to authorisation and access control.

Though the Apache document says you can continue to use (in .htaccess files) the deprecated directives: Order, Allow, Deny and Satisfy; along with the new directives, experience has shown that this is hard to do correctly, so we have disabled that backward compatibility. You must use the new form of access control, or you will get a "500: Internal Server Error" error when you visit a page affected by the old style directives in an .htaccess file.

As both the old (Apache 2.2), homepages, and new (Apache 2.4), homepagessl7, service are using the same .htaccess files, we have provided a way so you can continue to use both the old and new style directives in the same .htaccess file. Without one or the other servers giving an error. For example: to deny all access to a location, you could have an .htaccess file containg these lines for Apache 2.2:

Order deny,allow
Deny from all

This is the new way to achieve the same in Apache 2.4:

Require all denied

However, if you simply update your .htaccess by removing the old directives and replace them with the new directives, then though this will now not give an error on the new server. The old server will give you a "Internal Server Error" message, this isn't likely to be acceptable during the 2 week transition period. So the solution is to have both in your .htaccess file, but use the <IfVersion> directives ( so that only the appropriate bit of configuration is parsed by the corresponding apache server. The above example would become:

<IfVersion < 2.4>
Order deny,allow
Deny from all

<IfVersion >= 2.4>
Require all denied

This will mean that both the old and new server can use the same .htaccess file, and only apply the directives appropriate to them.

Server Parsed Documents

Anyone using the "Includes" feature ( may find that they get errors if using expressions, as they have changed. If you want to continue to use the "legacy expression syntax" then you can turn that back on by using the "SSILegacyExprParser on" directive. Again you'll probably want to put that in an "IfVersion" stanza so it doesn't give an error on the old homepages server:

<IfVersion >= 2.4>
SSILegacyExprParser on


Anyone using Cosign with the minimal directives of:

CosignProtected On
AuthType Cosign
This is no longer enough to actually trigger Cosign protection of the area. You need to have some form of "Require" directive. eg
CosignProtected On
AuthType Cosign

# only let neilb and jsmith in
Require user neilb jsmith 

# let anyone in who can successfully Cosign
Require valid-user


We are no longer using the mod_php module, instead PHP scripts are run as CGIs. So if you use mod_php directives in an .htaccess file, then they will need to be removed for the new server or be conditional on the presence of the module eg:

<IfModule mod_php5.c>
php_flag display_errors on

You could achieve the same result by adding

ini_set("display_errors", "1");
to the PHP script.

As mentioned, PHP scripts are now run like CGIs, so they run as the owner of the PHP file, not as the apache user. This means any PHP scripts have the same local file level access as the owner of the file (but not AFS files, as they do not get the necessary AFS credentials). Because of this, PHP scripts will not be executed if they are somehow modifiable by someone else, eg if they are group or world writeable, or if the directory they are contained within are group or world writeable.

The base PHP on a DICE SL7 machine is 5.4 and the binary is located at /usr/bin/php. On the SL7 homepages service, we are running the 5.6 Software Collection version of php - - which is rooted in /opt/rh/rh-php56/root/, and may not been available on all machines.

Currently there is no "php-imap" module available.

No localhost LDAP server

If you have any CGIs or PHP that queries LDAP on localhost, this will no longer work. You will need to update your code to query instead.


Finally there may be some occasional short breaks in service on the web server, while some last minute changes are made before going live. These should last only a few seconds.

And remember, if you are getting errors, try using either of these URLs (depending on whether the error is on the original homepages or the homepagessl7 service).

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic