Child pages
  • Sakai 10 and later System Requirements

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation

Operating system (OS) choices

Sakai is OS neutral. It is typically run on any of the numerous Linux distributions. Examples of common Linux distributions include as CentOS, Debian GNU/Linux, Fedora, Gentoo Linux, Red Hat Enterprise Linux (RHEL), SuSe Linux, Ubuntu. Sakai can 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.


Sakai 10 has been tested most thoroughly with Oracle's Java 7. It also should still be binary compatible with Java 6, aka Java 1.6 . Requires JDK 6 to build "all code".  Sakai 10 is currently not supported in Java 8 and it would advised against running or trying to build it as some tools will not work correctly 

. Certain files, such as *.jsp and *.jws, require compilation so downloading and attempting to use only the run time environment (e.g. JRE 7.0) will not suffice. 

For Sakai 10 (2014 release)

Targets Java 6+. QA'd with 7. Requires Java 6-7 to build.

Likely for Sakai 11 (2015 release)

Targets Java 7+. Likely QA'd with JRE 8. Likely will require Java 7-8 to build.

What breaks JRE compatibility is when someone wants or needs to use new features of the language or newer libraries. What breaks JDK compatibility are generally internal interface changes where we'd have to do work to support 2 sets of source code.



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.

Application server choices

Apache Tomcat 7 is the recommended, and most thoroughly tested servlet container, and is most often used with a web server like Apache Http Server. Several schools run their Tomcats with Windows IIS and nginx proxies without issue. A few schools such as Hong Kong University of Science and Technology and the Universidad de Guadalajara report have deployed Sakai on JBoss, in the past but no support for this setup is provided. As of Sakai 10's release, Tomcat 8 is beta and has not been tested.

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!

titleWebsphere deprecated
In Sakai 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.


Database choices

Sakai production installations typically run MySql 5.5 or later. Oracle is the next most popular choice. There are known installations of Sakai on Oracle 10g, 11g, and 12cMariaDB is a binary drop in replacement for Mysql (source) and MariaDB should work with Sakai but it is not officially supported. There are known installations of Sakai on MariaDB 5.1 or 5.5 (for example : at Rutgers University - source). 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. 

titleIBM DB2 Deprecated
Support for IBM Db2 was added for the Sakai 2.7.0 release but for 2.8.0 DB2 conversion scripts were not updated or tested and are currently considered deprecated, including for 2.9.x.
A demo version of Sakai includes HSQLDB; it should never be deployed in production.

Clustering, file storage and load balancing strategies

A typical Sakai cluster is comprised of one or more application servers running one or more instances of Tomcat 7 operating either in standalone mode or behind the Apache HTTP 2.2 web server. Each Tomcat instance runs a full copy of Sakai. 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.


External Authentication choices

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

Integrating with student information systems

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

Sakai 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 Sakai, 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 data (e.g. enrollment and course information) into Sakai is through web services. Many 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 REST and SOAP web services can be called from PHP, Python, Perl, Java, .NET or any other language. The Sakai 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 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.

Sv translation

Elección del sistema operativo

Sakai CLE es neutral respecto al sistema operativo. Habitualmente corre sobre cualquiera de los numerosas distribuciones Linux. Ejemplos de estas distribuciones comunes de Linux son CentOS, Debian GNU/Linux, Fedora, Gentoo Linux, Red Hat Enterprise Linux (RHEL), SuSe Linux, Ubuntu. Sakai CLE también puede funcionar en Mac OS X server, Microsoft Windows y Sun Solaris. Los sistemas que no Linux no son habitualmente tan testados por la comunidad, ya que los servidores de QA son Linux, por eso, habitualmente se recomienda uno de estos sistemas Linux.


Sakai 10 se ha probado mayoritariamente con Oracle's Java 7 . Puede ser compatible binariamente con Java 6, aka Java 1.6 . Requiere JDK 6 para compilar "todo el código".  Igualmente, JDK deberían complilar la mayoría del código.  No se recomienda el uso de Java 8 ya que se ha comprobado que ciertas herramientas no funcionan correctamente




Ciertos ficheros, como *.jsp y *.jws, requieren compilation por lo que descargar y tratar de usar sólo el run time environment (JRE 7.0) no es suficiente. 

