Meeting Room Booking System (MRBS)

As a "stop gap" until the central ediary comes along with the features we need/want for room booking, and as it was deemed that Shezhu had limitations that it would not be economical to spend time addressing, we are using the Open Source system MRBS to book rooms and resources for the ITO in Appleton Tower and for the Forum.

The basics are that it runs as http://rbs.inf.ed.ac.uk/ and uses Cosign to authenticate users. A small amount of local tweaking has gone on to use capabilities to restrict access, other than that it is configured via MRBS's config.inc.php file. But see Local Mods below as there have been some other tweaks.

Basic help can be found at: http://rbs.inf.ed.ac.uk/ito/help.php

Note: Previously on a machines called maelcum, danio and now kegan, hence you may see any of the names crop up.

User Management

First you should consider that we actually run multiple RBSes, currently the Forum, Forum visitor rooms, the ITO and the Labs. Each of these is ultimately the responsibility of someone, eg the ITO for the ITO one, Frank Keller and Rob Clark, it is less clear who is ultimately responsible for the Forum systems. Perhaps the events co-ordinator, perhaps the School Office, perhaps admin deputy heads? So before you people are given permissions to make bookings/alter other people's bookings, make sure you have the OK from who ever is responsible.

By default there are two capabilities for each system, and people with those capabilities can make bookings (with the usercap) or manage the system and change other people's bookings (with the admincap). The current capabilities are listed below:

config file user and admin caps
forum/config.inc.php $auth["admincap"][] = "rbs/forum/admin";
forum/config.inc.php $auth["usercap"][] = "rbs/forum/book";
forum-visitors/config.inc.php $auth["admincap"][] = "rbs/forum-visitors/admin";
forum-visitors/config.inc.php $auth["usercap"][] = "rbs/forum-visitors/book";
ito/config.inc.php $auth["admincap"][] = "rbs/ito/admin";
ito/config.inc.php $auth["usercap"][] = "rbs/ito/book";
labs/config.inc.php $auth["admincap"][] = "rbs/labs/admin";
labs/config.inc.php $auth["usercap"][] = "rbs/labs/book";

Some of these capabilities are granted via specific roles, eg forumbooking, forumbooking, forumbookingadmin, ifvisitorbooking, ifvisitorbookingadmin. Where as the 'ito' role has the caps added to it.

Other people have the capabilities/entitlements given to them directly via what ever prometheus tools we are using these days,

To see who has a particular capability you can do netgroup -U rbs/forum/book

Occasionally it may be necessary to edit the above config files by hand to add odd cases, eg iFriends to the labs. The files are under RCS control, and this should probably be done by a member of the services unit.

Service Management

MRBS needs MySQL, Apache and PHP. MySQL is configured via the mysql LCFG component. The idea being that other services on the host (currently danio.inf) could make use of it. The database fles are in /disk/rbs/mysqldata/ and a cron job dumps all the DBs to /disk/rbs/mysqldata.backup/, which is then mirrored.

The apacheconf component manages the apache virtual hosts that we need. Note there are other web services on this machine that also use the component. The rbs.inf config files are in /disk/rbs/apache/, which configures /disk/rbs/rbs/ to be the root of http://rbs.inf.ed.ac.uk/. The https version of the URL enables Cosign. In this apache root there are three instances of the MRBS software (just followed the MBRS INSTALL instructions to copy the web directory to the appropriate place, and then update config.inc.php).

The current instances are ito, forum, forum-visitors, labs and dev. The dev is just for us to trial things before copying to the live instances.

Old Bug

For information only - We were bitten by a bug in the version we were using (1.2.5) when the clocks go forward bookings all go to pot. Alison and Gordon managed to fix things up by manipulating the DB, but we have updated our version to 1.4.2, to avoid this next year (2010).

Example of setting up the SQL

rbs.inf.ed.ac.uk/forum/ is really /disk/rbs/rbs/forum/

Setup initial mysql with mysql component. Follow INSTALL instructions for creating initial tables, ie:

mysqladmin --socket=/disk/rbs/mysqldata/mysql.sock -u root -p create mrbsforum

this (and other mysql commands) will prompt for a root passwd, which is randomly generated by the mysql component and dumped into the rootpwd file. Then

mysql --socket=/disk/rbs/mysqldata/mysql.sock -u root
   -p mrbsforum[see note] < tables.my.sql

