Local EdWeb distribution - web.inf.ed.ac.uk

We are running a local copy of the EdWeb distribution, which is more or less a copy of the EdWeb (Drupal 7 with IS skinning, config and modules) that hosts the main Uni web site www.ed.ac.uk.

Our copy of the distro is (now, it used to contain local patches) virtually a vanilla install, so we get the benefit of the training resources etc that are available for the central service. The differences are some configuration changes, and a couple of extra modules.

This document gives you an overview of the setup, and the regular tasks that need to be carried out.


web.inf.ed.ac.uk is a fairly modest VM running the EdWeb distro, which basically means apache, mysql (mariadb), php and drupal. The live/edweb-school.h header does most of the work.

There is an equivalent VM at KB that answers as web-dr.inf.ed.ac.uk via the header live/edweb-school-dr.h which rsync's the live site every couple of hours. So if you need to switch, it isn't more than 2 hours out of date. See WebInfEdAcUKDisasterRecovery for more details.

The only regular tasks are:

  1. dealing with updates to the EdWeb distribution
  2. occasionally - moving the service to another machine

1 EdWeb updates

Generally just following the drush instructions on https://dist.drupal.is.ed.ac.uk/project/uoe_distribution (you need to have registered for an account on this site). Those steps being:


  1. Backup your code and database
  2. Update the distribution modules with
    • drush dl uoe_distribution --source=http://dist.drupal.is.ed.ac.uk/release-history
  3. Run database updates
    • drush updatedb
  4. Update core with
    • drush up drupal

Then check a few of our local settings have survived, they should if the features module has worked as expected.


There is a dev/test version of web.inf called webtest.inf.ed.ac.uk. It is best to try out upgrades, changes on there first. It is virtually an exact clone of web.inf, but with a different name (and less diskspace). The script /disk/data/scripts/webtest-clone (which is mastered on the live web.inf, but run on webtest) will take a fresh copy of /disk/data from web.inf onto webtest.inf.

Having taken a fresh clone, I will often change the home page colour scheme to something garish, and change the site title to "TEST SITE" so it is clear you are working with the dev version. Sometimes following links will take you back to the live version, and you want to be aware that you are experimenting with the correct site.

Having got your clone, run through the 3 steps above. They should not generate errors or warnings, however occasionally they do. Contact website.support@ed or ask on cse-drupal-reps@mlist or uws-tech@mlist if others have seen this.

Assuming things seem to have worked, and you have what looks like a working site. Check the following. Note that for some things you'll need to be equivalent of the drupal admin user. See EdWebAdminUser for details, but remember (especially on the live site) DO NOT edit or create content while you have admin privileges.

  • Sego has reported that the various groups of users that have various roles associated with various homepages within web.inf revert to some previous state when edweb is upgraded. There's a scripts/list-homepage-groups script that lists all the homepages and the users and the roles they have. So you can compare before and after the upgrade, they should be the same.

  • WYSIWYG editor toggle. People with the editor group role should be able to toggle the WYSIWYG editor off and on, if they are missing the plain text mode option, then as admin go to https://web(test).inf.ed.ac.uk/admin/config/content/ckeditor/edit/uoe_editor_profile and in the Editor Appearance section check that =Show the disable/enable rich text editor toggle= is set to "Show".

  • We have added a non-standard "InfWed Editor" Organic Group (OG), the idea is that it is the same as the standard EdWeb OG of "editor", but without the create permissions. So people with in this group can edit existing content, but can't create new content. Our feature module is supposed to set this up, but again worth checking. https://web(test).inf.ed.ac.uk/admin/config/group/permissions/node/homepage There should be a "InfWeb Editor" column, compare with "editor" column, but create permissions should be empty.

  • LinkIt is normally only available to users with roles beyond "trained user". We allow them to use the linkit button in the ckeditor. Do this by adding the "trained user" role to https://web(test).inf.ed.ac.uk/admin/config/content/linkit/list/uoe_base_linkit_profile/edit# . From the admin menu: Config -> Content Authoring -> Linkit Profiles -> UoE Base Linkit Profile -> Edit

  • We allow the use of the file upload component of WebForm , normally disabled in default distro. This needs a patch/hack to the code.profiles/uoe_distribution/modules/custom/uoe_webform/uoe_webform.module around about line 380
    function uoe_webform_webform_component_info_alter(&$components) {
      // Remove the file upload component.
    I just comment out the unset line

2. Moving the service to another machine

As it is a VM, if it is moving within the site (currently AT), then the MPU can do this for us, just by migrating it from VM Host to VM Host. However, if it needs to move to another site, and so VM migration can't be done. Then the basic plan is:

  • create a new machine at the new site
  • copy the relavent lcfg from the current web.inf profile
  • stop apache and mysql on both machines
  • rsync /disk/data from current web.inf to what will be new web.inf
  • update DNS to point web.inf at the new machine
  • start mysql and apache on new machine
  • preserve/move /var/lcfg/log/apacheconf.* files if necessary

You can minimise the downtime by doing an rsync of /disk/data ahead of time, but note that includes the live mysql (mariadb) files, so for the final rsync, you want to make sure mysql isn't running when you take the last rsync.

If it is just a temporary move, you could maybe use the webtest clone (see above), or the off site DR copy WebInfEdAcUKDisasterRecovery.

Local Modules

uoe_cosign - Our version of uoe_ease, but more or less a search and replace of "ease" with "cosign" and URLs updated to our weblogin.inf

features -

  • Admin User role (admin_user_role): The role that gives you near admin privileges
  • InfWeb Editor Config (infweb_editor_config): The ckeditor inf_web_editor profile
  • The InfWeb Editor role (infweb_editor_role): The OG Homepage InfWeb Editor role.

As you tweak settings corresponding to the above features and you notice "Overridden" on https://web(test).inf.ed.ac.uk/admin/structure/features . Then you'll probably want to Update (drush features-update) or Recreate (via web) a new version of the feature with those tweaked settings.

If you used Recreate, you'll have to remember to actually install the updated module into the sites/all/modules directory.

TODO: currently my development of these modules is just in my home dir ~/work/projected/edweb-364/modules/. Should probably be in subversion or git somewhere.


To create the initial site empty site. I more or less followed the instructions at https://www.wiki.ed.ac.uk/display/CSEDR/EdWeb+installation+hints though configured to be rooted at /disk/data/edweb, and apacheconf used to configure apache.

Initially I skipped the EASE stages, just so I could be happy I had a vanilla install working.

Then added HTTPS.

Then added the EASE modules, except rather than use uoe_ease I used my uoe_cosign, which is more or less a "search and replace" version, changing the www.ease URLs with weblogin.inf. Which if I can make it more generic/configurable, I should submit to https://dist.drupal.is.ed.ac.uk/project/project_module so others could use it.

With our "admin" user fixes, EdWebAdminUser, you can then go about creating the first homepage, and hand it over to whoever will be the wed admin (content-wise). https://www.wiki.ed.ac.uk/display/edweb/First+configuration+Steps

There's work an updated version of the above wiki page https://www.wiki.ed.ac.uk/display/EdWebDevOps/EdWeb+DevOps

Which also contains guides on separating HTTPS public access from HTTPS editor access, which we really must do some time.

Topic revision: r4 - 24 Oct 2018 - 14:29:28 - NeilBrown
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