Para Sakai 10

Objetivo Java 6+. Probado con 7. Requiere Java 6-8 7 para compilarse

Probablemente para  Sakai 11 (liberado en 2015)
Los objetivos son JRE Java 7+. Y probarlo a fondo con JRE 8. Requiere Posiblemente requerirá JDK 7-8 para compilar.

Lo que estropea la compatibilidad con los JRE es cuando alguien quiere o necesita utilizar nuevas funcionalidades del lenguaje o nuevas librerías. Lo que rompe la compatibilidad con el JDK son generalmente cambios internos en las interfaces donde tenemos que realizar trabajo para poder soportar 2 conjuntos de código fuente.



Oracle's Sun Java J2SE 5.0 (a.k.a Java 1.5) ha terminado el proceso EOL y ya no tiene soporte. Si todavía está usando Java 1.5 por favor dese cuenta de las vulnerabilidades en la seguridad que existen en las actualizaciones JDK/JRE 5.0 1.5.0_17 y anteriores.

Selección del Servidor de Aplicaciones

Apache Tomcat 7 es el recomendado y el más testeado en profundidad, y es utilizado mayoritariamente con un servidor web como Apache Http Server. Algunas instituciones ejecutan sus Tomcats con Windows IIS y proxies nginx sin ningún problema. Algunas escuelas como la Hong Kong University of Science and Technology y la Universidad de Guadalajara informan que han desplegado Sakai en JBoss, en el pasado pero no se proporciona soporte para este tipo de configuración. Como durante el proceso de Sakai 10, Tomcat 8 estaba en beta, no ha sido probado.


Sakai 2.8.0 y las versiones anteriores requerían Tomcat 5.5 por defecto pero pueden ser configuradas para correr sobre Tomcat 7. Sin embargo Tomcat 7 es el requisito para correr Sakai 2.9.0+. Hace falta realizar algunos cambios en la configuración de Tomcar para conseguir que Sakai funcione tanto en la versión binaria o la versión a partir del código fuente en Tomcat 7. Por favor, visite este enlace para más información

titleWebsphere no soportado

En Sakai CLE 2.7.0 se incluye un módulo Websphere para facilitar el despliegue en un entorno de producción Websphere/Db2; sin embargo, el soporte ha cesado y la opción de Websphere se considera actualmente obsoleta.                     


Selección de la Base de Datos

Las instalaciones de producción de Sakai CLE se ejecutan habitualmente sobre Oracle 10g/11g and 12c o MySQL 5.1/5.5. 

MariaDB puede remplazar Mysql (source) y MariaDB debería funcionar con Sakai, pero no está oficialmente soportadoHay instalaciones conocidas de Sakai sobre MariaDB 5.1 o 5.5 (por ejemplo en Rutgers University -source)

Sakai no se limita a estas opciones y la integración con otros RDBMS  no es difícil. En el pasado, al menos una instalación ha usado Microsoft SQL Server mientras que peticiones sobre integraciones con PostgreSQL de vez en cuando surgen en la lista de desarrolladores de Sakai. Sin embargo nadie en la comunidad Sakai ha dado un paso adelante para dar soporte a alternativas a Oracle o MySQL, un prerrequisito para añadir opciones adicionales de base de datos a Sakai.

titleIBM DB2 No soportado

El soporte de IBM Db2 se añadió en Sakai CLE 2.7.0 pero para 2.8.0 los scripts de conversión a DB2 no se actualizaron y se considera actualmente obsoletos, incluso para 2.9.x.                     


La versión demo de Sakai incluye HSQLDB; pero no se debe usar nunca en producción.                     

Estrategias de Clustering, almacenamiento de ficheros y balanceo de carga

Un clúster típico de Sakai CLE se compone de uno o más servidores de aplicaciones corriendo una o más instancias de Tomcat 7 operando cada uno en modo standalone o detrás de un servidor web Apache HTTP 2.2. Cada instancia de Tomcat ejecuta una copia completa de Sakai. El cluster está apoyado en una única base de datos proporcionado alojamiento transaccional a la información.

