jump to navigation

The ache of almost being in the sweet spot September 14, 2010

Posted by grimmeister in Geoinformatics.

Freshly back from another inspiring FOSS4G, Barcelona, I returned full of enthusiasm to slay a particular dragon of mine:

Our research organisation is a long term ESRI shop, where geographers, ecologists, planners, statisticians, remote sensing specialists and other assorted scientists have been happily using ArcGIS/INFO/View Desktop software for many moons. It is a semi-pointless battle to convince older users in particular of any benefits of using FOSS4G tools on the desktop – they have tools that they know well and perform the necessary tasks (even if we are talking venerable tools like ArcView 3.x). Convenience is a huge factor for such users, who do not necessarily consider themselves as GIS practioners in the first place, and will simply not be interested in learning a whole new GIS tool.

On the other hand, our organisation is supposed to push boundaries with FOSS in a country where we have a mandated FOSS policy. Now, there are a number of researchers who happen to run forms of Linux or who are comfortable with FOSS4G softwares, and are quite excited by the possibilites for pushing such software into all sort of nooks, crannies and other experimental places in conjunction with other FOSS apps, libraries and components.

In the middle of this situation, the organisation is trying to implement an enterprise SDI, from a modest budget that must fund a number of floating and single use ArcView and ArcInfo licenses. Since the folk who are actually running the implementation process are 1) not really GIS users or 2) have not tasted the yummy FOSS4G Kool Aid or 3) are from the IT department where certification and promises of support are paramount, the convenient thing to do has been to let the local ESRI guys lead the implementation thought process. The wisened amongst you will recognise the VAR wet dream. Indeed, the ArcGIS Server was shipped before you could say boo! to a goose. So the plan was an enterprise ArcSDE spatial database running on Oracle, serving all its wonderful goodness to our licensed Arc* users and the occasional WMS through ArcGIS Server. Sweet. Except for a nagging issue (well, I would call it that)….

Like, umm, what about us?!! The non-ESRI desktop users?!!! You know, the slightly geekier, poorer, maybe more experimental types???!! Are we to sit on the edge of the SDI hoping for a WFS tidbit (if the implementation of ArcGIS server even bothers with such a thing). Of course, it would be easy enough to run a parallel SDI on a FOSS stack, but that is not particularly constructive is it? Luckily Oracle to the rescue…

More precisely, its licensing fee structure. The expense of it. Too much for our modestly funded SDI effort, considering our need to share spatial data, originating in Oracle, over the web. Now, a while ago, I had sown the seed of a possible PostGIS backed ArcSDE for our enterprise, and had even experimented with such a configuration, concluding that we may just get by with it if limited editing/ upload capability was allowed for FOSS4G type clients – at least we would be able to work with shared read-only data and happily serve up W*S’s through GeoServer/MapServer.

ArcCatalog - Openlayers off Geoserver - QGIS direct read of SDE on PostGIS

So, re-enter me, fresh from FOSS4G, keen to see if PostGIS could be dropped into the enterprise, just like that!

Some annoying realities intruded to burst my wee little bubble. The PostGIS/SDE 9.3 combination is only supported on 32 bit Windows machines, and 32 bit Enterprise Linux flavours. I have been enjoying the bounteous riches of 64 bit Ubuntu (that really free OS) for some years now , so was a bit taken aback, worsened by the discovery that SDE 9.3 is only supported on Postgres 8.3.0 with PostGIS 1.3.2.  http://wikis.esri.com/wiki/display/ag93bsr/ArcSDE+PostgreSQL+Database+Requirements. No Prepared Geometries, Cascaded Unions, Geography Types, Window Queries, etc . I feel this is very weak support, but hey, at the least, we could still have PostGIS geometries, for what they are worth.

But then I let a sneaking suspicion re-enter my mind: nobody in the organisation really makes use of the powerful features of SDE, like versioning, geodatabase modelling, multi-user editing, etc, so why do we need ArcSDE/ArcGIS Server in the first place….? To test this, we met with a user whose research group potentially used geodatabases more fully. Her response inflated and deflated my mood at the same time. It turned out that they were not even using any enterprise provided database facilities, determining that they were not performant. Instead, the limited amount of geodatabase activity they undertook used a shared file geodatabase structure, from which they were publishing WMS offerings via ArcGIS Server. I left the meeting energised by the possibility that the road was open to replacing (rather than tweaking) ArcSDE and ArcGIS Server with PostGIS and Geoserver, but a bit concerned that a long road lay ahead to convince users to take advantage of shared SDI components.

