Support page for Secure AFS web server

It is now possible to publish AFS-based web pages that have a greater degree of protection than the mechanism currently employed on groups.inf or homepages.inf.

The new server, sweb.inf (aka arachne.inf), provides AFS space that is accessible anywhere (as is normal with AFS) and is editable by the user (also as normal), but the web (browser) access via Apache is constrained to a separate, user-specific ID (not the generic <apache> ID as is normal on other web servers). This access ID is not usually visible to, or used by, the user (although accessible to them if required).

This page describes how to create and properly configure this filespace. It is hoped that some or all of this process will be automated at some point, but that hasn't happened yet. It is assumed that uptake of this service will be limited (on request), although time will tell.

Note that, following various current usages, the AFS volume name has "sweb" as a prefix (for example, sweb.fred), but the AFS ID (for use in ACLs, etc) has "sweb" as a suffix (for example, fred.sweb).

Requests for this filespace should come via an RT ticket.

Create user-specific AFS ID (for apache access) and generate keytab

This section can be done on any machine.

  • allocate the user an sweb ID (see
    The ID should be of the form <username>.sweb (to conform with other user-based AFS ID names), although the AFS volume name is the other way around, namely sweb.<username> (also to conform with current usage).

  • create the user ID (this command is run as an AFS admin user, and uses the same "-name" string and "-id" number as in the AFS ID allocated above, ):
    pts createuser -name <username>.sweb -id <sweb-id>

    For example:
    pts createuser -name fred.sweb -id 12345

    creates the new AFS ID, and returns:
    "User fred.sweb has id 12345"

  • create sweb principal
    (this will include the automatic setting of a random password for that principal).
    Note that the kadmin command below (which will prompt for your admin password) starts the command-line interface, giving you the "kadmin: " prompt, after which you type the rest of the command(s).
    To quit the CLI, just type ^D.

    addprinc -randkey <username>/sweb

    For example:
    addprinc -randkey fred/sweb

    Note that the warning message:
    NOTICE: no policy specified for <username>/sweb@INF.ED.AC.UK; assigning "default"
    is to be expected, and is not an error.

  • generate keytab for sweb principal:

    kadmin (if not already running the CLI)
    ktadd -k /tmp/<username>-sweb.keytab <username>/sweb

Configure Apache

This section should be done on the sweb server (currently arachne.inf).

  • copy keytab file, /tmp/<username>-sweb.keytab, (from whichever machine the command was run on) to /etc/httpd/conf/<username>-sweb.keytab on the server.
    For example, if the keytab file for user "fred" is generated on host "desktop", then something like the following should work:

    arachne% scp desktop:/tmp/fred-sweb.keytab /tmp
    fred-sweb.keytab 100% 126 0.1KB/s 00:00

    ...and as root:

    arachne# mv /tmp/fred-sweb.keytab /etc/httpd/conf/
    arachne# chown apache /etc/httpd/conf/fred-sweb.keytab
    It's important you follow the naming convention and location of the keytab, or the macro in the next step won't find the files.

  • edit the header live/sweb-server.h, and use the SWEB_USER() macro to add the necessary apache config to the web server eg
    Commit your change and make sure the new profile builds and makes it to the sweb server.

If everything works, you should see the WaklogLocationPrincipal entry appear in the file /etc/httpd/lcfg.sites.d/sweb443.conf on the web server. (If it doesn't appear, for whatever reason, check with Services Unit).

Create & mount volume (including RO and backup)

The volume should be created with the user's username and " sweb. " prefix (for example, sweb.fred), otherwise this is a standard procedure (see, but replace "group." with "sweb.")

Once created, mounting it is a standard procedure (see above URL), but the mount point should be /afs/<username>.

If a specific amount of disk space has been requested, set the quota appropriately. If no diskspace has been requested, the default of 5Mb will apply (although it can always be increased later).

Configure ACLs

The new volume (path) should be writeable by the user, and readable by the equivalent sweb user and the web server. To avoid server-specific references (which might change) there is a dedicated group, system:securewebserver, that is used instead of an explicit host principal:

fs sa /afs/<username> <username> all
fs sa /afs/<username> <username>.sweb read
fs sa /afs/<username> system:securewebserver read

...which, for user "fred", should give something like:

Access list for /afs/ is
Normal rights:
system:administrators rlidwka
fred rlidwka
system:securewebserver rl
fred.sweb rl

The above will have created filespace /afs/, with the corresponding URL Note that the "~" form of the username in the URL is used to configure CGI script execution on a per-user basis (by invoking suEXEC). However, the tilde can be omitted if required (the suEXEC trigger will be inserted by Apache, as will the implict "=web=/" path element).

You will also need to create two sub-directories for the user, web and data, making sure the ownership permissions are the same as for the user-level directory. Static pages and scripts will go into the "web" directory, and any temporary script files or other files that do not need to be available via the web should go in the "data" directory:

mkdir /afs/
mkdir /afs/

If the permissions for the containing (sweb home) directory are correct, then they will be inherited by the web & data directories. Using "fs la" for the relevant directories should give something like:

Access list for /afs/ is
Normal rights:
system:administrators rlidwka
system:securewebserver rl
fred.sweb rl
fred rlidwka

Access list for /afs/ is
Normal rights:
system:administrators rlidwka
system:securewebserver rl
fred.sweb rl
fred rlidwka

Testing and Debugging

Should you wish to test the new filespace, simply copy (using your /admin principal) a test file into it, and browse to the appropriate URL. A test file, /afs/ (, may be available.

By default, URLs for exectuable scripts should contain "~" (tilde) as part of the username string - this is needed to work out the UID to use when running CGI scripts. However, as already mentioned, the tilde (required by suEXEC) will be inserted behind the scenes, and so need not be present (although it will work as normal if it is).

The following URL forms should all work:


If users want a separate cgi-bin sub-directory for scripts, this will also work.

Note also that the mechanism that runs the script as the script-owner (suexec) requires certain conditions to be satisfied before it will allow the script to run, so if there are run-time problems, make sure that these conditions are satisfied. They include:

  • the directory must not be writable by anyone else
  • the target CGI/SSI program must not be writable by anyone else
  • the target CGI/SSI program must not be setuid or setgid
  • the file must be owned by the username extracted from the invoking URL

(for full details, see the Apache documentation at

Disaster Recovery

A new VM can be recreated with:

kvmtool create --name <NAME> --host <VMHOST> --flavour=<OS> --disksize 15 --pool <POOL> --memory=2048

...where, for the current instance:

  • NAME = arachne
  • VMHOST = oyster
  • POOL = oysterpool1
  • OS = sl6_64

(it might also be worth checking that disksize and memory are sufficient for current usage).

- also make sure the correct (local) version of suexec is installed (currently httpd-2.2.15-47.sl6.1.sweb.inf.x86_64)

Note that, if the sweb server (a VM) is damaged or otherwise rendered inoperative, its profile should still exist and will contain most of the configuration information.

...currently, the profile defines:

  1. AFS cache & root partition sizes
  2. X509 certificate configurations (for "sweb" & "arachne")

...and uses resources to create or update:

  1. Apache config (httpd.conf)
  2. /etc/httpd/conf.d/waklogusertokens.conf
  3. /etc/httpd/conf.d/cgibin.conf

If not resurrecting arachne.inf, then a new AFS host principal and AFS Admin UID are needed for the new service host. Finally, create symlink /home to /afs/

TODO None of this covers restoring unique data on the server. The machine is not mirrored or backed up. That unique data is the user keytabs copied into /etc/httpd/conf/, that data can be regenerated from the ktadd -k step above and then copied back to the recovered machine.

-- RogerBurroughes - 17 Dec 2015

Topic revision: r29 - 09 Jul 2020 - 11:09:23 - NeilBrown
DICE.ServicesUnitSecureWebAFSSupportDocs moved from DICE.ServicesUnitSecureWebAFS on 02 Dec 2014 - 15:13 by RogerBurroughes - put it back
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies