Tuesday, February 15, 2011

Tomcat 6 & Fedora 14 frustrations

More woes trying to set up a server image.  Current pothole (as opposed to speed bump) is being brought to you by Tomcat 6 and Fedora 14. Having just gone through a whole lot of hoop-la getting java installed, I installed Tomcat with this simple command:

root@spin-1-16r tomcat6]# yum install tomcat6


First woe:
My woes began when I tried to start up tomcat how I started it up on Rhel:

[root@spin-1-16r tomcat6]# tomcat6 start
/usr/sbin/tomcat6: line 30: /logs/catalina.out: No such file or directory


What? How is an error happening when I haven't done anything but use the package installer yum to install tomcat? This time, I read my error carefully and decided to look in the file /usr/sbin/tomcat6, line 30 for the offending code which was:

    org.apache.catalina.startup.Bootstrap start >> ${CATALINA_BASE}/logs/catalina.out


Looking through the file, I don't see CATALINA_BASE defined. And then going back to the command prompt, I discover the environment variable CATALINA_BASE isn't defined anywhere:

[root@spin-1-16r webapps]# echo $CATALINA_BASE


More searching and I find that it is defined in /etc/tomcat6/tomcat6.conf and going back to the /usr/sbin/tomcat6 file, I see that the following is commented out:

# Get the tomcat config (use this for environment specific settings)
#if [ -z "${TOMCAT_CFG}" ]; then
#  TOMCAT_CFG="/etc/tomcat6/tomcat6.conf"
#fi
#
#if [ -r "$TOMCAT_CFG" ]; then
#  . $TOMCAT_CFG
#fi


Removing the comments from in front of lines 2-8 and saving solved this first issue.

*EDIT*
Avoid first woe sub-part one:
Remember earlier we went through some troubles to set up Sun's java and even set up some environment variables? We probably want to keep using Sun's java for tomcat. Open up the tomcat config file:
[frog@caffiend ~]# less ~tomcat/conf/tomcat6.conf

At the top of the file, after the comments about what file is for, you should see these lines:
# Where your java installation lives
JAVA_HOME="/usr/lib/jvm/java"

Now I'm not 100% that this will over-write the environment variable previously set, nor do I know whether or not that link will end up at the same location or not....so to be safe, I've commented it out on my server:
# Where your java installation lives
#JAVA_HOME="/usr/lib/jvm/java"

Second woe:
Now the next woe began.  For the purposes of work, the webapp war is dropped into the /usr/share/tomcat6 folder and a symbolic link is created in the webapp folder pointing to the war.  This is done because for our testing purposes, we swap various versions of the war, including snapshots, in and out and our deployment code to push out and configure multiple nodes have a hard link to the URL.  We could always just change the name of the war to match what we have in the URL in our code, but then we would lose the quick at a glance sanity check of which version we are running.  So that is what I did.  And I started up tomcat, but EGADS, the war would NOT inflate and deploy.  Why, oh why?  After much googling on keywords like symbolic link not deploying war tomcat6 fedora14, so on and so forth...and bringing in a second pair of eyes...it hits me like a ton of bricks:

[root@spin-1-16r tomcat6]# ls -l webapps/
total 0
lrwxrwxrwx 1 root root     39 Feb 15 22:10 node-server -> /usr/share/tomcat6/node-server-1.16.war


Do you see it now? It sure took me a while...my sym link did NOT end in .war. And that...is all it took. Changing the sym link and restarting tomcat my directory now looks like:

[root@spin-1-16r webapps]# ls -l
total 8
drwxr-xr-x 2 root root 4096 Feb 15 23:52 logs
drwxr-xr-x 4 root root 4096 Feb 15 23:52 node-server
lrwxrwxrwx 1 root root   39 Feb 15 23:52 node-server.war -> /usr/share/tomcat6/node-server-1.16.war


And thus ends my woes. It looks so simple and duh all summed up here, but man, was it hard to see for me.

Ubuntu (v10.04) update frustrations

*EDIT*
I wrote this a few months back and I'm not quite sure why I never published it...might have been one of those days...hopefully it's correct, if it's not, please let me know.
 