Seeing an open road, and a challenge, I dug around to see if there is a way to make this whole enterprise SDI lark a non-zero sum game. ZigGis seems to be the best (and good)  candidate to get ArcGIS clients to access PostGIS directly. This sounded really positive – the existence of a sweet spot, where everyone could be happy! What is more, it looks like ZigGIS is going Open Source again, potentially reducing the licensing overhead against our limited budget. Alas, we really need ZigGIS 3 – the sweet spot receded with the realisation that ZigGIS would not currently be useful to Arc* users primarily since it does not have ArcCatalog functionality . So, you may ask, what about funding the ZigGIS project in order to speed up its work tords a 3.0 release?  Good Point indeed! This is going to be fun trying to build up a business case for our organisation to fund development, when all the IT services want is risk reduction and guarantees. Which leads me to another reason why I ache so much today – a supported PostGIS/Geoserver/Desktop Client stack, so coveted by the IT minions, would actually cost a similar amount to an ESRI stack. Now, I can still think of a lot of reasons why such a stack offers more value (read replication, flexibility, wide usage of standards, etc), but I wonder to what extent this sweet spot, winners all around scenario will seem compelling enough to our moneybags people…

You may have heard this:

“There we were, two against two thousand – boy, did we take those two guys out!”

I feel like one of the two guys, lined up against a all sorts of obstacles (technical, organisational, lack of interest, financial, timing) before there is any view of what seems a sweet spot.

Ah well, nothing ventured and all that…


Revving up Geoserver on Ubuntu HH LTS November 10, 2008

Posted by grimmeister in Geoinformatics.
Tags: ,

Given my setup described at revisiting-geoserver-on-ubuntu
, I am slowly learning (with Tim Sutton) good and weird lessons on how to make geoserver really punch out those services…

No question, you have to do a few things. Geoserver out of the box is relatively minimalist. So a few things need attention, many outlined in the *geoserver in a production environment pages* of the website.

1) Make sure you are using the server jvm.

UPDATE: see Andrea’s comments – the server VM automatically kicks in if you have a server class machine, and configures resource allocation similar to what is described in point 2.

Many docs, including those at Geoserver suggest using a -server flag for the tomcat daemon. This is rather mystifying to myself and others, because Tomcat will not start on our systems if we have this flag set. So my conclusion is that the -server flag is inbuilt into server class machines, or in the Ubuntu 64 bit environment, it is just not available.

I suspect that the kind folk at Ubuntu have distributed the various server flavours with the server jvm as default. To check, type at prompt:

java -server -version

you should receive back something like :

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode)

If you get this, you will notice in the file /usr/lib/jvm/java-6-sun- that the server option is default.

If you do not get this message , it is likely that you have not got the sun jdk installed for your server, so fetch and install it, make sure the jdk /bin is first to be found on the path, then repeat the above test.

So the question you really need to answer, is whether /usr/bin/jsvc (commons-daemon on Debian/Ubuntu) is hitting the appropriate JVM.

A question that bothers me a bit is whether there is even a -server flag on 64 bit Ubuntu. This configuration step may be pointless. Seems odd, but my readings have hinted that it is not an option on AMD64 architectures. Given Ubuntu 64 bit seems to work on X86 and AMD64 systems, is it possible that an artifact is a missing -server flag

A little bit vague I know, but may give you enough of a hint to get it working fully.

2) Throw resources at Tomcat

From the get-go give tomcat lots of resources (depending on what else is running on your system). Do this in your tomcat daemon script ( /etc/init.d/tomcat5.5) JAVA_OPTS section. JAVA_OPTS="-Djava.awt.headless=true -Xms144m -Xmx768M -XX:SoftRefLRUPolicyMSPerMB=36000 -XX:MaxPermSize=256m -XX:XX:+UseParallelGC" So, I have set the minimum heap size to 144Mb of memory, maxing out at 768Mb and giving the JVM space to move. I have increased the perm gen space to 256 Mb to aid in classloading and have made use of my multiprocessor setup for garbage collection. There are loads of options available – I am certainly not sure if I am properly optimised here at all.

