...advanced dreams

21 June 2008

Ubuntu-server insight - custom configurations

This is first in the series of posts I'll be doing in next couple of weeks regarding Ubuntu server. With these posts I would like to show you little and, maybe, unknown details which could make your life easier as an Ubuntu system administrator or, if you aren't Ubuntu system administrator, jealous. These posts aren't for new users which don't know how to start with Ubuntu, but for experienced system administrators of other Linux distributions or UNIX operating systems. New users should checkout great server guide - https://help.ubuntu.com/8.04/serverguide/C/index.html.

Most of these posts, if not all, can be applied to Debian and other Debian based distributions, but it's primary target is Ubuntu server platform. So, let's start with a first one.

After installation of services, some customization of configuration is almost always needed. While directly editing /etc/apache2/apache2.conf does work and brings needed results, it can also create problems during update/upgrade of the apache2 package. This is because sometimes default configuration is changed between versions and you end up with diff between new default config and customized config. That's why we have famous '.d' directories:

/etc# find . -name conf.d

In our example, putting custom configuration into the /etc/apache2/conf.d directory results in painless upgrade and fully operational apache after upgrade. Apache2 is also special because of /etc/apache2/sites-enabled|available and /etc/apache2/mods-enabled|available. These directories enable us to create custom web pages in /etc/apache2/sites-available and list all available modules in /etc/apache2/mods-available directory. With a2ensite and a2dissite commands one can easily enable or disable website in Apache2. With a2enmod and a2dismod enable or disable apache modules.

All custom configuration done in conf.d directory overrides settings in the default configuration. Unfortunately, some services can't be handled like this. One very common example is CUPS. This is because CUPS has a web interface which can change configuration and that web interface isn't aware of multiple configuration files. In these case, we are on our own :/.

conf.d directories can contain some default configuration, too. Best example is amavisd-new, which has all of its configuration in /etc/amavis/conf.d. In those cases create a new file and put your configuration in it. In case of amavisd-new, make sure that custom configuration is loaded as a last configuration file. So, if last default configuration file is 50-user, create custom file named 60-my_custom_configuration.

If you follow this rules for configuration, your upgrades from one Ubuntu version to other, with all services up and running after upgrade, will be easy and without any questions.