Sakai CLE 2.x system requirements

Operating system (OS) choices

The Sakai CLE is OS neutral. It is typically run on any of the numerous Linux distributions such as CentOS, Debian GNU/Linux, Fedora, Gentoo Linux, Red Hat Enterprise Linux (RHEL), SuSe Linux, Ubuntu but is also run on Mac OS X server, Microsoft Windows and Sun Solaris. Operating systems other than Linux are not nearly as well tested, and all of the community QA servers are running Linux, so this is generally the recommendation.

Examples:

Cerritos College, Windows 2003.
Georgia Tech, RHEL.
Indiana University, RHEL.
Mount Holyoke College: Debian GNU/Linux.

Oxford University: Debian GNU/Linux.
Rutgers University: Sun Solaris.
University of California, Berkeley: Sun Solaris.
University of Cape Town: SuSe Linux.

University of Florida: RHEL.
Universidad de Murcia: CentOS.
University of Virginia: Fedora.
Virginia Tech: Ubuntu.

Java

Oracle's Sun Java SE 6, a.k.a Java 1.6, is the preferred version to use with the Sakai CLE. Certain files, such as *.jsp and *.jws, require compilation so downloading and attempting to use only the run time environment (JRE 6.0) will not suffice. Mac OS X 10.6 (Snow Leopard) includes the full version of Java SE 6 so Mac users do not need to install Java. If you find Sun's version and naming conventions confusing, see Sun Java SE Naming and Versions for an outline of their practices.

Oracle's Sun Java J2SE 5.0 (a.k.a Java 1.5) has completed the EOL process and is no longer supported. If are still running Java 1.5 please note that security vulnerabilities exist in JDK/JRE 5.0 updates 1.5.0_17 and earlier.

For Sakai 2.9 OpenJDK and JDK 7 are supported along with JDK 6. Previous releases would not work with OpenJDK.

Application server choices

The Sakai Community is overwhelmingly an Apache http/Apache Tomcat user community and the Sakai CLE is at home in such an environment. Some Several schools run their Tomcats with Windows IIS and nginx proxies without issue. Since Sakai CLE 2.7.0 a Websphere module was included in the release in order to facilitate deployment to a Websphere/Db2 production environment; however, support has waned and the Websphere option is currently considered deprecated. A few schools such as Hong Kong University of Science and Technology and the Universidad de Guadalajara report deploying Sakai on JBoss.

Sakai 2.8.0 and previous releases require Tomcat 5.5 out of the box but can be configured in custom builds to run under Tomcat 7. Tomcat 7 is the requirement for running Sakai 2.9.0+. There are some changes to the Tomcat configuration required to get Sakai to startup in the source or binary form under Tomcat 7. Please see this page for more information!

Database choices

Sakai CLE production installations typically run either Oracle 10g/11g or MySQL 5.0/5.1. Support for IBM Db2 was added for the Sakai CLE 2.7.0 release but for 2.8.0 DB2 conversion scripts were not updated or tested and are currently considered deprecated. A demo version of Sakai includes HSQLDB; it should never be deployed in production.

It should be noted that Sakai is not limited to these database choices and integration with other RDBMS systems is not difficult. In the past at least one installation used Microsoft SQL Server while requests for PostgreSQL integration are occasionally raised on the Sakai developers list. However, to date no one in the Sakai Community has stepped forward to support alternatives to either Oracle or MySQL, a prerequisite for adding additional database options to the release.

Australian National University, MySQL 5.1
Indiana University, Oracle 10g
Oxford University, MySQL 5.0

Stanford University, Oracle 10g
Texas State University, San Marcos, MySQL 5.1
University of Cape Town, MySQL 5.1

University of Florida, Oracle 11g
University of Virginia, MySQL 5.0
University of Michigan, Oracle 10g
Virginia Tech, Oracle 11g

Clustering, file storage and load balancing strategies

A typical Sakai CLE cluster is comprised of one or more application servers running one or more instances of Tomcat 5.5 operating either in standalone mode or behind the Apache HTTP 2.2 web server. Each Tomcat instance runs a full copy of the Sakai CLE. The cluster is backed by a single database providing a transactional store of information. Storing binary content outside the database is a configurable option in Sakai and highly recommended from a performance standpoint. Most Sakai schools with sizable user populations opt for network-attached storage (NAS) or storage area network (SAN) solutions. Load balancing is provided by Apache (using mod_jk, mod_proxy_balancer or mod_proxy_ajp) or dedicated hardware solutions such as F5 BIG-IP, NetScaler or Zeus.

Three examples should suffice:

University of Cape Town
User base: 27,000+
Cluster: six Dual Xeon 3.6 GHz 8G RAM, 64-bit SuSe Linux (4 x physical servers, 2 x VMWare servers).
App servers: Apache HTTP server 2.2, Tomcat 5.5, Sakai 2.7.1.
Database: MySQL 5.1, 2 x dual-core processors, 16G RAM.
File storage: SAN Disk shared via NFS.
Load balancing: Apache 2.2 with mod_jk.

University of Michigan
User base: 45,000+
Cluster: five Dell PowerEdge 1950 boxes, each with 16 GB RAM running 64-bit RHEL 5.x (a sixth PowerEdge 1950 is utilized outside the cluster as a search server).
App servers: Apache HTTP server 2.2, fronting a single Tomcat 5.5/Sakai 2.7.1 install. One Java 1.6 JVM is configured per server with a 6 GB heap.
Database: Oracle 10g running on a Sun Fire T5120 with 128 GB RAM and Solaris 10 as the OS.
File storage: allocated 6 TB of disk space and stored externally in a NetApp FAS3020 filer, NFS mount.
Load balancing: two NetScaler RS9800 Secure Application switches.

Indiana University
User base: 100,000+
Cluster: two HP DL740 servers, 8-way with 3.0 GHz CPUs, 64 GB RAM and an IBM ESS "Shark" SAN running nine virtual application servers.
App servers: each virtual server is allocated 2 CPUs and 3.6 GB RAM and runs Apache HTTP 2.2/Tomcat 5.5.
Database: the Oracle 10g database is also a virtual instance housed on a Dell 810, dual socket, Quad Core server. The database is allocated 8 CPU and 32 GB RAM.
File storage: allocated 7 TB of disk space and is stored externally utilizing two NetAppliance FAS920C filers, NFS mount.
Load balancing: two HP DL385 servers running Zeus ZXTM load balancers. The load balancers run under Red Hat Enterprise Linux (RHEL) within VMware virtual machines and the architecture allows for more horizontal scaling if required.

External Authentication choices

The Sakai CLE can integrate with a variety of external authentication services including CAS, Kerberos, LDAP, Shibboleth and WebAuth.

Examples:

Australian National University: LDAP.
Indiana University: CAS.
Georgia Tech: CAS.
Oxford University: WebAuth.
Pepperdine University: CAS.

Stanford University: Kerberos.
Stockholm University: Shibboleth.
University of California, Davis: CAS.
University of Delaware: LDAP.

University of Hawaii: LDAP.
University of Michigan: Kerberos.
University of Florida: Shibboleth.
Yale University, CAS.

Integrating with student information systems

Sakai Community institutions have integrated their Sakai CLE installations with Banner, Datatel and Peoplesoft as well as a variety of home-grown student information systems (SIS).

The Sakai CLE has two basic approaches to integrating data from external systems. Most sites use a combination of these approaches. The first approach is to use the internal Sakai "provider" APIs. These APIs are places for Sakai to "consult" while Sakai is running. There are APIs for User Identity, User Directory, Course Listing and User Roles.

User Identity API: allows Sakai to call local code to validate users when they log into the system. This commonly uses Kerberos, Active Directory or LDAP to validate the user's credentials.

User Directory API: allows user information such as name and e-Mail address to be retrieved from an external system such as LDAP or X.509. The User Directory API has provisions to allow the local site to make decisions when to display student information in order to meet FERPA requirements. Each institution has different interpretation of FERPA so the precise FERPA decisions are delegated to the User Directory API.

Course Listing API: consulted when the instructor is creating a course site - this API returns the list of externally stored rosters for which the current user is the instructor. The user can select from one or more of these external rosters to associate with the course they are creating.

User Role API: is consulted when users log in to determine which external rosters they user is a member of and what their role is within those rosters. The Sakai internal configuration is updated if there are any changes to an individual's roster status.

The above API's are "pull" APIs--they are consulted when the user logs in or tries to take some action. The Course List API described above does not auto-populate courses.

If there is a desire to "push" information into the Sakai CLE, there are two approaches - Quartz and web services.

Sakai utilizes an internal batch system called Quartz that provides a cron-like capability within Sakai. Quartz is used by creating a Java class that does the necessary work and then having Quartz schedule the regular execution of that Java code.

A more common approach to pushing configuration information into Sakai is through web services. Any of Sakai's APIs can be accessed by web services. Web service access points have been developed for many of the common Sakai APIs used for configuration. These SOAP web services can be called from PHP, Python, Perl, Java, .NET or any other language. The Sakai CLE web service data structures are kept simple to insure the widest possible interoperability with as many languages as possible. Administrators often build scripts to pull data from their SIS system and populate the Sakai CLE with that data. These scripts may be automated using cron or manually executed by the administrator at the proper time during a semester.

This combination of pull/push configuration capabilities allows for a very wide range of integration possibilities for the Sakai CLE.