NOTE: we intended to run two rbs services from one mysql service. This could be catered for by creating two DBs within mysql or naming the tables differently (MRBS provides a config to prepend the DB tables with a string). Either way, we need to update the config file, buy using different databases, you avoid needing to edit tables.my.sql with the different table names. So we went with the DBs option, so one called mrbsito and the other mrbsforum. Avoided using a - (dash) to avoid odd quoting when specifying the DB. You do need to make sure you specify the correct DB on the command line though.

Need to setup the user and password that you will tell the PHP to access the data with in config.inc.php, in this case mrbsuser and xxx, so do:

mysql --socket=/disk/rbs/mysqldata/mysql.sock -u root -p mrbsforum

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE ON mrbsforum.*
       TO 'mrbsuser'@'localhost' IDENTIFIED BY 'xxx';
Note that the socket needs to be accessibly by the user that httpd runs as. The socket is "world" accessible, but check the parent dir perms. I made it group apache and set g+x.

So a minimal recap of steps involved in creating a new ITO MRBS.

mysqladmin --socket=/disk/rbs/mysqldata/mysql.sock -u root -p create mrbsito

mysql --socket=/disk/rbs/mysqldata/mysql.sock -u root -p mrbsito < /disk/rbs/mrbs-1.4.2/tables.my.sql

mysql --socket=/disk/rbs/mysqldata/mysql.sock -u root -p mrbsito

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE ON mrbsito.*
       TO 'mrbsuser'@'localhost' IDENTIFIED BY 'xxx';

# copy the php files into the web tree
cp -ri /disk/rbs/mrbs-1.4.2/web/* /disk/rbs/rbs/ito

Apache is already configured in /disk/rbs/apache/ to make rbs.inf.ed.ac.uk/ ito cosign protected hence setting REMOTE_USER

Edit /disk/rbs/rbs/ito/config.inc.php appropriately, these are the lines we currently change:

$db_host = "localhost";
$db_database = "mrbs";
$db_login = "mrbs";
$db_password = 'mrbs-password';
$mrbs_admin = "Your Administrator";
$mrbs_admin_email = "admin_email@your.org";
$mrbs_company = "Your Company";
$morningstarts_minutes = 0;
$dateformat = 0;
$auth["session"] = "php"; # How to get and keep the user ID. One of
$auth["type"] = "config"; # How to validate the user/password. One of "none"
$auth["admin"][] = "administrator";     # A user name from the user list. Useful 
                                    #with most other session schemes.
$auth["user"]["administrator"] = "secret";
$auth["user"]["alice"] = "a";
$auth["user"]["bob"] = "b";
define ("MAIL_DOMAIN", '');
define ("SENDMAIL_ARGS", '');

That should be it.

Notes

We could/should spend time packaging this up and perhaps managing the whole thing via a component, but that would have taken time we don't really have, and this is supposed to be a temporary solution. This means to restore the service in case of disaster, we rely on the mirrors and backups of the disk root. This will restore the MySQL data (from the mysql dump data), and any code/configuration changes we've made. Not ideal, but should be OK.

So far the only files tweaked for Cosign and capabilities are: session_remote_user.inc auth_dice.inc

Mass changing owners of bookings, eg when a member of staff leaves

There's no built in way to change all bookings made by user X to user Y. Which is sometimes desirable if person Y isn't powerful enough to manage other people's bookings, but Y has taken over X's job. You can however do it by manipulating the MySQL DB directly. Obviously you should make sure you get the SQL correct, and perhaps take an extra dump of the DB before doing things, so you can roll back, but here's the basics.

  • First you need to identify the DB you want to modify. Each room booking area (Forum, Forum Visitors, AT/Wilkie, etc) has it's own database to you want to make sure you're updating the the correct one. You can do this by checking the value of $db_database in /disk/rbs/rbs/*/config.inc.php
  • Take a backup of the DB (just in case!), eg lcfgmysqldump mrbstest > /tmp/mrbstest.sql (see cos utils area for lcfgmysqldump)
  • As someone who has update privileges to the DB (eg the mysql 'root' user, or the mrbs user - again see the config.inc.php file for the user details), do the following.
  • Update the mrbs_repeat and mrbs_entry tables and update the create_by field for the appropriate bookings to the new user. eg
use mrbstest;
UPDATE mrbs_entry   SET create_by="cms" WHERE create_by="neilb" AND start_time >= UNIX_TIMESTAMP('2016-01-20');
UPDATE mrbs_repeat  SET create_by="cms" WHERE create_by="neilb" AND start_time >= UNIX_TIMESTAMP('2016-01-20');

