Page Comparison

System Requirements

Rogō runs on a standard LAMP stack:

• Apache 2.2 (minimum) (2.4.X is recommended)
• mod_SSL
• MySQL 5.1 (or above) - NOTE: Mysql 5.7+ is not currently compatible.
• PHP 5.3.9 (minimum) (5.4.X is recommended) - NOTE: PHP 7+ is not currently compatible.
• GD Library
• cURL
• php5_ctype (may not be installed by default on some Linux distros)
• php-mbstring extension required
• php-xml extension required
• php-xmlrpc extension required
• php-mysqli extension required usually labeled as php-mysql on package managers

To use LDAP for authentication or lookup:

• php-ldap extension required

N.B. Rogō is being used on Linux and Solaris servers for all known installations in the community. However, as Rogō runs on a LAMP stack there should be no issues with it running on a Windows server.

From Rogō 6.1 the install and update scripts will check that the listed extensions are installed before letting you proceed.

<?xml version="1.0"?>
<rogo>
    <version>6.3.0</version>
    <php>
        <min_version>5.3.9</min_version>
        <extensions>
            <extension>mysqli</extension>
            <extension>mcrypt</extension>
            <extension>curl</extension>
            <extension>gd</extension>
            <extension>ctype</extension>
            <extension>mbstring</extension>
            <extension>xml</extension>
            <extension>xmlrpc</extension>
            <extension>fileinfo</extension>
        </extensions>
    </php>
    <database>
        <mysql>
            <min_version>50100</min_version>
        </mysql>
    </database>
    <translations>
        <url>http://rogo-oss.nottingham.ac.uk/langpacks</url>
    </translations>
</rogo>

From 6.3 on intall and update rogo will attempt to download the latest language packs available. The university of nottingham hosts a rogo site to download these from. If you prefer this setting can be changed to a site of your choosing.

Hardware Recommendations

Running on-line summative assessments requires a stable hardware platform with enough resources to handle the current student numbers and predicted growth in numbers. Rogō is a web application based around the LAMP stack and many of the standard optimisation techniques are applicable. However, on-line summative assessments have a different load profile to normal web traffic caused by the start of the exam. This high load over a short time period and the importance of the consequence of hardware failure must be taken into account.

Below are some sample/example based systems.

Small-Scale/Trial

...

Large-Scale/Summative

...

Example University of Nottingham platform

...

Considerations

• Redundancy of Hardware This includes multiple PSUs (This allows either one source of power to fail or a failure of a PSU) and multiple networks (This allows either network hardware failure/routing issues or can increase the server bandwidth) along with Redundant storage solutions (allowing a disk failure to not interrupt the service and often provide higher performance than a single disk).
• Availability - the design of supporting architecture should mirror the risk associated with failure. For high-stakes summative exams this normally requires a higher level of risk mitigation than simple formative self-assessments, for example. There are two main models of availability possible: 
  1. Automatic high-availability - virtual machines or load balancers are used to seamlessly flow requests between multiple servers in case of failure. In main cases the aim is that end users will not even notice that traffic has been routed to a different server. This will also require HA or cluster mysql setup. 
  2. Manual fall-over - two machines of identical specification can be used in a 'live' and 'backup' configuration. Usually the database would be configured as 'master' on the live server and 'slave' on the backup to keep records synchronised in real-time. Files (e.g. images) can be copied between servers using cron jobs set to run each day. In the event of a failure in the live the master/slave database connection would be broken by the system administrator and students told to re-start the exam on the backup server. Worst case scenario would be that one screen of results could be lost. This is the simplest method and has been implemented at Nottingham for many years without actually needing to being used.
• Load - web-servers can handle thousands of users spread out over a period of time, but with summative exams high loads are imposed at the start of the exam and also we have seen at the end when students are quickly navigating between screens checking answers.
• Bandwidth - the bandwidth required will depend on the number of simultaneous students in an exam multiplied by the size of the data they are accessing. For example, 200 students viewing a page with a 5Mb PDF file will generate 1Gb of network traffic. If this is going into one computer lab then if might be necessary to investigate the speed rating of the switches and other gear which serves that lab. A way to partly mitigate against large spikes is to include larger files within the middle of an exam so that not all the students will be requesting the file at the same time as they work through the exam at their own rates.
• Storage - the Rogō application has quite modest storage needs, the main requirement will be the amount of media uploaded with each question. Images are usually not too large but attached PDF files, audio and video formats can take up quite a bit of space.

Platform Configuration

Rogō should run on any LAMP stack without modification however there are some configuration task which need to be undertaken to ensure smooth operation under load.

...

...

• `<rogo-data-dir>/help/staff/images`
• `<rogo-data-dir>/help/student/images`
• `<rogo-data-dir>/media`
• `<rogo-data-dir>/email_templates`
• `<rogo-data-dir>/qti/imports`
• `<rogo-data-dir>/qti/exports`
• `<rogo-dir>/config` - for installation only, so that config.inc.php can be written. This should be changed back to being writable by the owner only after installation.
• `<rogo-data-dir>/users/photos`
• `/tmp`

