Ubuntu 13.10 was released yesterday. As well as other package updates, it includes an upgrade from Apache 2.2 to 2.4, which broke a few things on my dev machine.
After the upgrade I was getting the standard « It works! » Apache message on all of my virtual hosts. Running
apache2ctl configtest gave me the familiar warning:
Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1. Set the ‘ServerName’ directive globally to suppress this message
You often get this error in an out-of-the-box Ubuntu setup as you need to tell Apache what hostname to use as the default. I’d previously fixed this by creating a config file at /etc/apache2/conf.d/fqdn that contains only:
so first I had to investigate why this was no longer working. It turned that Apache 2.4 no longer reads configs from conf.d. If you check the end of apache2.conf, you’ll see that it now looks in a folder called conf-enabled instead:
# Include generic snippets of statements IncludeOptional conf-enabled/*.conf
This folder contains symlinked files pointing at conf-available, making the conf setup similar to the approach used for vhosts. So, to fix the error I moved all of my configuration files from conf.d to /etc/apache2/conf-available/, added a .conf file extension to each one, and then ran:
to setup the symlink.
After restarting Apache, the FQDN error was gone, but I was still getting the « It works! » message for all my vhosts. I had another look at the main Apache config and found:
# Include the virtual host configurations: IncludeOptional sites-enabled/*.conf
So by default Apache expects the vhost files to have a .conf file extension (which it didn’t before). Mine just used the hostname as the filename. So I renamed each of these and updated the symlinks that point to them.
After that everything was back to normal.
A full 2.2 to 2.4 upgrade guide is available in case you have any other issues. Of particular note is the change to the syntax for ‘Deny from’ and ‘Require’, so if you start getting « 403 Forbidden » errors on things that previously worked you’ll probably need to update those directives.
Many/all of these issues could be mitigaged by either keeping old configs during the upgrade or by installing the provided compatibility module, but in development I prefer to always install package maintainer’s configs when upgrading so that I know how to fix things if they were to go wrong in production.