Skip to content Skip to site navigation

Central Web Servers / AFS Web Hosting Update

On December 13, 2018 between 5 and 6 a.m., University IT will update the operating system running on the central web servers, also known as AFS web hosting. This update includes newer versions of Apache (2.4) and PHP (5.6.37) that might affect websites and web applications hosted in AFS.

Website owners are urged to test their websites to see if they are affected by this update.

Only websites hosted on AFS are affected

The update will only impact websites that are on the central web servers (AFS). If you are not sure your website is hosted on AFS, see the Testing your website section on ways to find out.

What is not affected?

Websites and web applications that are not affected include:

  • Websites hosted in the cloud
  • Stanford Sites (Dedicated Drupal hosting infrastructure)
  • Departmental servers
  • Web Forms built with the Forms Service (aka FormBuilder)

Testing your website

University IT has set up a temporary testing environment that can be used to view your current website using the upgraded servers. How to test depends on the URL of your website.

Testing web.stanford.edu websites using wwwtest.stanford.edu

If your website’s URL start with web.stanford.edu it’s definitely hosted in AFS and you can test it by replacing web with wwwtest in the URL. For example, to test web.stanford.edu/dept/example you would visit wwwtest.stanford.edu/dept/example

Verify that your website works as expected. If it doesn’t, submit a Help ticket.

Testing virtual hosts (e.g. example.stanford.edu)

If your website uses a virtual host, such as example.stanford.edu, and not web.stanford.edu it might still be hosted in AFS. To find out if your website is hosted in AFS:

  1. Visit the Virtual Hosting page (https://tools.stanford.edu/cgi-bin/vhost-request)
  2. Search for your virtual host. In the case of example.stanford.edu, search for the virtual host example (do not enter “.stanford.edu”)
  3. Make a note of the destination (website address)

If your search returns a destination URL that starts with web.stanford.edu (e.g. web.stanford.edu/dept/example), your website is hosted on AFS and you should use the testing procedure below. If the search returns any other URL, or does not return any results, your website is hosted elsewhere and you do not need to test it.

To test your website:

  1. Load your website using its web.stanford.edu URL (e.g. web.stanford.edu/dept/example instead of example.stanford.edu)
  2. If your website doesn’t work as expected with the web.stanford.edu, or it redirects you to your virtual host, it can’t be tested with this method. See the Advanced Testing section for other ways to test or submit a Help ticket.
  3. If the website works as expected using web.stanford.edu and doesn’t redirect you back to your virtual host, replace web with wwwtest in the URL.
  4. Verify that your website works as expected when using wwwtest. If it doesn’t, submit a Help ticket.

Advanced Testing

If you cannot view your website hosted in AFS properly using its web.stanford.edu URL, it can’t be tested by simply replacing web with wwwtest. You’ll need to modify your computer’s configuration to test it properly.

If you are not comfortable with the command line, or making configuration changes to your computer, please submit a Help ticket to ask for assistance in testing your website.

The proper method for testing involves updating your hosts file by adding the following line, replacing example.stanford.edu with the URL of your website.

171.67.215.211 example.stanford.edu

Instructions on how to update your hosts file for different operating systems can be found here:

https://support.rackspace.com/how-to/modify-your-hosts-file/

When you are done testing, make sure to revert your configuration changes.

Known Issues and Solutions

Authentication Changes

One of the issues we have discovered is incompatibility with Apache 2.2 directives that control how authorization modules respond. This includes Apache 2.2 directives such as AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, AuthzUserAuthoritative, and AuthzOwnerAuthoritative. These directives have been replaced by the more expressive RequireAny, RequireNone, and RequireAll.

Apache 2.2

In Apache 2.2, .htaccess files may look something like:

AuthType WebAuth
AuthGroupFile  /afs/ir/group/group-name/WWW/etc/group
AuthzGroupFileAuthoritative Off
 <limit GET POST>
    require privgroup group:name group:name2
    require group users1 users2 users3
    require user user1
</limit>
 

Apache 2.4

In Apache 2.4, .htaccess files with directives from authorization modules need to be updated.

The update is something you can do now, even before the upgrade takes place by wrapping your 2.2 directives with and your 2.4 directives with (note the ! in the 2.2. directives). This is because mod_authz_core is only present in Apache 2.4 and not Apache 2.2 and so the first block of directives won’t conflict with the other.

<IfModule !mod_authz_core.c>
    AuthType WebAuth
    AuthGroupFile  /afs/ir/group/group-name/WWW/etc/group
    AuthzGroupFileAuthoritative Off
    <Limit GET POST>
        require privgroup group:name group:name2
        require group users1 users2 users3
        require user user1
    </Limit>
</IfModule>
 
<IfModule mod_authz_core.c>
AuthType WebAuth
    AuthGroupFile  /afs/ir/group/group-name/WWW/etc/group
    <RequireAll>
        <Limit GET POST >
            <RequireAny>
                require privgroup group:name group:name2
                require group users1 users2 users3
                require user user1
            </RequireAny>
        </Limit >
    </RequireAll>
</IfModule>

Technical Details

The central web servers will be updated to Debian 8.11 (Jessie) with Apache 2.4.10 and PHP 5.6.37-0+deb8u1

More information can be found at the Apache website.

Last modified November 20, 2018