skip to content

Managed Web Service Help & Support


Configuring Apache

Users of MWS sites are not able to update the main Apache configuration file (/etc/apache2/apache2.conf and files included from it). Apache can however be configured using .htaccess files inside the docroot directory. See Apache's documentation on .htaccess files.


A standard set of core Apache modules are installed and enabled:

  • access_compat_module
  • actions_module
  • alias_module
  • asis_module
  • auth_basic_module
  • authn_core_module
  • authn_file_module
  • authnz_ldap_module
  • authz_core_module
  • authz_groupfile_module
  • authz_host_module
  • authz_user_module
  • autoindex_module
  • cgi_module
  • deflate_module
  • dir_module
  • env_module
  • expires_module
  • filter_module
  • headers_module
  • http_module
  • include_module
  • ldap_module
  • log_config_module
  • logio_module
  • mime_module
  • mpm_prefork_module
  • negotiation_module
  • php5_module (php7 in Debian 9)
  • remoteip_module
  • reqtimeout_module
  • rewrite_module
  • setenvif_module
  • so_module
  • socache_shmcb_module
  • speling_module
  • ssl_module
  • status_module
  • ucam_webauth_module
  • unixd_module
  • version_module
  • watchdog_module
  • wsgi_module


CGI Scripts

Executable scripts in your servers's cgi-bin directory will be executed in response to requests for http://hostname/cgi-bin/script.

To run executable scripts in other parts of docroot, include the following in an appropriate .htaccess file

Options +ExecCGI
AddHandler cgi-script .cgi

List on the AddHandler line the file name suffixes of all your CGI files.

To make a script executable, execute

chmod a+x filename

CGI scripts will be run as the www-data user. The www-data user and all other users of your server are member of the www-data group. This is different from the situation in many commercial hosting environments where CGIs are run as same user as owns the entire web site.

Apache logs

Webserver logs are stored in the log directory of an individual web site. Logs are retained for 14 days. Apache access logs are written in 'combined' log format.

When things go wrong, and especially when Apache sends an error page to a browser, it writes a message to the current error.log file. If you experience a problem with one of your pages then it can be helpful to look in this file.

Restricting access

You can easily use Raven to restrict access to a site or part of a site.

Raven-controlled authentication

If all the people you want to have access have Raven accounts then we recommend using Raven-controlled access.

  • At a minimum, put the following into an .htaccess file in the directory you want to protect.
    AuthType Ucam-WebAuth
    Require valid-user

    (note that AACookieKey is not required as each site has its own which you cannot see so that it does not 'leak'). This will allow anyone who can authenticate to Raven to access the protected area(s).

  • To grant access to a specified list of people who are not registered managers or users, replace

    Require valid-user

    from the first example with a list of people who can authenticate using their CRSid e.g.

    Require user abc1 pqrs99
  • If you want to do 'CUDN or Raven' then try:

    Require all denied
    Allow host
    AuthType Ucam-WebAuth
    Require valid-user

    For further advice see the documentation for the Ucam WebAuth module.

Lookup-based authorisation

Given an identity established by Raven via Ucam-WebAuth (see above) it's possible to configure Apache to control access based on information in lookup via Lookup's LDAP interface. For example the following in an .htaccess file would strict access to members of University Information Services:

AuthType Ucam-WebAuth
AuthLDAPUrl ldap://,o=University%20of%20Cambridge,dc=cam,dc=ac,dc=uk
Require ldap-attribute instID=UIS

 For further information see Mod authnz ldap in the Raven Wiki.

Proxying access

You might want to route requests to a Managed Web Site through some other system. This is called 'proxying' requests. You might want to do this to make a Managed Web Site appear to be part of some other site, or to route requests through an 'external service for additional security.

How you configure your proxy service will vary, and there are several ways to do it. The best strategy for a Managed Web Server is

  1. Add the hostname that people will use to access the content to the site and tick the 'Special Domain name' box. If the name is already associated with the site remove it and re-add it with the 'special' box ticked. This will configure the site to recognise this name but won't register it in the DNS.
  2. Set this name to be the 'Main Hostname' for the site.
  3. Configure your proxy service to pass on requests to the underlying hostname of your MWS Server, e.g. You can find the underlying hostname of your MWS Server on the front page of your control panel, e.g:
  4. Configure the proxy not to rewrite the hostname header in requests that it passes on. This lts the Managed Web Server route requests to the right site. If the proxy does rewrite the hostname header this will probably cause a redirect loop.
  5. Configure the DNS to route requests for the hostname to your proxy service.
  6. Consider restricting access to your Managed Web Site to the IP address used by your proxy service, and possibly one or two other addresses for troubleshooting, to prevent people bypassing your proxy and accessing the site directly.