For these writable directories the permissions should be set to drwxrwxr-x for the user that Apache runs as.

Note:
The path to the temporary directory (e.g. /tmp) is configurable in /config/config.inc.php.

...

Optimising apache can be a specialised task so if you have an apache expert/experienced sysadmin please consult with them.

...

The settings for apache adjust how many processes are listening and how many spare threads are available (As of writing this document running php as a module in apache is only recommended for the prefork configuration of apache). For small scale tests then the default apache settings are acceptable, but to increase performance then the numbers should be increased (this will usually use more ram as these are extra processes). It is recommended to increase the minimum spare servers & the start servers (as this will improve the initial start from when the users arrive at the page as it can cope with more simultaneous requests) This is directly related to how much RAM is used

For more info about this please go and read the Apache documentation.

Server prefork settings from a basic apache config from a default install of apache in Centos 6.2

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000

An example from a university of Nottingham Apache config for prefork settings

StartServers         50
MaxClients          150
MinSpareThreads      25
MaxSpareThreads      75 
ThreadsPerChild      25
MaxRequestsPerChild   0

...

As a minimum Apache should be configured with the following to prevent access to sensitive files

# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
<FilesMatch "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</FilesMatch>

#The following lines prevent .inc files files from being
# viewed by Web clients.
<FilesMatch "\.inc$">
    Order allow,deny
    Deny from all
    Satisfy All
</FilesMatch>

...

If you have a MySQL Expert or database administrator you are recommended to contact them for advice first as optimizing MySQL is an 'art'. The basic default installation config should work in small settings. It is best to increase the key_buffer (the settings do depend upon your exact conditions) then make sure that the query cache is increased. You would be recommended to have a read of the MySQL documentation. The my-large.cnf should be suitable for most configurations (this should be supplied with mysql maybe in the examples directory).

An example MySQL my.cnf segment from University of Nottingham:

[mysqld]
ft_min_word_len=3
key_buffer = 384M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 8
max_connections = 500
query-cache-type = 1
query_cache_limit = 5M
query_cache_size = 500M
max_heap_table_size = 536870912
tmp_table_size = 536870912
table_open_cache = 2500

#innoDB options
innodb_buffer_pool_size = 2000M
innodb_additional_mem_pool_size = 200M
innodb_log_buffer_size = 5M
innodb_flush_log_at_trx_commit = 1 // or 2 on server with slow IO 
innodb_lock_wait_timeout = 50

#binlogs on is recommended
log-bin=mysql-bin
binlog_format=mixed

[mysqldump]
quick
max_allowed_packet = 24M

On systems with networked file storage (SANS) with slow disk IO times considerer using:

innodb_flush_log_at_trx_commit = 2 //default value = 1 

See 'adaptive flushing' for a description of the consequence.

max_execution_time = 120
memory_limit = 512M
post_max_size = 20M
upload_max_filesize = 20M
default_charset = "utf-8"
mbstring.internal_encoding = UTF-8
max_input_vars = 3000

Non English Language installation.

Users wishing to install in one of the supported languages other than English should download and install the language pack http://rogo-oss.nottingham.ac.uk/langpacks/ before proceeding with the installation.

Installation

Extract Rogō into the web root and visit 'https://[YOUR_HOST_NAME]/install/index.php'. This will check your installation and create the appropriate databases and users.

...

Please check which version you are on as there may be a number of steps you need to follow.

Upgrading to 5.0

1. The /updates/version4.php will translate the 4.x database structure into the new 5.0 database structure.
2. Edit /config/start.inc and modify the ends of lines 9 and 15 to read <td style="color:white;width:190px;text-align:center">

Upgrading to 5.x

1. To upgrade a version 5 installation to a newer version 5 run the script /updates/version5.php

Upgrading to 6.0

1. When upgrading to version 6 copy /config/start.inc from the BitBucket repository and re-style to local needs. If the old one is copied the 'Fire Exits' will not work.

Upgrading to 6.1

No need skip this.

Upgrading to 6.2

1. Ensure you have copied the config/campuses.inc file into your new rogo directory if you are jumping from a pre rogo 6.1 version

cd /path_to_rogo_root_directory

php composer.phar install --no-dev

...

Upgrading to 6.

...

3

No need skip this.

Upgrading to 6.4

1. Your base rogo must be atleast rogo 6.2.X in order to upgrade to 6.4.X

cd /path_to_rogo_root_directory

php composer.phar install --no-dev

cd /path_to_rogo_root_directory

npm install --production

Rogō Configuration

Rogō main configuration file is in /config/config.inc.php – This holds system wide setting for your installation.

Known Issues

• Rogō uses a large number of prepared SQL statements, MySQL before version 5.1 does not cache prepared statements. Using MySQL version greater than 5.1 is highly recommended for large cohorts.

...

Upgrading to 6.5

Rogo 6.5 is a pre-requiste to Rogo 7. Please upgrade to 6.5 first.

Upgrading to 7

Upgrading to 7.2

Upgrading to 7.3

See the releases page for a download link.