Sakai 2.5
Sakai 2.5 incorporates a large number of refinements and refactoring touches both the tool layer and the framework. One new provisional tool (Reset Password) has been added, while two very successful provisional tools (OSP and Tests & Quizzes) have been promoted to the enterprise bundle. One core tool (Discussion) has been retired, being replaced by other tool options (e.g., Forums).
Sakai 2.5 is dedicated to the memory of the late Marc Brierley, a member of the Sakai community since its inception, whose work as a user interaction designer at Stanford University helped shape the Sakai release today.
Current Release: Sakai 2.5.6 (released 28 Jan 2010)
The Sakai 2.5.6 maintenance release provides a set of bug fixes and security enhancements that improve upon Sakai 2.5.5. Over 130 issues have been addressed in this release. Fixes have been applied to the following tools/services: announcements, assignments, blog, calendar, content service, entity service, entitybroker, event service, forums, gradebook, mailtool, messages, post'em, polls, portal, portfolios, profile, providers, reports, resources, roster, rwiki, schedule, search, section info, site info, sites, syllabus, Test & Quizzes, user service, web content, webdav and worksite setup.
Sakai 2.5 Distribution Packages
There are two ways to acquire Sakai source code. You can choose to download a packaged *.zip or *tar.gz file from Sakai's release page or check out the code directly from our code repository using Subversion's (SVN) source control management system.
Demo
|
The Sakai Demo is a pre-built version of Sakai with Apache Tomcat and a simple configuration, perfect for a quick and easy demo of Sakai. The demo is NOT intended for large scale implementations. It is suitable only for evaluating the software and running small pilot implementations on a single server. BinaryThe Sakai Binary is a pre-built version of Sakai without Apache Tomcat, jar dependencies, or extra configuration files. Download the Binary release if you want to just drop the Sakai bundle into a pre-existing Tomcat environment. SourceThe Sakai Source includes Sakai portal, tool and service source code. Start from Source if you plan to make any code-level changes to your Sakai system. |
|
|
Sakai 2.5 Source Code
Sakai source code can also be checked out anonymously from our SVN repository. The latest development work is located in /trunk; stable releases can be found in /tags while maintenance, experimental and other work are performed in /branches.
Starting with Sakai 2.5, Sakai common services (e.g., authz, content, event, site, tool, user, etc.) have been repackaged and refactored as the Sakai Kernel (K1). In most cases, you will never have to check out the kernel manually as Sakai 2.5 kernel dependencies are managed by Maven.
| Sakai | Repository location |
|---|---|
| Trunk | https://source.sakaiproject.org/svn/sakai/trunk/ |
| Tags | https://source.sakaiproject.org/svn/sakai/tags/ |
| Branches | https://source.sakaiproject.org/svn/sakai/branches/ |
To checkout a stable release tag of Sakai 2.5.6 issue the following svn command from the terminal:
svn co https://source.sakaiproject.org/svn/sakai/tags/sakai-2.5.5/ sakai-2.5.6
Sakai 2-5-x Maintenance Branch
The latest bug fixes for a particular release can be found in our maintenance branches. Please note that certain maintenance branch fixes require database schema changes; see the Sakai Confluence Wiki 2-5-x branch summary for more information. You can check out the maintenance branch by issuing the following command from the terminal:
svn co https://source.sakaiproject.org/svn/sakai/branches/sakai_2-5-x/ sakai_2-5-x
Migrating from a Previous Release
Migration from an earlier version of Sakai usually involves a database conversion (for which scripts are supplied with the release), an update to custom skins and possibly changes to any custom code. See the "Migration" tab for more details.
Security Issues and Older Releases
Sakai 2.5.5 addresses a number of security vulnerabilities, patches for which have been applied to the Sakai 2-5-x and 2-4-x maintenance branches (where appropriate). However, as of 23 July 2009 the Sakai 2.4 series including the 2.4.x maintenance branch will no longer be supported officially by the Sakai Community. Organizations running Sakai 2.4 or earlier versions are strongly encouraged to upgrade to the latest versions of Sakai 2.5 or Sakai 2.6.
Comments, Feedback
The documentation is presented here for ongoing comment, correction, and clarification, so please use the "Add Comment" link at the bottom of any of these pages if you note errors, require further details or have tips to share.
Sakai 2.5 Installation Guides
Demo Distribution Installation Guide
Binary Distribution Installation Guide
Source Distribution Installation Guide
Configuring Sakai 2.5
1.0 Create a sakai.properties File
The sakai.properties file is a central configuration file that is typically stored in a /sakai subdirectory relative to the Tomcat home directory ($CATALINA_HOME). It is a non-XML text file containing a series of key/value pairs that can be read using the load method of java.util.properties. Settings in sakai.properties govern everything from setting your institution name to configuring your database. All settings in sakai.properties are only read on startup; thus any changes you make will only take effect when you restart Tomcat.
The default sakai.properties file is located in the Components API project module:
sakai-src/component/component-api/component/src/config/org/sakaiproject/config/sakai.properties
A sample sakai.properties file which documents many of the standard properties can be found in the Reference module:
sakai-src/reference/docs/sakai.properties
To override the defaults you can create your own sakai.properties file either from scratch or from a known working copy. New key/value settings can be added to the sakai.properties. Since any component property can in principle be overridden here, any sample sakai.properties will show only a small fraction of all the possible settings.
If you checkout a copy of sakai.properties from our SVN repository make sure it corresponds to the version of Sakai you are using (e.g. Sakai 2.5.x):
$ svn co http://source.sakaiproject.org/svn/reference/branches/sakai_2-5-x/docs/sakai.properties
If you create your own sakai.properties file the standard place to locate it is $CATALINA_HOME/sakai. This directory is not created by Maven during the build and deployment process, so you will have to create it manually.
You may find it preferable to store Sakai's configuration files outside of the Tomcat file hierarchy. In a development environment, for example, you may find yourself frequently reinstalling Tomcat and unless you create a build script to automate the Tomcat installation and configuration process you will likely want to avoid having to recreate the $CATALINA_HOME/sakai folder and its property file contents each time.
To locate your properties file outside of Tomcat modify the Java startup command or the JAVA_OPTS environment variable and set a system property named sakai.home. Make sure your external location is readable and writable by Tomcat.
-Dsakai.home=/path/to/desired/sakai/home/
For list of sakai.properties settings see the [Sakai Properties Reference; for detailed documentation on the full variety of possible sakai.properties settings, see the sakai_properties.doc in /reference/docs/architecture/sakai_properties.doc.
2.0 Configure Email
Enabling Sakai to both send and receive email requires setting a number of properties in sakai.properties. For sending mail Sakai requires the address (name or IP) of an external SMTP server that will accept mail from Sakai:
smtp@org.sakaiproject.email.api.EmailService=some.smtp.org
To enable Sakai to receive mail you'll need to set the following properties:
# dns addresses used for incoming email smtp.dns.1 = 255.255.255.1 smtp.dns.2 = 255.255.255.2 # SMTP port on which our SMTP server runs. Default is 25. #Recommend running on 8025, and using a standard mailer on 25 to forward mail to Sakai. smtp.port = 25 # flag to enable or disable our SMTP server for incoming email (true | false) smtp.enabled = true # email address used as the "from" address for any email sent by Worksite Setup tool or Site Info tool. # Recipients may not receive notifications if this address isn't valid. #setup.request=address@somedomain
To disable the SMTP server for incoming email, set smtp.enabled=false in sakai.properties:
smtp.enabled=false
Sakai's SMTP server is Apache James. Utilizing the above configuration to run James on the standard SMTP port 25 requires admin privileges. Most admins won't permit Tomcat to run with the above permissions and would rather run a standard mailer like Postfix on port 25 and configure it to forward requests to Sakai. You may also already have a mailer service running on port 25 (Linux usually has it running by default) and so you will want to change the James port port in order to avoid a conflict. For example:
smtp.port=8025
3.0 Configure Logging
Once you have Sakai installed, configured and started, you can monitor Sakai by watching the logs. The log level for the standard Sakai source code and the demo is set to show info and warnings only. Watch for the WARN: messages. There are going to be some "normal" ones at startup, and some will likely slip by at runtime, but any warning is potentially something you might want to check out.
Logging levels can be specified in sakai.properties. This augments and overrides the levels set in the default config file. Example:
log.config.count=3 log.config.1 = ALL.org.sakaiproject.log.impl log.config.2 = OFF.org.sakaiproject log.config.3 = DEBUG.org.sakaiproject.db.impl
This uses the established (if awkward) method of having a name.count followed by name.1, name.2 etc. to form an array of strings for the value "name". In this case, the name is "log.config". The values are of the form LEVEL.logger, and the possible levels are: OFF TRACE DEBUG INFO WARN ERROR FATAL ALL.
Changing the Log Configuration
Sakai uses log4j for logging. See the official log4j documentation for more information about how to configure it if you have questions, but a few notes are collected here below.
To change the logging for Sakai in the source you can use sakai-src/kernel/log-configure/src/conf/log4j.properties, and the relevant property is:
log4j.logger.org.sakaiproject=INFO
To turn on debug logging for all of Sakai, change that value from INFO to DEBUG. In order to turn on debug logging for just a single component of Sakai, add a line such as in the following example, which will leave most of Sakai at INFO, but generate DEBUG level messages for the SQL service:
log4j.logger.org.sakaiproject=INFO log4j.logger.org.sakaiproject.component.framework.sql.BasicSqlService=DEBUG
The logging controls are part of the LogConfigurationManager, implemented as a component in the util module. It can be disabled, if that's desired, with an entry in sakai.properties:
enabled@org.sakaiproject.log.api.LogConfigurationManager = false
For Mac and *nix systems, the most important log is found in Tomcat's logs/catalina.out. It can be instructive to watch this log as Tomcat is starting up, by using a startup command like the following:
bin/startup.sh; tail -f logs/catalina.out
Tomcat on Windows tends to be a little more puzzling about its logs, and it includes more of them, but its default behavior is to open catalina.out in a new window as soon as you start Tomcat. If you need more information about the logs in Windows, we'll refer you to the official Tomcat documentation.
The SMTP server logs from Sakai will be written to the $CATALINA_HOME/sakai/logs directory.
4.0 Supported Database
Sakai has been tested against and supports the following production-grade databases:
| MySQL | Oracle |
|---|---|
| MySQL 5.0.x | Oracle 10g |
| MySQL 4.1.12+ | Oracle 9i |
Sakai requires transaction support. In the case of MySQL you must implement the InnoDB storage engine to ensure proper transaction handling.
4.1 Create Database
For pilot and production installations a Sakai database and privileged user must be prepared for Sakai's use. Consult your database documentation for details, but below are sample commands for MySQL.
You can check to see if MySQL is installed on your system by checking the version from the command line.
sakaiger$ mysql --version mysql Ver 14.12 Distrib 5.0.45, for apple-darwin8.5.1 (i686) using readline 5.0
If MySQL is not installed download it from http://dev.mysql.com/downloads/. Linux users should install MySQL using a package or binaries if possible. Choose the standard configuration. Windows users should consider installing MySQL as a service. Remember to include MySQL's /bin directory in your PATH statement.
C:\opt\mysql\> mysql -u root -p Enter password: ****** Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 51 to server version: 4.1.5-gamma-nt Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create database sakai default character set utf8; Query OK, 1 row affected (0.00 sec) mysql> grant all on sakai.* to sakaiuser@'localhost' identified by 'sakaipassword'; Query OK, 0 rows affected (0.00 sec mysql> grant all on sakai.* to sakaiuser@'127.0.0.1' identified by 'sakaipassword'; Query OK, 0 rows affected (0.00 sec) mysql> quit
Note that you will not need to create Sakai database objects (tables, indices, etc) when setting up your database. Sakai generates its own database schema automatically during the Tomcat setup process via the autoDDL setting in sakai.properties.
UTF-8 Character Set
Irrespective of whether you utilize MySQL or Oracle be sure you have configured your database to use the UTF-8 character set. Failure to do so will result in range of issues when attempting to use Unicode characters in Sakai. Consult your Db documentation or a local DBA for instructions on how to set your database up properly.
If you are uncertain as to how your database is currently configured, you can check with a query. Here is a sample query for checking an Oracle instance:
SQL> select value from nls_database_parameters where parameter = 'NLS_CHARACTERSET'; VALUE -------------------------------------------------------------------------------- AL32UTF8
For Mysql, the command to see what encoding your database is currently set to is "show create database sakai", assuming, of course, that your database is named "sakai". e.g.:
mysql> show create database sakai; +----------+----------------------------------------------------------------+ | Database | Create Database | +----------+----------------------------------------------------------------+ | sakai | CREATE DATABASE `sakai` /*!40100 DEFAULT CHARACTER SET utf8 */ | +----------+----------------------------------------------------------------+ 1 row in set (0.00 sec)
Converting a database from one character set to another is a non-trivial operation, particularly if it is a large production database. We recommend strongly that you verify this aspect of the database creation and configuration process before deploying Sakai.
4.2 Add Database Drivers
Choose the appropriate MySQL or Oracle JDBC driver (or connector) for your installation.
MySQL Connector/J Driver
For MySQL, download the *zip/*tar.gz archive, extract its contents and copy the mysql-connector-java-<version>-bin.jar to $CATALINA_HOME/common/lib.
| Db Version | Connector/J |
|---|---|
| MySQL 5.0.x | MySQL Connector/J 5.0.4+ http://dev.mysql.com/downloads/connector/j/5.0.html |
| MySQL 4.1.12+ | MySQL Connector/J 3.1.12+ http://dev.mysql.com/downloads/connector/j/3.1.html |
For MySQL 4.1 users problems have been reported for both the MySQL Connector/J 3.1.10 and 3.1.11 drivers. Choose version 3.1.12 or higher.
Oracle OJDBC Driver
For Oracle download the ojdbc14.jar file and copy it to $CATALINA_HOME/common/lib.
| Db Version | JDBC Driver |
|---|---|
| Oracle 10g/Oracle 9i | http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html |
Both Oracle 10g AND Oracle 9i users must use the 10g driver; the latest 10g "Release 2" (10.2.x) or higher is recommended.
4.3 Configure Database Connection Settings
The sakai.properties configuration file defines database technology and connection information. Appropriate sample settings for HSQLDB, Oracle and MySQL are listed below.
By default, all Sakai distributions are configured to use an in-memory version of HSQLDB. HSQLDB is provided for testing/demo purposes only and should not be run in production.
Whatever database you choose to use, you will need to modify at a minimum the following connection settings:
url@javax.sql.BaseDataSource
username@javax.sql.BaseDataSource
password@javax.sql.BaseDataSource
Set the Database Username and Password
Start by setting your database username and password:
# DATABASE CONFIGURATION - make sure to modify details to match your particular setup # The username and password. The defaults are for the out-of-the-box HSQLDB. Change to match your setup. username@javax.sql.BaseDataSource=yourDbUserName password@javax.sql.BaseDataSource=yourDbPassword
Configure Database Settings
HSQLDB Sample Configuration
HSQLDB is Sakai's default database. Remember to comment out its settings should you choose to run Sakai utilizing either MySQL or Oracle.
## HSQLDB settings - on by default
vendor@org.sakaiproject.db.api.SqlService=hsqldb
driverClassName@javax.sql.BaseDataSource=org.hsqldb.jdbcDriver
hibernate.dialect=org.hibernate.dialect.HSQLDialect
validationQuery@javax.sql.BaseDataSource=select 1 from INFORMATION_SCHEMA.SYSTEM_USERS
# two hsqldb storage options: first for in-memory (no persistence between runs), second for disk based
#url@javax.sql.BaseDataSource=jdbc:hsqldb:mem:sakai
url@javax.sql.BaseDataSource=jdbc:hsqldb:file:${sakai.home}db/sakai.db
MySQL Sample Configuration
Locate the MySQL configuration block, uncomment the settings and save your changes. Make sure you modify the data source, username and password settings to match your local environment. Do not forget to comment out the HSQLDB and Oracle settings.
# MySQL settings - make sure to alter as appropriate vendor@org.sakaiproject.db.api.SqlService=mysql driverClassName@javax.sql.BaseDataSource=com.mysql.jdbc.Driver hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect url@javax.sql.BaseDataSource=jdbc:mysql://127.0.0.1:3306/sakai?useUnicode=true&characterEncoding=UTF-8 validationQuery@javax.sql.BaseDataSource=select 1 from DUAL defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED # To get accurate mysql query throughput statistics (for example for graphing) from the mysql command # show status like 'Com_select' # this alternate validation query should be used so as not to increment the query counter unnecessarily # when validating the connection: #validationQuery@javax.sql.BaseDataSource=show variables like 'version'
Oracle Sample Configuration
Locate the Oracle configuration block, uncomment the settings and save your changes. Make sure you modify the data source, username and password settings to match your local environment. Do not forget to comment out the HSQLDB and MySQL settings.
## Oracle settings - make sure to alter as appropriate vendor@org.sakaiproject.db.api.SqlService=oracle driverClassName@javax.sql.BaseDataSource=oracle.jdbc.driver.OracleDriver hibernate.dialect=org.hibernate.dialect.Oracle9Dialect url@javax.sql.BaseDataSource=jdbc:oracle:thin:@your.oracle.dns:1521:SID validationQuery@javax.sql.BaseDataSource=select 1 from DUAL defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED
Oracle users may experience performance issues with certain of the SQL settings that work for HSQL and MySQL. Oracle users can reduce Db load by uncommenting the following settings:
# For improved Oracle performance (from the University of Michigan) validationQuery@javax.sql.BaseDataSource= defaultTransactionIsolationString@javax.sql.BaseDataSource= testOnBorrow@javax.sql.BaseDataSource=false
The auto.ddl Setting
On startup, Sakai will generate all database objects (tables, keys, constraints, etc.) automatically, obviating the need to run DDL scripts manually.
# establish auto.ddl - on by default auto.ddl=true #auto.ddl=false
Once the database schema is created you should set auto.ddl=false.
Sakai 2.x Administrator's Guide
This is a single-page version of the Sakai 2.x Administrator's guide, which is intended to be more useful for printing and exporting the document in PDF format. To export in PDF format, click the PDF icon (
) that appears in the top right side of each Confluence page.
You can also view the guide in sections.
Introduction
This document covers the basics involved in moving from limited exploration of Sakai to something that can be used reliably by a larger group of users. The document will take as a given a working Sakai installation that uses the out of the box defaults.
This document assumes you have already been able to successfully install Sakai. It is also recommended that you take a moment to familiarize yourself with using the application before exploring the topics in this guide.
If you get stuck during the installation or configuration process, please start by searching this site and/or an archive of the sakai-dev list (such as gmane). If all else fails, join the Sakai developer list (sakai-dev) or the Sakai production list (production) and ask for help. For more information, see the "Joining the Community" section of this document.
The sakai.properties file
As mentioned in other areas, the sakai.properties file is a central configuration file that is typically stored in a sakai subdirectory relative to the tomcat home directory ([here are details on changing the default location]). All settings in the sakai.properties file are only read on startup, thus any changes you make will only take effect when you restart tomcat.
The sakai.properties file is a non-XML text file containing a series of key/value pairs that can be read using the load method of java.util.properties.
The first type of simple property (used to set booleans, simple strings, integers, etc.) is set simply by separating a key from a value with an equal sign, along the lines of:
sampleboolean=true samplestring=set to a string value with one or more spaces, ending in a new line
Sakai makes use of hierarchical lists of property values, which require that you specify a "count" variable indicating the total number of values. The values themselves are defined by appending a number after each instance of the key. Here's an example:
sampleproperty.count=3 sampleproperty.1=peas sampleproperty.2=porridge sampleproperty.3=hot
Configuring the sakai.properties file
An option set in the sakai.properties file is only meaningful if one or more sections of the Sakai code base read and make use of the option and its configured value. There are at present over 250 configuration options used by portions of the Sakai 2.4 code base.
To assist users in setting the most important of the options, an example sakai.properties file is included with the Sakai source, in the directory reference/docs relative to the root of the source directory. The demo and binary distributions are distributed with a basic sakai.properties file as well, which should be stored in the sakai directory relative to the tomcat install included with the distribution.
Starting with this file, it is most critical to review and edit the following settings:
These and other configuration settings are mentioned throughout the remainder of this document. For a full glossary of available configuration options, consult the Sakai Properties Reference.
The Configuration Viewer tool
There is an optional tool available to provide a detailed guide to the sakai.properties file. For more information, visit the Config Viewer Tool home page.
This tool includes a complete list of known sakai properties, which you can download independently of the tool and open using Excel or any spreadsheet program that can open tab-delimited text files. The latest version of the sakai properties data can be found here:
Branding and Identity
sakai.properties settings
There are a number of configuration options found in the sakai.properties file that control branding and identity. These settings are responsible not only for changing the cosmetic wording that end users see in the web interface, but also for customizing information found in logs and email messages.
| Setting | Description |
|---|---|
| ui.institution | The name of the organization associated with this Sakai installation (such as "My University"). |
| ui.service | The local brand for Sakai within the institution. Among other things, this text is displayed at the root of the bread crumb bar that appears within Sakai. |
| serverId | A unique identifier for the particular server Sakai is running on. This is used to distinguish nodes in a clustered environment from one another. |
| serverUrl | The full service URL for this installation of Sakai |
| serverName | The server name for this installation of Sakai (this should match the value for serverUrl). |
| skin.repo | The location in which skins for this site are housed. This can be set to a relative or absolute URL. The default is /library/skin, which includes the default skins bundled with Sakai. |
| skin.default | The default skin to use for all sites. This should be the name of a skin directory that exists in the skin home directory. |
Skinning
To further change the look of a Sakai installation, it is possible to "reskin" the installation using a series of style sheets and/or updated graphics, which are typically stored in TOMCAT_HOME/webapps/library/skin. For more information about skinning your Sakai installation, visit the "Reskinning Sakai" section of the Sakaipedia.
Binary Content and Filesystem Settings
Binary content (files) uploaded into Sakai can either be stored in the database itself, or on the filesystem. By default, binary content is stored in the database.
Storing binary content on the filesystem
To use the filesystem to store binary content, add properties like the following to your sakai.properties file:
bodyPath@org.sakaiproject.content.api.ContentHostingService=/content/sakai # Only uncomment the bodyVolumes property if you have multiple content volumes # (sub directories/ mount points relative to the location specified above) bodyVolumes@org.sakaiproject.content.api.ContentHostingService=vol1,vol2,vol3 # uncomment the next line if you wish to set a site quota of 1Gb # siteQuota@org.sakaiproject.content.api.ContentHostingService=1048576
Note that Sakai only balances content between active volumes. Sakai doesn't check the availabilty of disk space on each volume. So, for example, if you have a single volume containing 100Mb of filesystem content and add four additional volumes, when another 400Mb of files are added, the distribution is likely to be something like 180Mb on the first volume and 80Mb on each of the new volumes.
| Body volumes should not include spaces Warning: If you are using filesystem storage, you should be very careful not to include spaces before or after the commas in your bodyVolumes@org.sakaiproject.content.api.ContentHostingService. This will cause your volume to be created with spaces in their names, which can cause problems. For more information, see: |
| Setting at least one body volume Note: If you are using filesystem storage, you should set at least one volume by adding a bodyVolumes@org.sakaiproject.content.api.ContentHostingService option (see above). This will give you room to expand and relocate your filesystem content as your Sakai installation grows. If you do not set this option, binary content will be stored in the root of the directory specified in bodyPath@org.sakaiproject.content.api.ContentHostingService. |
Storing binary content in the database
To use the database to store binary content, comment out the directives mentioned above in your sakai.properties file. Any content already located on the filesystem will remain on the filesystem.
Migrating from database storage to filesystem storage
If you have previously stored your binary content in the database and would like to move that content to the filesystem, add the following directive to your sakai.properties file and restart:
convertToFile@org.sakaiproject.content.api.ContentHostingService=true
There is currently no conversion route to move from storing content on the filesystem to storing content in the database.
Antivirus Scanning
The Rsmart group has developed a wrapper for content hosting that uses ClamAV to scan incoming binary content before it is stored. Source code can be found at:
https://source.sakaiproject.org/contrib/rsmart/antivirus/
Database Configuration and Tuning
By default, all distributions of Sakai are configured to use an in-memory version of HSQL db, which is adequate for very basic testing, but does not offer the same reliability and scalability as a more robust relational database. Many developers and the vast majority of Sakai installations choose to use either MySQL or Oracle in production. The reference sakai.properties files include example configurations for Oracle and MySQL. Rather than copying and pasting this code, you should comment out the database configurations you aren't using, and then uncomment and modify the settings appropriate for your database.
Here is a sample configuration block for Oracle:
# Oracle settings - make sure to alter as appropriate vendor@org.sakaiproject.db.api.SqlService=oracle driverClassName@javax.sql.BaseDataSource=oracle.jdbc.driver.OracleDriver hibernate.dialect=org.hibernate.dialect.Oracle9Dialect url@javax.sql.BaseDataSource=jdbc:oracle:thin:@your.oracle.dns:1521:SID validationQuery@javax.sql.BaseDataSource=select 1 from DUAL defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED
Here is a sample configuration block for MySQL:
# MySQL settings - make sure to alter as appropriate
vendor@org.sakaiproject.db.api.SqlService=mysql
driverClassName@javax.sql.BaseDataSource=com.mysql.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MySQLDialect
url@javax.sql.BaseDataSource=jdbc:mysql://127.0.0.1:3306/sakai?useUnicode=true&characterEncoding=UTF-8
validationQuery@javax.sql.BaseDataSource=show variables like 'version'
defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED
When using this block or uncommenting an existing block, you will need to modify the connection settings specified by the setting url@javax.sql.BaseDataSource at the very least. In addition, you'll need to set the username and password options whichever database you choose, as in:
username@javax.sql.BaseDataSource=sakai password@javax.sql.BaseDataSource=********
Configuring for Performance
Larger institutions have found the database to be the bottleneck when it comes to Sakai performance. Setting additional database configuration settings may be worth considering (see below for tips for Oracle and MySQL).
Oracle
Oracle may have performance problems with some of the SQL settings that work for HSQL and MySQL. Sakai installations using Oracle should strongly consider the following settings in sakai.properties to avoid these problems:
# For improved Oracle performance (from the University of Michigan) validationQuery@javax.sql.BaseDataSource= defaultTransactionIsolationString@javax.sql.BaseDataSource= testOnBorrow@javax.sql.BaseDataSource=false
These settings will reduce the DB load by not forcing these settings with each use or transaction.
Oracle and Tests & Quizzes
If you're running Oracle and using the Tests&Quizzes tool you should check the datatype of the MEDIA column in the SAM_MEDIA_T table. Hibernate tries to choose the right data type for a field, but has a habit of choosing the wrong one for Oracle. The correct types for each database are:
HSQL: varbinary
MySQL: longblob
Oracle: blob
If you need to change this type for your database, this will also involve finding the primary key constraint, dropping it and then recreating it. Contact your local DBA for further information on making this change. Below is some sample Oracle SQLplus output to better illustrate (SYS_C0064435 is the example constraint; replace it with yours):
SQL> alter table SAM_MEDIA_T modify MEDIA BLOB; Table altered. SQL> select constraint_name from user_constraints where table_name='SAM_MEDIA_T' and CONSTRAINT_TYPE='P'; CONSTRAINT_NAME ------------------------------ SYS_C0064435 SQL> alter table sam_media_t drop constraint SYS_C0064435; Table altered. SQL> alter table SAM_MEDIA_T add constraint SYS_C0064435 primary key (MEDIAID); Table altered. SQL> desc SAM_MEDIA_T; [table with BLOB type] SQL> select constraint_name from user_constraints where table_name='SAM_MEDIA_T' and CONSTRAINT_TYPE='P'; CONSTRAINT_NAME ------------------------------ SYS_C0064435 SQL> commit; Commit complete.
MySQL
Case Sensitivity
By default, table names in MySQL are case insensitive on Windows, and case sensitive on UNIX systems. Portions of Sakai that attempt to access tables directly may specify table names in all uppercase or lowercase, which may cause problems if the name specified in the query does not correspond exactly to the name of the table. The solution to this problem (other than waiting for code to be cleaned up) is to configure MySQL to think of table names as being case insensitive. This can be accomplished by editing /etc/my.cnf and adding the following:
lower_case_table_names=1
Query Caching
MySQL performance can be considerably improved by caching queries. You can do this by editing your sakai.properties file and altering the connection string as below, all on one line.
url@javax.sql.BaseDataSource=jdbc:mysql://localhost:3306/sakai?useUnicode=true&characterEncoding=UTF-8 &useServerPrepStmts=false&cachePrepStmts=true&prepStmtCacheSize=4096&prepStmtCacheSqlLimit=4096
The parameter that enables use of the query cache is 'useServerPrepStmts=false', while the others (cachePrepStmts=true, prepStmtCacheSize=4096, and prepStmtCacheSqlLimit=4096) enable caching of prepared statements on the server side. Based on production experience at UniSA, a query cache size of 128M is recommended. The query cache size is typically configured on UNIX systems by editing /etc/my.cnf to like this:
[mysqld] query_cache_size = 128M
You will need to restart your instance of mysql after making the change.
There are some other settable properties for the query cache, but there doesn't seem to be a need to change the defaults. To learn more, you can visit:
- http://dev.mysql.com/doc/refman/4.1/en/query-cache-configuration.html
- http://dev.mysql.com/doc/refman/4.1/en/connector-j-reference-configuration-properties.html
| MySQL 5 The above configuration properties work for MySQL 4.1 only. The connection parameters that allow MySQL caching on MySQL 4 cause problems with bit types on MySQL 5. Until the issue is resolved MySQL 5 cannot be recommended for Sakai production, since the use of a non-caching string results in markedly poorer performance. |
SAKAI_PRESENCE as an in-memory table
Running SAKAI_PRESENCE as an in-memory table can have a significant positive effect on performance for MySQL. The SQL necessary to convert is just:
DROP TABLE SAKAI_PRESENCE; CREATE TABLE `SAKAI_PRESENCE` ( `SESSION_ID` varchar(36) default NULL, `LOCATION_ID` varchar(255) default NULL, KEY `SAKAI_PRESENCE_SESSION_INDEX` (`SESSION_ID`), KEY `SAKAI_PRESENCE_LOCATION_INDEX` (`LOCATION_ID`) ) ENGINE=MEMORY DEFAULT CHARSET=utf8;
But be sure to run this at a quiet time as otherwise you'd be sure to generate some odd results for users.
Disk I/O issues on Linux (Suse Linux Enterprise Server 9/Red Hat Enterprise Linux 4)
A Linux database server may see big disk-hanging delays (especially if the DB and the web server are on the same machine) under load. This appears to be a side effect of the default SLES9 I/O scheduler, CFQ. The Deadline scheduler, which has a maximum latency for serving requests, is therefore a better choice for database operations - although pages may still render slowly under load, performance will degrade more gracefully, avoiding hangs, and will provide some feedback to users.
To switch to the Deadline scheduler, the boot parameter elevator=deadline must be passed to the kernel that's being used. You can do so by editing the /etc/grub.conf file and adding the parameter to the kernel that's being used:
title Red Hat Enterprise Linux AS (2.4.21-32.0.1.ELhugemem) root (hd0,0) kernel /vmlinuz-2.4.21-32.0.1.ELhugemem ro root=/dev/sda2 elevator=deadline reboot=warm initrd /initrd-2.4.21-32.0.1.ELhugemem.img
You will need to reboot the system to activate the new scheduler.
For more information about these Database issues, refer to the following:
- http://www.puschitz.com/TuningLinuxForOracle.shtml
- http://nextre.it/oracledocs/ioscheduler_01.html
- http://www.open-mag.com/features/Vol_104/SLES9/SLES9.htm
Email Configuration
Out of the box, Sakai uses incoming mail to receive content that will be viewed using the Mail Archive tool, and to receive delivery failure notifications for outgoing messages. Outgoing mail is used for notification purposes, bug reporting, and to deliver content received by the Mail Archive tool.
You need to change a handful of settings within and outside of sakai to get mail working. Most of the changes are in sakai.properties, and will require you to stop Sakai, remove the sakai-mailarchive-james directory under webapps (but leave sakai-mailarchive-james.war), and then start Sakai again.
Outgoing Mail
For outgoing mail, you'll also need to set smtp.dns.1 and smtp.dns.2 to your DNS servers, and to set smtp@org.sakaiproject.email.api.EmailService to a host that handles SMTP in your environment. James can also handle outgoing mail for Sakai, but that this should only be used for small scale installations, as James will not provide the same level of robustness as a dedicated mail server. In particular, James will not handle delivery failures nicely, which makes it unsuited for a real deployment.
You'll probably also want to set setup.request so that informational messages either appear to come from a meaningful address (such as helpdesk@your.institution) or to clearly not come from a usable address (such as noreply@your.sakai.hostname).
You can make all the changes at once, but you'll need to stop sakai, remove webapps/sakai-mailarchive-james/, and then start sakai again each time you want for changes to take effect in james.
Testing Outgoing Mail Using a Notification
The simplest way to test outgoing mail is to add a guest user to a site and enable notification:
- Log in to Sakai as an administrator (or at least a site maintainer)
- Navigate to a worksite
- Open the "Site Info" tool
- Click the "Add Participants" Link
- Enter a valid email address that you have the ability to check under the "Guest(s) Email Address" heading (the lower text area), then click "Continue"
- Select a site role (usually "access" or "maintain"), then click "Continue"
- Tick the "Send Now" radio button and hit "Continue"
- Click "Finish"
A mail message should have been sent to the email address you entered for the guest account.
Incoming Mail
To receive mail, you need to set smtp.enabled to true. You'll also need to set serverName to the service name of your installation (as in sakai.your.institution), so that James knows what messages it should field. You should also set serverId to the real hostname of the individual machine (or at least the unique part of it).
If you don't already have a mail transport agent (ala sendmail or postfix) and can bind to port 25, you should change smtp.port to 25. If you already have a mail agent, you'll need to find some way to move the appropriate mail from port 25 to 8025 (where james lives). You can use a NAT rule, or can configure sendmail or postfix to do the forwarding for you:
Sendmail Integration Instructions: http://bugs.sakaiproject.org/confluence/display/ENC/Sendmail+integration
Postfix Integration Instructions: http://article.gmane.org/gmane.comp.cms.sakai.devel/6139/
Exim Integration Instructions: Exim Configuration
The following is a sample section of sakai.properties including all of the above changes:
# enable James smtp.enabled=true # configuring the port on which James listens. In this example, another component (NAT rules, Sendmail) forward from 25 to 8025 smtp.port=8025 # James will only accept messages for this hostname serverName=service.my.edu # You'll get more meaningful feedback if you have the node name configured serverID=node.my.edu
You can make these changes all at once, but you'll need to stop sakai, remove webapps/sakai-mailarchive-james/, and then start sakai again each time you want for changes to take effect in james.
Testing Incoming (and outgoing) Mail Using James
Once you get all that done and start Sakai, you should be able to test the your configuration as follows:
- make sure James is listening on the right port
telnet {the value you used for serverName} 8025 [or 25 if you've set it to that]- you should see a status message from the server indicating the server name and the MTA. The server name should match what you put in for serverId (plus a domain), and should be followed by something like
(James SMTP Server 2.1.3) ready {date and time}
- Set up a site for testing the mail archive tool
- Create a new site that includes the mailarchive tool.
- Open the mailarchive tool in the new site. You should see the value of serverName as configured in sakai.properties.
- Change the options for the mailarchive tool to accept mail from anyone (this makes it easier to test things).
- Enroll a user in the test site with an email address you can monitor. Once this is done, you should get a copy of your test messages.
- Test James from the command line using telnet
- Connect to James using the port you set up above and a command like the following:
telnet {your hostname, or localhost} 8025 - Now type:
EHLO {your service name, ala sakai.your.institution) - You should see a response like:
250 {serverID.domain} Hello {serverName} (localhost [127.0.0.1]) - Now type:
MAIL FROM:<{your.email@your.institution}>and hit enter.
- You should see a receipt like:
250 Sender <{your.email@your.institution}> OK - Now type:
RCPT TO:<{the email address you entered for the mailarchive tool in your site}>and hit enter.
- You should see a receipt like:
250 Recipient <{email address for the mailarchive tool in your site} OK - Now type:
DATA
and hit enter.
- Now type:
Subject: test...
(or something like that) and hit enter.
- Now type the body of your message as in:
This is a message I am using to test James.
When you're done entering the body of the message, hit enter twice.
- Now hit enter, enter a single period, then hit enter.
- You should see a receipt like:
250 Message received
- Now type:
QUIT
and hit enter.
- Check the mailarchive tool to see if your message made it in.
- If that doesn't work, go back and check your settings. The log files logs/catalina.out and sakai/logs/james-DATE may help figure out what's wrong.
- Connect to James using the port you set up above and a command like the following:
- If you have a separate mail transport agent (i.e. sendmail or postfix), try the same steps as above, but with the port for the MTA (25) instead of James.
- Check to see that you've received a copy of the messages. If you haven't, check the logs and look for details in the returned message that will eventually be sent to the MAIL FROM: address you entered.
Delivery Failure Notifications
If you wish to receive delivery failure notifications, abuse notifications, etc. for mail sent from your Sakai installation, you should make sure that postmaster@{your service name} is a working email address. It is also advisable to set meaningful email addresses for the postmaster and admin users included with Sakai. If you are using James as a standalone mail server or forwarding all mail for your service host name to James, you may wish to configure an instance of the Email Archive tool to receive, display, and forward all mail for postmaster. By default, the alias "postmaster" is reserved (to prevent site maintainers from assuming that address). In order to set up an instance of the Email Archive tool to handle the postmaster address, you will need to manually remove the entry for the postmaster address from the sakai_alias table. You should then immediately add an instance of the Email Archive tool to a site of your choice (either the Admin Workspace or a dedicated site). Messages received for postmaster by James will then be viewable in the instance of the Email Archive tool you've set up. You should configure that instance of the Email Archive tool to accept messages from anyone.
Email Archive Tool Alias Naming Limitation
As noted above, Sakai includes a postmaster account for use by James. As a consequence, the alias "postmaster" is reserved and should never be used as an Email Archive Tool alias. Doing so will result in Sakai throwing a runtime error.
Configuring Sakai from within the Web Application
Once Sakai is up and running and you are familiar with the basic operation of the software, there are few common administrative tasks that you may wish to perform.
|
Change the Default Administrator's Password
|
Adding Administrative Users
If you wish to delegate administrative permissions to a range of users and wish a clearer audit trail for admin changes, you may want to set up additional administrator accounts. To add a new administrative user:
- Log in as an existing administrator
- Under the "Administration Workspace" site, open the "Users" tool.
- Click the "New User" link.
- Enter the new user's information and set their type to admin (mostly a nicety to help remember who the admins are)
- Click "Save Details"
- Open the "Worksite Setup" tool. Check the box next to the "Administration Workspace" site, then click "Edit".
- Click "Add Participants" then enter the username you created earlier in the "Username(s)" text area (the upper of the two). Click "Continue".
- Tick the radio button for the "admin" role, then click "Continue".
- Select your notification options if desired, then click "Continue".
- Click "Finish" to add the user to the Administration Workspace as an admin.
If you wish to give a user superadmin privileges without adding them to the Administrative Workspace site:
- Create a new user following the first 5 steps above.
- Under the "Administration Workspace" site, open the "Realms" tool.
- Enter "/site/!admin" in the search field and hit the "Search" link.
- Click the "/site/!admin" link that appears in the list of results.
- Click the "Grant Ability" link at the top of the screen that appears.
- Enter the id of the user created above in the "User Id:" text box, select the "admin" role, then click "Done".
Manually Adding a Tool to a Sakai Site.
By default, a number of provisional tools are included with Sakai, but can only be added to a site manually. This process is detailed in the SakaiPedia entry "Manually Adding a Tool to a Sakai Site".
Displaying dynamic HTML within the gateway and other sites.
By default, the gateway site displayed before users logged in displays a two-column layout containing the latest message of the day and the content of the location specified by server.info.url in your sakai.properties file. The default location for server.info.url points to a static HTML file bundled with a standar Sakai installation. Administrators are likely to prefer a message that can be updated without requiring a restart. Here's an approach to making the server info displayed in the gateway dynamic:
- Open the "Administration Workspace"
- Open the "Resources" tool
- Click on the "public" directory.
- Use the triangle to the right of the Add button to select the "Create HTML Page" option.
- Enter your content, then click "Continue.
- Select a name and copyright options for your page, then click "Finish".
- Once the page is saved, copy and paste the URL for your page into memory (the URL will typically be something like http://hostname/public/Your File Name.
- Edit your sakai.properties file and set server.info.url to the URL specified above (the protocol and port are optional).
- Restart Sakai
A similar approach can be used to prepare public content for use in any site or template. As above, create public content from the "Administration Workspace" site. Once you've saved your content, simply add an additional "Web Content" tool to the site in question. Here's an example in which we add a custom page to the default template for new "My Workspace" sites (useful for training materials, etc.):
- Follow the steps to create a dynamic page as in the previous examples.
- Open the "Sites" tool
- Open the "My Workspace" template (!user)
- Click the "Pages" button
- Click the "New Page" link
- Enter a name for your new page (this will appear in the list of pages in the navigation bar).
- Click the "Tools" button
- Click the "New Tool" link
- Select the radio button next to the "Web Content" tool
- Scroll down and enter the URL you copied above into the "source" field.
- Click "Done" to save your changes.
Template sites only show up in the "Sites" tool. For individual sites, you can simply add the dynamic content as follows:
- Follow the steps to create a dynamic page as in the previous examples.
- Open the site
- Open the "Site Info" tool
- Click the "Edit Tools" link
- Select the "Web Content" tool, then click "Continue"
- Enter the URL you copied above into the "URL" field, then click "Continue", then "Finish"
Permissions
The permission to view, edit, delete, and otherwise manage the data associated with Sakai tools is managed using realms, which are most commonly associated with a site. Each realm has one or more roles to which a user can be assigned. Permissions are managed using the Realms tool in the administrative workspace.
Examples of roles would be instructor, student, teaching assistant, grader, site maintainer, site accessor. A role is typically given a single word name like "instructor", "student", "ta", "grader", "maintain", "access". Each role specifies explicitly all of its permissions, and one set of permissions does not imply another (for example, "add" for a given tool does not imply "edit" or even "read" for the same tool).
The default permissions for a realm are inherited from the most appropriate realm template for a given site at the time the site is created. A site with a type of "project" would inherit from the realm !site.template.project realm if it exists, or from the !site.template realm if !site.template.project realm does not exist.
JVM Tuning
JVM tuning is an ever-evolving process that changes with each version of Java. Even for development instances, you'll need to read through and apply the basic JVM tuning suggestions below.
Basic JVM Tuning
The default JVM settings are not adequate to run Sakai. At a minimum, you need to increase the overall heap size and the maximum size allowed for the permanent generation. This can be done as follows.
Mac/Linux: Create the file TOMCAT_HOME/bin/setenv.sh containing a line like the following:
export JAVA_OPTS="-server -XX:+UseParallelGC -Xmx768m -XX:MaxPermSize=160m -Djava.awt.headless=true"
Windows(PC): Create the file TOMCAT_HOME/bin/setenv.bat containing a line like the following:
set JAVA_OPTS=-server -XX:+UseParallelGC -Xmx768m -XX:MaxPermSize=160m -Djava.awt.headless=true
Advanced JVM Tuning
For more information, please see:
Load Balancing and Scaling
Introduction
Although Sakai can be run on a single server which houses all database and filesystem content, many sites will want to consider growing their installation beyond the confines of a single server. This section of the admin guide will outline the basic approach to scaling up your sakai installation. When deciding which approach is best for you, you should consider the information below. Whatever solution you choose should be tested for performance and tuned as needed. For more information on tuning, see the Sakai Admin Guide - JVM Tuning and Sakai Admin Guide - Database Configuration and Tuning sections of the admin guide.
Standalone Server

The simplest option is to run all components of Sakai on a single server. As indicated by the asterisks in the diagram, Apache and filesystem storage are optional components, as Sakai can run with Apache (using Tomcat to handle requests directly) and can be made to store binary content in the database.
This configuration entails installing a database server locally or using the default Hypersonic SQL implementation bundled with Sakai. This option offers the least benefits in terms of scalability and redundancy.
However, this configuration is highly portable, and can be set up on a reasonably powerful laptop. Thus it is ideally suited for a standalone development environment, which allows a developer to write and test tools and modules for Sakai without even a network connection. This is also a good option when demonstrating Sakai in environments without reliable networking.
Thin client configuration

A "thin" client is simply a server which only runs the application component of Sakai, and which does not house any database or filesystem content. This solution allows institutions with existing database and distributed storage resources to take advantage of their existing infrastructure. It may be acceptable to run a limited demonstration or pilot with this configuration, but a load balanced solution is recommended for anything beyond that (see below).
Load balanced thin client

A load balanced collection of thin clients is one of the scalable options for Sakai. It offers load balancing to distribute large volumes of traffic. It also offers redundancy, which allows for the more seamless management of hardware failures and preventative maintenance. In this configuration, each application server is pictured as only running tomcat, which is the minimum required to run Sakai.
Thicker client

A "thicker" client is simply an application server that runs one or more tomcat instances behind an apache instance. Adding Apache allows you to take advantage of the configurability and maturity of Apache, and also to set up clients that contain more than one instance of tomcat. A key reason to consider this information is the hard limit of memory usage on 32-bit hardware. The 32-bit JVM is only capable of addressing around 2G of RAM, which is tight for a full Sakai installation. You can install multiple tomcats on a single application server, and thus take better advantage of the memory available.
Big Iron

A number of sites have chosen to run with a smaller number of more powerful servers (as few as one), which are divided up into a series of virtual machines using solutions like VMWare. Although this may create a single point of failure for instances with only one large server, it offers the ability to dynamically allocate CPU and RAM among multiple virtual machines. It also has great advantages for change management, as a single node can be updated, tested, and then cloned into the appropriate number of updated application servers. Also, the state of a node can be saved for rolling back major changes if problems are detected later on.
Load Balancing Solutions
Sites running sakai in production have chosen to handle load balancing in a multitude of ways. These can roughly be divided into software solutions, which run on existing hardware, and hardware solutions, which run software on dedicated hardware, typically provided by a commercial vendor.
Software Solutions
The simplest software solution is to use an instance of Apache to balance traffic between multiple tomcat installations using mod_jk (apache 1.3 and 2.0) or mod_proxy_ajp (apache 2.2 and higher). Apache 2.2 or higher also offer the ability to use mod_proxy_balancer to balance multiple apache or tomcat installations. For more details on setting up tomcat with mod_proxy_ajp, see the Sakai Admin Guide - Advanced Tomcat (and Apache) Configuration section of the admin guide.
Hardware Solutions
There are a number of dedicated solutions provided by commercial vendors such as Big5 Networks and Zeus. Some solutions offer only the ability to load balance HTTP traffic (comparable to mod_proxy_balancer), while others offer the ability to use AJP (comparable to mod_jk or mod_proxy_ajp). Any solution that provides compatible sticky sessions (see below) should be capable of working with Sakai.
Sticky Sessions and Sakai
Whatever load balancing solution you choose, you must ensure that each client remains on the same app server for the life of their session. There are multiple approaches for monitoring and maintaining sticky sessions. Solutions that use IP-based sessions have problems with virtual private networks and proxies. Solutions that use dedicated cookies seem to work best for most people, but may cause problems with web services calls and some DAV clients. Whichever method you choose, be aware that the sticky session timeout is one of the factors controlling how long idle sessions remain active, as users will be required to log in again if they are sent to a different node after their sticky session times out.
Cluster Options in the sakai.properties File
Key portions of Sakai are designed to be cluster-aware. There are a handful of settings in the sakai.properties file that control the way in which clustering is managed.
| Property | Description |
|---|---|
| expired@org.sakaiproject.cluster.api.ClusterService | The time in seconds after which an inactive server will be expired from the cluster. |
| ghostingPercent@org.sakaiproject.cluster.api.ClusterService | The percentage of maintenance passes to run the full de-ghosting / cleanup activities, including delisting stale server nodes. |
| refresh@org.sakaiproject.cluster.api.ClusterService | How often (in seconds) a server should register that it is still alive. |
Clustering and auto.ddl
There have been problems reported lately with installations that enable the auto.ddl property on multiple nodes in a cluster. There are some suggestions that auto.ddl should only be used for the initial installation, and that updates should be managed using the migration scripts included with each release. Others choose to allow one node to start up with auto.ddl enabled, and to allow that node to create new tables, update existing tables, and create indexes.
Performance Testing
When testing and configuring for performance, you will be focusing on modifying one or more of the following:
- your tomcat JVM settings
- your tomcat configuration
- your apache configuration
- your database configuration
- operating system settings
- load balancer settings
- the number of application servers allocated
The basic methodology prior to moving into production is to simulate an appropriate amount of load, monitor performance, and tune components appropriately. Once you are in production, the basic methodology is to monitor performance and make incremental adjustments as needed.
There are a handful of commercial and free tools available for generating load. Of the commercial tools available, the most commonly used in the Sakai community are WebLoad and LoadRunner. Of the free tools available, the most commonly used is JMeter. For more information on using JMeter, please visit:
Advanced Tomcat Configuration
Tomcat as configured out of the box is adequate for development and very basic exploration of Sakai. If you want to move beyond this point, you will need to satisfy a few additional concerns, namely handling SSL and scaling beyond a single server.
Redirecting Traffic to the Portal
The default root context for tomcat provides documentation for tomcat itself when users visit the root of your site. When running Sakai in production, you should redirect traffic to your portal of choice by removing or renaming the existing content in TOMCAT/webapps/ROOT and replacing it with an index.html file with contents like:
<html> <head> <title>Redirecting to /portal</title> <meta http-equiv="Refresh" content="0:URL=/portal"> </head> <body bgcolor="#ffffff" onLoad="javascript:window.location='/portal';"> <div style="margin:18px;width:288px;background-color:#cccc99;padding:18px;border:thin solid #666600;text-align:justify"> <p style="margin-top:0px"> You are being redirected to the Sakai portal. If you are not automatically redirected, use the link below to continue:<br/> <a href="/portal">Take me to the Sakai portal</a> </p> </body> </html>
Configuring tomcat to handle SSL
SSL can be handled by tomcat itself, by putting tomcat behind an apache front end, or by putting tomcat (with or without apache) behind a dedicated load balancer. Tomcat standalone can either handle SSL natively, or can now be configured to use the tomcat-native jars and APR libraries to handle http and https.
Configuring tomcat to handle SSL natively
If you want to expose your Sakai installation to end users, you will need to set up SSL support using a certificate signed either by a local or external certificate authority. If you do not already have a certificate, you can create a self-signed certificate by running the following command as the user that will run sakai:
keytool -genrsa -alias tomcat -keyalg RSA
If you need to obtain and install a certificate signed by a trusted authority, review the tomcat documentation here:
http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html
You can also take an existing X509 certificate and private key and import them into a keystore using the following utility:
http://www.comu.de/docs/tomcat_ssl.htm
Once you have a .keystore file in your service user's root directory, you will need to uncomment the SSL connector in your tomcat's server.xml file:
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />
Configuring tomcat to use APR
If you take the time to install APR and the tomcat native libraries, tomcat can be made to work with an X509 certificate in PEM format without conversion. Those instructions can be found at:
http://tomcat.apache.org/tomcat-5.5-doc/apr.html
Configuring tomcat to force SSL for appropriate content
At a minimum, any components (login, xlogin) that transmit username and password information should be transmitted using SSL. To avoid problems with session cookie hijacking, it is recommended that an entire Sakai installation be secured with security being relaxed only as needed.
Securing Individual Tomcat Contexts
To secure an individual tomcat context, you must edit its WEB-INF/web.xml and add the following inside the <web-app> tags:
<!-- redirect all traffic to the SSL port -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Automatic SLL Forwarding</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
At a minimum, you should secure The ROOT and login contexts.
Securing All Tomcat Contexts
If you wish to secure the entire tomcat installation (which can be done regardless of how you provide SSL), add the following to TOMCAT_HOME/conf/web.xml inside the web-app tags:
<!-- redirect all traffic to the SSL port -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Automatic SLL Forwarding</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
| DAV issues when requiring SSL site-wide When using the above configuration to require SSL for your entire tomcat installation, you must ensure that the serverURL specified in your sakai.properties file specifies the https protocol, including the port if the port is not 443. If you fail to do this, the DAV functionality built into to Sakai may not function properly. (You'll also be requiring users to suffer through a redirect for most if not all URLs they follow within your Sakai installation.) |
Relaxing Security Restrictions for a Single Context
If you have content that is required to be transmitted using http (for example, a tool that exports subscribable iCal calendars), you may want to relax the overall security restriction for a single context. This can be done by adding the following to a context's WEB-INF/web.xml file:
<security-constraint>
<web-resource-collection>
<web-resource-name>SSL Requirement Disabled</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
| This will only ensure that SSL is not required. You can still of course use SSL to communicate with this context. |
Configuring Apache to proxy connections to tomcat
The following instructions will describe the basic options for setting up tomcat behind apache 2.2. Apache offers two main methods to proxy connections to tomcat: mod_proxy and mod_proxy_ajp.
Configuring mod_proxy
mod_proxy proxies connections to tomcat using plain http or https. The following configuration directives in your apache server's httpd.conf will map all contexts from a stock tomcat installation running on port 8080 to the root of the apache install:
ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/
If you are proxying an SSL connection to an SSL connection or a non-SSL connection to a non-SSL connection, you will need to reconfigure tomcat's connectors so that they are aware of the ports that end users are using. Otherwise the URLs tomcat constructs internally will reflect the wrong port numbers. This is accomplished by modifying the connectors defined in TOMCAT_HOME/conf/server.xml along these lines:
<Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" proxyName="{YOUR SERVICE NAME}" proxyPort="80" /> <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" proxyName="{YOUR SERVICE NAME}" proxyPort="443" />
The key changes are updating the redirectPort for non-SSL ports, and adding the ProxyName and ProxyPort attributes. Note that this must be done for each active connector that is being mapped using mod_proxy.
If you use mod_proxy to proxy an SSL connection to a non-SSL tomcat connector (such as the one that runs on port 8080 by default), you will need to add the force.url.secure parameter to your sakai.properties file, typically with a value like:
force.url.secure=443
Configuring mod_proxy_ajp
AJP, or the The Apache Jserv protocol is the protocol by which tomcat and some other proxying service (Apache or a dedicated hardware load balancer) communicate. If you intend to use apache to provide other static content or to handle SSL, you may want to configure Tomcat to listen for AJP requests, and the have Apache proxy requests for tomcat using AJP rather than HTTP or HTTPS. To do this, you will need to do the following:
- enable the AJP connector for one or more tomcat installations by editing TOMCAT_HOME/conf/server.xml and uncommenting the AJP connector included with the default distribution:
<Connector enableLookups="false" port="8009" protocol="AJP/1.3" redirectPort="8443"/>

If you are load balancing multiple tomcat instances on the same server, you will need to ensure that each one listens for AJP requests on a different IP address and/or port. - You can load balance requests between tomcat instances by adding something like the following to your Apache httpd.conf:
ProxyPass / balancer://sakaiCluster/ stickysession=JSESSIONID nofailover=On <Proxy balancer://sakaiCluster> BalancerMember ajp://localhost:8009 BalancerMember ajp://localhost:8019 BalancerMember ajp://localhost:8029 </Proxy>

You must have mod_proxy, mod_proxy_ajp, and mod_balancer enabled to use the above configuration options. It has also been noted that versions of mod_proxy_balancer prior to 2.2.4 have errors with this configuration.
Configuring mod_jk
mod_jk is an earlier (and still supported) apache module that supports proxying connections via AJP. mod_jk is available from tomcat.apache.org:
http://tomcat.apache.org/download-connectors.cgi
Once you have mod_jk installed, the simplest and most widely supported method of configuring mod_jk is to add directives like the following to your httpd.conf file:
# Set the location of the worker.properties file JkWorkersFile /etc/apache2/worker.properties # mount the root and all subdirectories associated with our Sakai installation JkMount /* sakaiWorker
You will then need to create a worker.properties file at the location specified in your httpd.conf which contains lines like the following:
# We only have one worker, so this is a short list. worker.list=sakaiWorker # The minimum properties for the sakaiWorker are set here worker.sakaiWorker.type=ajp13 worker.sakaiWorker.host=localhost worker.sakaiWorker.port=8009
For more information on configuring mod_jk (including examples that demonstrate using mod_jk to load balance between multiple tomcat instances), consult the Tomcat connector documentation.
Configuring Apache to Use Compression
If you are proxying connections to Tomcat through Apache, you may wish to look at enabling and configuring compression in Apache. This will allow Apache to greatly reduce the size of generated content prior to delivery to end users. This appeals particularly to sites whose users download content over dial-up or otherwise bandwidth-limited connections. Below are sample settings to be placed in httpd.conf (thanks to Stephen Marquard for those):
# mod_deflate (compress output for browsers that support it) AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript text/x-js application/json application/xml application/javascript # Some adjustments for IE browsers (c/f http://www.robertswarthout.com/rswarthout/2007/05/ie-6-apache-mod_deflate-blank-pages/) BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html BrowserMatch \bMSIE\s8 !no-gzip !gzip-only-text/html
| Some sites have experienced problems using compression with Apache 2.0. Apache 2.2 or higher is recommended when using compression. |
Configuring Tomcat Standalone to Work with a Load Balancer
If you have a software or hardware load balancer (see the Sakai Admin Guide - Load Balancing and Scaling section of the admin guide for more information), you can typically configure it to remap all traffic for the normal http and https ports associated with your service address to one or more instances of sakai. The steps for doing so will vary according to your load balancing solution, consult your load balancer's documentation for more information.
As above, if you proxy an SSL connection to Sakai to a non-SSL connector, you will need to add the force.url.secure parameter to your sakai.properties file, typically with a value like:
force.url.secure=443
References
For more information, visit the following pages:
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html
http://tomcat.apache.org/tomcat-3.3-doc/AJPv13.html
http://edocs.bea.com/wls/docs61/webapp/web_xml.html
Advanced Configuration Topics
This document covers advanced topics that may be of use in supporting and growing your Sakai installation.
Web Services
For information about Sakai's web services implementation, please visit:
- Web Services Documentation
- Home
- Assessment Web Services
- Announcement Web Services
- Content Hosting Web Services
- Web Services with Apache Axis
- CHS Web Services
For a good body of working examples, take a look at the Web services scripts available in the contrib space:
- https://source.sakaiproject.org/contrib/sakaiscript/webservices/examples
- https://source.sakaiproject.org/contrib/sakaiscript/clientexamples/
Quartz Scheduler
User Directory, Authentication, and Authorization Providers
A number of institutions have created providers to allow a Sakai install to authenticate and authorize users based on the contents of an external service. This section provides links to some of the documentation for the most commonly supported Auth/Auth mechanisms.
General
LDAP
- The Enterprise Working Group's LDAP Page
- The SakaiPedia Ldap Integration Page
- [The Standford KerberosLdap provider]
- A Presentation Regarding Integrating Sakai with LDAP that David Ross presented in Vancounter
CAS
- Steve Swindberg's notes on CAS Integration?
- Enterprise Working Group CAS Integration Page (older)
Shibboleth
SakaiPortalLogin Web Service
The SakaiPortalLogin Web service is used to allow a user who has been authenticated in a trusted external system (in most cases this would be a portal) to get into Sakai without having to log in again. Sometimes described as Single Sign On (SSO) this allows a user to move seamlessly from an external system into Sakai without having to login twice. To set this up use the following procedure:
1) Enable Sakai Web Services by adding the following entry to sakai.properties (by default Sakai Web Services are disabled):
- Indicates whether or not we allow web-service logins
webservices.allowlogin=true
1) Add the following entry in your sakai.properties file:
webservice.portalsecret = somePassword
This portalsecret is shared by Sakai and your trusted external system. When the trusted external system passes it to Sakai, Sakai knows that the Web service request is coming from a trusted server.
2) In your trusted external system (e.g. your portal) code a SakaiPortalLogin Web service to communicate with Sakai after the user has authenticated into the external system. Here is an example written in Coldfusion:
<cfinvoke webservice="http://#request.SakaiURL#/sakai-axis/SakaiPortalLogin.jws?wsdl" method="login" returnVariable="returnCode">
<cfinvokeargument name="id" value="the_User's_unique_identifier_in_Sakai"/>
<cfinvokeargument name="pw" value="the_portalSecret"/>
</cfinvoke>
If Sakai accepts the user's id and the portalsecret passed by the SakaiPortalLogin it will return a session (in the above Coldfusion example that session is contained in the variable "returnCode").
3) Add the following link to a Web page in the external system:
<a href=http://#request.SakaiURL#/portal?sakai.session=#returnCode#' >SSO to Sakai</a>
Modify the above link so that the sakai.session parameter contains the session returned by your SakaiPortalLogin Web service.
When the user clicks on the above link they get into Sakai through single-sign-on (SSO)!
Note 1: SakaiPortalLogin requires Sakai to have accounts that are identified using an identifier that matches the id passed by the SakaiPortalLogin Web service. You can pre-load these accounts using Sakai Web services or you can add them on the fly using Web services.
Note 2: Make sure your trusted external system and Sakai communicate in ways that can't be overheard – otherwise somebody might be able to figure out what the portalSecret is.
Note 3: If you want Sakai users to exclusively navigate (and authenticate) into Sakai through the external portal you can configure Sakai so that the top login on Sakai links to the external system. To do this set the following parameters in sakai.properties:
top.login=false
login.text=Login
login.url=url_of_external_system/portal
Admins can still log into Sakai directly by going to
http://yourCollegesSakaiURL/portal/xlogin
Course Management Integration
http://confluence.sakaiproject.org/confluence/display/ENTR/Course+Management+Integration
Verifying and Troubleshooting Your Sakai Installation
Verifying Your Installation
Whether you are performing your first install of Sakai or upgrading to a newer revision, it is advisable to test the functionality you care about after each round of configuration changes.
A good source of information for running a Sakai installation through its paces are the test scripts coming out of the QA Working Group. In all likelihood, you will want to test a subset of the functionality covered by the test scripts according to the tools and use cases at your site.
When you develop your local test protocol, you will want to exercise the full range of options in each of the tools you plan to support. This will help uncover configuration issues local to your institutions. It may also help you build familiarity with known bugs and workarounds with your version of Sakai.
In addition to having your test users record problems that occur using a methodology like the critical incident technique, you should pay close attention to messages that appear in the tomcat system log (usually TOMCAT_HOME/logs/catalina.out).
Once you have verified functionality, go through the Sakai Admin Guide - Load Balancing and Scaling and Sakai Admin Guide - JVM Tuning sections of the admin guide for information on making sure your instance is configured to perform reliably under load.
Automated Verification of Your Installation
Some groups have had positive experiences using Selenium to perform automated tests on a Sakai installation. For more information, see one of the following links:
- [The Development Discussion Group's Selenium Page]
- The QA Working Group's Selenium Page
Troubleshooting Your Installation
When you encounter an unexpected behavior with your Sakai installation, there are a handful of sources of information that can help you diagnose the problem:
- Any onscreen messages
- Your tomcat logs (usually TOMCAT_HOME/catalina.out)
- Any component logs (such as that generated by James)
- The SakaiPedia and other Sakai Confluence pages
- The Sakai JIRA bug database
- Searching the archives of tool-specific mailing lists (such as OSP)
- Searching the sakai-dev gmane archives (for general problems)
If there are no stack traces or error messages, you may find it useful to increase the verbosity of logging. The log levels in Sakai can be changed by adding log.config directives to your sakai.properties file as specified here:
http://confluence.sakaiproject.org/confluence/display/BOOT/Controlling+logging+from+sakai.properties
If you reach the point where you have searched other sources of infomration and are asking the sakai-dev list for help, please make sure you provide:
- Minimal details about your installation (Platform, OS, Sakai version, Java version, Tomcat version)
- A description of the problem behavior and the steps required to reproduce
- The text of any on-screen error messages you received
- The text of the stack trace(s) recorded in your log files.
If you are able to verify that the problem is not an existing open bug and that it's not a local configuration problem, best practice is to report the bug using JIRA.
Operations Best Practices
Introduction
This section is intended to bring together a handful of best practices not covered elsewhere in the admin guide. These are not canonical, but represent the range of techniques production sites use to manage the uptime and performance of their sakai installations.
Maintenance Schedules
Although continuous availability is the ultimate goal, many sites find it useful to announce routine daily and/or weekly maintenance times to ensure that routine maintenance can be performed in an orderly fashion. A basic approach is to schedule a short daily window, and a longer window that occurs once a week. The daily maintenance window is scheduled for 15-30 minutes each day, which can be used for minor updates, restarts, log rotation, et cetera. The weekly maintenance window typically occurs on the slowest day of the week, and is long enough to allow for patches, cold database backups, version updates, hardware migrations, etc. Both the daily and weekly window should either be based on clearly observed usage patterns among your users, or on the scheduled down time of systems on which your installation depends (database, distributed storage), et cetera.
|
Your downtime schedule should be clearly advertised on both the gateway site (which users see before logging in) and in each user's "My Workspace" site. This is critical to establishing the expectation among end users that the system will be unavailable during scheduled maintenance times. |
Another useful feature is to set up a separate apache installation that is the failover node for your load balanced cluster. This apache instance should present a page that reminds users of the published maintenance schedule, and also serves as a notification mechanism in explaining unexpected outages.
Hot Deployment of Changes
If you have a load balanced installation of Sakai, application changes can be hot deployed, although there are caveats. If you wish to take an application server out of the load balanced pool and then take it down, you must keep in mind the sticky session timeout for your sakai installation, and must carefully monitor the sticky sessions assigned to a node before shutting it down. Here's an example methodology for hot deployment of changes:
- remove the node from the load balanced pool while continuing to allow current active connections
- monitor sticky sessions until all users are off of the node
- take down the node
- patch or otherwise update the node
- bring the node up and test individually
- return the node to the load balanced pool
- continue the process with the next node
If your session timeout is longer than an hour, you can imagine that it may take some time to ensure that all traffic is off of a node before restarting. If you choose to shorten the process by shutting down the node once the load falls below a certain threshhold, keep in mind that any users who remain connected to a node when it shuts down may lose their work in progress, including assessments. This is another benefit of clearly advertising your downtime schedule, it gives you a safer time in which to introduce changes.
Automated Deployment
If you are deploying Sakai with local customizations and configuration changes (as most sites do), you may find a benefit in creating an automated deployment process. This process would do something like:
- download the base version of Sakai from subversion
- overlay any local tools and code changes
- test the build and notify an administrator if there are failures
- stop Sakai
- deploy the updated build
- restart Sakai
The downloading and overlaying of code can be managed to a large extent by establishing your own subversion repository and using the svn:externals functionality to create a combined source directory. For more information on svn:externals, see:
An example of an automated build process was detailed in David Haines' talk at the 5th Sakai Conference in Atlanta:
http://bugs.sakaiproject.org/confluence/display/CONF06/The+University+of+Michigan+Build+Process
Security
Security updates are not publicly announced until there has been enough time for existing installations to address the problem. All security notifications are coordinated through Anthony Whyte. For more information, see the "Sakai Admin Guide - Joining the Community" section of this document or the "[ENC:Documenting your Sakai instance as part of the Sakai community]" section of the SakaiPedia.
Patches
You may find that your version of Sakai suffers from a known bug for which there is a patch. Applying a patch to a sakai installation requires a source build and the standard patch utility. The steps are typically as follows:
- Obtain the patch or updated source
- shut down your sakai installation
- undeploy the affected component using the Sakai plugin for Maven ("maven sakai:undeploy" from the component's source directory).
- build and deploy the affected components using the Sakai plugin for Maven ("maven sakai" from the component's source directory).
- start your sakai installation
Monitoring
Many institutions choose to use programs like Nagios and Big Brother to monitor the health of their Sakai installation and notify key staff. These programs typically verify that all processes are running, and that Sakai is listening on the desired ports. There are also scripts to monitor the contents returned by a web request. One approach is to have a simple tool installed within Sakai that's accessible without a password return a summary of the status of the internal health of a Sakai install (database connections, memory, etc.).
If you are running in a load balanced installation, your load balancer may also offer tools to monitor the health of a node and either reduce the amount of load directed to the node over time, or flag the node as unavailable and redirect all traffic from that node. Where possible, you should tie your load balancer's monitoring to something that reflects the internal health of Sakai rather than whether it is simply up and perhaps not responsive. One suggestion would be to use a internal health check script as mentioned above and tie the load balancer to that. Another would be to test the response time of a node and flag it as down if it responds too slowly.
Notification
A key practice of any monitoring system is to quickly notify staff who can attend to the problem. Some institutions use a rotating on-call system where one staff member responds to all alerts during a given time period. Some institutions use a system in which the first person to respond to the problem indicates to everyone else that they are working on the problem. Some institutions with dedicated operators use a call tree that begins with first responders and continues through the organization.
Proactive review
It's also good practice to review the errors recorded in catalina.out regularly and compare to known bugs to help isolate configuration changes or previously unseen bugs. This is important as an ongoing activity, and as a part of quality assurance and change management.
Joining the Community
Whether you are running Sakai at a small scale or large scale, it is important to become an active part of the community. Community engagement expands your portfolio of best practices, it provides a forum for affecting change, and the Sakai community and product both benefit from a broad base of input. This section details a few community resources that are available and may be of help to you in supporting your Sakai installation.
Confluence
http://confluence.sakaiproject.org/
Confluence is the wiki used to document the Sakai product itself as well as the business processes related to the larger community. You can view materials without an account, but if you want to ccomment on , edit, or create your own new content, then you need an account. You can request an account by emailing confluence-admins@collab.sakaiproject.org.
JIRA
http://jira.sakaiproject.org/
JIRA is the bug, requirements, and task tracking system used to manage the efforts of the Sakai community. You can browse JIRA without an account, but if you want to report new issues or comment on existing issues you'll need to request an account by sending mail to jira-admins@collab.sakaiproject.org. The same email address is used to request permissions, new project areas, et cetera.
Key work groups and discussion groups
The following is a short list of the mailing lists on collab.sakaiproject.org that may be of interest to Sakai administrators:
| List | Description |
|---|---|
| WG: Production (Deploying Sakai) | The best place to exchange day-to-day production issues |
| DG: Development (aka sakai-dev) (Building Sakai) | Intended to be a development-centered list |
To join these or any other lists:
- Create an account on collab.sakaiproject.org if you have not already done so
- Log in to collab.sakaiproject.org
- In your "My Workspace" area, you'll find a "Membership" link. Follow this link to see your current memberships
- Follow the "Joinable Sites" link.
- Click the "Join" link next to any site you wish to join.
Sakai Conferences
The Sakai conferences are another good source of up-to-the-minute information about current versions of sakai, upcoming releases, and are a great way to build a network of contacts that are dealing with many of the same support issues. For details about the next upcoming conference, visit http://sakaiproject.org/.
Presentations and podcasts from previous conferences are retained for the use of the community.
Documenting your installation
As you move forward in supporting and learning about Sakai, it is important to learn about other administrators and their experiences in supporting Sakai. One way to do this is by registering your installation with the Sakai community.
For more information contact Anthony Whyte.
Migrating from a previous release
Migration from an earlier version of Sakai typically involves a database conversion (for which scripts are supplied with the release), an update to any custom skins, and possibly changes to any custom code.
1.0 Changes in sakai.properties
In addition to new sakai.properties values introduced for Sakai 2.5, there are also some changes to address when upgrading from a previous version of Sakai:
New preference.pages property (SAK-6545)
This property controls page order and visibility in the Preferences tool. The property takes comma-separated list of values identifying the pages (and toolbar actions) to display. Available pages are Notifications, Customize Tabs, Time Zone and Language. Below is an example of prefences.pages setting:
preference.pages=prefs_tab_title, prefs_noti_title, prefs_timezone_title, prefs_lang_title
The order of values in the comma-separated list determines page order and also the order of actions in the toolbar. If a value is missing, that page's action will not appear in the toolbar and the page will not be reachable via the UI. If the preference.pages property is not set, page order will be the (current) default.
If you remove
enable.privacy.status = true
you can achieve a similar effect by defining preferences.pages as follows:
preference.pages=prefs_tab_title, prefs_noti_title, prefs_timezone_title, prefs_lang_title, prefs_privacy_title
WebDAV properties changes SAK-13403
The properties associated with the WebDAV authentication cache have changed. In Sakai 2.5.0 and earlier the following properties were used:
maximumSize@org.sakaiproject.user.impl.AuthenticationCache timeoutMs@org.sakaiproject.user.impl.AuthenticationCache failureThrottleTimeoutMs@org.sakaiproject.user.impl.AuthenticationCache
These settings have been replaced as of Sakai 2.5.2 with:
maxElementsInMemory@org.sakaiproject.user.api.AuthenticationManager.cache timeToLive@org.sakaiproject.user.api.AuthenticationManager.cache
Worksite Setup/Site Info properties changes (pre-2.5 to 2.6 upgrade) (SAK-10762)
In Worksite Setup/Site Info the names of properties associated with the ability to add participants via email address have changed:
| Old Name (Sakai 2.4 and earlier) | New Name (Sakai 2.5.0 and later) |
|---|---|
| invalidEmailInIdAccountString | invalidNonOfficialAccountString |
| noEmailInIdAccountName | officialAccountName |
| noEmailInIdAccountLabel | officialAccountLabel |
| emailInIdAccountName | nonOfficialAccountName |
| emailInIdAccountLabel | nonOfficialAccountLabel |
| emailInIdAccount.url | nonOfficialAccount.url |
| emailInIdAccountInstru | nonOfficialAccountInstru |
| noEmailInIdAccountValue | officialAccountValue |
| emailInIdAccountValue | nonOfficialAccountValue |
Portfolios (OSP) permission settings (pre-2.5 to 2.6 upgrade) (SAK-13205)
If you are upgrading from a pre-2.5.0 version of Sakai, then you need to force conversion of the OSP permissions by setting osp.upgrade25=true in your sakai.properties file. (See also discussion.)
Portfolios (OSP) reports property changes (pre-2.5 to 2.6 upgrade) (SAK-10451)
Those upgrading from a pre-2.5.0 version of Sakai need to change osp.reports.useWarehouse to sakai.reports.useWarehouse.
2.0 Database Conversions
A database conversion is typically required between Sakai versions. Database conversion scripts - in distinct versions for MySQL and Oracle, respectively - are found in the reference/docs/conversion folder of the release or in our SVN repository:
In the same directory you'll also find conversion scripts for earlier Sakai versions. Migration from an earlier version will require the successive application of all intermediate scripts (see the following table). You cannot, for example, move from 2.2.1 to 2.4.0 by applying a single script. The were no database schema changes between 2.4.0 and 2.4.1, so you can migrate to the 2.5.0 schema from either version using the 2.4.0 scripts.
As a general rule, be sure to read through the conversion scripts before applying them. The conversion scripts are generic in the sense that they do not take into account any special customizations you may have made - such as new roles, or the deployment of additional tools or if you are migrating from 2.4.x - and they may complicate your migration with unintended consequences if you execute them blindly.
The latter version represents a security release that replaced one or more intervening Sakai releases. In this case the provided conversion script contains the necessary information to migrate you through the no longer available, intervening Sakai versions.
There were no schema changes between Sakai 2.5.1 and 2.5.2. The Sakai 2.5.1 and 2.5.2 releases are both based on 2.5.0; Sakai 2.5.1 containing a major portfolio tool bug that was reverted in Sakai 2.5.2.
No 2.6.* conversion scripts yet exist for DB2. Please contact John Bush if the absence of scripts poses a problem for you.
3.0 Other Conversions
Sakai 2.5 also includes data and schema conversion outside the standard scripts for Assignments and Content Hosting to address data integrity for assignments and performance enhancements in both tools. Below is a quick summary and overview of the process for each tool.
3.1 Assignments Tool
The assignment service has permitted the creation of duplicate submission objects (i.e. 2 or more submissions for the same student and assignment). While the UI should prevent this from happening, at various stages in the evolution of the Assignments code, bugs, race conditions or other failures have led to duplicate objects being created. This conversion seeks to reconcile those duplicates and add database constraints to prevent this is the future.
In summary, the conversion script is necessary to
- Remove existing duplicate submission records, if any
- Prevent future submission duplicates by applying unique constraint on the ASSIGNMENT_SUBMISSION table
- Improve performance of the Assignment tool
The conversion script does the following to the existing ASSIGNMENT_SUBMISSION table in Sakai database:
- read in all tuples as AssignmentSubmission object, parse out data such as submitter_id, submit_time, submitted, and graded, and stores those attributes as separate columns in the ASSIGNMENT_SUBMISSION table;
- Runs though the table, combine and remove submission duplicates (tuples with same "context" and "submitter_id" combination);
- apply the unique constraint of "context" + "submitter_id" to ASSIGNMENT_SUBMISSION table.
There is a readme file with detailed instructions on this process at https://source.sakaiproject.org/svn/assignment/tags/sakai_2-5-0. In addition, there is further information in the related JIRA SAK-11821.
This conversion was a part of the post-2.4 assignments branch so those migrating from a version already running this can disregard this step.
3.2 Content Hosting
Migrating from 2.4 to 2.5 requires adding several columns to the database tables used by the Content Hosting Service (the service used by the Resources tool, Dropbox, filepicker and WebDAV). The conversion scripts contain DDL statements to accomplish those changes. You need to run these conversions scripts (or perform the equivalent operations manually) and then convert your existing Resources via one of the methods outlined below, before you will gain the performance improvements Sakai 2.5 offers.
The new columns added to the database tables support a switch from XML serialization to "binary-entity" serialization, and enable Resources to perform faster and use less memory. One of the key areas this impacts is improving the performance of quota calculations.
There are two methods for converting existing Resources, with the first being the recommended option, as it enables all performance improvements when completed:
- Run the conversion utility, which can be run on a live system. (See readme for more details.)
Systems running oracle should read the email threads copied to the comments section below.
- Let the code convert each Resource as it is accessed.
This is only recommended for implementations with small datasets, such as pilot deployments; otherwise you should use the above conversion utility.
While some performance benefits from the binary-entity serialization can be realized immediately using this method, others, such as the quota calculation improvements will not be available until all Resources have been accessed and converted.
Based on the state of the data in the Content Hosting Service tables, it will start up in one of two modes:
- Binary only - If the code detects on start-up that all of the XML fields are null – as would be the case after running the conversion utility – it will run in binary mode. The means the system will only read and write using binary-entity serialization, and you will be able to fully realize all the performance enhancements that it offers.
- Dual mode - If the code detects there is still data in the XML fields – as would be the case if the conversion utility has not be run – it will run in dual mode. This means the system will be capable of reading both XML-serialized and binary-entity-serialized resources, but will write using only binary, and will convert any XML data it encounters into binary data. This gives you some of the performance benefits of binary-entity serialization without running the conversion utility, but you will never get the quota-calculation improvements unless all Resources end up converted.
3.3 Discussion Tool
Commencing with Sakai 2.5, Sakai packaged distributions, tags or maintenance branches no longer include the Discussion tool. It has been retired and removed from the release, since there was no longer an active project team supporting the tool nor actively used by production institutions. feedback The Forums tool provides a viable alternative.
If you are upgrading and previously used the Discussion tool, you have two options:
- Continue using Discussion. A 2.5-compatible version of the Discussion tool is available in Contrib. You can build it and add it to your Sakai instance. No one has committed to supporting this version of the tool though, and you should not rely on it remaining available for future Sakai releases.
- Migrate Discussion content to Forums. A utility for converting Discussion tool content to Forums tool content is available in Contrib. See the README.TXT file for more information.
1. Enterprise Bundle (Core) Tools
Tools that are integral to every Sakai release are called "Core" tools. Such tools are those that are deemed most tried, tested, and follow best practices for Sakai. They are visible out-of-the-box, and require no special configuration to begin using them. With each new release some tools are considered for promotion to "Core" status (see Provisional Tools below).
1.1 Worksite Tools
The following tools (with one exception, see below) are available in Worksite Setup and Site Info > Edit Tools by default.
- Announcements (sakai.announcements)
- Assignments (sakai.assignment.grades)
- Calendar Summary (sakai.summary.calendar) - a synoptic tool for events created in the Schedule tool
- Chat Room (sakai.chat)
- Drop Box (sakai.dropbox)
- Email Archive (sakai.mailbox)
- Forums (sakai.forums) - discussion forums, formerly part of "Message Center"
- Gradebook (sakai.gradebook.tool)
- Messages (sakai.messages) - for sending private messages, formerly included in "Message Center"
- News (sakai.news)
- Post 'Em (sakai.postem) - for quick uploading of feedback with an Excel import
- Presentation (sakai.presentation)
- Resources (sakai.resources)
- Schedule (sakai.schedule)
- Section Info (sakai.sections)
- Site Info (sakai.siteinfo)
- Syllabus (sakai.syllabus)
- Tests & Quizzes (sakai.samigo)
- Web Content (sakai.iframe)
- Wiki (sakai.rwiki)
The following tools are not available for direct selection from Worksite Setup, as they are designed to be components of the Home page of a worksite.
- My Workspace Info Display (sakai.iframe.myworkspace)
- Recent Announcements (sakai.synoptic.announcement)
- Recent Chat Messages (sakai.synoptic.chat)
- Recent Discussion Items (sakai.synoptic.discussion)
1.2 Admin Tools
These core tools are found within the Admin Workspace by default. Provisional admin tools are also visible by default (see below for details).
- Admin: Archive Tool (sakai.archive)
- Administrator's Preferences Tool (sakai.admin.prefs)
- Admin: Alias Editor (sakai.aliases)
- Admin: Memory / Cache Tool (sakai.memory)
- Admin: On-Line (sakai.online)
- Admin: Realms Editor (sakai.realms)
- Admin: Sites Editor (sakai.sites)
- Admin: User Editor (sakai.users)
- Job Scheduler (sakai.scheduler) - based on Quartz
1.3 My Workspace and Special Tools
These tools all have some special, specific function in a particular region of Sakai, such as the My Workspace or Gateway sites.
- Account (sakai.singleuser)
- Help Documentation (sakai.help)
- Membership (sakai.membership)
- Message Of The Day (sakai.motd)
- New Account (sakai.createuser)
- Preferences Tool (sakai.preferences)
- Presence Tool (sakai.presence)
- Profile (sakai.profile)
- Service Information Display (sakai.iframe.service)
- Site Browser (sakai.sitebrowser)
- Site Information Display (sakai.iframe.site)
- Worksite Setup (sakai.sitesetup)
1.4 Portfolio Tools
The following tool suite supports portfolio-based learning and assessment activities.
- Evaluation (osp.evaluation)
- Exposed Matrix (osp.exposedmatrix)
- Exposed Wizard (osp.exposedwizard)
- Glossary (osp.glossary)
- Guidance Sample (osp.guidance.sample)
- Matrix (osp.matrix)
- Presentation Template (osp.presTemplate)
- Presentation (osp.presentation)
- Synoptic (osp.synoptic)
- Synoptic Editor (osp.synoptic.design.publish)
- Wizard (osp.wizard)
- Metaobj (sakai.metaobj)
1.5 Other Tools
Tools that defy categorization and are not for the end user are collected here.
- Admin: Site Management (sakai.sitemanage) (stealthed) - unfinished tool
- Gradebook Service Test (sakai.gradebook.testservice)
- Sakai OSID Unit Test Servlet (sakai.test.tools.OSIDUnitTest)
- Sample use of RepositoryManager Component (sakai.sample.tools.OSIDRepository)
- Simple Sample Servlet Tool (sakai.sample.tool.servlet)
- Simple Sample Servlet Tool 2 (sakai.sample.tool.servlet2)
2. Provisional Tools
A provisional tool is one which is considered to be mature enough to be included in the release distribution, but is not (yet) considered to be an official part of the enterprise bundle, and which does not come enabled by default. Additional steps are required to enable these extra tools. However, a provisional tool may meet a need that the standard tools do not. Since one of the criteria for provisional status is that the tool must already have seen successful production use at more than one member institution, and since provisional tools are included in the code QA'ed for a release, you should be able to deploy a provisional tool in production with some confidence.
The basic idea of provisional tools is to allow implementors to have ready access to blossoming tools for testing and evaluation. If they meet needs and broad success is reported in production, they may be included as a standard part of the bundle in future releases. Your feedback on the suitability of these tools for inclusion in an upcoming Sakai release is therefore an important part of this process. You'll find a more complete description of the criteria for provisional status among the "community practices" posted on Confluence: Criteria for Provisional Status
2.1 Making Provisional Tools Visible
Provisional tools are, as a general rule, "stealthed" by default. This means they do not appear as options in either the Worksite Setup or Edit Tools lists - they effectively require the intervention of an admin in order to be added to a site.
| Tools Unstealthed in the "Demo" Release The release is distributed in a few forms, and the "Demo" release is designed to showcase Sakai's functionality as much as possible. As a result, provisional tools are often unstealthed in the demo, but stealthed in the source distro and in the default settings in subversion. |
Stealthing can be overridden in sakai.properties through a combination of two settings: one for revealing stealthed tools, and the other for hiding tools (whether they are stealthed or not). To add tools to these settings, simply include the particular tool ID in a comma-separated list, e.g.:
visibleTools@org.sakaiproject.tool.api.ActiveToolManager=sakai.mailtool,sakai.poll hiddenTools@org.sakaiproject.tool.api.ActiveToolManager=sakai.announcements
2.2 Provisional Worksite Tools
A brief overview of each provisional tool is provided below. For more detailed information visit the Confluence links provided, or send your questions to the listed contact.
2.2.1 Blog
| Tool ID | blogger |
|---|---|
| Confluence Space | Blog |
| Contact | Adrian Fish (Lancaster University) |
Overview: The Blog is a tool that allows the creation of journals that are available on the web. The information written in the Blog is instantly published in the Web site, so it is available virtually wherever the potential readers are and whenever they want. The Blog is not just a personal blog. It is a team-oriented blog. That means that all the information you publish to the team blog can be revised, modified and appended to by any member of your team. All your team members can also add comments to any blog entry.
Configuration: Change your JVM startup configuration by adding this option:
java.awt.headless=true
This is necessary for the JPEG convertor.
2.2.2 LinkTool
| Tool ID | sakai.rutgers.linktool |
|---|---|
| Confluence Space | Linktool |
| Contact | Charles Hedrick (Rutgers University) |
Overview: Linktool is intended for calling external applications, e.g. written in PHP. It requires the application to be able to do web services calls back to sakai. Other than that, it is very light-weight.
2.2.3 Mailtool
| Tool ID | sakai.mailtool |
|---|---|
| Confluence Space | Mailtool |
| Contact | SOO IL KIM (Boston University) |
Overview: The mailtool is a group-and-role-aware mail composition client, allowing site participants to send email to targeted subsets of site participants. See the functional specification.
Configuration: There are a couple optional mailtool settings for sakai.properties:
mailtool.max.num.attachment= # the default is unlimited mailtool.upload.directory= # for handling uploaded attachments. The default is /tmp/
2.2.4 Page Order Helper
| Tool ID | NA |
|---|---|
| Confluence Space | Page Order Helper |
| Contact | Joshua Ryan (Arizona State University) |
Overview: The Page Order Helper is actually designed to be a portion of the "Site Info" tool, and allows a drag-and-drop interface for site maintainers to reorder the lefthand tool menu for their worksites.
2.2.5 Podcasts
| Tool ID | sakai.podcasts |
|---|---|
| Confluence Space | [Podcast] |
| Contact | Lance Speelmon (Indiana University) |
Overview: a podcasting tool which takes advantage of the Resources tool for storage, but displays podcasts in a user friendly way and provides an RSS feed for access through one's favorite podcatcher.
2.2.6 Polls
| Tool ID | sakai.poll |
|---|---|
| Confluence Space | Polls |
| Contact | David Horwitz (University of Cape Town) |
Overview: The poll tool allows site maintainers to post simple multiple-choice polls for the voting of site participants.
2.2.7 Reports
| Tool ID | sakai.reports |
|---|---|
| Confluence Space | Reports |
| Contact |
Overview:
The Reports Tool is used to run pre-defined SQL-based reports. These reports can be exposed to any level of user for running the report (choosing the parameters) or viewing an already run report. Report and data security is the responsibility of the report designer. The report designer can designate what site types and what roles have access to certain reports. By using system-generated values such as "current user" or "current worksite id" in the SQL queries, the report designer can assure that only appropriate data is exposed.
Configuration:
Configuration of the Report Tool is largely a matter of defining reports. Details about report definitions can be found here.
2.2.8 Reset Password
| Tool ID | sakai.retrievepass |
|---|---|
| Confluence Space | Reset Password |
| Contact | Stephen Marquard (University of Cape Town) |
Overview: Reset Password is a simple tool which allows users to request that a new password be emailed to them by entering their email address. Its primary use case is to allow guest users to change their password if they have forgotten their current password.
Configuration: by default, Reset Password will only reset passwords for users of the guest type. This can be configured by a sakai.properties setting, e.g.
retrieveRoles.count=2 retrieveRoles.1=guest retrieveRoles.2=staff
2.2.9 Roster
| Tool ID | sakai.site.roster |
|---|---|
| Confluence Space | None |
| Contact | Oliver Heyer (University of California Berkeley) |
Overview: Roster allows users to view the names, photos and profiles of site participants who have made their information accessible through the Profile tool in My Workspace. If an institution has institutional photos, the photos can be made accessible separately to site maintainers.
Configuration: Some extra work may need to be done to provide photos for it from campus systems.
2.2.10 Search
| Tool ID | sakai.search |
|---|---|
| Confluence Space | Search |
| Contact |
Overview: The search tool aims to provide a tool that allows a Google-like search of all content in a Sakai instance. It also provides a service component that can be used by other tools to provide search functionality. When search is turned on, an indexer runs in the background that treats content as it is added to the system,
Configuration: To turn on search indexing, add the following to sakai.properties:
search.enable=true
2.3 Provisional Admin Tools
Admin tools are designed to be available in the Admin Workspace only, where there is little point in obscuring them (apart from forcing an admin to click through a few screens to add them). The provisional tools below are thus available in the Admin Workspace by default.
2.3.1 Data Warehouse
| Tool ID | NA |
|---|---|
| Confluence Space | None |
| Contact |
Overview:
The Data Warehouse is designed to use in conjunction with Reports. It provides a way to extract reportable data from the Sakai database through the Sakai APIs, which avoids the need to know about the data model of the database. It also allows access to data in the database that are stored in xml (resource metadata, forms data, etc), by extracting that information through the APIs and putting it into tables in the data warehouse area. Reports, therefore, are as backwards compatible as the APIs are. The tables generated by the Data Warehouse do not necessarily need to be used with the reports tool. After the data is extracted, any third party SQL reporting tool can be used, such as BIRT, Pentaho or Crystal Reports. Not all Sakai data is currently extracted using the Data Warehouse process. There are utility classes that make it easy to create extracts for new areas of the system. Documentation on what is extracted and the data model are planned for future releases. Currently, all tables in the extract have the dw_ prefix.
Configuration:
The Data Warehouse is designed to run as a scheduled quartz job. To schedule the Data Warehouse to run at a certain time, use the Job Schedule Tool and create a job using the "Data Warehouse Update" job type. Create a trigger that will run on a pre-determined basis (usually once a day). The Data Warehouse can live in a separate database instance from live Sakai data. This is potentially helpful for security and performance concerns. By default, the Data Warehouse will be created in the Sakai database, to change this configuration, edit any of the following properties:
driverClassName@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=oracle.jdbc.driver.OracleDriver url@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=jdbc:oracle:thin:@mercury.phx.rsmart.com:1521:VMWARE username@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=jdetest password@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=jdetest maxActive@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=20 maxIdle@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=2 validationQuery@org.sakaiproject.warehouse.service.DataWarehouseManager.dataSource=select 1 from DUAL
2.3.2 SU
| Tool ID | sakai.su |
|---|---|
| Confluence Space | None |
| Contact | Zach A. Thomas (Aeroplane Software) |
Overview: SU is a tool for administrators to use to log in as another user. It is code developed at Texas State University for their local brand of Sakai called TRACS: Teaching Research and Collaboration System. It is meant to be used within the Admin Workspace, and so it does not need to be stealthed or unstealthed (it will never appear among the tool options in "Worksite Setup"). It features a simple form in which you type the user id of the user you wish to "become" in the system.
The name stands for Super User, and comes from a command-line tool in Unix that serves the same purpose. It is often pronounced "Sue."
Configuration: In order to use the tool, edit the !admin site (i.e. the Admin MyWorkspace) through the admin Sites tool, add a page or edit an existing page, and place the tool on that page. The SU tool will appear in the list with the title "Become User" and the id sakai.su.
The tool itself is very simple. There is a text field to type a user id, and there is a Submit button. Your session will continue as though you had logged in as the specified user. This will work even if that user is already logged in at another location. To change back to yourself, you must logout and log back in.
Security: The SU tool is hard-coded only to work for users with administrative privileges. Naturally you should take care to whom you give these privileges.
2.3.3 User Membership
| Tool ID | sakai.usermembership |
|---|---|
| Confluence Space | User Membership |
| Contact | Nuno Fernandes (UFP) |
Overview: The user membership tool offers user lookup features beyond that of the default Admin Users tool. It allows searches to be conducted for external users, by user type, and full lists of site membership for any given user. It also provides CSV exports of the results of any of these searches.
3. Contrib Tools
A great deal of useful functionality can be found amidst Contrib tools, which range from brand-new ideas to fully mature projects to old tools retired from the release. Many schools deploy one or more Contrib tools in production whose functionality they find particular valuable. The Contrib tools are not, however, included in releases for a variety of reasons, perhaps because of license compatibility issues, development and release timelines are our of sync, they are not fully integrated with key Sakai services, etc.
In general Contrib tools have not been formally QA'ed as part of the Sakai release process, and the level and effort of integration varies considerably, though many can be deployed in a Sakai instance with trivial effort. Contrib tools should be evaluated on a case-by-case by basis by organizations interested in deploying them.
Contrib tools are available in most cases from the Contrib area of Sakai's Subversion repository. In some cases they are hosted external to the Sakai project by the group leading their development.
As of the Sakai 2.5.0 release there are over 40 Contrib tools in various stages of development (see below). Links to more, up-to-date information on individual Contrib tools can be found in the Project Directory.
| Tool | Description |
|---|---|
| Agora | Agora is an easy to use, open source online meeting tool. All members of a Sakai worksite can create a meeting in just a few mouse clicks, and joining is as simple as clicking a link in the Sakai tool. Apart from a Java virtual machine there is no need for any explicit software installation on the user's PC, all required software is transparently loaded at startup. |
| Assignments2 | A second generation of the assignments tool. Initial phase involves conversion to RSF, better gradebook integration, and a redesign for an improved user experience. Future phases involve JCR for content storage and customizable workflows. |
| BlogWow | An RSF-based blog tool. |
| Breeze Link | The Breeze Link allows a Sakai installation to seamlessly connect to a Breeze server and allows users to connect to Breeze meetings with a single click. No additional sign on is required and users will appear in the meeting with their display name from Sakai. |
| CANS | Context-aware Activity Notification System (CANS) is a notification system for online communities that is designed around the importance of a user's social context and personal notification preferences. |
| Checklist | The Checklist Contrib Project will be responsible for addressing or promoting the needs of graduate students through Sakai. |
| Clicker Registration | The Clicker Registration is for students to register their Clicker ID's in courses that use them. |
| Conditional Release | A Conditional Release architecture and design, which involve a "ConditionService" which will work in concert with other services and store rules against a tool or domain object. |
| Configuration Viewer and Editor | The Sakai Config Viewer is a tool to help administrators make sense of the configuration options that can be set in sakai.properties. It displays a list of available properties along with a host of value added data. |
| Content Viewer | The Resources Viewer is a simple tool which displays the contents of selected folders from the Resources tool in a simpler, more user-friendly manner. In particular, it fulfills the requirements of displaying a list of resources together with their descriptions and creating links to Resources content in the left-hand navigation (tool) menu. |
| Course Homepage | Home Page tool offers a substitute for the current Home view of a site. |
| Email Template Service | A service providing localizable and internationalizable email templates for Sakai Applications. |
| Evaluation System | Give formative evaluations to students in their courses and review the results. |
| Form Builder | Form Builder (formerly known as XSD Weaver) is a graphical user interface for creating XSD files for use in ePortfolios. |
| Goal Management | Enables the definition of program, course, and/or personal goals, the ability to tag activities (such as assignments, datapoints, OSP wizard pages and/or OSP matrix cells) with applicable goals, and the ability to rate user performance towards goals based on work submitted for the activities. |
| I10n-Stats | Tool for analyzing the status of the Sakai translations in the source repository. |
| Image Gallery | The Gallery Tool will allow a user to select a collection of images (a gallery) and view the images in a specified order. The tool is focused on selecting, sequencing, and viewing - not creation or editing. |
| ImageQuiz | A responder- or clicker- type tool designed for synchronous, though not necessarily co-located, classroom settings. In addition to the typical responder functionality, an image can be displayed with an accompanying question or note, each student can click on the image at a particular location to indicate their response, and the aggregated results of all student clicks can be viewed. |
| IMS Enterprise Services | IMS Enterprise Services |
| JForum | JForum Discussion & Private Messages is an easy-to-use, yet robust tool that offers industry-standard functionality to users. Instructors can set up unlimited categories and forums, moderate topics (move, edit, delete, lock, or unlock), read recent topics and mark them as read, watch and bookmark topics, and much more. JForum comes with built-in private messaging that allows site members to communicate privately while discussing issues or collaborating on projects. JForum has a familiar (popular phpBB) graphical user interface, and is liked by faculty and students, alike. |
| Learning Log | A derivation of the Blog tool aimed at pedagogies where reflective learning takes center stage. |
| MailArchive Wow! | MailArchive Wow! builds upon the ideas in the existing MailArchive, and leverages a number of new libraries/specs such as JSR-170 and RSF. |
| Melete - Modules | Melete allows instructors to publish learning sequences that can be created by using a rich text editor, uploading learning objects, or pointing to existing URL resources. Instructors can design content that supports instructor facilitated learning or system managed self-study. Lessons can be released automatically based on start and stop dates. Melete supports IMS Content Packaging and SCORM 2004 export. Future features include conditional release of lesson sequences to students based on completion of tasks. Melete stores its content in a private area of content hosting. |
| Mneme - Test Center | Mneme is an assessment system for Sakai. Mneme has a delivery module that is high performance, able to handle large loads, has an Assessments module to manage the publication of assessments, has a module for grading assessments, optionally integrated with Sakai's Gradebook, and has a module for authoring questions and managing pools. |
| My Sakai | "My Sakai" makes it possible to get your files and announcements, and keep track of what's going on in your Sakai sites, straight from your desktop. For example, a student engrossed in writing an essay, who suddenly realises they need to check something in a document in their course site, can open it straight from their desktop widget, without having to break off and navigate through Sakai to find it. "My Sakai" widgets show you recent activity on all of the worksites you're a member of. This means that the widget will tell you when a new announcement or a new resource has been added. The widgets also provide synoptic views of Resources and Announcements. We have created widgets for Mac DashBoard, Vista Sidebar, Facebook, iGoogle, Google Desktop, and RSS. |
| News Feeds | News Feeds is a feed aggregator tool developed for Sakai. The tool supports multiple feeds, user-provided feeds or selection from pre-configured institutional list, BASIC/DIGEST authentication and feed attachments (enclosures). |
| OCW | Support in Sakai for creating OpenCourseWare materials and sites. For information about the OpenCourseWare initiative, see http://www.ocwconsortium.org/about/index.shtml. |
| OODB | oodb is a Sakai Service for using the db4o oo-database for persistence. |
| OpenCast | A webcasting infrastructure application based on Apple's Podcast Producer with an administrative UI in Sakai. |
| OpenSyllabus | OpenSyllabus is an easy to use tool to create and publish model-based syllabi where faculty can finely control which resources (doc, ppt, xls, pdf, etc.) are accessible to registered students or to the general public. OpenSyllabus offers a unified interface with a standardized vocabulary for easy navigation. It also supports courses given to multiple sections. |
| QNA (Questions and Answers) | QNA (Questions and Answers) is a new tool being developed by UNISA and UCT. QNA enables students to ask questions anonymously, which can be answered by other students or lecturers or tutors (instructors/TAs). Questions are ranked by their popularity and can also be organized into categories. QNA builds on experiences from two existing tools: UNISA's FAQ tool and UCT's DFAQ tool. |
| Roleplay | Roleplay (aka "user alias") is a tool and service for Sakai 2.6.0 and later which allows users to be known as a name other than their default Sakai name within a site. It was originally developed at UCT for an international trade bargaining simulation game in which students were known by country names representing their teams (e.g. "Brazil 2A") rather than realm names. |
| Sakaibrary | Sakaibrary is a project to integrate licensed library resources with Sakai. |
| Sakai Groovy Shell | Sakai Groovy Shell |
| Sakai Maps | The SakaiMaps tool integrates Google Maps into Sakai and allows users to define and browse points of interest (POI) on the map. Each POI has a name, a short description, a type and optionally a url with more information. |
| SCORM Player | A Sakai tool able to launch and sequence a known conformant 'SCORM 2004 Conformant Sharable Content Object' (SCO), including data persistence of the full data model. |
| Sign-Up | A tool that allows users to organize office hours, review sessions, study groups and similar activities. |
| Simple Page Tool | The simple page tool allows users to create simple pages in worksites using the WYSIWYG editor, these pages can then link to things in resources if desired. It is defined as a multi tool so it can be added multiple times to the same site using the page order tool. |
| Sitestats | Site Stats is a tool for showing site statistics by user, event, or resource. |
| Skin Manager | The Skin manager tool allows site administrators to install and manage skins in a Sakai instance. Skins are uploaded in the portal as .zip archives that contain graphics and style sheets. The tool displays all the skins in use throughout the Sakai instance and indicates which sites use a particular skin. Skins may be revised by uploading a new archive and it is possible to revert to earlier versions of a skin. This strongly simplifies the skin installation process: no longer access to the file system of the sakai instance is needed. |
| Sparkline | Sparkline collects and displays continuous real-time feedback. It has an interface for users to continuously adjust a relative rating scale and a constantly updating sparkline of the average rating. |
| Taggable | Taggable API. |
| Textbook | A tool to facilitate the identification, buying and selling of textbooks. |
| TransformAble | TransformAble is useful for users who want to customize Sakai's appearance to improve the readability and accessibility. |
| Wicket | The goal of Wicket Contrib is to provide a component set to facilitate the development of Sakai tools using Apache Wicket (http://wicket.apache.org). If you're wondering what Wicket is all about, we've started compiling a list of hopefully useful links here. We are also compiling a list of projects that are using Wicket. |
| Wimba Integration | Integration of Wimba and Sakai. |
| Word-to-QTI Convertor | A Word-2-QTI Converter. |
Sakai 2.5 Release Notes
Installing and Upgrading
The Sakai 2.5 installation guides provides information on how to install Sakai 2.5 or upgrade from a previous release. If you've upgraded from past Sakai versions, you will find the process essentially unchanged. Database conversion scripts are supplied in each 2.5 release in order to help you migrate your data to the 2.5 database schema.
What's New
The following sections provide an overview of what is new in this release. A more detailed list of enhancements is available from Jira, our issue management system: Enhancements and Fixes (2.5). A complete list of tools included in this release is also available.
Tool Promotions
Tools Status Definitions:
- Core – tools with which the community has a great-deal of experience and confidence in their robustness, stability, and scalability, and which are enabled by default in the release.
- Provisional – tools which the community has less experience, and which are disabled by default in the release.
- Contrib – tools with which the community has little experience, often are still in early stages of development, and are not recommended for broad usage in a production environment. (Contrib tools are available separate from the release, in the Contrib area of Sakai's source repository.
| Tool | Status Change |
|---|---|
| OSP Tools (Forms, Glossary, Matrices, Portfolio Layouts, Portfolio Templates, Portfolios, Styles, and Wizards) | Provisional to Core |
| Tests & Quizzes (Samigo) | Provisional to Core |
| Reset Password | Contrib to Provisional |
| Discussion | Retired from release to Contrib (More info...) |
| Assignments (Non-Graded Version) | Retired from release to Contrib |
General Enhancements
Accessibility WG
- Outcomes from 2.4 accessibility review influenced many changes and improvements for 2.5.
Internationalization WG
- Currently Available
- Arabic
- English/UK (new)
- Catalan
- Simplified Chinese (updated)
- Dutch (updated)
- French/Canadian (updated)
- Japanese (updated)
- Korean (updated)
- Portuguese/Brazilian (new)
- Portuguese/Portuguese (updated)
- Russian (new)
- Spanish (updated)
- Swedish
- Translation Underway (
Translations will be merged to maintenance branch as they are finished.)
- Traditional Chinese
- Danish
- French/France
- German
- Hebrew
- Mongolian
- Slovakian
- Turkish
- Vietnamese
[User Experience WG]
- iFrame-less Accessible portal (PDA Portal).
- Skin improvements:
- Restyled the default site tabs to appear as literal tabs.
- Added icons for all the core tools.
- Optional treatment of the "More Sites" drop-down as a pop-up window organized by site type.
This feature is disabled by default; enable in sakai.properties by setting portal.use.dhtml.more=true.
Content Hosting Service
- Improved performance by rewriting underlying Storage of entities to reduce memory usage and CPU load.
Upgraded Sakai instances will not be able to take advantage of all performance improvements until they have converted their existing Resources. See Content Hosting Conversion for more details.)
- Re-factoring of database to eliminate bottlenecks in the underlying content hosting service.
- Preliminary support for the integration of JSR-170 repositories
- (See also Resources above.)
Content Review
- Minor changes in APIs and to integration with Assignments; only applicable to sites running a content review implementation (e.g., TurnItIn).
Database
- Addition of a faster lower memory footprint entity parser based on SAX.
- Addition of an optimized binary entity serialization.
- Added bulk header to email notifications.
- Improved handling of long URLs in emails.
Memory
- Centralized management of Hibernate Cache provision.
- Replacement of MemoryService cache with ehcache in preparation for cluster wide cache optimizations.
- Upgrade to ecache 1.3 to enable JMX capabilities.
Portal
- Addition of site categorization.
- Addition of tool categorization.
- Improved experimental iFrame-less tool presentation (a.k.a. PDA portal).
User Directory Service
- Improved performance when retrieving provided users.
- Support for login IDs (for Kerberos authentication, for example) which differ from user EIDs.
- Optional short-term authentication caching to greatly improve DAV performance.
- Can now enable or disable User Directory Provider implementations via the sakai.properties file.
- Reduced number of required methods in the User Directory Provider interface.
Tool Enhancements
A brief overview of functionality added or improved since the Sakai 2.4 release.
Account
- Option to sync user data between Account and Profile tools.
Assignments
- Allow grading for students that have not posted any submissions.
- Non-electronic submission type.
- Notifications for new submissions.
- Upload all.
- Reordering of assignments (like Resources).
- Improved Assignments-Gradebook integration.
Attachment Widget
- Changed default security setting for viewing attachments from security-by-obscurity to forcing a user to login first.
Chat Room
- Ability to delete all chat history for a given room.
Citations Helper
- Import citations in RIS format from other tools such as RefWorks and Endnote.
- Sort citation lists by author, title, or date.
- Search for and embed citations from within the WYSIWYG Editor (FCKeditor) in Sakai tools.
Forums
- Ability to delete forum messages.
- Added synoptic views for Home.
MessageCenter was previously separated in 2.4 into Forums and Messages.
Help
- Support for help content in multiple languages.
- Added sakai.properties setting to hide help collections.
- Added tool registration property to register additional help collections.
- Updates to help content from Indiana University (IU) Knowledge Base for 2.5 functionality (as provided by project leads and IU KB team).
Gradebook
- Support for categories and weighted categories.
- Added percentages as a grade type option.
- Added letter grading as a grade type option.
This feature is disabled by default; enable in sakai.properties by setting gradebook_enable_letter_grade=true.
- Import grades using a downloaded spreadsheet template.
- Individual student grade reports for instructors.
- Enable an instructor to "see what a student sees".
- Allow export course grades in addition to export gradebook.
- Blank grades now treated as null (rather than previous treatment as 0).
- Introduction of grader permissions (ie grading by group and/or section).
- Usability enhancements in workflow and layout.
Messages
- Ability to bulk Move and Delete Message.
- Ability to forward Messages.
- Added synoptic views for Home.
MessageCenter was previously separated in 2.4 into Forums and Messages.
Portfolio (OSP)
- Promoted from Provisional to Cores status.
- New XSLT portal.
- Aggregated View of Matrix and Portfolios.
- Expanded sharing capabilities for Portfolios.
- Many user interface bug fixes and improvements.
- Group-aware matrices.
- Assignment references within Matrix/Wizards.
Profile
- Option to sync user data between Account and Profile tools.
Resources
- Replaced dropdown widget for Add and Action menus with an accessible one.
- Dropboxes
- Students and Instructors can now choose to email each other when they upload to a Dropbox.
- Instructors can now see a visual indication of which folders contain recently updated content.
- Removal of inappropriate options from Dropbox interface.
- (See also Content below.)
Roster
- New UI with a separate tabular view for profile and official institutional photos.
- Integration with Course Management API to display enrollment status information.
- Expanded permission scheme to retain the Roster's general use purpose while incorporating course-specific features.
- Significant performance improvements.
Schedule
- Performance improvements to reduce memory load of schedules with a large number of items.
- iCal subscription export service and import; reoccurring events are not yet supported
This feature is disabled by default; enable in sakai.properties by setting ical.experimental=true.
Section Info
- Download or print a roster list that provides each student's section memberships.
- Better enforcement of the maximum section size.
Tests & Quizzes, a.k.a. Samigo
- Promoted from Provisional to Core status.
- Allow feedback to be viewed right after an assessment is submitted.
- Allow ability to move/copy/remove multiple questions to other pools.
- Allow ability to adjust score in edit assessment screen.
- Allow ability to remove published assessments.
- Add event logging for user operations.
- Allow copying of all questions in a part to a selected pool.
- Allow students' responses to be exported to Excel.
- Allow point values of questions to be reset when a random draw from pool part is created; all questions from the pool are copied to the part.
- Further details are available in the Tests & Quizzes/Samigo Release Notes.
(Provisional) Blogger
- Internationalization improvements.
- Switch to using same WYSIWYG editor as other tools in Sakai (FCK editor).
(Provisional) Data Warehouse
- Separated from OSP to realize its general usefulness for reporting functionality.
(Provisional) Linktool
- Updated documentation.
- Now deploy SakaiSigning.jws to webservices by default.
- Added placement id to list of parameters passed.
- Support for specifying additional parameters in the tool setup or URL.
- Cleaned up tool formatting and validation.
- Added new default verification script.
(Provisional) Page Order Helper
- Improved keyboard accessibility.
(Provisional) Podcasts
- Permissions now a reflection of permissions in Resources.
(Provisional) Polls
- Now uses WYSIWYG (FCKedtior).
- Improved date picker.
- Improved data validation.
(Provisional) Reset Password
- Added to release as a Provisional tool.
(Provisional) Search
- Addressed critical indexing errors for clusters with a journaled indexer.
- Reduced memory usage in indexers.
Fixes Included in this Release
Fixes (2.5) – a list of fixes included in this release.
Open Issues
Open Issues (2.5) – a list of open or unresolved issues that affect this release.
Maintenance Branch and Maintenance Releases
After each release, work continues on resolving bugs, including ones identified after the release. In addition to fixing these bugs for the next release, when appropriate, the fix is also placed in a "maintenance branch", from which you can easily incorporate the fixes into your own local deployment of Sakai. For this release, the maintenance branch is known as the 2.5.x maintenance branch.
Maintenance branches are maintained for at least one year after the release, longer if there is sufficient community interest and resources. A key feature of the maintenance branch is that it will only contain bug fixes, no new features will be introduced.
We also will be periodically creating maintenance releases (2.5.1, 2.5.2, 2.5.3, ...), based on the maintenance branch, on the order of approximately every one to two months. These releases will include a targeted set of fixes drawn from the maintenance branch, which can be easily QA'ed (this means selecting a subset of the available fixes in the branch so that only a few areas need to be regression tested for each release.) Thus, the QA on these maintenance releases will differ from the QA on a full, major release, such as 2.5.0, in that it will focus only on regression testing areas of change. As a result, the maintenance releases will necessarily lag the maintenance branch in terms of completeness of fixes. The maintenance releases are intended to suit the needs of Sakai deployments for which tracking and incorporating individual advancements in the maintenance branch is not feasible or desired.
For more information, please see:
- 2.5.x Maintenance Branch – specific information on the Sakai Maintenance branch.
- 2.5 Maintenance Releases – specific information on the Sakai 2.5 maintenance releases.
- Release Practice Guidelines – general information on maintenance branches and releases.
Sakai 2.5.5 Sakai 2.5.4 Sakai 2.5.3 Sakai 2.5.2 Sakai 2.5.0
Sakai 2.5.6: fixes
BaseContentService returns non-URL-encoded URLs SAK-17459, SAK-16564 and SAK-13532
A number of BaseContentService methods return URLs that are not URL-encoded, thus breaking on filenames with characters that require encoding. For example, uploading a syllabus attachment with a filename such as räksmörgås.txt will result in a 404 error when clicking on the file link. This issue has been addressed in the upcoming 2.7.0 release.
Uploading a file using the Attachments helper loads the body into memory (SAK-16838)
Currently uploading files using the attachments helper loads the file into memory. Under certain conditions this can lead to out of memory errors. The issue has been addressed in the upcoming 2.7.0 release and a 2.5.x patch is available. The patch is included as an attachment to (SAK-16838).
Sakai_Person_T notes field size change
SAK-6102, SAK-3917: Users who have been running Sakai prior to 19 July 2006 release of Sakai 2.2.0 should check the field size of the SAKAI_PERSON_T "Notes" field. A field size change was added to the 2.1.2 to 2.2.0 conversion script on 17 January 2007. Depending on when deployers executed the 2.1.2->2.2.0 conversion script for the 2.1->2.2 upgrade, this update may have been missed. See the following Jiras as well as the sakai-dev "Notes in SAKAI_PERSON_T table" thread discussion for more information.
MySQL
--- reference/trunk/docs/conversion/sakai_2_1_2-2_2_0_mysql_conversion.sql 2007/01/17 18:57:13 20392
+++ reference/trunk/docs/conversion/sakai_2_1_2-2_2_0_mysql_conversion.sql 2007/01/17 19:10:09 20393
@@ -2237,3 +2237,9 @@
----------------------------------------------------------------------------------------------------------------------------------------
ALTER TABLE SAKAI_SESSION CHANGE SESSION_IP SESSION_IP VARCHAR (128);
+
+----------------------------------------------------------------------------------------------------------------------------------------
+-- Increase the field size for the NOTES field in the SAKAI_PERSON_T table
+----------------------------------------------------------------------------------------------------------------------------------------
+
+ALTER TABLE SAKAI_PERSON_T CHANGE NOTES NOTES varchar(4000);
Oracle
--- reference/trunk/docs/conversion/sakai_2_1_2-2_2_0_oracle_conversion.sql 2007/01/17 18:57:13 20392
+++ reference/trunk/docs/conversion/sakai_2_1_2-2_2_0_oracle_conversion.sql 2007/01/17 19:10:09 20393
@@ -2243,3 +2243,9 @@
----------------------------------------------------------------------------------------------------------------------------------------
ALTER TABLE SAKAI_SESSION MODIFY SESSION_IP VARCHAR2 (128);
+
+----------------------------------------------------------------------------------------------------------------------------------------
+-- Increase the field size for the NOTES field in the SAKAI_PERSON_T table
+----------------------------------------------------------------------------------------------------------------------------------------
+
+ALTER TABLE SAKAI_PERSON_T MODIFY (NOTES varchar2(4000));
Sakai Foundation Security Policy
version 3.1
NOTICE: If you uncover a security vulnerability in Sakai software please do not voice your concerns on any public listserv, blog or other open communication channel but instead notify the Sakai Foundation immediately at security@sakaifoundation.org. Please provide a callback telephone number so that we can contact you by telephone if it is deemed necessary.
INTRODUCTION
Sakai is an open-source software initiative that promotes knowledge sharing and information transparency. However, when dealing with security vulnerabilities the integrity of existing Sakai installations can be compromised by the premature public disclosure of security threats before the Sakai Community has had time to analyze, develop and distribute countermeasures through private channels to institutions and organizations that have implemented Sakai software. Recognizing this danger, the Sakai Foundation has developed a security policy that seeks to safeguard the security of existing Sakai installations as well as provide full public disclosure of Sakai security vulnerabilities in a timely manner.
REPORTING SECURITY ISSUES
Security vulnerabilities in Sakai should be reported immediately to the Sakai Foundation at security@sakaifoundation.org. When contacting the Foundation, please provide a callback telephone number so that we can contact you by phone if it is deemed necessary. Sakai Foundation staff and community developers, working with the original reporter of the vulnerability, will investigate the issue, determine versions affected, and, if necessary, develop and distribute as quickly as is possible a security update for the Sakai Community and general public.
GENERAL POLICIES
Issues identified as security-related are prioritized and addressed differently than functionality or other issues classified as bugs. Access to issues flagged as security vulnerabilities in Sakai's JIRA issue tracking system will be restricted to Sakai security contacts and members of the Sakai Security Work Group (see below). Discussion, analysis, code development and testing relevant to reported security vulnerabilities will be treated as confidential information.
The Sakai Foundation will work with Sakai Community members to develop fixes for both vulnerable released versions and vulnerable branches (up to a particular date or release number). Code commits for security-related fixes will seek to mask the nature of the vulnerability. This usually takes one of two forms: (1) the commit is held until a patch can be tested, distributed and implemented in known sites or (2) in the case of a fix to a less significant threat the commit may be checked in with limited commentary.
During our QA and release cycles security-related issues will receive priority. At a minimum, the Sakai Security WG will review outstanding security issues before the start of each QA cycle.
The Sakai Foundation will issue security advisories and security updates to the general public once existing Sakai installations have been notified and given time to patch their systems.
SECURITY WORK GROUP
The Sakai Community has instituted a Security Work Group (WG) composed of senior members of the community to respond to reports of security vulnerabilities and who operate using private channels of communication. Besides working to resolve known security vulnerabilities the Security WG will also operate in a pro-active manner, reviewing existing tools and services from a security perspective; defining Sakai security requirements; devising QA/testing models that identify potential security weaknesses; producing security-related documentation; and helping educate developers on web-related security vulnerabilities.
SECURITY DOCUMENTATION
Public information regarding security vulnerabilities will be documented in security advisories, Sakai software release notes and readme files included in demo, binary and source distributions as well as online at the following locations:
Sakai Issues Tracking: http://jira.sakaiproject.org/jira/
Sakai Release page: http://source.sakaiproject.org/release
Release documentation for security updates will identify the Sakai version affected including code branches and provide information on how to close the vulnerability. Security vulnerabilities will be ranked by the threat level index listed below:
Critical Risk
Security vulnerabilities classified as a critical risk involve the possible exposure of data to unauthorized viewing, modification, deletion or acquisition as well as attacks that could result in data corruption.
Major Risk
Security vulnerabilities classified as a major risk involve logical attacks that could compromise the availability of Sakai or otherwise degrade system performance, disrupt or circumvent normal application flow control of Sakai tools and services or use Sakai as a platform for attacks on other systems.
Minor Risk
Security vulnerabilities classified as a minor risk involve threats that (1) can be eliminated by updating existing configuration files to reflect a default secure state (e.g., sakai.properties), (2) are considered extremely difficult for attackers to exploit and/or (3), if exploited, are of minor consequence to the operation of Sakai installations.
SECURITY ADVISORIES
Whenever Sakai security vulnerabilities surface, the Sakai Foundation will execute a three-step security advisory protocol in order to alert (1) Sakai Foundation partners and designated security contacts associated with known Sakai implementations, (2) the wider Sakai Community, and (3) the public at large regarding security issues.
The first step in our protocol involves providing alerts to our partner institutions and organizations as well as to our security contacts throughout the Sakai Community via the use of private communication channels. We delay deliberately the issuance of community-wide and public security advisories in order to allow time for security updates to be devised, tested, distributed and, if necessary, applied to Sakai installations that are known to the Foundation. Once these systems are patched the wider Sakai Community is alerted and time provided for Sakai implementers unknown to the Foundation to identify themselves, designate security contacts, and patch their systems before we proceed to the third and final step in our security advisory protocol, the general public announcement.
SECURITY CONTACTS
The Sakai Foundation encourages institutions and organizations that download and install Sakai software to consider contacting the Foundation and providing the name(s) and contact details of one or more individuals to serve as security contacts. Security contact information should be emailed to security@sakaifoundation.org.
As noted above, Sakai security contacts receive security updates in advance of public release in order their institution or organization time to patch their Sakai installation before any Sakai security vulnerability becomes general knowledge. Designated security contacts are also provided access rights to view, comment and address issues flagged as security items in Sakai's JIRA issue tracking application. Security-related JIRA issues are hidden from public view. We do not grant access to these JIRA items lightly and we verify the identity and role of each person who is designated as a security contact.
Email traffic sent to sakai-security-contacts@collab.sakaiproject.org should be treated confidentially and should not be forwarded to other Sakai or public email lists or discussed elsewhere in order to help protect institutions and organizations running Sakai from security-related exploits or attacks.