Alojar el contenido binario fuera de la base de datos es una opción configurable en Sakai y es altamente recomendable para un mejor rendimiento. La mayoría de las organizaciones con Sakai con gran cantidad de usuarios optan por soluciones de alojamiento en red tipo NAS o SAN. El balanceo de carga lo proporciona Apache (usando mod_jk, mod_proxy_balancer o mod_proxy_ajp) o con hardware dedicado, como las soluciones F5 BIG-IP, NetScaler o Zeus.


Opciones de autenticación externa

Sakai CLE se puede integrar con varios sistemas de autenticación externa incluyendo CAS, Kerberos, LDAP, Shibboleth y WebAuth.

Integrando Sakai con los Sistemas de Información de Estudiantes (Student information systems - SIS)

Las instituciones de la Comunidad Sakai han integrado sus instalaciones de Sakai CLE con Banner, Datatel y Peoplesoft así como con una gran variedad de sistemas propios.

Sakai CLE tiene dos formas básicamente de integrar los datos de sistemas externos. En la mayoría de lugares se usa una combinación de estas dos formas. La primera es utilizar los API's internos que proporciona Sakai. Estos APIs son lugares donde Sakai puede consultar mientras está en marcha. Hay APIs para la Identidad del Usuario, para el Directorio de Usuarios, para el Listado de Cursos y Roles de Usuario.

User Identity API: permite a Sakai llamar código local para validar usuarios cuando se loguean en el sistema. Esto usualmente se hace usando Kerberos, Active Directory o LDAP para validar las credenciales del usuario.

User Directory API: Permite que la información del usuario, como el nombre o el e-Mail sea consultada por un sistema externo como LDAP o X.509. El User Directory API permite decidir al sitio local cuando mostrar la información del estudiante para cumplir los requisitos FERPA (Protección de datos personales). Cada institución tiene diferente interpretación de FERPA por lo que las decisiones finales sobre FERPA se delegan al User Directory API.

Course Listing API: es consultado cuando el instructor crea un sitio del tipo curso. Este API devuelve la lista de grupos en los que el usuario actual es el profesor. El usuario puede seleccionar uno o más de esos grupos externos para asociarlos con el curso que está creando.

User Role API: se consulta cuando los usuarios entran en la plataforma para determinar de qué grupos externos el usuario es miembro y cual es el rol en esos grupos. La configuración interna de Sakai se actualiza si hay cambios el estado del usuario en un grupo externo.

Los APIs anteriores son "pull" APIs-- se consultan cuando el usuario entra o intenta hacer alguna acción. El Course List API descrito anteriormente no matricula automáticamente los cursos.

Si se desea "empujar" la información en Sakai CLE, hay dos formas de hacerlo - Quartz y web services.

Sakai utiliza un sistema interno de tareas llamado Quartz que proporciona la capacidad de lanzar tareas programadas en Sakai. Quartz se usa creando una clase de Java que hace el trabajo necesario y entonces se programa en Quartz una agenda de ejecución regular de ese código Java.

Una forma más común de introducir información en Sakai es mediante los web services. Cualquiera de los APIs de Sakai puede ser accedido por web services. Los puntos de acceso de los web services se han desarrollado a partir de los APIs habitualmente utilizados para configuración. Estos web services SOAP pueden llamarse desde PHP, Python, Perl, Java, .NET o cualquier otro lenguaje. La estructura de datos de los web services de  Sakai CLE se mantienen lo más simple posible para asegurar la mayor interoperabilidad posible con el mayor número de lenguajes posible. Los administradores a menudo construyen scripts para meter datos de sus SIS y poblar el Sakai CLE con datos. Estos scrips se pueden automatizar con cron o ser ejecutados manualmente por el administrador en el momento adecuado.

Esta combinación de capacidades de configuración pull/push permiten un gran rango de posibilidades de integración de Sakai CLE.

Sv translation


Sakai是操作系统中立的。可以安装在绝大多数的Linux发行版上。常见的Linux发行版包括CentOS,Debian GNU/Linux,Fedora,Gentoo Linux,Red Hat Enterprise Linux (RHEL),SUSE Linux,Ubuntu。Sakai也可以运行在Mac OS X服务器,Microsoft Windows以及Sun Solaris上。Linux意外的操作系统没有被充分测试过,所有的社区测试服务器都是部署在Linux上,所以一般也建议使用Linux来部署Sakai。


