Maybe you’ve noticed a signature at the end of error pages showing your server name, server version and OS name.
Not Found
The requested URL /notfound was not found on this server.
Apache/2.2.16 (Debian) Server at www.example.com Port 80
There’s also another place where these information are given away: the Server header.
$ wget -q -S http://www.example.com/ 2>&1 | grep Server
Server: Apache/2.2.16 (Debian)
It can be helpful when trying to find on which Apache server an error occurred, but when everything works fine, it can be a good idea to disable the server signature.
It doesn’t really make Apache more secure, but at least it will make it less straightforward for people trying to find servers running a specific OS and Apache version known to be vulnerable.
There are two directives to consider:
- The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents, for example when displaying error pages.
- The ServerTokens directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules. It also controls the information presented by the ServerSignature directive.
Under Debian, we can find those directives in the configuration file named /etc/apache2/conf.d/security:
$ sudoedit /etc/apache2/conf.d/security
Comment ServerTokens OS and add a new line ServerTokens Prod. It should now look like this:
ServerTokens Prod
#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
Comment ServerSignature On and uncomment ServerSignature Off. It should now look like this:
ServerSignature Off
#ServerSignature On
Finally restart Apache:
$ sudo service apache2 restart
Let’s see what is displayed now when we visit a page that doesn’t exist:
Not Found
The requested URL /notfound was not found on this server.
The server name, server version and OS name are no longer shown. And what about the Server header?
$ wget -q -S http://www.example.com/ 2>&1 | grep Server
Server: Apache
The server version and OS name are no longer shown, only the server name is still there.
The Account Manager plugin is a really useful Trac plugin, which offers several features for managing user accounts:
- allow users to register new accounts
- login via an HTML form instead of using HTTP authentication
- allow existing users to change their passwords, even delete their accounts
- send a new password to users who’ve forgotten their password
- administration of user accounts
and much more, but you’re probably already convinced 
So let’s start:
$ sudo aptitude install trac-accountmanager
Now edit the Trac configuration file (mine is located at /var/trac/conf/trac.ini) to add this section:
[account-manager]
password_store = HtDigestStore
password_file = /var/trac/passwd
htdigest_realm = trac
and under the [components] section, add:
trac.web.auth.LoginModule = disabled
acct_mgr.admin.AccountManagerAdminPage = enabled
acct_mgr.htfile.HtDigestStore = enabled
acct_mgr.web_ui.LoginModule = enabled
acct_mgr.web_ui.RegistrationModule = disabled
It replaces the traditional Trac HTTP authentication with a login form, using an htdigest password file, enables the admin page for the account manager plugin, and disables user registration.
We also need to modify the Trac virtual host configuration file (mine is at /etc/apache2/sites-available/trac) to remove the following section:
<Location /login>
AuthType Digest
AuthName "trac"
AuthDigestDomain /
AuthUserFile /var/trac/passwd
Require valid-user
</Location>Now restart Apache:
$ sudo service apache2 restart
Finally visit the Trac administration panel, and in the Plugins section you should see a new entry named TracAccountManager.
Trac is correctly set up, it works fine, but when trying to log in, we get this message:
Trac Error
Authentication information not available. Please refer to the installation documentation.
That’s because Trac uses HTTP authentication, so we need to configure Apache to request authentication when someone clicks on the Login link.
We’ll only see how to set up digest authentication, as it is safer than basic authentication.
We need to create a password file used to store usernames, realm and password for digest authentication of HTTP users.
Let’s create an admin user:
$ sudo htdigest -c /var/trac/passwd trac admin
The -c flag creates a new file, /var/trac/passwd is the location of the password file, and trac is the realm.
Now change the ownership of this file to user www-data and group www-data:
$ sudo chown www-data:www-data /var/trac/passwd
We also need to grant admin rights in Trac to the admin user:
$ sudo trac-admin /var/trac permission add admin TRAC_ADMIN
This user will have a new tab named Admin on the web page, allowing her/him to admin the project.
It’s time for Apache configuration. Edit the Trac virtual host configuration file (mine is at /etc/apache2/sites-available/trac) to add the following:
<Location /login>
AuthType Digest
AuthName "trac"
AuthDigestDomain /
AuthUserFile /var/trac/passwd
Require valid-user
</Location>Make sure that AuthName has the same value as the realm you chose earlier when using htdigest. In this example, it is set to trac.
If you followed the previous post named How to set up Trac with FastCGI and Apache, your configuration file should now look like this:
<VirtualHost *:80>
ServerName trac.example.com
ServerAdmin webmaster@example.com
DocumentRoot /var/www/trac
ErrorLog /var/log/apache2/trac/error.log
CustomLog /var/log/apache2/trac/access.log common
Alias /robots.txt /var/www/trac/robots.txt
Alias /favicon.ico /var/www/trac/favicon.ico
Alias /chrome/common /var/www/trac/chrome/common
ScriptAlias / /var/www/trac/cgi-bin/trac.fcgi/
<Location />
SetHandler fcgid-script
Options ExecCGI
Allow from all
</Location>
<Location /login>
AuthType Digest
AuthName "trac"
AuthDigestDomain /
AuthUserFile /var/trac/passwd
Require valid-user
</Location>
<Location /robots.txt>
SetHandler None
</Location>
<Location /favicon.ico>
SetHandler None
</Location>
<Location /chrome>
SetHandler None
</Location>
</VirtualHost>Enable the Apache modules needed for digest authentication with a password file:
$ sudo a2enmod auth_digest authn_file authz_user
And finally restart Apache:
$ sudo service apache2 restart
If you get this error:
$ sudo service apache2 restart
Syntax error on line 29 of /etc/apache2/sites-enabled/example:
Invalid command 'AuthUserFile', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
failed!
the solution is to enable the mod_authn_file Apache module, and restart Apache:
$ sudo a2enmod authn_file
$ sudo service apache2 restart
This module is required when using the AuthUserFile directive.
If you get this error:
$ sudo service apache2 restart
Syntax error on line 29 of /etc/apache2/sites-enabled/example:
Unknown Authn provider: file
Action 'configtest' failed.
The Apache error log may have more information.
failed!
the solution is to enable the mod_authn_file Apache module, and restart Apache:
$ sudo a2enmod authn_file
$ sudo service apache2 restart
This module is required when using the AuthBasicProvider file (from mod_auth_basic) or AuthDigestProvider file (from mod_auth_digest) directives.
If you get this error:
$ sudo service apache2 restart
Syntax error on line 160 of /etc/apache2/apache2.conf:
Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
failed!
the solution is to enable the mod_authz_host Apache module, and restart Apache:
$ sudo a2enmod authz_host
$ sudo service apache2 restart
This module is required when using the Allow, Deny and Order directives.
You’ve just added digest authentication to your Apache virtual host configuration file, and trying to test if it works, you get:
Authorization Required
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.
You try a few times, just to be sure you entered the password correctly, and still the same error message. Finally, you decide to take a look at the error.log:
[Tue Oct 11 14:29:20 2011] [error] [client *.*.*.*] access to /login failed, reason: require directives present and no Authoritative handler., referer: http://www.example.com/
In fact, the solution is pretty simple:
$ sudo a2enmod authz_user
$ sudo service apache2 restart
Since Apache 2.1, there is a module named mod_authz_user which must be loaded in order to use the Require user or Require valid-user directive.
After installing Trac 0.12, let’s see how to set it up with FastCGI and Apache.
The first thing to do it is to create a Trac Environment. On the disk, it is actually a directory containing the configuration file, the database, plugins,… I’ve chosen /var/trac:
$ sudo trac-admin /var/trac initenv
It will ask for the name of your project, enter what you want. Then it will ask for the database connection string, just press ENTER if you want to use a local SQLite database.
Now change the ownership of this directory to the same user and group Apache runs as:
$ grep -E "APACHE_RUN_(USER|GROUP)" /etc/apache2/envvars
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
$ sudo chown -R www-data:www-data /var/trac
Then we deploy the static resources and scripts, and again change the ownership:
$ sudo trac-admin /var/trac deploy /var/www/trac
$ sudo chown -R www-data:www-data /var/www/trac
It will create two subdirectories in /var/www/trac:
$ ls /var/www/trac
cgi-bin htdocs
The cgi-bin/ directory contains different Python scripts, but we’ll only keep the one concerning FastCGI:
$ sudo rm /var/www/trac/trac.{cgi,wsgi}The trac.fcgi script has not been deployed with the correct permissions:
$ ls -l trac.fcgi
-rw-r--r-- 1 www-data www-data 1585 Oct 6 17:26 trac.fcgi
We have to give Apache execute permission on this file (user www-data and group www-data):
$ sudo chmod ug+x trac.fcgi
I also choose to rename the htdocs/ directory to chrome/ to be consistent with the URL Trac uses to access static resources:
$ sudo mv /var/www/trac/htdocs /var/www/trac/chrome
Now let’s take care of Apache and its configuration!
First, install mod_fcgid (it will be automatically enabled):
$ sudo aptitude install libapache2-mod-fcgid
Then create a configuration file for your Trac virtual host:
$ sudoedit /etc/apache2/sites-available/trac
And this is what it should look like:
<VirtualHost *:80>
ServerName trac.example.com
ServerAdmin webmaster@example.com
DocumentRoot /var/www/trac
ErrorLog /var/log/apache2/trac/error.log
CustomLog /var/log/apache2/trac/access.log common
ScriptAlias / /var/www/trac/cgi-bin/trac.fcgi/
<Location />
SetHandler fcgid-script
Options ExecCGI
Allow from all
</Location>
</VirtualHost>The problem with this configuration is that it is not optimized: Trac will pass static resources such as style sheets or images through itself, instead of letting Apache serve them directly. We’ll fix that:
<VirtualHost *:80>
ServerName trac.example.com
ServerAdmin webmaster@example.com
DocumentRoot /var/www/trac
ErrorLog /var/log/apache2/trac/error.log
CustomLog /var/log/apache2/trac/access.log common
Alias /robots.txt /var/www/trac/robots.txt
Alias /favicon.ico /var/www/trac/favicon.ico
Alias /chrome/common /var/www/trac/chrome/common
ScriptAlias / /var/www/trac/cgi-bin/trac.fcgi/
<Location />
SetHandler fcgid-script
Options ExecCGI
Allow from all
</Location>
<Location /robots.txt>
SetHandler None
</Location>
<Location /favicon.ico>
SetHandler None
</Location>
<Location /chrome>
SetHandler None
</Location>
</VirtualHost>Finally we need to enable this new virtual host:
And restart Apache:
$ sudo service apache2 restart
Adobe has stopped supporting Air for Linux, but the 2.6 package can still be downloaded from their website:
$ wget http://airdownload.adobe.com/air/lin/download/2.6/adobeair.deb
The problem is that this package is for an i386 architecture, so this is what you’ll get when trying to install it on a 64-bit Debian:
$ sudo dpkg -i adobeair.deb
dpkg: error processing adobeair.deb (--install):
package architecture (i386) does not match system (amd64)
Errors were encountered while processing:
adobeair.deb
The solution is quite easy:
$ sudo dpkg -i --force-architecture adobeair.deb
There’s another solution which is longer. It involves extracting the package, changing the architecture from i386 to all in the Debian control file, and then repackaging it:
$ mkdir adobeair
$ dpkg-deb -x adobeair.deb adobeair
$ dpkg-deb --control adobeair.deb adobeair/DEBIAN
$ sed -i "s/i386/all/" adobeair/DEBIAN/control
$ dpkg -b adobeair adobeair_64.deb
$ rm -rf adobeair
$ sudo dpkg -i adobeair_64.deb
We’ve previously seen How to install Trac 0.12 on Debian Squeeze, and then Upgrading from Trac 0.11 to Trac 0.12.
Now, let’s see how to migrate Trac from a single-repository setup to multiple repositories.
My Trac Environment is in /var/trac. Don’t forget to change this path according to your setup.
We need to modify the file named trac.ini (which is in the conf/ directory of your Trac Environment, ie /var/trac/conf/trac.ini in my case).
Now we need to resynchronize the Trac Environment against the source code repositories:
$ sudo trac-admin /var/trac repository resync '*'
Finally restart Apache:
$ sudo service apache2 restart
And point your browser to your Trac installation to check that everything is fine.