Ubuntu 9.04, Tomcat 6 and Railo

August 26, 2009 · By Sean Corfield · 11 Comments

Update: As Jamie Krug pointed out in a comment, I meant 9.04... See my response to him in the comments below!

Today I was asked to try installing Railo on Tomcat 6 on Ubuntu because it doesn't work out of the box. I normally use CentOS for Linux testing so I went ahead and downloaded the Ubuntu 9.04 Server 64-bit ISO and fired up VMWare Fusion to install it on a new VM. It's a pretty slick (if DOS-like) installer and you can install LAMP and Tomcat 6 directly as part of the initial setup which I did. Soon I had a running Ubuntu server with MySQL, PHP and Tomcat 6 all ticking along.I downloaded the latest Railo WAR, renamed it to railo.war and copied it to /var/lib/tomcat6/webapps/. It seemed to auto-deploy as expected but when I hit http://seantu.local:8080/railo/ I was greeted with an unpleasant Java security error! Ubuntu configures Tomcat to use the Java security manager by default (which is unusual, IMO, and extremely restrictive). Rather than wrestle with all the policy files to try to make things work (which you could do if you're a) brave and persistent or b) a Java security policy expert), the simplest solution is just to tell Tomcat not to use the darn Java security manager in the first place! Go to /etc/init.d/ and edit the tomcat6 script. Around line 68 you'll see: TOMCAT_SECURITY=yes Change that to: TOMCAT_SECURITY=no Then restart it: ./tomcat6 restart With that change Railo spun up perfectly at http://seantu.local:8080/railo/ and I was off to the races. I hope this helps folks trying to use Railo on Ubuntu's install of Tomcat 6! Note: you'll need to be root or sudo'd for all the above.

View count: 609

Tags: HowTo · Linux · Railo 3.1

11 responses so far ↓

1 Scott Mebberson // Aug 26, 2009 at 3:55 AM

Thanks for the info Sean. I actually didn't run into this when I went about setting up Tomcat and Railo on Ubuntu 8.10 (intrepid). Perhaps they've changed the default configuration for Tomcat?
2 Jamie Krug // Aug 26, 2009 at 4:46 AM

Sean, very cool. I wrestled with those default Java security settings for a bit and finally gave up. I thought I'd even tried the setting you mention here with no luck, but maybe not...

By the way, Ubuntu 7.04?? That's awfully old -- client on that? 8.04 is the current LTS and 9.04 the latest non-LTS release.

Also, I think I've passed this doc along before, but if not, here's a whole lot of notes on my production Ubuntu 8.04/Apache/Tomcat/Railo/MySQL basic config:
http://bit.ly/o5pOx

I went with a completely manual install of Tomcat, since the Ubuntu repos had an older version and that Java security management drove me nuts!
3 Sean Corfield // Aug 26, 2009 at 5:12 AM

Ah, I meant 9.04! I actually tried two installs. I started with 7.x because VMWare had a prebuilt VM for download but it didn't have a lot of the useful command line stuff installed and it was just going to take too long so I went and got the latest from Ubuntu's site instead.
4 Tom Chiverton // Aug 26, 2009 at 12:16 PM

What are the security implications of that though ?
I must admit to having in the past just deployed a non-packaged Tomcat ON Ubuntu, following your previous instructions, rather than fight with it :-)
5 Jamie Krug // Aug 26, 2009 at 4:49 PM

@Tom: Sean will likely have a much better idea of the security implications, but my guess is that this is primarily to secure various applications running on the servlet container. Even with a non-package Tomcat instance, you can keep things rather safe by simply running Tomcat as a non-privileged user and give that user only file permissions needed.
6 Sean Corfield // Aug 26, 2009 at 5:22 PM

@Tom, I've never seen a Tomcat installation in the wild that uses the Java security model. I'd agree that locking down all the permissions with Java like that would definitely be more "secure" but I'm not quite sure who or what it would secure the server from! In the default configuration, the Java security model is securing the server from the code that runs on Tomcat which is potentially good if you're hosting other people's code but not such an issue for running your own code.

I always run Tomcat under a non-privileged user which , as Jamie notes, mitigates a lot of potential problems.

The benefit of the Java security model is that you get total control over how each web application behaves - but if you're hosting with Railo, each web application gets its own security sandbox anyway so, again, it's not as critical in my mind to have Tomcat running in such a locked down manner.
7 Jamie Krug // Aug 27, 2009 at 5:26 PM

Also, if you happen to have an install of Ubuntu 9.04 already running (without including Tomcat at initial distro install), you can quickly add it with a good ol':
sudo apt-get install tomcat6

Here's a good docs page to get you started:
https://help.ubuntu.com/9.04/serverguide/C/tomcat.html
8 Greg // May 7, 2010 at 5:06 PM

Hi all,
I have been running Railo for the past 4 months everything was going great but I added a new host to the server.xml file and restarted railo and now I am gitting

May 7, 2010 8:47:41 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-0
May 7, 2010 8:47:42 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
May 7, 2010 8:47:42 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/15 config=null
May 7, 2010 8:47:42 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1690 ms
May 7, 2010 8:47:42 AM org.apache.catalina.core.StandardServer await
SEVERE: StandardServer.await: create[8005]:
java.net.BindException: Cannot assign requested address
   at java.net.PlainSocketImpl.socketBind(Native Method)
   at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
   at java.net.ServerSocket.bind(ServerSocket.java:319)
   at java.net.ServerSocket.<init>(ServerSocket.java:185)
   at org.apache.catalina.core.StandardServer.await(StandardServer.java:373)
   at org.apache.catalina.startup.Catalina.await(Catalina.java:647)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:607)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
May 7, 2010 8:48:03 AM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-0
May 7, 2010 8:48:04 AM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
May 7, 2010 8:48:04 AM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-0

and Tomcat will not start.
I have check my lo loopback and it seems to be fine and I'm not sure what has happend. I even reloaded Railo with no success.
Can any one help?
Thanks
9 Sean Corfield // May 8, 2010 at 6:24 AM

@Greg, it sounds to me like Tomcat did not shutdown cleanly and therefore did not release the port. It's a long-standing known bug in Tomcat that the shutdown script doesn't actually work for all JEE apps - you have to kill the Tomcat process manually.
10 Jamie Krug // May 10, 2010 at 2:56 PM

@Greg: As Sean mentioned, that is not uncommon. A simple workaround is to pass a -force flag to the shutdown.sh or catalina.sh script. You may need to set the CATALINA_PID variable, if not set automatically. You can also hard-code that force-kill if you look in the catalina.sh script; then, the script will be sure to kill the process for you on shutdown. I posted a boot script to leverage this--a while back on the Railo Google Group.
11 Greg // May 10, 2010 at 4:51 PM

Sean, Thanks for the comment.
I have checked all the running proccesses and ports and their is no service on port 8005 I also changed the port from 8005 to 8007 and still no start I'm Thinking it's
a network issue but not sure why or where any thoughts.
Greg

Default