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:
- dealing with updates to the EdWeb distribution
- occasionally - moving the service to another machine
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
- Backup your code and database
- 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
- Run database updates
- Update core with
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.
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.
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