The Server section of the Site administration settings lets you control various aspects of your site's setup.
The system paths page includes the following options:
GD is a graphics library that manipulates graphics. It’s used to create thumbnail images from uploaded files and other graphics on the fly. If you don’t know what version is installed, leave this on the original setting.
|Path to zip and unzip||If you are running Totara on a Unix or Unix-like server (Linux, Solaris, BSD, Mac OS X), you may need to specify where the ZIP program is located. Zip and unzip are used to compress and decompress ZIP archives such as the backup folder.||-|
|Path to aspell|
To use spell checking within the HTML editor, you must have aspell 0.50 or later (http://aspell.net/) installed on your server. You must also specify the correct path to access the aspell binary.
A Site Administrator can specify a support name, email, and/or support page in Server > Support contact under the quick-access menu for including in the account confirmation email.
When a user changes the email address in their profile a confirmation email is sent from the primary administrator of the site, rather than from the support email.
The session handling page includes the following options:
|Use database for session information||If enabled, this setting will use the database to store information about current sessions. If you change this setting it will log out all current users (including you). If you are using MySQL please make sure that max_allowed_packet in my.cnf (or my.ini) is at least 4M. Other session drivers can be configured directly in config.php.||-|
Once someone logs in to your Totara server, the server starts a session. The session data allows the server to track users as they access different pages. If users don’t load a new page during the amount of time set here, Totara will end their sessions and log them out.
|Be sure this time frame is long enough to cover the longest test your trainers may offer. If learners are logged out while they are taking a test, their responses to the test questions may be lost.|
|Cookie prefix||Most of the time, you can leave this blank, unless you are running more than one Totara site on the same server. In this case, you will want to customise the name of the cookie each Totara site uses to track the session. This enables you to be logged in to more than one Totara site at the same time.|
If you change the cookie prefix you will need to log in again, as the change takes effect immediately.
If you need to change where browsers send the Totara cookies, you can change this setting to specify a subdirectory of your web site.Otherwise leaves this as the default.
This allows you to change the domain that the Totara cookies are available from. This is useful for Totara customisations (e.g. authentication or enrolment plugins) that need to share Totara session information with a web application on another subdomain.
It is strongly recommended to leave the Cookie domain setting at the default (empty) as an incorrect value will prevent all logins to the site.
If you enable site Statistics, Totara will gather information on the number of hits there have been on each course as well as the site as a whole. Statistics do not show how many distinct users they have been. This data will be displayed in both table and graph format by date.
A Site Administrator can enable statistics via the quick-access menu under Server > Statistics.
|Maximum processing interval||Use the dropdown menu to select how far back the logs should be processed the first time the cronjob wants to process statistics. If you have a lot of traffic and are on shared hosting, it's probably not a good idea to go too far back, as it could take a long time to run and be quite resource intensive. (Note that for this setting, 1 month = 28 days. In the graphs and reports generated, 1 month = 1 calendar month.)||-|
Specifies the maximum time allowed to calculate the statistics for one day, bearing in mind that statistics processing can put a big load on the server. The maximum number of days processed in one cron can be specified below.
|Day to process|
Specifies the maximum number of days processed in each statistics execution. Once the statistics are up-to-date, only one day will be processed, so adjust this value depending of your server load, reducing it if shorter cron executions are needed.
Set the stats processing to start an hour before your automated course backups are scheduled to start, then set the maximum run- time to one hour. This ensures that stats are not being processed at the same time as course backups are being made.
This setting specifies the minimum number of enrolled users for a course to be included in statistics calculations.
A Site Administrator can change the HTTP settings via Server > HTTP in the quick-access menu. Click Save changes to save any setting changes before leaving the page.
The setting Use slash arguments should always be enabled. Slash arguments (using PATH_INFO) is required for SCORM packages and multiple-file resources to display correctly. If your web server doesn't support slash arguments and you are unable to configure it, this setting can be temporarily disabled, though it will result in things not working.
Disabling the use of slash arguments will result in SCORM packages not working and slash arguments warnings being displayed.
If your server is behind a reserves proxy you can use Logged IP address source to specify which HTTP headers can be trusted to contain the remote IP address. The headers are read in order, using the first one that is available.
Your Totara server may need to access the Internet through a proxy server, depending on your network configuration. If you're not sure about whether you need a proxy server, contact your network administrator.
Fill in the below fields if your Totara server can not access internet directly. Internet access is required for download of environment data, language packs, RSS feeds, timezones, etc.
PHP cURL extension is required.
Maintenance mode is for preventing any users other than administrators from using the site while maintenance is taking place.
When users attempt to access a course while your site is in maintenance mode, they receive a message informing them that the site is in maintenance mode. If you wish, you can create a customised maintenance mode message, perhaps stating when the site will be available again or giving the reason for doing maintenance.
The front page of your site will appear as normal when your site is in maintenance mode. Users will only see the maintenance mode message when they attempt to access a course.
To put your site in maintenance mode:
- Click Server > Maintenance mode in the quick-access menu.
- Click the Enable button.
An alternative way of putting your site in maintenance mode if you’re unable to access the web interface is to create a file called maintenance.html and save it in the folder called 1 in your totaradata folder. A customised maintenance mode message can be entered in the maintenance.html file.
If you wish to give access to users other than Site Administrators when in maintenance mode (perhaps for testing) then you can enable the capability Access site while in maintenance mode (site:maintenanceaccess) in the system context for a role. This will allow access to the site when $CFG->maintenance_enabled is turned on.
The size of specific tables in database can be controlled by setting appropriate limits in the under Server > Cleanup in the quick-access menu.
The cleanup page contains the following options:
|Delete not fully setup users after|
If you are using email authentication, this is the period within which a response will be accepted from users. After this period, old unconfirmed accounts are deleted.
|Delete incomplete users after|
After this period, old not fully setup accounts are deleted.
|Disable grade history|
Disable history tracking of changes in grades related tables. This may speed up the server a little and conserve space in database.
|Grade history lifetime|
This specifies the length of time you want to keep history of changes in grade related tables. It is recommended to keep it as long as possible. If you experience performance problems or have limited database space, try to set lower value.
|Clean up temporary data files older than|
Remove temporary data files from the data folder that are older than the selected time.
The environment page enables you to check that your server meets all system requirements for your current and future versions of Totara.
Check that the status is okay for all of the server requirements.
Totara uses the Unicode character encryption system. The UTF-8 encoding form is used to support multiple languages, as well as special characters used in science and mathematics. You can read more about Unicode on the Unicode consortium's website.
The PHP info page provides information on the version of PHP your server is running, including PHP compilation options and extensions, server information, and the PHP environment and OS version information.
The Totara cron process is a PHP script (part of the standard Totara installation) that must be run regularly in the background. The Totara cron script runs different tasks at differently scheduled intervals.
Do not skip setting up the cron process on your server for your Totara site. Your site will not work properly without it.
A special program is used to run the Totara cron script at a regular interval. The Totara cron script runs tasks include sending mail, updating Totara reports, RSS feeds, activity completions, posting forum messages, and other tasks. Since different tasks have different schedules, not every task will run in Totara when the cron script is triggered.
The cron program (that runs the Totara script) is a core part of Unix based systems (including Linux and OSX) being used to run all manner of time-dependent services. On Windows the simplest solution is to create a task in the Windows Task Scheduler and set it to run at regular intervals. On shared hosting, you should find the documentation (or ask support) how cron is configured.
Essentially, the task involves adding a single command to the list of cron activities on your system. On Unix based systems this list is a file called a crontab which all users have.
The Totara cron command
Totara has two different ways to deploy cron which uses different scripts within the Totara install. These are as follows:
- The CLI (command line interpreter) script: This will be at the path /path/to/Totara/admin/cli/cron.php. If in doubt, this is the correct script to use. This needs to be run by a PHP CLI program on your computer. So the final command may look something like /usr/bin/php /path/to/Totara/admin/cli/cron.php. You can (and should) try this on your command line to see if it works.
- The web based script: This needs to be run from a web browser and will be accessed via a web URL something like http://your.totara.site/admin/cron.php. You can find command line based web browser (e.g. wget) so the final command may look like /usr/bin/wget http://your.totara.site/admin/cron.php. This has the advantage that it can be run from anywhere. If you can't get cron to work on your machine it can be run somewhere else.
Finding the right place to put the command
This really does depend on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Totara cron to run consists of establishing the correct command (above) and then adding it, and the time to run the command, to some sort of file. This might be either through a specific user interface or by editing the file directly.
If using the CLI version you also need to make sure that the cron process is run as the correct user. This is not an issue with the web version.
Example: Installing cron on Ubuntu/Debian Linux. Assuming logged in as root:
Use the crontab command to open a crontab editor window for the www-data user. This is the user that Apache (the web server) runsason Debian based systems.
$ crontab -u www-data -e
This will open an editor window. To run the clicron script every 15 minutes, add the line:
*/15 * * * * /usr/bin/php /path/to/Totara/admin/cli/cron.php >/dev/null
Note that the final ">/dev/null" sends all the output to the 'bin' and stops you getting an email every 15 minutes.
The Performance page (under Server > Performance) contains a variety of settings that can be used to optimise the performance of your site.
|Extra PHP memory limit|
Some scripts like search, backup/restore, or cron require more memory, therefore, it is recommended to set higher values for large sites.
|Maximum time limit|
This setting is used to restrict the maximum PHP execution time that Totara will allow without any output. To use the default restrictions enter 0. If you have a front-end server with its own time limit, set this value lower to receive PHP errors in logs. Does not apply to CLI scripts.
|cURL cache TTL|
Time-to-live for cURL cache, in seconds.
|Bitrate to use when calculating cURL timeouts (Kbps)|
This setting is used to calculate an appropriate timeout during large cURL requests. As part of this calculation, an HTTP HEAD request is made to determine the size of the content. Setting this to 0 disables this request from being made.
|Cache top navigation|
Higher values improve performance but some changes in menu structure may be delayed.