Before commencing with your OLAT installation you must first ensure that the following prerequisites are present and are functioning correctly. Please consult the relevant product documentation for further information as well as installation and configuration instructions.

On busy production sites continuous monitoring of OLAT is recommended in order to assess performance and to resource dimensioning needs accurately. OLAT recommends the use of SNMP based monitoring tools such as Multi Route Traffic Grapher or Nagios as well as log analysis tools (e.g., access statistics etc.) such as Webalizer. Please refer to the relevant product documentation for installation and configuration instructions.

This chapter describes the installation of OLAT for those wishing to use OLAT in a test or production environment. If you are a developer then please skip this section and proceed to Section 2.3, “Developer Installation” where the installation process for an Eclipse IDE environment is described (please see the specific notes regarding Eclipse and WTP found in developer installation instructions!) If you are a deployment manager then we suggest that you review the Operations chapter to consider additional installation and configuration details. This installation process has been tested on Linux, MacOSX and Windows systems. Our production systems run on Linux and use JDK 1.6.x, Tomcat 6.x, MySQL 5.x and the latest Openfire 3.4.x

The following are the necessary steps for installation:

This section describes the installation process for developers working on OLAT code. Please ensure that you have already installed the necessary prerequisites as described in Section 2.1, “Prerequisites” and that these are functioning correctly.

Throughout we assume that you are working with Eclipse and have the Web Tools Platform (WTP) and Concurrent Version Systems (CVS) support installed. We have found that it is best to install WTP when packaged with Eclipse (e.g., by downloading the Eclipse IDE for Java Developers) rather than attempt to install WTP to an existing Eclipse installation.

Maven is the build tool used by OLAT and we encourage you to become familar with it (you may be interested to know that the Maven: The Complete Reference is available online)

Step by Step Development Installation :

Background (optional for further interest) :

For OLAT configuration see olat.properties. You can overwrite each property in your olat.local.properties.

The following are the most frequently used Maven goals. Generally speaking for normal development it suffices to invoke compile or package under the developer profile i.e.,

mvn package

Deployment involves manual configuration of your Tomcat context and the copying of the application resources into the target directory. Developers should be aware that the build process (using the developer profile) will create a local deployment target accessible from within Eclipse.

Configuration of Tomcat requires an application context be configured pointing to the directory where you have deployed your application assets. Practices vary with some administrators preferring to put this context into the server.xml file and others preferring to place it separately under the Catalina engine directory tree. Either way your context should resemble something of the form:

			<Context path="/olat" 
				docBase="/path/to/olat"
					debug="4" reloadable="false" />

You may now deploy your application from either the administrative or the manager consoles within Tomcat, or by restating your Tomcat instance (which is often the preferred approach if you are using the CATALINA_BASE methodology).

You can access your deployed application by visiting http://tomcat_host:tomcat_port/olat in your browser (if you are accessing the instance from behind a reverse proxy then your should use your virtual host name.) By default you can either login as administrator (password olat) or as author (password test). The former has full administrative rights and we strongly recommend that you change the password immediately by navigating to 'Home', 'Settings' and 'Password'. See the tab 'User Management' for a list of all test users (all with password 'test').

Be aware that OLAT does not yet work deployed as an unpacked war file due to some issues with servletcontext methods we use. Tomcat comes with unpack war files set to true as default.

WebDAV (Web-based Distributed Authoring and Versioning) is a set of HTTP extension aimed at supporting the management (incl. creation, deletion etc.) of files on the web. It is used within OLAT for access to personal, course and shared folders and is activated out of the box.

Log in to your OLAT instance, open the personal folder under Home and see the online help for WebDAV beside the WebDAV for your OLAT instance.

The basic configuration of OLAT Full text search is mostly done via olat.local.properties. The following parameters have to be set:

OLAT 6.0.3 introduced the possibility to have a separate OLAT instance running for indexing and processing search queries. You may consider running two instances if on of the following is true:

If you decide to install the search / full indexer instance you need to install and run a JMS server, e.g. apaches ActiveMQ

The University Zurich runs two complete separate tomcat instances, but you may experiment with different setups. It is as easy as setting up two olat instances which then communicate over JMS, for example with the following setup:

The users work with /olat/dmz and the /olatfullindex/dmz is only open for administrators .

If you start now the /olat/dmz/ instance and have jms server running, your should receive a Search not available message if you enter something in the search box. This is as expected, because the other instance is not yet started. Just start the /olatfullindex/dmz instance, and if successfully started you should be able to search.