3) Sessions

I have been grappling a fair amount with a particular issue around Tomcat sessions spiralling out of
control for the geoserver context.

So, make sure (if you are using tomcat, and this seems to be a problem) that you add or modify
the /webapps/geoserver/WEB-INF/web.xml file to include:


This prevents sessions from being kept alive when idle for more than a
minute. Geoserver does not need them apparently. Be aware that you should probably only do this once your geoserver config is happy – otherwise you will be logging in a lot 😦
4) Logging

make sure to set the log level to PRODUCTION-LOGGING.properties in the server part of the config.

5) Tile Cache

If you are serving WMS, put a tile cache of some variety up in order to reduce the load on the database and geoserver. MetaCarta’s TileCache, GeoWebCache, OSCache, even something like Squid could be used. I have not set it up a tile cache yet, but will add details if and when when I do so (my WMS’s data tend to change quite a lot)

6) Apache Portable Run Time library with Tomcat

The use of this library allows certain aspects of tomcat to be enhanced, with performance gains of 10% or so reported. I guess it would depend on what you were serving!

Binaries for this library can be found, but it is better to compile from source ( with some help from http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Tomcat+Native+Library ).

Make sure that you have the libssl-dev and libapr1-dev packages installed ( sudo apt-get install libssl-dev libapr1-dev)

http://apache.seekmeup.com/tomcat/tomcat-connectors/native/1.1.15/source/tomcat-native-1.1.15-src.tar.gz is some source code

Extract the tarball of the tomcat native lib (tar -xvzf tomcat-native.tar.gz)

cd tomcat-native-1.1.5/jni/native

Configure ./configure --with-apr=/usr --with-java-home=/usr/lib/jvm/java-6-sun- (or wherever your jdk lives)

Make and install (sudo make && sudo make install) – generates the library and symlinks in /usr/local/apr/lib

Change to the system library folder ( cd /usr/lib )

Make a symlink to the library  (sudo ln -s /usr/local/apr/lib/libtcnative-1.so libtcnative-1.so)

Edit ${TOMCAT_HOME}/bin/catalina.sh adding the following lines somewhere before java is executed ( LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH )

Restart Tomcat and make sure to check your logs for success or failure. It seems that failure may likely result from problems with IPv6 enabled machines. Disable IPv6 ( edit /etc/modprobe.d/aliases and change the linealias net-pf-10 ipv6toalias net-pf-10 off ipv6 and reboot ) if you can.

7) Native JAI rather than the pure java JAI

This applies in particular if one is attempting to serve raster data, perhaps some satellite imagery but per Andrea’s comment is valuable for improving WMS generation too. So:

fetch the libraries. I got myself the ones from http://download.java.net/media/jai/builds/release/1_1_3/jai-1_1_3-lib-linux-amd64.tar.gz

After unpacking the tarball, I copied the 3 jar files:

