Doc tools: Log in
This page lists the changes to the webservers of ULYSSIS in the summer of 2014, and how you can prepare for it. If any of these instructions are not clear to you, or if you have some more questions about the change, don't hesitate to e-mail us at firstname.lastname@example.org.
The exact date will still be announced, but are currently planned for the last weekend of July: there will be a downtime on July 26 and 27 when we upgrade all of our servers. After that, we will use the new webserver configuration.
Our new webservers can be directly accessed at the IP address
188.8.131.52. You can see if your site still works on the new servers by changing your hosts file.
On Windows: if Windows is installed in
C:\Windows (the default), this will be
On Mac OS X:
If your website is at
username.studentenweb.org, then you can test if it works by adding the following line to your hosts file:
184.108.40.206 username.ulyssis.be username.studentenweb.org
Make sure that you remove these changes when you're done testing.
If any issues crop up, you can check the logs at
username is your username) for hints on what went wrong. Don't worry if you don't find your username listed in the directory
/var/log/new_apache_user, it will appear automatically when you enter it. If you found a problem that you can't fix yourself, please do
e-mail us at email@example.com. We'd like the transfer to go smoothly for all of our users.
The most important changes are the following, click on them or scroll down for more info:
If you stuck to best practices when working with PHP, and if you have kept everything up to date, your website will in most cases just work.
If you use a common CMS, like Wordpress or Drupal, this will usually pose no issues. Any changes to files within your home directory (and your www directory) are already automatically updated on all of our servers. Your files are actually located on a single server, and we use NFS on all of our other servers to access it.
Make sure that none of the software you wrote yourself relies on having everything on a single server. This could be the case if you put files in
that you then access from another user session, or such. You are discouraged to put temporary files in
/tmp, and should prefer to put those in a folder
within your home directory.
The logs in
/var/log/apache_user used to be in so-called NCSA combined log format. In the new webserver configuration, we've added two extra fields: a unique id for the request, and the name of the webserver. For example, if you have a log message like:
220.127.116.11 - - [08/Jun/2014:20:23:18 +0200] "GET /sdfds HTTP/1.1" 404 404 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0" U5SqFsCoAI0AAGnQH3MAAAAA bc1
U5SqFsCoAI0AAGnQH3MAAAAA is the unique request id, and
bc1 is the webserver. You can use the unique id to easily find the accompanying log message in the error log. The error log will contain
If you use a log processing tool, make sure that you change its configuration, so that it can handle this change. For AWStats, you can use:
%host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot %other %other
Note that the date and time of log messages may be out of order, because the logs come from different webservers. AWStats can deal with this, but other log processing tools might not.
On the new webservers, the PHP version is 5.5, whereas on the old webserver, this was 5.3.
Notably, magic quotes and register_globals are removed: these features have been deprecated for a long time, and had been disabled by default on our webserver. If you have turned on these features, change your code to not rely on them. If you use an up-to-date CMS or framework, it should already not rely on magic quotes, or register_globals.
If you use an old version of TYPO3, this will stop working, because it explicitly checks for how PHP is provided, but doesn't know about PHP-FPM. Make sure you update to a recent, supported, version.
php_flag instructions in
.htaccess files are normally only available when using
mod_php, but we use the
htscanner module so that these are still supported, so don't worry about those: they shouldn't break.
With PHP-FPM, you can make your PHP code more secure. After the switch you can make the following changes.
PHP code used to be executed using
mod_php, and run as the
www-data user. This will now change: PHP code will run using PHP-FPM and as your ULYSSIS user. This is an opportunity to tighten up your website's security: the user
www-data no longer needs to be able to read
.php files, it only needs to know that these files exist. This means that any PHP files have to be only readable by you. This also means that in order to be able to create files inside of a directory, that directory only has to be writeable by you.
Suppose you have a file called
config.php, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using
chmod 600 config.php. In FileZilla, you can do this by right-clicking on the config file, clicking on "File permissions...", and changing the permissions according to the following screenshots:
Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called
uploads, you can remove write rights for others with
chmod go-w uploads. In FileZilla, you can do this by right-clicking on the config file, clicking on "File permissions...", and changing the permissions according to the following screenshots:
As noted earlier, PHP is now executed as your user instead of
www-data. This also has the effect that by default email sent using the mail() function will come from
firstname.lastname@example.org (where username is your username) instead of
email@example.com. This also means that all bounces caused by emailing to an non-existing or unavailable address will now arrive in your ULYSSIS account.
Notably, the old
Allow directives are removed. However, we use the
mod_access_compat module to continue to provide these directives. You are however encouraged to switch to the new auth directives. Consult the Apache documentation for more information.
To faculty organisations: If your website uses the Centrale KULeuven Login, you will have to add
ShibDisable Off to your
.htaccess file. We have to disable Shibboleth by default, because it inferferes with regular file-based basic authentication.