The integrated Wiki rendering component which is currently used in the repository type Wiki can display mathematics in Web pages. Is is based on the great javascript project called jsMath ( jsMath Website). It tries to render the formular with special mathematics fonts, if the fonts are not installed it uses images provided by the javascript library. As it is a huge number of images (20'000) we do not provide them unpacked in our distro as it makes unzipping the distro too long. Therefore you have to run 'mvn olat:font' to unzip the font files to the appropriate location.

During a Google summer of Code project (GSoC) Maurus Rohner implemented an LDAP interface for OLAT. The following features are supported:

The implementation does not cover group synchronization or LDAP group to OLAT group mappings. If you need such features, ask for commercial help, frentix GmbH who supervised and integrated the project into OLAT can develop it for you.

LDAP administration

The LDAP module offers an administration GUI that lets you manually synchronize LDAP users. The LDAP admin panel can be found under Administration > LDAP.

To manually delete users in OLAT that do not exist on the LDAP server anymore, press the Start button in the section Delete users deleted in LDAP.

To manually create new and synchronize existing users in OLAT compared to the server, press the Start button in the section Synchronization.

At the bottom you see a logging panel that shows all logging messages regarding the LDAP module. For example, here you see that a certain user could not be synced from the LDAP server because a required attribute was missing.

To manually delete users in OLAT that do not exist on the LDAP server anymore, press the To manually delete users in OLAT that do not exist on the LDAP server anymore, press the Start button in the section Delete users deleted in LDAP.Start button in the section Delete users deleted in LDAP.

Shibboleth is a standardized authentication and authorization mechanism. With Shibboleth, the user is redirected to a WAYF/Discovery Service (Where Are You From?), asked to chose her Home Organisation/Identity Provider (her university / company website) to authenticate. The user selects his Home Organization 'University B' and is redirected to its login page. The user sees the familiar login page of 'University B' and provides his login name and password. If login name and password match, the user is redirected back to the resource (e.g. OLAT) he initially requested. After successful authentication at his Home Organization, the resource (OLAT) decides (based on the provided attributes) on granting or denying him access. In the background, the Home Organization provided minimal user details to OLAT, which it requires for the access authorization decision and for delivering its service. See the SWITCH AAI Demo for a Shibboleth Login Procedure summary.

A Shibboleth Service Provider is needed, to protect any resource (e.g. OLAT) on that web server, either with web server access rules or within the application itself. OLAT uses since 6.2.x Shibboleth Service Provider 2.0 with Apache, mod-shib, shibd, mod_jk. The Shibboleth Service Provider Access Rules guideline is found here. A resource either can be protected with acces rules defined in the web server configuration or by the application itself by checking certain Shibboleth attributes. In both cases, a Shibboleth session must be enforced on the file, location or directory to protect. Second, there must be an authorization rule based on attributes that determines how access is granted. If you plan to use the XML access control rules with Apache (e.g. in order to dynamically protect a location), you first have to make sure that the Shibboleth module actually is active for the specific location or the whole web server. This can be done by using a rule in the Apache configuration like the following:

 
			<Location /olat/shib> 
				AuthType shibboleth
    				ShibRequireSession On
    				require valid-user
    				ShibUseHeaders On
  			</Location>
			

If you wonder what the names are of the attributes you can check for, have a look at the attribute-map.xml file.

The configuration of OLAT Shibboleth Module is done via olat.local.properties / olat_config.xml. The following parameters have to be set:

Step by step guide to enable Shibboleth 2 on your OLAT installation (without set up of identiy provider):

The fully integrated Instant Messaging System enables the following features in OLAT

#Instant Messaging properties
instantMessaging.enable=true (enable or disable all instant messaging features)
instantMessaging.server.name=your.jabber.server 
#(you need a own dns name or just localhost for testing)
instantMessaging.generateTestUsers=true 
# (the OLAT test users are generated in OLAT/IM-server with the default passwords also for instant messaging)
instantMessaging.admin.username=admin 
#(these are the default settings of openfire, Change later!)
instantMessaging.admin.password=admin

insert into ofProperty (name,propValue) values('cache.group.size','5242880');
insert into ofProperty (name,propValue) values('cache.group.maxLifetime','3600000');

insert into ofProperty (name,propValue) values('cache.username2roster.size','5242880');
insert into ofProperty (name,propValue) values('cache.username2roster.maxLifetime','3600000');

insert into ofProperty (name,propValue) values('cache.userGroup.size','5242880');
insert into ofProperty (name,propValue) values('cache.userGroup.maxLifetime','3600000');

insert into ofProperty (name,propValue) values('cache.userCache.size','2097152');
insert into ofProperty (name,propValue) values('cache.userCache.maxLifetime','3600000');

insert into ofProperty (name,propValue) values('cache.groupMeta.size','2097152');
insert into ofProperty (name,propValue) values('cache.groupMeta.maxLifetime','3600000'); 
      

#  increasing the max number of filehandles on a Linux box
ulimit -Sn 4096
ulimit -Hn 4096
         

OLAT provides some graphical monitoring tools to supervise the helthness of your server. The graphics are generated by a tool called MRTG which originally has been designed to monitor network devices. Thanks to the very generic interface it can be used to monitor anything that provides a comparable value.

The available scripts are all built for Unix. If someone creates some windows equivalents, please share them with us.

The default OLAT assessment plugin can be overridden using the assessmentplugin.activate property in your olat.local.properties. Please consult the section assessmentplugin config in the olat.properties for further details.

####################################################
# assessmentplugin config
####################################################
# Olat -> default assessmentplugin
# Onyx -> The Onyx-Testplayer (onyxassessmentplugin) can be downloaded at http://www.olat.de/onyx.
#                 The Testplayer is one element of the Onyx-Testsuite and has been designed,
#                 developed and tested by BPS - Bildungsportal Sachsen GmbH - http://www.bps-system.de
#         OLAT makes no representations or warranties of any kind, either express or implied,
#         nor shall OLAT have any liability whatsoever to any person using Onyx, with respect to its functionality.
#         For all questions and help concerning the Onyx-Testplayer and the Onyx-Testsuite
#         including any support write to support@bps-system.de
####
assessmentplugin.activate=Olat

The main configuration file defines the default values and is serving its properties for the Spring configuration files described in Section 4.4, “Spring read configuration files”.

The olat.properties file is well documented, you should read there what and how to set the values.

OLAT will startup without configuration, using the integrated HSQLDB and a data directory path defined by the Java property java.io.tmpdir

The olat.local.properties found in the olat3 project serves as a template and must be copied manually to the classpath. If no olat.local.properties file can be found during first startup, OLAT creates an empty olat.local.properties file in the tomcat/lib directory, and must be restarted.

The values in the olat.local.properties override the default values from the olat.properties.

If you setup OLAT in Eclipse IDE and want to develop, the following properties are recommended in addition. See also the devloper documentation for more information.

There are three types of configuration files to find here and a simple mechanism of overwriting default values with your customized ones. In this installation and administration guide only the configuration files and their meaning is outlined. The Spring config files make use of the defined property values in olat.properties and olat.local.properties.

<bean name="userPropertyFirstName" class="org.olat.user.propertyhandlers.Generic127CharTextPropertyHandler"> 
	<property name="name" value="firstName" />  
	<property name="group" value="account" /> 
	<property name="deletable" value="false" /> 
</bean>
  						

<bean id="org.olat.user.UserPropertiesConfig" class="org.olat.user.propertyhandlers.UserPropertiesConfigImpl">
	<property name="userPropertyHandlers"> 
		<list>
			<ref bean="userPropertyFirstName" />	
			<ref bean="userPropertyLastName" />
			<ref bean="userPropertyEmail" />
			<ref bean="userPropertyBirthDay" />
			<ref bean="userPropertyGender" />
			<ref bean="userPropertyTelPrivate" />
			<ref bean="userPropertyTelMobile" />
			<ref bean="userPropertyTelOffice" />
			<ref bean="userPropertySkype" />
			<ref bean="userPropertyHomepage" />
			<ref bean="userPropertyStreet" />
			<ref bean="userPropertyExtendedAddress" />
			<ref bean="userPropertyPoBox" />
			<ref bean="userPropertyZipCode" />
			<ref bean="userPropertyRegion" />
			<ref bean="userPropertyCity" />
			<ref bean="userPropertyCountry" />
			<ref bean="userPropertyInstitutionalName" />
			<ref bean="userPropertyInstitutionalUserIdentifier" />
			<ref bean="userPropertyInstitutionalEmail" />
			<ref bean="userPropertyOrgUnit" />
			<ref bean="userPropertyStudySubject" />
		</list>
	</property>
  					

<bean id="org.olat.user.UserPropertiesConfig" class="org.olat.user.propertyhandlers.UserPropertiesConfigImpl">
	<property name="userPropertyHandlers">
		<list>
			<ref bean="userPropertyFirstName" />
			<ref bean="userPropertyLastName" />
			.
			.
			.
			<ref bean="userPropertyStudySubject" />
		</list>
	</property>		
	<property name="userPropertyUsageContexts">
		<map>
			<!-- 
				Forms that show user properties
			-->
			<entry key="org.olat.user.ProfileFormController"> 
				<bean class="org.olat.user.propertyhandlers.UserPropertyUsageContext">
					<property name="propertyHandlers"> 
						<list>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							.
							.
							.
							<ref bean="userPropertyStudySubject" />
						</list>
					</property>
					<property name="mandatoryProperties"> 
						<set>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							<ref bean="userPropertyEmail" />
						</set>
					</property>
					<property name="userViewReadOnlyProperties"> 
						<set>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							.
							.
							.
							<ref bean="userPropertyStudySubject" />
						</set>
					</property>
					<property name="adminViewOnlyProperties"> 
						<set />
					</property>
				</bean>
			</entry>
  					

See our extensive manual for more information about the new translation tool and existing translations.

The Brasato application framework offers full internationalization (i18n) support. Every GUI message visible in the user's browser (e.g. navigation, error messages etc.) is computed by the i18n system based on the user's language configuration.

Translations, as we call these GUI messages, are stored in Java Properties files on the file system as part of the source code of the application. Each Java package can contain a directory _i18n. There you will find the localization files, e.g. LocalStrings_de.properties for German translations. In the context of the translation infrastructure we call the package to which the translation belongs the bundle. Translation files in org/olat/core/_i18n/ are the translation files for the bundle org.olat.core.

The i18n system features an easy to use translation tool that allows users to translate new languages or customize an existing language package for a certain use case. The system does also provide easy to use workflows to enable and disable languages, import and export language packages and to create or delete languages.

If you wish to translate OLAT to a new language and you want to contribute this translation to the OLAT community, please contact us first. We have a dedicated translation server where your translations will automatically be checked into our CVS and we can communicate you the changes that happend in the code due to code refactoring and development. We would love to have your favorite language as an official OLAT language!

Languages are configured in olat3/webapp/WEB-INF/olat_config.xml. Add new languages in the Localization module and set the default and fallback language. You sould make your changes in the olat_config.xml.in rather than in the olat_config.xml file. You can then run maven mvn olat:properties to generate your olat_config.xml file.

From this config files the system reads the default configuration. Once an administrator uses the admin GUI to set the language parameters, the config is written into the olatdata user space. This user space configuration overwrites the default values. The configuration can be found in the file olatdata/system/configuration/org.olat.core.util.i18n.I18nModule.properties. This file can be deleted to restore the configuration to the default settings.

We really appreciate if you do your translation on our translation server and contribute it to the community. If you still want to set up your own translation server then you have to do the following:

When loggin in as administrator you will now see a menu item Administration > Translation Tool.

OLAT has a handy translation tool built into the system so that you do not have to understand an IDE like eclipse. All translation files can be edited via webbrowser.

The translation tool together with related topics how to set up a tranlation server, how to create, import and export a lanuage, etc. are explained in detail in a separate manual: Understanding the Internationalization (i18n) and Translation System.

OLAT 6.3 introduced two ways to customize the disclaimer. You can add a second checkbox to the disclaimer and a link to a file download.

Clustered System Overview

The clustered OLAT system is based on three layers :

Each of the layer could be on different hosts. The services on a layer could be clustered vertical too e.g. each OLAT Node could be on an other machine.

OLAT in cluster mode requires a JMS system to be available. Since we completely rely on the JMS specification you can use any of your preferred JMS provider. Also, we don't put any special requirements on the JMS provider such as persistency or failure tolerance. Hence you could use a standalone JMS server or a serverless, multicast based JMS.

As an example we're presenting the configuration of ActiveMQ here.

This section describes Apache with mod_jk as a solution for load balancing in an OLAT cluster. You are free to use any other load balancer (hard- or software) as long as certain criterias are met (see below).

Refer to http://tomcat.apache.org/connectors-doc/generic_howto/workers.html for details

Criterias for the Load Balancer

Example configuration of Apache with mod_jk

mod_jk.conf:

  <IfModule mod_jk.c>
    JkRequestLogFormat "%w %V %T %r"
    JkWorkersFile      "/modjkdirectory/workers.properties"
    JkLogFile          "/logdirectory/mod_jk.log"
    JkShmFile          "/modjkdirectory/mod_jk-runtime-status"
    JkLogLevel         error 
    JkOptions          +ForwardURICompatUnparsed
    JkMount            /olat/* loadbalancerworker
    JkMount            /olat loadbalancerworker
    JkUnMount          /olat/raw/* loadbalancerworker

   ...
   </IfModule>	  	
	  	

workers.properties:

workers.tomcat_home=/usr/local/opt/tomcat-6.0
workers.java_home=/usr/local/opt/java-1.6
ps=/

worker.list=loadbalancerworker

worker.loadbalancerworker.type=lb
worker.loadbalancerworker.balance_workers=tomcatolat02,tomcatolat01
worker.loadbalancerworker.sticky_session=true
worker.loadbalancerworker.sticky_session_force=false
worker.loadbalancerworker.method=s
worker.loadbalancerworker.connect_timeout=15000
worker.loadbalancerworker.prepost_timeout=15000

worker.basic.type=ajp13
worker.basic.socket_timeout=1200
worker.basic.cachesize=1
worker.basic.cache_timeout=1300
worker.basic.recycle_timeout=1300
worker.basic.port=8009
worker.basic.distance=10
worker.basic.lbfactor=10
worker.basic.connect_timeout=30000
worker.basic.prepost_timeout=30000

worker.tomcatolat01.host=localhost
worker.tomcatolat01.port=8019
worker.tomcatolat01.domain=tomcatolat01
worker.tomcatolat01.reference=worker.basic
worker.tomcatolat01.lbfactor=10

worker.tomcatolat02.host=localhost
worker.tomcatolat02.port=8029
worker.tomcatolat02.domain=tomcatolat02
worker.tomcatolat02.reference=worker.basic
worker.tomcatolat02.lbfactor=10
	  	

If you are using VirtualHost and JkMountCopy together, please refer to http://tomcat.apache.org/connectors-doc/reference/apache.html for details, how JkMount is inherited from global server to VirtualHosts.

# server port must be the one visible to the outside - usually 80
server.port=80

# server.port.ssl must is usually 443
server.port.ssl=443

# this must definitely be true in cluster mode
server.modjk.enabled=true

# the jvmRoute must match what you configure in the worker.properties
server.modjk.jvmRoute=tomcatolat01

# the internal http port is used for directly connecting to tomcat, bypassing apache
server.internal.http.port=8081

#
# more specific cluster properties
#
# cluster.mode must be set to Cluster 
cluster.mode=Cluster

# select one node in your cluster where you enable singleton services, disable it on all others
cluster.singleton.services=disabled|enabled

# used for stopping tomcat
cluster.catalinaport=8015

# the ajpport port must match the one you configure in worker.properties
cluster.ajpport=8019

# when in cluster mode every node needs an unique integer between (1-64), first node has to be node "1".
node.id=1

# jms broker url for the eventbus
jms.broker.url=failover:(tcp://activemq.host.name:61616?wireFormat.maxInactivityDuration=30000)


# the treecache.xml file name - used for Cacher
treecache.xml.file=treecache.xml

# the multicast port used by jboss treecache
multicast.port=41414
      

You can join in and register your OLAT installation at olat.org to transfer statistical information anonymously (such as number of users, courses, etc.). These data will not be related to your installation. They will only serve to better document OLAT's use.

Here you can control the communication with the instant-messaging server. :

Since OLAT 6.0.3 there is a course activity information available. This is a list with the loaded courses. The table is only refreshed by clicking again on the menu entry.

If you are running the Full text search/indexer in the same instance as the OLAT LMS. You will see every course loaded.

Search form for user's properties. For more specific search use the advanced property search. More information about the property you will find in the next section 'Advanced properties'.

Almost everything in OLAT can have its properties. They are saved in the table o_property, a very generic table. As you see below only three of thirteen rows can not be NULL. The fields are used dependent on the businesscase and this are not in every case all of them.

mysql> desc o_property;
+------------------+----------------+------+-----+---------------------+-------+
| Field            | Type           | Null | Key | Default             | Extra |
+------------------+----------------+------+-----+---------------------+-------+
| id               | bigint(20)     |      | PRI | 0                   |       |
| lastmodified     | datetime       |      |     | 0000-00-00 00:00:00 |       |
| creationdate     | datetime       | YES  |     | NULL                |       |
| identity         | bigint(20)     | YES  | MUL | NULL                |       |
| grp              | bigint(20)     | YES  | MUL | NULL                |       |
| resourcetypename | varchar(50)    | YES  | MUL | NULL                |       |
| resourcetypeid   | bigint(20)     | YES  | MUL | NULL                |       |
| category         | varchar(33)    | YES  | MUL | NULL                |       |
| name             | varchar(255)   |      | MUL |                     |       |
| floatvalue       | decimal(78,30) | YES  |     | NULL                |       |
| longvalue        | bigint(20)     | YES  |     | NULL                |       |
| stringvalue      | varchar(255)   | YES  |     | NULL                |       |
| textvalue        | text           | YES  |     | NULL                |       |
+------------------+----------------+------+-----+---------------------+-------+
13 rows in set (0.03 sec)

mysql> select * from o_property where name="InfoMsg";
+--------+---------------------+---------------------+----------+------+------------------+----------------+
| id     | lastmodified        | creationdate        | identity | grp  | resourcetypename | resourcetypeid |
+--------+---------------------+---------------------+----------+------+------------------+----------------+
| 393217 | 2005-04-12 17:09:06 | 2005-04-12 17:09:06 |     NULL | NULL | NULL             |           NULL |
+--------+---------------------+---------------------+----------+------+------------------+----------------+

   ----------+---------+------------+-----------+-------------+--------------+
    category | name    | floatvalue | longvalue | stringvalue | textvalue    |
   ----------+---------+------------+-----------+-------------+--------------+
    _o3_     | InfoMsg |       NULL |      NULL | NULL        | only as demo |
   ----------+---------+------------+-----------+-------------+--------------+
1 row in set (0.01 sec)

mysql> select * from o_property where category="NID:iqte::71256453203971" and name="PASSED" and stringvalue="true";
+--------+---------------------+---------------------+----------+------+------------------+----------------+
| id     | lastmodified        | creationdate        | identity | grp  | resourcetypename | resourcetypeid |
+--------+---------------------+---------------------+----------+------+------------------+----------------+
| 655376 | 2005-04-13 13:01:49 | 2005-04-13 13:01:49 |   163847 | NULL | CourseModule     | 71256453203963 |
| 655384 | 2005-04-13 13:17:51 | 2005-04-13 13:17:51 |   163849 | NULL | CourseModule     | 71256453203963 |
+--------+---------------------+---------------------+----------+------+------------------+----------------+

   --------------------------+--------+------------+-----------+-------------+-----------+
    category                 | name   | floatvalue | longvalue | stringvalue | textvalue |
   --------------------------+--------+------------+-----------+-------------+-----------+
    NID:iqte::71256453203971 | PASSED |       NULL |      NULL | true        | NULL      |
    NID:iqte::71256453203971 | PASSED |       NULL |      NULL | true        | NULL      |
   --------------------------+--------+------------+-----------+-------------+-----------+
2 rows in set (0.01 sec)

See the chapter Chapter 5, Customize your installation

In the cluster-mode, this menu item is only enabled on the node where the search-service is running. There are 6 sections :

Notfications are triggered automatically once daily 10min after midnight. You can configure the time in the OLAT configuration. If you wish to notify the users immediate during the day you can trigger the notification manually be pressing the button in the admin area.

                   +---------------+  
+---------+        | o_bs_identity |
| o_user  |        +---------------+
+---------+        | id            |
| user_id | 1 -- 1 | fk_user_id    |
+---------+        +---------------+

                         +-----------------+                     
                         | o_bs_membership |        +---------------+       
+---------------+        +-----------------+        | o_bs_secgroup |        
| o_bs_identity |        | id              |        +---------------+
+---------------+        | secgroup_id     | n -- 1 | id            |
| id            | 1 -- n | identity_id     |        +---------------+
| fk_user_id    |        +-----------------+
+---------------+

                        +--------------+
                        | o_bs_policy  |        +----------------+        
+--------------+        +--------------+        | o_olatresource |
|o_bs_secgroup |        | id           |        +----------------+
+--------------+        | oresource_id | n --1  | resource_id    |
| id           | 1 -- n | group_id     |        | resname        |
+--------------+        | permission   |        | resid          |  
                        +--------------+        +----------------+

The policy shows you which group has what kind of permission for which resource-type (resname). Permissions are e.g: "access", "read", "hasRole", etc. It depends on the particular business case how they are to interpret. Resources can be everything, e.g. BaseSecurityModules, FileResources, Controllers, etc.

User can be deleted in 'User management' tab. Users can be deleted directly without any notification with 'Delete user immediately' or users can be deleted with notification-email workflow. All user data will be deleted. The login-name of a deleted users is still reserved because new user account should not use an used login-name. A deleted user can not be recovered.

A user can have the following states :

An user manager can change the state in form 'Manage user settings' at tab 'Roles'

Only the efficiency statement of a user will be archived as excel sheet. You will find the excel sheet at ARCHIVE_PATH/archive_deleted_users/DELETE_DATE/del_identity_DELETED_IDENTITY_NAME. The ARCHIVE_PATH can be configrated in olat.properties with property 'archive.dir' (e.g. archive.dir=C:/temp/deleted_archive). The directory can be somewhere in the filesystem. The idea is, that the archive directory is outside of olat-system. The OLAT system did not use the archived data and the archived data can not be recovered into the OLAT system.

The following user-data will be deleted : personal-folder, home-page, notes, user-properties, personal calendar, bookmarks, notifications, test-results, interrupted tests and instant messaging accout. The will be removed as owner from the following resources : groups, learning resources and catalog. If the reoved user is the last owner of the resource, the administartor will be inserted as owner.

User Deletion Workflow

The user-deletion workflow includes three steps :

1. Inactive users :

   List of users which have not logged on to OLAT since xx months (e.g. 24 month, limit can be configurated). You can inform them via e-mail about the imminent deletion of their user account.

   That deletion can be prevented by clicking Activate. You can select the users which you want to delete and press the 'send notification email' button. In a popup you can edit or disable the notification email. The selected users will be removed form the 'Inactive user' list and moved to the 'E-mail sent' list.

2. E-mail sent :

   List of users which have been notified via e-mail about the imminent deletion of their user account. The period for reaction (answer via e-mail or login) has not yet expired (e.g. 30 days, limit can be configurated). That deletion can be prevented by clicking Activate.

3. Ready to delete :

   List of user accounts which are ready for deletion. The period of 30 days for reaction has expired. By clicking Activate you can prevent the deletion of user accounts.

   The deleted user accounts can not be recovered.

User deletion workflow

The OLAT administrator will be supported to delete inactive (not used over certain time) learning resources. The workflow to delete inactive learning resources includes three steps :

The learning resource will be archived in a ZIP file at : ARCHIVE_PATH/archive_deleted_resources/DELETE_DATE/del_group_DELETED_RESOURCE_NAME. The ARCHIVE_PATH can be configrated in olat.properties with property 'archive.dir' (e.g. archive.dir=C:/temp/deleted_archive). The directory can be somewhere in the filesystem. The idea is, that the archive directory is outside of olat-system. The OLAT system did not use the archived data and the archived data can not be recovered into the OLAT system.

The OLAT administrator will be supported to delete inactive project groups. The workflow to delete inactive project group includes three steps :

The group will be archived in a ZIP file at : ARCHIVE_PATH/archive_deleted_groups/DELETE_DATE/del_group_DELETED_GROUP_NAME. The ARCHIVE_PATH can be configrated in olat.properties with property 'archive.dir' (e.g. archive.dir=C:/temp/deleted_archive). The directory can be somewhere in the filesystem. The idea is, that the archive directory is outside of olat-system. The OLAT system did not use the archived data and the archived data can not be recovered into the OLAT system.

When upgrading from a previous OLAT version several things have to be done:

OLAT Configuration mechanism changed for the 7.0 release.

OLAT is configured by the placeholder replacement mechanism from Spring Framework. Spring searches for two files: serviceconfig/olat.properties and classpath: olat.local.properties. The entries in the second file overwrite the default entries in the first file.

To overwrite the defaults create an empty olat.local.propeties file and place it in /yourTomcatDir/lib (part of the classpath) or in the root of your OLAT classpath (e.g. webapp/WEB-INF/classes). See OLAT Administration tab (Setup entry) for your running configuration. When you start OLAT with an empty olat.local.propeties file for development reasons, your userdata will be written to java.io.tmpdir which is platform dependent (e.g. linux: /tmp). You can overwrite this location with a VM parameter -Djava.io.tmpdir=/home/user/data to have userdata in a convenient place.

Example for olat.local.propeties properties for MySQL.

# DB-properties of your 6.3 installation
db.name=olat_63
db.user=olat_63
db.pass=****

db.vendor=mysql
db.database.dialect=org.hibernate.dialect.MySQL5Dialect
# Important because validation would failed because validation is done before upgrade!
db.hibernate.ddl.auto=none

# Path-properties of your 6.3 installation
userdata.dir=/opt/olatdata
archive.dir=${userdata.dir}/archive
log.dir=${userdata.dir}/logs
upgrade.dir=${userdata.dir}/upgrades
folder.root=${userdata.dir}/bcroot
temp.dir=${userdata.dir}/tmp
      

Upgrade steps :

Install OLAT as described in the installation chapter make sure you do not drop your existing database (see database properties)!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat6.x.x and install the 6.x.x package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

Your userdata will be upgraded with several migrations during the first startup. Depending of the amout of data this takes some time. Succesfull upgrades are listet in PATH_TO_OLATDATA/system/installed_upgrades.xml (OLATUpgrade_6_3_0 stuff)

Your database will be upgraded with new tables/colums automatically upon the first startup. See PATH_TO_YOUR_OLAT/database for altering code for your database. Succesfull upgrades are listet in PATH_TO_OLATDATA/system/installed_upgrades.xml

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat6.0.x and install the 6.2.x package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

OLAT 6.2.x comes with a rich text formatting textarea field which is used in forums and many general description fields. These field now support html tags and the content of these fields need so be migrated to get rid of the former wiki syntax which gets replaced by html. This process is automatically done upon first starting 6.2.x but you may have a look into the log file for errors.

#cd PATH_TO_YOUR_OLAT
        #rm olat (if olat is a symlink, otherwise: mv olat3 olat6.1.1)
        #unzip OLAT-6.2.0.zip
        #ln -s OLAT-6.2.0-PUBLIC-XXXXX olat
        #cd olat
        #cp olat.properties.default olat.properties
        #vi olat.properties
        #ant install

Your database will be upgraded with new tables/colums automatically upon the first startup. See PATH_TO_YOUR_OLAT/database for altering code for your database. Succesfull upgrades are listet in PATH_TO_OLATDATA/system/installed_upgrades.xml

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat6.0.x and install the 6.1.1 package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

#cd PATH_TO_YOUR_OLAT
        #rm olat (if olat is a symlink, otherwise: mv olat3 olat6.0.x)
        #unzip OLAT-6.1.1.zip
        #ln -s OLAT-6.1.1-PUBLIC-XXXXX olat
        #cd olat
        #cp olat.properties.default olat.properties
        #vi olat.properties
        #ant install

Your database will be upgraded with new tables/colums automatically upon the first startup. See PATH_TO_YOUR_OLAT/database for altering code for your database. Succesfull upgrades are listet in PATH_TO_OLATDATA/system/installed_upgrades.xml

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat6.0.1 and install the 6.0.3 package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

#cd PATH_TO_YOUR_OLAT
#rm olat (if olat is a symlink, otherwise: mv olat3 olat6.0.1)
#unzip OLAT-6.0.3.zip
#ln -s OLAT-6.0.3-PUBLIC-XXXXX olat
#cd olat
#cp olat.properties.default olat.properties
#vi olat.properties
#ant install

Update your database manually according to PATH_TO_YOUR_OLAT/olat3/database/alter_6_0_0_to_6_0_3.sql

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat5.2.x and install the 6.0.x package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

#cd PATH_TO_YOUR_OLAT
#rm olat (if olat is a symlink, otherwise: mv olat3 olat5.2.x)
#unzip OLAT-6.0.1.zip
#ln -s OLAT-6.0.1-PUBLIC-XXXXX olat
#cd olat
#cp olat.properties.default olat.properties
#vi olat.properties
#ant install

Update your database manually according to PATH_TO_YOUR_OLAT/olat3/database/alter_5_2_x_to_6_0_0.sql

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat5.2.x and install the 5.2.x package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

#cd PATH_TO_YOUR_OLAT
#rm olat (if olat is a symlink, otherwise: mv olat3 olat5.2.0)
#unzip OLAT-5.2.0.zip
#ln -s OLAT-5.2.0-FINAL-XXXXX olat
#cd olat
#cp olat.properties.default olat.properties
#vi olat.properties
#ant install

Update your database manually according to PATH_TO_YOUR_OLAT/olat3/database/alter_5_1_0_to_5_2_0.sql

Now start tomcat.

Install OLAT as described in the installation chapter but DON'T RUN 'ant dbsetup'!! We recommend to move your existing installation from PATH_TO_YOUR_OLAT/olat3 to PATH_TO_YOUR_OLAT/olat5.1.x and install the 5.1.x package as your new PATH_TO_YOUR_OLAT/olat3. All user data is located in the olatdata directory which should not be located in the PATH_TO_YOUR_OLAT/olat3. The olatdata directory and the database won't be changed when installing the new code.

#cd PATH_TO_YOUR_OLAT
#rm olat (if olat is a symlink, otherwise: mv olat3 olat4.1.4)
#unzip OLAT-5.1.0.zip
#ln -s OLAT-5.1.0-FINAL-XXXXX olat
#cd olat
#cp olat.properties.default olat.properties
#vi olat.properties
#ant config-all
#ant install

Update your database manually according to PATH_TO_YOUR_OLAT/olat3/database/alter_5_0_0_to_5_1_0.sql

Now start tomcat.

$ cd  PATH_TO_YOUR_OLAT/bin/wiki_migration
## edit the wiki_migration_51.sh to your path of repoistory and olat installation
$ vi wiki_migration_51.sh
## change export BCROOT=/usr/local/opt/olat/olatdata/bcroot to your installation
## change export OLATROOT=/usr/local/opt/olat/olatlive to your installation
## run it!
$ ./wiki_migration_51.sh
## in the output.log you will see what changed
        

OLAT 3.x is not compatible with OLAT 2.x. Install OLAT 3.0 as a new installation as described in chapter 2. To migrate your data from your existing OLAT 2.x installation you need to install the newest 2.x release and then follow the migration instruction described in the 2.x to 3.0 migration guide.

If you have any questions about the code or the usage of OLAT please contact us using one of our mailinglists. You will find them at http://lists.olat.org

Please follow the usual netiquette on mailing lists. The more detailed, polite and patient you are, the faster and better is the answer you will receive.

For personal questions you can contact us via info@olat.org. Please do not ask questions on this address that are of general interest, use the mailinglists for this instead.

For professional OLAT support, hosting, training (developers, administrators or authors) or customization please visit the homepage of frentix .

Frentix GmbH is a spin-off company from the University of Zurich that has great experience in developing and deploying the LMS OLAT.