Why Tomcat ?
In a nut shell, this project being developed here, is going to soon run some web applications ( that hopefully change the world for the better etc ), using the famous apache web server in the font end ( with ssl ) and java servlets in the backend securely handling the database and formatting web pages back though to apache. So the backend java servlets with be running, naturally enough, in the web server called Tomcat. All seems simple enough…. well, when staying on the main road here, so to speak.
Step 1. Install the java complier
and some other things ...
(a) # apt-get install default-jdk
As this currently defaults to java version 7 which is not the latest version ( at the time of writing this ), a later version is available from oracle corporation, who purchased java from sun micro systems, the original creators.
Read the licence.
One thing the oracle version does do differently, is to install a timestamp in the home directory —> /home/tomcat/.oracle_jre_usage.
This alternate java is optional though, as mainstream tomcat works just fine on java version 7.
# echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee /etc/apt/sources.list.d/webupd8team-java.list deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main # echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main # apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886 # apt-get install oracle-java8-installer
(b) A handy way to change between versions of the installed java compliers, is this:
# update-alternatives –config java
However, the often confusing environment variable for java to run ( ie JAVA_HOME ), is easier these days to set up globally in the system’s “/etc/environment” file.
Simply edit the file and enter the line to define JAVA_HOME to be one of the lines shown up from running “update-alternatives –config java”
# vi /etc/environment
Testing to see if java is working is easy. Typing “java -showversion”at the command line for example, will produce its details. The version shown here ( on the command line ) may be different however, from what the $JAVA_HOME variable is set too. A good idea then, is to check what version of java tomcat is running when it gets going ( eg “ps -ef | grep tomcat” ).
Step 2. Install Tomcat
(a) Create a user account for the tomcat server to run under. An easy name to remember is “tomcat”, naturally.
# adduser –system –shell /bin/bash –gecos ‘Tomcat Java Server’ –group –disabled-password –home /home/tomcat tomcat
(b) Download and unpack the latest tomcat files.
# cd /usr/local/src
The latest news of what is actually the latest stable release —> http://tomcat.apache.org/
Next, download the files found there.
# wget http://apache.mirror.digitalpacific.com.au/tomcat/tomcat-8/v8.5.14/bin/apache-tomcat-8.5.14.tar.gz
# tar xvfz tomcat-8/v8.5.14/bin/apache-tomcat-8.5.14.tar.gz
(b) As apache2 is in “/usr/local”, I simply create a link from there to where the tomcat sources are located, so everything is easier to remember where things are – as well as making it easier to install new versions ( for documentation and for other programs to consistently find as well ).
A side note that might explain this …. or not
# cd /usr/local/ # ln -s /usr/local/src/apache-tomcat-8.5.14 tomcat
# chown -R tomcat:tomcat tomcat/* # chmod +x tomcat/bin/*.sh
Step 3. Starting the Tomcat server
# su – tomcat -c /usr/local/tomcat/bin/startup.sh
Using CATALINA_BASE: /usr/local/tomcat Using CATALINA_HOME: /usr/local/tomcat Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME: /usr/lib/jvm/java-8-oracle Using CLASSPATH: /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar Tomcat started.
# su – tomcat -c /usr/local/tomcat/bin/shutdown.sh ( to stop tomcat )
Step 4. Testing Tomcat to see if it is working.
With a newly installed Tomcat, the default settings will have tom cat listening for web connections on port 8080. So all that is needed is to open a browser at the machine’s ip address on port 8080, instead of the default 80.
For example: http://programmer.com.au:8080
Step 5. Tomcat automatic startup.
Create a file called “/etc/systemctl/system/tomcat.service” with this:
[Unit] Description=Tomcat Server After=syslog.target network.target [Service] Type=forking ##EnvironmentFile=/etc/environment Environment=JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre Environment=CATALINA_PID=/usr/local/tomcat/temp/tomcat.pid Environment=CATALINA_HOME=/usr/local/tomcat Environment=CATALINA_BASE=/usr/local/tomcat Environment='CATALINE_OPTS=-Xms128M -Xmx765M -server -XX:+UseParallelGC' Environment='JAVA_OPTS=-Djava.awt.haedless=true -Djava.security.egd=file:/dev/./urandom' ExecStart=/usr/local/tomcat/bin/startup.sh ExecStop=/usr/local/tomcat/bin/shutdown.sh User=tomcat Group=tomcat UMask=0007 RestartSec=5 Restart=always [Install] WantedBy=multi-user.target
Enter the command: systemctl daemon-reload
Test starting and stopping tomcat with:
# systemctl start tomcat # systemctl status tomcat # systemctl stop tomcat
Problems and solutions
Problem 1. Nothing much shows up in the browser.
(a) If the web page is entirely blank, chances are that this is coming from Tomcat. Probably caused by Tomcat not having file permissions for all of its files, both in /usr/local/tomcat and in /var/logs.
(b) A 404 message from Tomcat will probably mean that there is a configuration error in the apache configuration file, or there really is some missing index pages in the Tomcat installation.
(c ) Other messages will be from apache not being able to connect to Tomcat on 8080. The firewall will need checking to make sure 8080 traffic is let through ( coming as it were, from on the same machine ).
(d) If problems persist, best to reinstall a fresh copy of Tomcat and start by keeping things simple and build up from there ( as well as having a simple apache config file ).
Problem 2. Tomcat crashes.
Checking the Tomcat log files usually has lots of usfull information on what caused the crash. Could be a range of issues, from the java runtime running out of memory, to there being a conflict in one of the connection ports. Some commands that can be useful at times include:
(i) “netstat -a” etc to show what program is using what ports,
(ii) The process identifier (pid) for Tomcat can be found with “ps -ef | grep tomcat”.
(iii) lsof -p <pid of tomcat> to show what files Tomcat is accessing. And if all else fails of course, there is always the hope that google will eventually have an answer somewhere or other.
© 2017, James Harry Burton. All rights reserved.