MRBS Installation Instructions
REQUIREMENTS
---------------------------------------------------------------------------
MRBS works with both MySQL (Version 5.5.3 and above, though MySQL Version
5.7.5 and above or MariaDB Version 10.0.2 and above are recommended) and
PostgreSQL (Version 8.2 and above) systems. [The reason that if you are using
MySQL you are recommended to use MySQL Version 5.7.5 and above or MariaDB
Version 10.0.2 and above is that these versions support multiple locks and thus
enable MRBS to use a custom database session handler. This is more secure than
the standard file based session handler, easier to configure and enables MRBS
to be used on clustered web servers.]
You must have at least PHP 7.2, with support for your chosen database system
installed and working for this application. See the PHP (www.php.net), MySQL
(www.mysql.com), and PostgreSQL (www.postgresql.org) sites for more info on
setting these up. You need to know how to install, secure, run, maintain,
and back up your chosen database system.
MRBS also requires that 'iconv' PHP extension, to provide
internationalisation.
You can run PHP either as a CGI or with a direct module interface (also called
SAPI). These servers include Apache, Microsoft Internet Information Server,
Netscape and iPlanet servers. Many other servers have support for ISAPI, the
Microsoft module interface.
You'll get better performance with PHP setup as a module. Not only will you
not have to deal with the CGI performance hit, but you'll be able to use PHP's
database connection pooling. However, be careful that you don't exceed
the maximum number of connections allowed to your database; with connection
pooling PHP/Apache can potentially create a connection from each Apache
child server to the database.
Also many MRBS authentication schemes use basic HTTP authentication. These
don't work if you run PHP as a CGI.
If you are using PHP as an Apache module, you probably want to ensure that
the Apache MaxRequestsPerChild is not set to 0, in case of undetected memory
leaks in PHP or MRBS.
OVERVIEW
---------------------------------------------------------------------------
The steps involved in installing MRBS are:
1. Installing the MRBS files on your web server
2. Creating the MRBS tables in your database
3. Configuring MRBS
After that you can then point your browser at MRBS and start creating areas
and rooms.
INSTALLING THE MRBS FILES
---------------------------------------------------------------------------
To install MRBS, just unpack the distribution into a temporary directory,
then copy the files in the "web" subdirectory into a new directory somewhere
your web server can find them.
If you are using a remote webserver, unpack the files into a temporary
directory on your local machine and then upload them to suitable directory
on your webserver, for example mydomain.com/mrbs
If you are using a Unix/Linux webserver to which you have access, then
an example of the installation might be:
Unpack the software into a new temporary directory, something like this:
$ tar -xvzf ~/download/mrbs-1.7.1.tgz (or whatever version)
$ cd mrbs-1.7.1 (or whatever version)
MRBS comes with a sample configuration file "web/config.inc.php-sample" -
this should be copied to "web/config.inc.php" and configured for your
site. The minimum you generally need to configure are the timezone
(unless your PHP configuration already defines the timezone) and the
database access details.
If you are upgrading from a previous version of MRBS, you should consider
copying your changes to the "config.inc.php" file into a new copy
of config.inc.php copied from the new MRBS version's config.inc.php-sample.
Now install MRBS by copying the contents of the "web" subdirectory of the
distribution somewhere your web server can find it. For example:
$ cp -r web /var/lib/apache/htdocs/mrbs
CREATING THE MRBS TABLES IN YOUR DATABASE
---------------------------------------------------------------------------
For a new install:
If you are using a remote webserver you should use your database
administration program (eg phpMyAdmin in your control panel) to create the
MRBS tables, by executing the contents of tables.my.sql. For example, if
you are using phpMyAdmin copy the contents of tables.my.sql into the SQL
tab of phpMyAdmin and execute it as an SQL query. This assumes that you
have already created a database - if not you should create a database
first.
If you are using a Unix/Linux webserver to which you have access, then the
procedure might be:
[MySQL] $ mysqladmin create mrbs
[PostgreSQL] $ createdb -E UTF8 -T template0 mrbs
(This will create a database named "mrbs", but you can use any name.)
Create the MRBS tables using the supplied tables.*.sql file:
[MySQL] $ mysql mrbs < tables.my.sql
[PostgreSQL] $ psql -a -f tables.pg.sql mrbs
where "mrbs" is the name of your database (mentioned above).
This will create all the needed tables.
You may need to set rights on the tables; for PostgreSQL see "grant.pg.sql".
If you need to delete the tables, for PostgreSQL see "destroy.pg.sql".
The tables are now empty and ready for use.
For an upgrade:
If you are upgrading from MRBS 1.2-pre3 or later, your database will be
upgraded automatically if necessary when you first run MRBS. You will
be prompted for a database (not MRBS) username and password with rights
to create and alter tables. Otherwise, please see the UPGRADE file.
For a second installation or to use different table names:
If you have table name conflicts or want to do a second installation
and only have access to one database, then you can modify the 'mrbs_'
prefix for the table names.
In tables.*.sql you will need to change the table names and then follow
the instructions above for creating the tables in your database.
When editing config.inc.php, you need to change the table name prefix
from "mrbs_" to the value you chose using the variable $db_tbl_prefix.
WARNING: All of the .sql files are set up to use the 'mrbs_' prefix
therefore you will have to edit them before you use them if you
change the prefix for your tables.
Maintenance:
Be sure to back up your database regularly.
For PostgreSQL, be sure to run the "vacuum" command regularly.
You can clean out old entries from your database using the supplied SQL
scripts purge.my.sql (for MySQL) and purge.pg.sql (for PostgreSQL). Read
the comments at the top of the scripts before using them.
ADDING EXTRA COLUMNS TO THE DATABASE TABLES
---------------------------------------------------------------------------
It is possible to add extra columns to the entry, repeat, room and users
tables, if you need to hold extra information about bookings, rooms and users.
For example you might want to add a column in the room table to record whether
or not a room has a coffee machine and you might want to record the phone
numbers of users. (Note that the users table is only used if you are using
the 'db' authentication scheme). Similarly you might want to add a field
to the entry and repeat tables to record the number of participants for
a meeting.
To add extra columns, just go into your database administration tool, eg
phpMyAdmin, and add the extra columns manually. MRBS will then recognise them
and handle them automatically, displaying the information in the lists of rooms
and users and allowing you to edit the data in the appropriate forms.
NOTES:
(1) if you are adding a field to the entry table you must add an
identical field to the repeat table. If you do not MRBS will fail with
a fatal error when you try and run it.
(2) names must consist of letters, numbers or underscores. If you are
using PostgreSQL then the name must begin with a letter or an underscore.
If you are using MySQL then there is no restriction on the first character
as long as it is in the permitted set, ie a letter, number or underscore.
(Although MySQL will allow other characters in column names, MRBS imposes
restrictions on the characters allowed in order to simplify the code. For
a technical explanation see below).
At the moment only text, varchar, date, decimal/numeric, int, smallint and
tinyint columns are supported, displayed as textarea, text, date, number
or checkbox fields as appropriate. Whether a varchar is displayed as a text
or textarea input depends on its maximum length, with the breakpoint
determined by a configuration variable. Ints are treated as integer types, as
you would expect. However smallints and tinyints are assumed to be booleans
and are displayed as checkboxes.
[Note: smallints are assumed to be booleans because the boolean type in
PostgreSQL presents some problems in PHP when trying to process the results
of a query in a database independent way, so it is more convenient to use a
smallint instead of a boolean in PostgreSQL.]
Text descriptions are set in the config file using the $vocab_override variable
using the appropriate language(s) and with the tag room.column_name,
eg room.coffee_machine, or users.phone enabling translations to be provided.
If not present, the column name will be used for labels etc. If you are adding
columns to the entry and repeat tables then you only need to add the
entry.column_name tags: you don't need to add a repeat.column_name tag.
As an example, to add a field to the room table recording whether or not
there is a coffee machine you would, in MySQL, add the column
coffee_machine tinyint
to the room table and add the line
$vocab_override['en']['room.coffee_machine'] = "Coffee machine";
to the config file and similarly for other languages as required. MRBS
should then do the rest and display your coffee machine field on the room
pages.
Extra options for custom fields:
1)
You can create dropdown boxes for a custom field by defining an
entry in the configuration array $select_options. For example:
$select_options['entry.conference_facilities'] = array('Video',
'Telephone',
'None');
would define the 'conference_facilities' custom field to have three
possible values.
For custom fields only (will be extended later) it is also possible to use
an associative array for $select_options, for example
$select_options['entry.catering'] = array('c' => 'Coffee',
's' => 'Sandwiches',
'h' => 'Hot Lunch');
In this case the key (eg 'c') is stored in the database, but the value
(eg 'Coffee') is displayed and can be searched for using Search and Report.
This allows you to alter the displayed values, for example changing 'Coffee'
to 'Coffee, Tea and Biscuits', without having to alter the database. It can also
be useful if the database table is being shared with another application.
MRBS will auto-detect whether the array is associative.
2)
You can specify that a field is mandatory. This will ensure that the
user specifies a value for a field that may be empty, like a text box
or a selection, as in 1) above. For example:
$is_mandatory_field['entry.conference_facilities'] = true;
would define the 'conference_facilities' custom field to be mandatory.
In the case of a select field, this adds an empty value to the dropdown
list.
Making a checkbox field mandatory is possible and requires the
checkbox to be ticked before the form can be submitted. This can be
useful for example for requiring users to accept terms of service or
terms and conditions.
3)
You can also specify that a field is private, ensuring that the contents
are only visible to yourself and the administrators. For example:
$is_private_field['entry.refreshments'] = true;
$is_private_field['users.tel'] = true;
would prevent the details of your refreshments being visible to other
users - provided that private bookings are enabled. See the section
on private bookings in systemdefaults.inc.php for more information.
Note that private fields are only supported in the entry and users tables.
4)
You can also enter regular expressions for validating text field input using
the pattern attribute. At the moment this is limited to custom fields in the
users table. For example the following could be used to ensure a valid US ZIP
code (you might want to have a better regex - this is just for illustration):
$pattern['users.zip_code'] = "^[0-9]{5}(?:-[0-9]{4})?$";
You would probably also want to enter a custom error message by using
$vocab_override, with the tag consisting of "table.field.oninvalid" eg
$vocab_override['users.zip_code.oninvalid']['en'] = "Please enter a valid " .
"ZIP code, eg '12345' or '12345-6789'";
Technical explanation of the restriction on column names for custom fields
--------------------------------------------------------------------------
// Column names for custom fields are used by MRBS in a number of ways:
// - as the column name in the database
// - as part of an HTML name attribute for a form input
// - as part of a PHP variable name
//
// MySQL, PostgreSQL, HTML and PHP all have different rules for these tokens:
// - MySQL: almost anything is allowed except that:
// - "No identifier can contain ASCII NUL (0x00) or a byte with a value
// of 255."
// - "Database, table, and column names should not end with space
// characters."
// (http://dev.mysql.com/doc/refman/5.0/en/identifiers.html)
//
// - PostgreSQL: "SQL identifiers and key words must begin with a letter (a-z,
// but also letters with diacritical marks and non-Latin letters) or an
// underscore (_). Subsequent characters in an identifier or key word can
// be letters, underscores, digits (0-9), or dollar signs ($). Note that
// dollar signs are not allowed in identifiers according to the letter of the
// SQL standard, so their use may render applications less portable. The SQL
// standard will not define a key word that contains digits or starts or ends
// with an underscore, so identifiers of this form are safe against possible
// conflict with future extensions of the standard."
// (http://www.postgresql.org/docs/8.1/interactive/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS)
//
// - PHP: "Variable names follow the same rules as other labels in PHP. A
// valid variable name starts with a letter or underscore, followed by any
// number of letters, numbers, or underscores. As a regular expression, it
// would be expressed thus: '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*' "
// (http://php.net/manual/en/language.variables.basics.php)
//
// - HTML: "ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
// followed by any number of letters, digits ([0-9]), hyphens ("-"),
// underscores ("_"), colons (":"), and periods (".")."
// (http://www.w3.org/TR/html401/types.html#type-cdata)
//
// In order to avoid complications with using names in each of these contexts,
// we restrict custom field names to the set of names which conforms to all
// four rules, taking into account the fact that when MRBS uses column names
// in PHP and HTML it always prefixes them with a string beginning with a letter.
// This gives us the rule that custom field names must consist of letters,
// numbers or underscores.
CONFIGURING MRBS
---------------------------------------------------------------------------
Next, you will need to create and customize the file "config.inc.php"...
First of all copy the file config.inc.php-sample to config.inc.php. Then you
need to edit the settings in that file and add other settings as required.
As a minimum you will need to set the timezone and the database variables.
Other settings can be changed by copying lines from systemdefaults.inc.php and
areadefaults.inc.php and pasting them into config.inc.php. Do not edit
systemdefaults.inc.php or areadefaults.inc.php as it will make it harder for
you to upgrade when new versions are released.
Note that there are two different defaults files (systemdefaults.inc.php and
areadefaults.inc.php) to draw attention to the fact that the settings in
areadefaults just determine the settings for NEW areas. Settings for existing
areas are set using a web browser by following the "Rooms" link in MRBS. (It
can be a little frustrating editing the area settings to find that they have no
effect on existing areas!)
1. Timezone
You must set the timezone to a valid value, a list of which can be found at
http://php.net/manual/timezones.php. Don't forget to uncomment the line
by removing the '//' at the beginning. Note that the timezone to use is the
timezone in which your meeting rooms are located, not the timezone of your
server in case they are different.
However, if you already have bookings in your system which were made under
a different timezone (perhaps if you are upgrading from a previous version
of MRBS where the timezone wasn't set explicitly and the timezone defaulted to
that of the server) then you have two choices:
(a) to set the timezone to be the same as the previous timezone. This will
ensure that all your existing bookings still appear correctly, but you will
have to continue to put up with some minor inconveniences. For example
"Go to Today" will not always go to the today for your rooms, if you happen
to be using MRBS at a time of day when the rooms are on one day but the
timezone you have selected is on the day before or after. Also if you are
using the min and max book ahead facility then you will find that this is out
by the difference between the timezone of your rooms and the timezone you have
chosen.
(b) to set the timezone to the timezone of your rooms, having first corrected
the start and end times of all your existing bookings, in both the entry and
repeat tables. This is not a trivial exercise and you should back up your
database before starting. Note also that it is not necessarily as simple as
adding or subtracting a fixed number of hours to existing bookings since the
dates at which your rooms change between summer and winter time may be different
to the dates at which your previous timezone made the DST change. This can
happen for example if your rooms are in Europe and your server is in the USA,
as there is usually a week when Europe has changed but the USA has not.
2. Database Settings:
First, select your database system. Define one of the following:
$dbsys = "mysql";
$dbsys = "pgsql";
Then define your database connection parameters. Set the values for:
$db_host = The hostname that the database server is running on.
$db_database = The name of the database containing the MRBS tables.
$db_login = The database login username
$db_password = The database login password for the above login username
If the database server and web server are the same machine, use
$db_host="localhost". Or, with PostgreSQL only, you can use $db_host="" to
use Unix Domain Sockets to connect to the database server on the same machine.
By default, MRBS will not use PHP persistent (pooled) database connections.
Persistent connections can sometimes give better performance, but they can
also cause problems with transactions and locks. For more details see
http://php.net/manual/en/features.persistent-connections.php Although
MRBS is designed to work with persistent connections we recommend that you
don't use them unless they give a significant performance boost. To use
persistent connections set
$db_persist = TRUE;
If you want to install multiple sets of mrbs tables when only one
SQL database is available, or resolve table name conflicts, you have
to change the prefix of "mrbs_" for the tables in your database,
then you will need to set the value of:
$db_tbl_prefix = The table name prefix
3. Other Settings
Now go through systemdefaults.inc.php and areadefaults.inc.php and see which other
configuration settings you would like to change. Do this by copying them to
config.inc.php and changing them there. This should make the task of upgrading to
new releases easier as all your site-specific configuration changes will be confined
to config.inc.php.
There is a wide variety of settings that can be changed, including
- site identification information
- themes
- calendar settings
- booking policies
- display and time format settings
- private bookings settings
- provisional bookings settings
- authentication settings
- email settings
- language settings
- report settings
- entry types
The comments in the systemdefaults.inc.php and areadefaults.inc.php files should
explain the purpose of the various configuration variables and how to change them.
(Note that some of the settings can be set on a per-area basis through the area
administration page in MRBS. In this case the setting in the areadefaults.inc.php
and config.inc.php files defines the default settings for new areas.)
The Help information is held in the site_faq files, one per language. You may well
want to customise it by editing the files.
CHANGING TEXT STRINGS
---------------------------------------------------------------------------
All the text strings used by MRBS, except those used on the Help page, are held in a
series of lang.* files, for example lang.en for English, or lang.fr for French. They
are overridden by the $vocab_override array in the config file. If you want to change
some of the text strings used by MRBS, for example change "Room" to "Computer", then
look for the appropriate string in the lang files, remember its tag and set the
$vocab_override variable in the config file. For example
$vocab_override['en']['ctrl_click'] = "Use Control-Click to select more than one computer";
Doing it this way, rather than editing the lang files, will mean that when you upgrade to
the next version of MRBS you will not have to re-edit the lang files.
INTERNATIONALISATION
---------------------------------------------------------------------------
From MRBS 1.4.6, MRBS is internationalised and uses UTF-8 throughout.
MRBS will serve all of its pages in UTF-8 and stores everything in the
database in UTF-8. This means that all languages work together.
For MRBS to use Unicode, PHP must be built with 'iconv' support
('--with-iconv' directive), or have the iconv extension installed
and enabled. On Windows, if you are using PHP 5, iconv support is built-in.
PERIODS
---------------------------------------------------------------------------
When using periods, MRBS stores bookings internally as one minute slots
starting at 1200. If once you have had your system up and running for
a while find that you need to add a new period then you will need to
adjust the times of your existing bookings unless your new period is at
the end of the day.
The simplest example is when you want to add a new period at the start of
the day. In this case you will need to run some SQL using phpMyAdmin or
a similar program to move all bookings one minute later. In this example
the SQL required would be
UPDATE mrbs_entry SET start_time=start_time+60, end_time=end_time+60;
UPDATE mrbs_repeat SET start_time=start_time+60, end_time=end_time+60,
end_date=end_date+60;
having changed "mrbs_" to your table prefix if necessary.
Before running this SQL you should of course backup your database.
MULTISITE
---------------------------------------------------------------------------
MRBS can be run in multisite mode by setting in the config file
$multisite = true;
In multisite mode a single instance of the MRBS code can serve a number of
sites. Each site has its own config file in the sites/<sitename> directory
which will override any settings in the global config file. At a minimum
the local config file will contain a table prefix for the site, but can also
contain any other config settings including a theme and custom CSS. The sites
are reached by specifying the sitename in the query string, eg
index.php?site=sitename
Individual sites can even have their own authentication methods, but note that
authentication against WordPress multisite is not supported.
SECURITY NOTES!
---------------------------------------------------------------------------
You can configure your web server so that users can not obtain the ".inc"
files but this is not essential, since critical files containing your
database login and password use a ".php" extension like config.inc.php.
See your web server documentation on how to do this.
There are example Apache .htaccess files included, for different versions of
Apache, but Apache might ignore a .htaccess file in your MRBS directory
due to the setting of the "AllowOverride" directive in your web server
configuration. Either change "AllowOverride None" to "AllowOverride Limit",
or create a new <Directory> entry with the contents of the .htaccess example
file in it for your MRBS installation. Then read the Apache docs five or six
times, until you know what you just did.
You may protect "config.inc.php" to only allow the web server to read it.
For example: # chown httpd config.inc.php; chmod 400 config.inc.php
The script "testdata.php" is for testing only. Do not leave it in a
directory accessible to your web server. Anyone running this will add a
large number of test entries to your database, regardless of
authentication, and book all your rooms to people you've never heard of.
