Tuesday, May 29, 2007

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.

Friday, May 25, 2007

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.

Tuesday, May 22, 2007

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.

Monday, May 21, 2007

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.