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.

It would be helpful if you have been on an EdWeb training course, so that you know the basics of how it works. And the golden rule, of "don't alter content as admin".

Overview

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:

Overview

We are not using the OS default version of 5.4 of PHP. We are likely to be running PHP 7.1 via a software collection http://computing.help.inf.ed.ac.uk/scl . So before executing drush commands, switch to a PHP 7.1 bash session with

scl enable rh-php71 bash

1. Backup your code and database
2. Update the distribution modules with
   • cd /disk/data/edweb/sites/default or where your edweb is installed
   • 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.

Detail

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.

• https://www.wiki.ed.ac.uk/display/edweb/Colour+palettes

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.

One semi-regular problem is that a new Drupal Core update comes out between the EdWeb release and you installing it, in which case the "drush up drupal" stage my produce something like:

Update information last refreshed: Mon, 06/01/2020 - 12:23
 Name    Installed Version  Proposed version  Message                   
 Drupal  7.67               7.69              SECURITY UPDATE available 
 Do you really want to continue? (y/n):

While you are testing this out on a dev site, then just say yes. It will probably all work, but back in the drupal web interface, it will warn that 7.69 (in this case) is not supported. At this point I'd fire an email off to website.support@ed and see what they suggest. You'll probably find the site is fine, and you can solve the drupal warning by updating edweb/profiles/uoe_distribution/drupal-org-core.make appropriately, but you could just leave it. See what support say. Depending on the outcome of all that you, may end up having to do the same on the live site when it comes to updating it.

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".

• 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 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.

• 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.
    unset($components['file']);
  }
  

  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.

Creation

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.

Common Problems

Can't log in

Assuming all the cosign stuff is working fine then the user will probably be getting some PHP error. The two likely reasons are:

• the user doesn't have a First.Surname@ed alias - there's some IS auth assumption about this.
  • Solution - Get the user to request an @ed email alias.
• the user has changed UUN, eg sMATRIC to staff UUN, and they have previously accessed HTTPS edweb with their old UUN. This automatically creates an entry in Drupal users table associating UUN to their ed.ac.uk email. When they then try to access HTTPS as their new UUN (with the same @ed alias) it clashes (two users can't have same email) and the error occurs.
  • Solution 1 Change the UUN of the older account to the new UUN. You can do this from within edweb (if you have the power):
    • Goto their page https://web.inf.ed.ac.uk/users/OLDUUN
    • Click edit on the upper right, and then change their Username to NEWUUN (oddly you can't change their email!) and click save
    • That's it. This is the simplest option if they are no longer going to access as OLDUUN.
  • Solution 2 Update the MySQL directly to change the email address of OLDUUN to something else (but valid), eg UUN@infREMOVE_THIS. Then when they next try to login with new UUN, their new account will be created automatically as normal. As this involves directly manipulating the DB, best to take a backup first in case you need to roll back. I wouldn't recommend this route, unless there's some reason both accounts need to exist. The gist of it would be:

    root> drush sql-query "select uid,name,mail from users where mail like '%brown%'"
    5       neilb   Neil.Brown@ed.ccuk
    1328    lmb     L.M.Brown@ed.ccuk
    ...
    root> drush sql-query "update users set mail='neilb@inf.ed.ccuk' where uid = 5"
    

End