Sakai 10 主要在Oracle Java 7下进行测试. 但应该在Java 6(Java 1.6)环境下也可以正常运行。但编译系统至少需要JDK 6或以上版本;JDK 8环境应该也可以运行。有些文件(例如*.jsp和*.jws)需要在部署后进行编译,所以仅仅安装JRE是不够的,必须要安装JDK。

Sakai 10 (2014发布)

版本要求 Java 6+。基于 Java 7进行测试。需要使用 Java 6-8进行编译。

Sakai 11 可能需求 (2015发布)

版本要求 Java 7+。可能基于 Java 8进行测试。可能需要使用Java 7-8进行编译。




Oracle Sun Java J2SE 5.0 (Java 1.5) 已经结束了生命周期,不再被官方维护。如果您还在使用 Java 1.5,请注意相关安全问题,并升级到1.5.0_17或更新版本。


推荐使用Apache Tomcat 7,这是被充分测试的应用服务器,一般会与Apache HTTP Server这样的Web服务器一起使用。有些学校也成功使用了Windows IIS或Nginx作为Web服务器。还有一些学校(香港科技大学和瓜达拉哈拉大学)使用JBoss运行Sakai,但这里不提供相关的安装指导。在Sakai 10完成开发时,Tomcat 8依旧处于beta状态,所以没有进行过相关测试。

Sakai 2.8.0和之前版本需要Tomcat 5.5,但可以通过修改配置运行在Tomcat 7中。Sakai 2.9.0及以后版本需要运行Tomcat 7,并需要修改Tomcat的配置来使其正常运行。具体信息请参考这篇文档。
Sakai 2.7.0中包含Websphere模块来支持Websphere/DB2生产环境,然而由于缺乏维护,Websphere已不被支持。



现有Sakai生产环境中,使用最多的是MySql 5.5或更新版本,Oracle其次;已知的使用Oracle版本包括10g,11g,12c。Sakai并不局限于这两种数据库,与其它关系型数据库的集成也不是很困难。曾经有学校使用Microsoft SQL Server作为数据库,Sakai开发者中也偶尔有人建议支持PostgreSQL。但是,目前Sakai社区中没有人支持除MySQL和Oracle以外的数据库。

title不再支持IBM DB2
Sakai 2.7.0中增加了IBM DB2支持,但是在2.8.0中,数据库更新脚本没有被更新和测试。所以Sakai不再支持DB2,包括此后的2.9.x。
Sakai demo版使用HSQLDB作为数据库,但请不要在生产环境中进行使用。


典型的Sakai集群使用多台服务器,每个服务器上部署一个或多个Tomcat,然后还可以将这些服务器部署在Apache HTTP Server之后。其中,每个Tomcat中部署一份完整的Sakai。另外还需要部署一台数据库服务器。

将用户文件保存在数据库外是推荐的做法,但需要在Sakai的配置文件中进行设置。多数部署Sakai的学校使用NAS或SAN来存储文件。负载均衡通过Apache HTTP Server(通过mod_jk,mod_proxy,mod_proxy_balancer或mod_proxy_ajp等模块)或者负载均衡硬件(如F5 BIG-IP,NetScaler或Zeus)实现。 





Sakai有几种基本的集成外部系统的方法。这几种方法可以混合使用。第一种是使用Sakai "provider" API,Sakai在运行时可以通过调用这些API获取信息,包括用户帐号,用户信息,课程信息,用户角色等。

用户帐号 API:Sakai用来确定用户是否可以登录到系统。可以用于Kerberos,Active Directory或者LDAP来进行验证用户身份。

用户信息 API: Sakai用来获取用户姓名、email等信息,获取的来源可以是LDAP或X.509。通过选择性地展示用户信息,可以保护用户隐私。




如果需要将数据“推送”到Sakai,有2种方案 - 计划任务和Web Services。


另一种更加普遍的方法是将相关数据通过Web Services的方法推送到Sakai。通过Web Services,可以简介访问很多Sakai的API。REST和SOAP接口可以被多种语言调用。系统管理员也可以根据实际需要创建自己的Web Services。但这种方法在数据量大时,可能会产生一定的性能问题。