Finally decided to do the updates that my Ubuntu has been asking me about for a week or so now.  And of course, my Eclipse breaks because Ubuntu keeps trying to change my java to OpenJDK, which does not play together happily with Eclipse (v3.3). I'm sure others must also have this problem, so here is my step by step troubleshooting:
  1. Did  the update change the environment variables?
    • Check the bashrc file:
      frog@caffiend:~$ vi ~/.bashrc
      

      Where vi is your console editor. You can use any editor you like. The file should contain the following, most likely at the end:
      export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.20/
      
  2. Did the update change the symbolic link?
    • First find your Sun Java directory. I think it usually gets installed in /usr/lib/jvm. One way is to do a search from the FileSystem using the File Browser for "sun".  You're looking for a folder with a name like: java-x-sun-n.n.nn, where x is the version of java (nowadays, most likely 6...possibly 5) and n.n.nn is the release. 
    • Now check to make sure the java folder is pointing correctly to the alternatives folder:
      frog@caffiend~:$ ls -l /usr/bin/java
      lrwxrwxrwx 1 root root 22 2010-11-02 12:26 /usr/bin/java -> /etc/alternatives/java
      
    • Now check where the alternatives folder is pointing to:
      frog@caffiend~:$ ls -l /etc/alternatives/java
      lrwxrwxrwx 1 root root 36 2010-11-02 12:26 /etc/alternatives/java -> /usr/lib/jvm/java-6-sun/jre/bin/java
      
    • If one or both of these symbolic links are not pointing to the correct location:
      frog@caffiend~:$ cd /usr/bin/
      frog@caffiend~:$ sudo ln -f -s /etc/alternatives/java java
      frog@caffiend~:$ cd /etc/alternatives/
      frog@caffiend~:$ sudo ln -f -s /usr/lib/jvm/java-6-sun/jre/bin/java java
      
  3. Did the update change which Java is being used?
    • frog@caffiend~:$ udo update-alternatives --config java
      [sudo] password for frog: 
      There are 2 choices for the alternative java (providing /usr/bin/java).
      
        Selection    Path                                      Priority   Status
      ------------------------------------------------------------
        0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      auto mode
        1            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manual mode
      * 2            /usr/lib/jvm/java-6-sun/jre/bin/java       63        manual mode
      
      Press enter to keep the current choice[*], or type selection number: 2
      
  4. Confirm that the correct Java is being used:
    • frog@caffiend~:$ which java
      /usr/bin/java
      frog@caffiend:/usr/bin$ java -version
      java version "1.6.0_22"
      Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
      Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode)
      
Now try starting Eclipse.  There is a chance you may still get an error if you use Maven, subclipse.  A solution can be found here.

Errors Installing Java JDK on Linux.

Several hours that I will never get back have just been lost due to errors received trying to install Sun's Java (specifically the JDK) on a virtual machine.  I had previously been able to install the JDK without much of a hiccup last fall on the virtual machine at this particular vendor, and was quite puzzled as to why this was no longer working.  Googling the error and various keywords didn't point out any obvious issues, everything seemed to say that Fedora 14 and Sun Java played well together, with the exception of having to configure the alternatives to point to the correct java (which I knew).

[root@spin-1 opt]# sh ./jdk-6u22-linux-i586.bin 
Unpacking...
Checksumming...
Extracting...
./jdk-6u22-linux-i586.bin: ./install.sfx.20270: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Fine, let's try the self extracting rpm version:
[root@spin-1 opt]# sh ./jdk-6u22-linux-i586-rpm.bin 
Unpacking...
Checksumming...
Extracting...
./jdk-6u22-linux-i586-rpm.bin: ./install.sfx.20566: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Installing JavaDB
error: open of sun-javadb-common-10.5.3-0.2.i386.rpm failed: No such file or directory
error: open of sun-javadb-core-10.5.3-0.2.i386.rpm failed: No such file or directory
error: open of sun-javadb-client-10.5.3-0.2.i386.rpm failed: No such file or directory
error: open of sun-javadb-demo-10.5.3-0.2.i386.rpm failed: No such file or directory
error: open of sun-javadb-docs-10.5.3-0.2.i386.rpm failed: No such file or directory
error: open of sun-javadb-javadoc-10.5.3-0.2.i386.rpm failed: No such file or directory
 
Done.

After much googling, I kept coming back to this one forum post. In the middle of it, there is the following information from a poster:

"The library you are missing is comes from the 32bit version of the glibc. You can try installing the i386 version of glibc using yum. That would install /lib/ld-linux.so.2 for you."

Great, so let's try installing the glibc ... (some of you may be seeing where this is going, but sadly I did not yet).

[root@spin-1 opt]# yum install glibc*

Alright, so now that's installed, I tried installing java again...to no avail. Scrolling back up the console to at the yum output from installing the glibc* I see:
=============================================================================
 Package                       Arch     Version             Repository Size
=============================================================================
Installing:
 gcc                           x86_64   4.5.1-4.fc14        fedora     14 M
Installing for dependencies:
 cloog-ppl                     x86_64   0.15.7-2.fc14       fedora     93 k
 cpp                           x86_64   4.5.1-4.fc14        fedora     4.0 M
 glibc-devel                   x86_64   2.13-1              updates    968 k
 glibc-headers                 x86_64   2.13-1              updates    599 k
 kernel-headers                x86_64   2.6.35.11-83.fc14   updates    742 k
 libmpc                        x86_64   0.8.1-1.fc13        fedora     44 k
 mpfr                          x86_64   2.4.2-1.fc13        fedora     158 k
 ppl                           x86_64   0.10.2-10.fc12      fedora     1.1 M

Transaction Summary
=============================================================================
Now wait just a hot minute, why is it installing the x86_64 and not the i386 32bit ones....^Insert light bulb.

That's right folks, the virtual machine is 64 bit and I was trying to install a 32bit version of Java.  Some time between when I last tried this particular exercise out on the vendor and now, the vendor moved from 32bit OS's to 64bit OS's.  To verify:

[root@spin-1 opt]# uname -m
x86_64

Well would you look at that, my vm's architecture is x86_64. :: sigh :: downloading the 64 bit version of Java JDK resolved the issues.

For completeness of this post, some links to get started with Sun JDK Java and Tomcat 6 on Fedora 14, in order of things to do.
  1. Configuring yum repositories on fedora
    • On the remote machine, as root user, do the following:
      yum --nogpgcheck install http://rpm.livna.org/livna-release.rpm http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
  2. On the remote machine, as root user, do the following:
    yum update 

  3. Download the 64 bit version of Java JDK desired onto local machine and then scp the file to the /opt directory of the remote machine

  4. On the remote machine, possibly need to be remote user, do the following:
    [root@spin-1 opt]# sh ./opt/jdk-6u22-linux-x64.bin 

  5. *EDIT*
    (realized I also did the following and it is not included in the link at step 6, not entirely sure of the necessity, but I did this anyways just to make sure and everything is working)
  6. Add the following environment variables (not included as part of the directions in 6, may not be 100% necessary, but I did this and everything work) to the end of ~/.bashrc:
    export JAVA_HOME=/opt/jdk1.6.0_22
    export JRE_HOME=${JAVA_HOME}/jre
    export PATH=${JAVA_HOME}/bin:${PATH}
    export CLASSPATH=${JAVA_HOME}/jre/lib:${CLASSPATH}
    

    This is what my ~/.bashrc looks like:
    # .bashrc
    
    # User specific aliases and functions
    
    alias rm='rm -i'
    alias cp='cp -i'
    alias mv='mv -i'
    
    # Source global definitions
    if [ -f /etc/bashrc ]; then
            . /etc/bashrc
    fi
    
    export JAVA_HOME=/opt/jdk1.6.0_22
    export JRE_HOME=${JAVA_HOME}/jre
    export PATH=${JAVA_HOME}/bin:${PATH}
    export CLASSPATH=${JAVA_HOME}/jre/lib:${CLASSPATH}
    

    Save the file and from the command prompt, source the file:
    [root@newImage ~]# source ~/.bashrc 
    

    Now do an echo to make sure the environment variable exists and points to the correct location:
    [root@newImage ~]# echo $JAVA_HOME
    /opt/jdk1.6.0_22

    You should see the location your jdk is installed, my jdk is installed in /opt/.
    N.B.For the testing that we're doing here at work, we're always either logged in as root or tomcat is logged in as tomcat. I'm not familiar enough with environment variables and bash scripts to know where they need to be or what needs to be done to ensure the variable persists through all users.

  7. Follow the directions found here for setting up the alternatives in Fedora to point to the correct java distro

  8. Install tomcat:
    yum install tomcat6*.*