Sakai (and Bodington)

And next up is Sakai.

I am trying to get up to speed with what is happening between Bodington and Sakai. I have more or less been sold on the idea of a strong hierarchy organizing content. My take on it (I could be exposing my understanding as hopelessly naive here) is that the content hierarchy allows two overlapping hierarchies to exist.

On the one hand, the data is organized in “buildings” by some principle. This allows permissions to cascade easily, but also allows users to navigate in a logical way. On the other hand, users can be organized into their own groups (I am not yet sure whether users can be members of multiple groups, as I haven’t tried to do that yet). So I can have a group “StateDOT” with a sub-group “managers” with a sub-group “mid-level-managers” containing the names of managers. (TODO: Find out if I can also have DOT districts as a parallel set of groups, so I can have a person me a mid-level manager in District 12 or District 4?)

So I’m pretty sure I can let StateDOT-Managers-Mid-Level-Managers have access to the Transims floor of the Microsimulation Building, but only give them view rights to certain rooms on that floor, so they don’t go about trying to take courses that are designed for engineers, not managers.

On the other hand, why should the hierarchy be restricted to the concept of buildings/floors/rooms? Rather, I guess my real question that I am going to look at today is whether or not the hierarchy is in fact limiting. We have a use case in which we want to grant managers access to a broad selection of topics, but only the high-level, introductory lectures. On the other hand, we want the engineering staff (and our students) to initially see only specific, vertically integrated topics, but have the opportunity to branch sideways if necessary.

Anyway, this post is supposed to be about building and installing Sakai.

The download and build went off with only a few hitches, mostly related to my initial attempt to use

git svn clone https://source.sakaiproject.org/svn/sakai/trunk

which didn’t work right. Rather than figuring out the proper incantation, I just used svn as instructed.

The maven 2 build went fine, but the install is a different matter. The instructions on the wiki are probably prefect if you are running Tomcat 5.5, but if you are retarded like I am and decided to upgrade to Tomcat 6, then you’ll have problems.

First one small hitch in that I needed to add my regular user account to the tomcat group and make the shared and webapp directories writable by the tomcat group (someday I’ll read Unix System Administration, but until then I muddle along with half-formed notions of how to run Linux properly) (at least I didn’t build and install as root).

Two other install/deploy problems cropped up related to installing to shared (my Gentoo install of Tomcat 6 didn’t create the directory /var/lib/tomcat-6/shared) and a non-existent common directory. This is a hiccup between Tomcat 5.5 and Tomcat 6, as according to the Gentoo docs, the standard Tomcat 6 layout should be


/opt/tomcat-x.y/bin
/opt/tomcat-x.y/conf
/opt/tomcat-x.y/logs
/opt/tomcat-x.y/lib
/opt/tomcat-x.y/shared
/opt/tomcat-x.y/temp
/opt/tomcat-x.y/webapps
/opt/tomcat-x.y/work

(without common or server directories) which Gentoo has modified to

/usr/share/tomcat-x.y/bin
/etc/tomcat-x.y
/var/log/tomcat-x.y/logs
/usr/share/tomcat-x.y/lib
/var/lib/tomcat-x.y/shared
/var/tmp/tomcat-x.y
/var/lib/tomcat-x.y/webapps
/var/run/tomcat-x.y

Unfortunately the correct answer is to use the environment variables CATALINA_HOME (Gentoo default is /usr/share/tomcat-6) and CATALINA_BASE (Gentoo default is /var/lib/tomcat-6) instead of the single directory -Dmaven.tomcat.home=/var/lib/tomcat-6. But that requires fixing all of the pom.xml files. Time to fire up emacs. An easier answer is to just symlink server/lib and common/lib to /usr/shared/tomcat-6/lib, but I’d rather not do that. So I first changed the deploy target to shared, as in

 <properties>
   <deploy.target>shared</deploy.target>
 </properties>

in the “deviant” pom.xml files. Specifically, I changed the deploy.target from common to shared for dav/dav-common/pom.xml, util/util-common-deploy/pom.xml, and util/util-impl/log/pom.xml; and from server to shared for dav/dav-server/pom.xml.

With that, I was rewarded with

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13 minutes 12 seconds
[INFO] Finished at: Thu May 31 15:24:51 PDT 2007
[INFO] Final Memory: 89M/494M
[INFO] ------------------------------------------------------------------------

Next up, actually running Sakai

Advertisements

3 thoughts on “Sakai (and Bodington)

  1. Back again ;-)

    To answer a few things, yes a person can be in more than one group in Bodington and the permissions are additive. The underlying code supports negative permissions but they aren’t exposed in the UI. Our users have a hard enough time using the permissions without introducing the complexity of negative permissions.

    Building Sakai with Maven 2 is still a bit bleeding edge, it should hopefully sort itself out over the next few months but Maven 1 is the safe way to go. Tomcat 6 is also not tested and has changed its classloader setup from 5.5, although I believe you could emulate the 5.5 setup with 6.

    If you get Sakai running well on Tomcat 6 I’m sure the Sakai dev list would like to hear about what you had to change.

  2. One thing I forgot to mention is that we here at Oxford are looking to take some of the best hierarchical and group features of Bodington and implement them in Sakai. So we are looking to have a hierarchy of sites and the ability to inherit permissions. This is part of the work of a group of UK Universities called The Tetra Collaboration (http://www.tetraproject.org/)

  3. Matthew: thanks for the comments.
    Negative permissions sounds interesting. I was imagining binary permissions or’ed together, but in fact my use case (limiting managers from seeing really low-level stuff) might be better served by denying them the resource (negative permissions?) rather than actively allowing the resources to non-managers.
    I need to dig into the Bodington code, but haven’t had a chance to do more than scratch the surface.
    On the Sakai front, I am comfortable with Maven 2, as I did the migration thing from Maven 1 a while back. I think I am running into exactly the classloader changes you mention, but I’ve gotten some (but not all) of Sakai running by using symlinks to mimic the old server/shared/common libraries. When I get everything running I’ll post how I did it both here and on the Sakai list.
    I am also quite interested in the Tetra effort. I found the Tetra ELF dev mailing list, and checked out the contrib code from the Sakai svn repository, but haven’t done much more than that pending getting Sakai up and running. Thanks for the Tetra website link. At the moment it appears to be just the press release, but hopefully it will soon include links to the evolving BodingtonNG.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s