Sakai Portal Handlers

Sakai has a reworked portal in 2.4 called the Charon Skinnable Portal and this portal has the concept of handlers which can be used to handle different requests. Most of this code is in portal/portal-impl. The PortalHandler interface has a useful base class called BasePortalHandler and then some of the usable implementations are:

• PageHandler - Just displays a page which will load the tool in an iframe without anything else by default. URL: /portal/page/placementId
• WorksiteHandler - Just displays a site with the list of tools but no inter site navigation, supports supplying a additional page reference. URL: /portal/worksite/siteId
• GalleryHandler - Display the site as well as the inter site navigation but still no logo or login box, supports supplying an additional page reference. URL: /portal/gallery/siteId
• SiteHandler - Display a normal Sakai screen with site and inter site navigation, including login/logout links.

All the handlers are setup in SkinnableCharonPortal.init() which calls through to the portal service. The list of handlers if configurable at runtime through the portal service. Just posting this as a note for future reference really.

Bash History Expansion

I've alway been quite fond of bash history expansion and in particular !! (previous command) and !$ (last argument of previous command) but today I discovered a new trick, the :h modifier. This takes a word and removes file file name, here I am using it in action.

buckett@oucs-matthewb:~ $ sudo vi /opt/tivoli/tsm/client/ba/bin/incl.excl.SAVE 
buckett@oucs-matthewb:~ $ cd !$:h
cd /opt/tivoli/tsm/client/ba/bin
buckett@oucs-matthewb:/opt/tivoli/tsm/client/ba/bin $ mv incl.excl.SAVE incl.excl
mv: cannot move `incl.excl.SAVE' to `incl.excl': Permission denied
buckett@oucs-matthewb:/opt/tivoli/tsm/client/ba/bin $ sudo !!
sudo mv incl.excl.SAVE incl.excl

Now I just have to remember it for more than a few days for it to seep into my normal usage of the shell.

Sakai Startup Logs

Often after I've started up Sakai I'll tail(1) the logs so I can see how the startup is going, however by default Sakai spits out quite a few informational messages and it is easy to miss the important stuff so now I tend to watch the logs with the following command:

tail -f logs/catalina.out | grep -v INFO

which doesn't display all the INFO messages but still shows me anything serious, and all the internal tomcat messages about how the startup is progressing. I know I could change the logging (log4j) but this is a simple trick which still allows me to look back at the info messages to check things.

Installing Grouper Quickstart

Here are a few of my notes on the Internet2 Grouper project. I'm just attempting to get the quickstart up and running to get more of a feel for the application. First of all I grabbed a copy of Grouper 1.2.0RC2 quickstart and started following the instructions. After unpacking the archive and unpacking a clean copy of tomcat I copied across the tomcat-users.xml as I didn't have any existing users I wanted to keep.

After a quick scan of the grouper-ui/build.properties file I attempted to build the UI with ant ui and selected option 6 (war) however this fell over with an ugly ant error. Looking at the build.xml it seemed to be failing on the <propertyfile> task. A quick google and it seems this is an optional task, from previous experience I knew that the nice Ubuntu people split off the optional ant tasks into a seperate packages and sure enough that was missing on my system. An apt-get later and I had the ant build successfully running.

I copies the newly created WAR into Tomcat and started it up. 14 seconds later I could access the Grouper UI. After a delay I realised that all I had was a redirect to populateIndex.do and a blank page. Then I remembered a mention at the start of the document saying I needed an HSQL database to be running. As it turns out this is actually reasonably easy, just ant db at the toplevel of the quickstart. Then a trip back to the webserver and yey, a working grouper installation. Now time for a little play.

Upgrading Sakai to 2.4

Ok, I've just upgraded our test sakai instance to the just released 2.4.0. Here are the notes of how I did it, this isn't a recommended pattern:

• Get source checkout from svn of 2.4.0
• Set maven.repo.remote in master/build.properties
• Check build works with maven bld
• Get patches used on 2.3.1 release
• Apply patches to login-tool and providers and fix rejections
• maven cln bld
• maven sakai:deploy-zip
• Copy sakai.tar.gz to server
• Stop existing tomcat and move out of the way
• Expand a clean tomcat 5.5.23
• Copy across conf/server.xml
• Copy across sakai folder from 2.3.1
• Copy across mysql connector from 2.3.1
• Upgrade the schema
• Copy across /portal redirection
• Start up tomcat

Of course it didn't go this well, and it took just over a couple of hours to get it all working. We need to patch login-tool for WebAuth authentication and the providers to configure the LDAP provider of user account information, but otherwise it is a fairly standard sakai install.

Sakai maven 1 & 2 problems

I had a checkout of sakai trunk and had a look at using maven 2 to build and deploy it. After a little experimentation I changed back to maven 1. Then I did an svn update and rebuilt with maven 1 and after deploy I started to see errors at the tomcat startup, after allot of checking I finally realised that I had the maven 1 and maven 2 artifacts deloyed into the same tomcat instance as as they have different versions by default they both existed in parallel, which means I had both sakai-site-api-dev.jar (from maven 1) and sakai-site-api-M2.jar (from maven 2).

Maybe the version of maven 2 artifacts should be dev by default, rather than M2, to match maven 1? What I'm not yet sure of is why you would ever want more than copy of a particular JAR in a classloader, so maybe the version shouldn't be used in the filename when the deployment is made. Although in production it is useful to have the versions for working out what versions of a file you have.

Google Apps at Oxford

Here in OUCS we recently had a presentation by Barry Cornelius about Google Apps. Barry had setup Google Apps to use the Oxford Single Signon solution WebAuth to allow members of Oxford University to login to Google Apps on a domain, in his example he used his own domain but it could easily be something like docs.ox.ac.uk. This meant that anyone with an Oxford Account could use Google Apps without having to create another account.

Now when you signup for Google Apps you are asked to provide a domain onto which these apps will run and Google then allows you to provide branding of that domain. Google has the option to provide lots of applications (Word Processing, Spreadsheets, Calendaring, etc) and here I am talking about providing about everything except GMail which is a much more complicated issue.

My personal thinking is that OUCS should provide this service to its users and view it in a similar way to how it will provide a Shibboleth service. We provide the authentication, but the actual application is run and managed by someone else and the users should be aware of that. The possible problem with running Google Apps on an Oxford domain (docs.ox.ac.uk) is that it looks like an Oxford endorsed service and that if you have issues with it you should visit the Oxford helpdesk. However if Oxford could use the domain oxford.google.co.uk (or similar) then I believe it is much clearer that the service is provided by Google and Oxford is just providing the integration with SSO.

For a little effort we have the ability to make users lives easier in that they only need to sign on to WebAuth and they automatically get access to Google Apps. As Google already provides this service free to individuals there is nothing to stop any member of Oxford University just visiting Google and signing up for an account.

This also shows members of the University how SSO makes lives easier and how OUCS is looking to embrace new tools. But I think that we need to be clear that OUCS isn't endorsing the use of Google Apps and isn't supporting it (Google is). And why stop at Google Apps, if other companies provide similar authentication integration service why not integrate with them?