That will update all bookings on or after 20th Jan 2016 made by "neilb" to instead be made by "cms". You could at first do a little confidence test by just displaying the bookings you'd be about to update with:

SELECT * FROM mrbs_entry WHERE create_by="neilb" AND start_time >= UNIX_TIMESTAMP('2016-01-20');

Local Mods.

session_remote_user.inc Cosign tweak for the login/logout link. Not needed for RBS 1.4.9
auth_dice.inc authorisation using our capabilities
site_faq.html some local doc changes
del_entry.php Notification emails now include the UUN of the person making the change
functions_mail.inc
config.inc.php The main config for the instance, doesn't really count

The audit trail in the MRBS DB isn't very good, when an entry is deleted, it really is deleted, not just marked as gone, so you can't show that there was a booking if someone has come along and deleted it. This is becoming an issue for the forum room booking, so the mail notifications are being used as a record of the transactions. Hence the changes to del_entry.php and functions_mail.inc (though probably only the latter needs to be changed) to include the UUN of the person triggering the change. Currently Marije and Neil B are getting the mails for the forum, and I'm filing them into my staffmail/rbs-notifications folder which I've shared with the rest of the services unit so they can see the messages.

Copying an RBS setup

Occasionally it is useful to try things out on a copy of a live RBS setup, before doing it for real. Creating a copy of an exist RBS is fairly straight forward, but you do have to make sure you do all the steps or you could end up modifying the live data you thought you were copying.

We'll assume that $DATADIR is the root of the partition with the rbs database and web pages. In this example we're making a copy of the "labs" booking system, and calling it "labscopy".

First create the new database.

/usr/bin/mysql -u root -p`cat $DATADIR/mysqldata/rootpwd` --socket=$DATADIR/mysqldata/mysql.sock -e 'create database labscopy'

Then copy the "mrbslabs" data to the "labscopy" database.

/usr/bin/mysqldump -u root -p`cat $DATADIR/mysqldata/rootpwd` --socket=$DATADIR/mysqldata/mysql.sock mrbslabs | /usr/bin/mysql -u root -p`cat $DATADIR/mysqldata/rootpwd` --socket=$DATADIR/mysqldata/mysql.sock labscopy

Then give permission for the "mrbsuser" that the PHP uses to access the "labscopy" database. Replace "xxx" with the actual password, which can be found in the config.inc.php file.

/usr/bin/mysql -u root -p`cat $DATADIR/mysqldata/rootpwd` --socket=$DATADIR/mysqldata/mysql.sock -e "GRANT SELECT,INSERT,UPDATE,DELETE,CREATE ON labscopy.* TO 'mrbsuser'@'localhost' IDENTIFIED BY 'xxx'"

Copy the "labs" web pages to "labscopy":

cp -a $DATADIR/rbs/labs $DATADIR/rbs/labscopy

Finally edit $DATADIR/rbs/labscopy/config.inc.php and update the following variables. This is important, or you will endup modifying the live "labs" data, even though you are using the "labscopy" URL.

From:
$db_database = "mrbslabs";
$url_base = "https://rbs.inf.ed.ac.uk/labs";

To:
$db_database = "labscopy";
$url_base = "https://rbs.inf.ed.ac.uk/labscopy";

You may want to make a couple of (different) innocuous bookings on both the original and the copy to make sure they are using the different databases.

Office365 interaction

As more people move to Office365, they may find that bookings made in RBS are automatically added to their calendar. If this is happening, and they don't want it, then it is a feature of Outlook 365 being "helpful". Their booking (or if they access the inf reception shared mailbox, which gets copies of all bookings) generates an email, and Outlook automatically spots those and adds them to their calendar. To turn this off do:

  • Click the gear icon in the top right corner.
  • Click Calendar under Your app settings.
  • In the left hand menu, click Events from email *(under the Automatic processing section), and select the "Don't add events to my calendar from email" option to disable the feature entirely, or select which events you want added to your calendar from email.
  • Click Save.

-- NeilBrown - 20 Jan 2008

Topic attachments
I Attachment Action Size Date Who Comment
elseinc auth_dice.inc manage 4.2 K 14 May 2013 - 11:32 NeilBrown Implements our $auth["type"] = "dice" in RBS
Topic revision: r10 - 03 Dec 2018 - 09:39:11 - 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