sudo cp jai-1_1_3/lib/*.jar  /usr/lib/jvm/java-6-sun-

and the shared library:

sudo cp jai-1_1_3/lib/libmlib_jai.so  /usr/lib/jvm/java-6-sun-

then restarted Tomcat. JAI appears as available on the Geoserver Admin page.

Revisiting Geoserver on Ubuntu July 28, 2008

Posted by grimmeister in Geoinformatics.

After a year or so of running Geoserver 1.5.x in a prototyping environment, I have run through the process of getting Geoserver 1.6.4 running in Ubuntu 8.04 a.k.a Hardy Heron production environment.

The overall view: it is dead easy now, with less fiddling necessary. So the steps in the process

Apache Tomcat/5.5
Sun jdk 1.6.0_06-b02
Linux 2.6.24-16-server kernel
64 bit Architecture

1) sudo apt-get install sun-java6-jdk.
Given that sun jdk installed, make sure its jvm is the default jvm
sudo update-alternatives --config java
choose the sun option

2)Tomcat is a bit quirky on Ubuntu

2.1)if not installed, do:
sudo apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps

2.2)Configure Tomcat for the Java JDK. Edit /etc/default/tomcat5.5, uncommenting this line:

2.3)Set some permissions:
cd /var/lib/tomcat5.5/
sudo chown -R tomcat55:tomcat55 logs work
sudo chown tomcat55:tomcat55 /usr/share/tomcat5.5

2.4)Change service port to 8080 (default is 8180) in /etc/tomcat5.5/server.xml if need be

2.5)Change the users and passwords for working with tomcat, tomcat admin and tomcat manager in /var/lib/tomcat5.5/conf/tomcat-users.xml
Advice seems to be to get a separate admin user with roles {admin, manager,tomcat}

2.6) No more need to fiddle with the catalina.out issue – seems to have been fixed

So, to Geoserver…

1) We need to have the ability to serve OGC standard WFS, WMS and potentially WCS. We know the Geoserver tool works as we have been serving WMS, WFS and very large WCS’s through it.

1.1) Download the .war file in a zip file from the Geoserver website. We are using 1.6.4. Extract .war file

1.2) Deploy the .war file from the Tomcat Manager page. This will take place okay, but Geoserver will not be able to start, for Tomcat on Ubuntu (well, as provided by Ubuntu in the repositories) is by default tightly locked down.

1.3) No need seems to exist to create a geoserver.policy file anymore. On 8.04, it would appear that such a file would have to live in /etc/tomcat-5.5/conf/policy.d directory, but its presence completely prevented Tomcat from even starting, so I left it out

1.4) One still needs to open the /var/lib/tomcat5.5/conf/policy.d/04webapps.policy document and add a line to it granting looser security permissions:
permission java.security.AllPermission;

Then restart Tomcat and get cracking with setting up your data environment or migrating it across to the new version of Geoserver.

Ubuntu Gutsy 64 bit GIS Workstation Theme part 1 November 1, 2007

Posted by grimmeister in Geoinformatics.
add a comment

I have a nice shiny new 64 bit workstation:

  • Dell Precision 690
  • 2 x Xeon 3Ghz cpu’s
  • 4Gb RAM
  • 2 x 250 Gb Seagate SCSI harddrives
  • NVIDIA 256 mb graphics card


which I populated after some deliberation – I haven’t owned a 64 bit machine before – with Ubuntu Gusty Gibbon. The result – a rather crisp workstation!!!

I naturally installed qgis out of the Ubuntu repositories but with the late October release of QGIS 0.9.0, I felt it was time to check out the latest and greatest. Following the always useful advice of Matt Perry, in this case at Turning Ubuntu Into a GIS workstation, I downloaded the qgis release binaries for Ubuntu Gutsy and, full of expectation, tried to run them. Cue the sound of deflating expectations….

Of course, the binaries were not compiled for the 64bit architecture. So, I braved the world of cmaking QGIS, ‘cos I really want version 0.9.0. with Python bindings and GRASS capability. This description is best read in conjunction with the detailed readme available with the source code – mainly it is just a simple version…
So, to the first part of the build process as outlined on the QGIS wiki: cmake .

  • The usual suspects (depending on requirements) need to be present on your system – Proj, GEOS, GDAL, PostgreSQL and GRASS
  • Additional common components include Expat and Sqlite3 – get them from the repositories
  • Make sure you have a C compiler installed – well, it is unlikely you won’t have one…
  • Make sure you have a C++ compiler installed ( I installed G++ 4.1 from the repositories )
  • Make sure you have flex and bison installed ( again, I got them from the repositories )
  • Make sure you have the GNU Scientific Libraries installed (gsl-bin, libgsl0, libgsl0-dev from the repositories)
  • Get the sip Python/C++ bindings generator (sip4 in the repository, plus, for good measure, I installed the python-sip4 and python-sip4-dev libraries).
  • Ensure the presence of a whole bunch of QT components like qmake, which is found in the libqt4-dev library. This library comes with a bunch of QT and related dependencies – that is a set of relationships I have no understanding of. Basically, you need to have QT installed. The qgis readme is the place to source these dependencies. If they are not on your system, the download is reasonably large.

And so cmake . finishes and one has the build files generated and configured.

So, to the second part of the build process, the make and make install. This went fine, once I had returned from a ramble into QT country. I am not sure why the readme wants one to install certain libraries such as resolvconf.

I am sure the build files could be more optimised for a Debian install, but that is about a thousand steps too far for me at this point – I’ll accept the default graciously.

And off we go – QGIS on Ubuntu Gutsy on 64 bit workstation. Looks great so far – most obvious diffrences are the much larger array of GRASS tools available and the existence of a WFS plugin.

FOSS4G2008 coming to the Southern Tip August 28, 2007

Posted by grimmeister in Geoinformatics.
add a comment

A couple of weeks ago, South Africa was awarded the Free and Open Source Software for Geospatial Conference for 2008. It will be hosted in Cape Town in September. This is really good news and, I feel, a bold decision from OSGEO. I believe, for the first time, they will be moving the conference away from the core developer community of FOSS4G.

However, the timing is great to bring it to SA because of rapidly increasing interest and investment in FOSS, driven by stated government policy to prioritise its usage. There seem to be three drivers for this: a perception of reduced cost; the importance of FOSS in bridging the ‘Digital Divide’; and FOSS’s role in increasing innovation and ICT literacy.

To me, the latter two are the themes that will enliven FOSS4G2008 in Cape Town, though there will without a doubt be much carping about costs. South Africa has a little bit of a tradition of innovation in the geoinformatics/ GIS space – off the top of my head I can point to Danie Krige of kriging fame, PlanetGIS and the ReGIS software, parts of which were later incorporated into Autodesk’s products. It would be interesting to know of other GI innovaters/innovations originating from SA.

The general reality on the ground in SA is the strong dominance of ESRI. This in and of itself is not a *bad thing* exactly, as the ESRI software is pretty darn good, but one effect has been the creation of a nation of ‘ArcView jockeys’, who know what buttons to press without necessarily understanding anything of what is happening under the hood. With exceptions, of course, it is really a mentality of “let ESRI understand what needs to be done and we will just buy the software/extension/script/service pack”. Convenient, yes; innovative, no; expensive, certainly – the dollar stretches a long way in SA. Well, hopefully FOSS4G2008 should help to perk up a few minds locally to the ocean of potential lying in the FOSS4G stacks.

As for the FOSS4G2008 overseas punters , well Cape Town is really rather nice. The effect of such a statement on a Capetonian is a bit like the effect of telling a Vancouverite the same thing. Cue spluttering indignation… Whatever. There will certainly be some interesting sights, sounds and experiences to be enjoyed. I hope it turns out to be a very hands-on, fun and enriching conference.


Two pairs of eyes August 14, 2007

Posted by grimmeister in Geoinformatics.
add a comment

I am writing some Python code using the OGR libary. It essentially ingests text files dropped onto a filesystem and turns them into features amongst other things. The data provided are x and y coordinates and some attributes. So, no problem, turn them into points. Trouble is, I needed to turn the points into square buffers of size 3km. I built a buffering routine but it was behaving oddly, generating buffers for all text files in a given directory on one pass, but only generating buffers for one text file on another pass. Eventually, the problem emerged: segmentation fault. I had been pulling my hair out for days trying to understand the problem.

The thing is, one gets commited to one’s code, trying to adjust it in tiny bits and pieces, rather than trying something new. This is where a second pair of eyes comes in. A second person overlooking your work does not have any emotional?? attachment to it and can happily suggest throwing code out and trying a new approach. End result: no more segmentation fault and a program that runs much more efficiently. Thanks Shriram!


More hair-pulling out! As my colleague Lee points out, if you want to know what is really going on in your code, don’t use wrappers! It took me hours to figure out that OGR (admittedly, a rather older version thereof), when used with its Python bindings, does not seem to enjoy having too many OGR objects used within a single method/routine. Thusly, in my method that ultimately buffers a point geometry and stores the new polygon geometry in a shapefile, I was unable to do a ‘contains’ test on the point geometry without getting weird and woolly segmentation faults and glibc double-linked list errors. This geometry test had to be done in a completely different part of the application.

Now, Lee suggested I rewrite the geometry testing code. The heresy of it!! I still like OGR and put it down to my own inexperience with the libraries. There is more chance of our *illustrious* President firing our unspeakable Health Minister than there is of me writing a usable geometry library. Those of you in the know about current SA politics will agree on the futility of it…


Setting up an Open Geospatial Consortium Service server August 8, 2007

Posted by grimmeister in Geoinformatics.


Our web server that we were using for OGC WFS and SOS decided to die on Monday – two disks in the RAID 5 array went to disk heaven (where I presume there is no I/O, after all, one does not expect to work in a heaven). We received this event with mixed emotions. All our services went down (big headache), but this was the long-needed opportunity to get off of Gentoo and on to Ubuntu. Gentoo is great, but the extra understanding and attention needed to maintain it is lacking in our workgroup. So, for better or for worse, it was decided to rebuild the server with Ubuntu Feisty, hoping that the extra attention that Ubuntu pays to Sun Java would pay off when it came to running Java-based webservices. While on the topicof ubuntu, I just love this xkcd irreverance:

xkcd genius again!

So, we got Ubuntu, Sun’s JDK 1.5 and Tomcat 5.5 installed easily. Of course, Tomcat did not immediately run. That would be too simple.

Enlisting the help of a few good websites (http://www.kintespace.com/rasxlog/?p=468;


http://ubuntuforums.org/showpost.php?p=2611681&postcount=1), I managed to get Tomcat grafting in a shortish time. This is significant, ‘cos I am clearly not what could be called a skilled sysadmin, and frankly, Tomcat fills me with fear 🙂

sun jdk
tomcat 5.5

1)Given that sun jdk installed, make sure its jvm is the default jvm
sudo update-alternatives --config java
choose the sun option

I also added the var JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/ to the /etc/profile file but no idea if it has any useful effect

2)Tomcat is a bit quirky on Ubuntu

2.1)if not installed, do:
sudo apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps

2.2)Configure Tomcat for the Java JDK. Edit /etc/default/tomcat5 uncommenting this line:

2.3)Set some permissions:
cd /var/lib/tomcat5.5/
sudo chown -R tomcat55:tomcat55 logs work
sudo chown tomcat55:tomcat55 /usr/share/tomcat5.5

2.4)Change service port to 8080 (default is 8180) in /etc/tomcat5.5/server.xml

2.5)Change the users and passwords for working with tomcat, tomcat admin and tomcat manager in /var/lib/tomcat5.5/conf/tomcat-users.xml
Advice seems to be to get a separate admin user with roles {admin, manager,tomcat}

2.6) Fix the catalina.out problem – it is trying to set the logfile as a pipe, rather make it a regular file to get tomcat to start
cd /var/log/tomcat5.5/
sudo rm catalina.out
sudo touch catalina.out
sudo chown tomcat55:nogroup catalina.out
sudo chmod uo-wrx catalina.out

/etc/init.d/tomcat5.5 start -> Tomcat now runs as a daemon

So, now to the OGC use cases!

1) We need to have the ability to serve OGC standard WFS, WMS and potentially WCS. We know the Geoserver tool, we like it, and dammit, I have just taken the time to install Tomcat, so sure as anything I am going to be using a servlet…

2) We need to serve Sensor Observation Service Offerings. There are now a number of implementations of the SOS, some richer than others at this early stage. We are familiar with the 52North SOS implementation and have worked with 52North developers on several occasions.

I’ll save my experiences with installing the SOS for another day, when I am feeling strong. Geoserver, however, is pretty easy to install and run.

1.1) Download the .war file in a zip file from the Geoserver website. We are using 1.5.1. Extract .war file

1.2) Deploy the .war file from the Tomcat Manager page. This will take place okay, but Geoserver will not be able to start, for Tomcat on Ubuntu is by default tightly locked down.

1.3) Follow the instructions at http://docs.codehaus.org/display/GEOSDOC/4+GeoServer+in+Production+Environment, which tell one to create a file called, in our case, ‘geoserver.policy’ in the /etc/tomcat-5.5/policy.d directory and populate it as follows:
grant codeBase "file:/var/lib/tomcat5.5/webapps/geoserver/WEB-INF/classes/-" {
permission java.security.AllPermission;
grant codeBase "file:/var/lib/tomcat5.5/webapps/geoserver/WEB-INF/lib/-" {
permission java.security.AllPermission;

This is supposed to get Geoserver working after Tomcat is restarted, but it does not. Instead a ServletException is thrown when one tries to access the Geoserver servlet. The key is to open the /etc/tomcat5.5/policy.d/04webapps.policy document and add a line to it granting looser security permissions:
permission java.security.AllPermission;

Then restart Tomcat and voila! the joys of Geoserver are yours to experience. I find the administration of Geoserver almost ridiculously intuitive once the servlet is running. It just takes a bit of time to set your spatial data hosting environment up