FilterProvider syntax has changed in Apache 2.4(Error FilterProvider takes three arguments, filter-name provider-name match-expression)

With apache 2.4 there has been few configuration changes in place and causing 500 errors. One such is the legacy filter_module syntax on the htaccess file.

Error : The following error in error log is actually causing by legacy filter_module syntax on the htaccess file.

[Fri Jan 03 00:19:57.673915 2014] [core:alert] [pid 774253] [client X.X.X.X:54553] /home/XX/public_html/.htaccess: FilterProvider takes three arguments, filter-name provider-name match-expression

With apache version 2.4 in your server  it wont accept the legacy filter_module syntax. You should need to make some changes in it. For example my users filter_module rules were as follows in his .htaccess file.


FilterDeclare COMPRESS
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/html
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/css
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/plain
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/x-component
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/javascript
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/json
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/xhtml+xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/rss+xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/atom+xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/vnd.ms-fontobject
FilterProvider COMPRESS DEFLATE resp=Content-Type $image/svg+xml
FilterProvider COMPRESS DEFLATE resp=Content-Type $image/x-icon
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/x-font-ttf
FilterProvider COMPRESS DEFLATE resp=Content-Type $font/opentype
FilterChain COMPRESS
FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no

It was changed to


FilterDeclare COMPRESS
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'text/html'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'text/css'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'text/plain'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'text/xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'text/x-component'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/javascript'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/json'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/xhtml+xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/rss+xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/atom+xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/vnd.ms-fontobject'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'image/svg+xml'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'image/x-icon'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'application/x-font-ttf'"
FilterProvider COMPRESS DEFLATE "%{Content_Type} = 'font/opentype'"
FilterChain COMPRESS
FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no

With the above codes in place the error all vanished :)

Running Two Tomcat Instances On Same Server (*nix)

Sometimes you want to host applications that cannot run on the same instance of Tomcat because of some incompatibility between the required classes of the two applications, or you might want to deploy the same application multiple times, perhaps for different customers, and you cannot do that on a single instance of Tomcat.

Here’s a brief step by step guide to running more than one instance of Tomcat on a single machine.

Lets first understand Tomcat Directory Structure..

When creating multiple instances of tomcat server, we need to play with the folders inside the server. These folders contain the actual scripts and code for the server. We have the option to either use the code base for tomcat in shared mode where all tomcat instances refer to the same physical code or we can create separate copies of these folder for each tomcat instance.

• /bin : This directory contains the startup and shutdown scripts for both Windows and Linux.
• /conf : This directory contains the main configuration files for Tomcat. The two most important are the server.xml and the global web.xml .
• /server : This directory contains the Tomcat Java Archive files.
• /lib : This directory contains Java Archive files that Tomcat is dependent upon.
• /logs : This directory contains Tomcat’s log files.
• /src : This directory contains the source code used by the Tomcat server. Once Tomcat is released, it will probably contain interfaces and abstract classes only.
• /webapps : All web applications are deployed in this directory; it contains the WAR file.
• /work : This is the directory in which Tomcat will place all servlets that are generated from JSPs. If you want to see exactly how a particular JSP is interpreted, look in this directory.
  

Tomcat server ports

Having a good understanding of tomcat ports is essential to manage the multiple instances of the same server installation. These ports are used by tomcat for start-up, deployment and shut-down operations. The detail of each port is as:

• Connector Port : This is the port where Apache Tomcat listen for the HTTP requests.
• Shutdown Port : This port is used when we try to shutdown the Apache Tomcat Server.
• AJP (Apache JServ Protocol) Connector Port : The Apache JServ Protocol (AJP) is a binary protocol that can conduct inbound requests from a web server through to an application server that sits behind the web server.
• Redirect Port : Any redirection happening inside Apache Tomcat will happen through this port. In Apache TOMCAT there are two instance where redirectPort is mentioned. First one is for the Apache TOMCAT server and other one is for the AJP port.
  

JDK(Java Development Kit)

For proper execution, Tomcat requires JDK(Java Development Kit). JDK that contains API classes, Java compiler(javac), Java Virtual Machine(JVM) provides the basic tools to compile Java applications and applets.

Install JDK

You can download the latest version of JDK(JDK 7) from Sun's Java web URL's at:
http://java.sun.com/products/archive/index.html

http://java.sun.com/products/archive/j2se/1.4.2_08/index.html

http://java.sun.com/j2se/1.4.2/download.html
Unpack and install JDK in the directory /usr/local/. Now, we need to define the environment variable JAVA_HOME, such that it points to the java installation directory "/usr/local/jdk1.X.X".
Add the following lines to the "/etc/bashrc" or "/etc/profile" file, so that the environment variable can be used by all aplications/users in the server.

JAVA_HOME=/usr/local/jdk1.X.X
export JAVA_HOME

Install Tomcat

The Tomcat complete package is available for download at the following URL :

http://tomcat.apache.org/download-55.cgi
Download the latest version of Tomcat and Install it in the /usr/local directory.

mv apache-tomcat-5.5.26.tar.gz /usr/local
tar -xvzf apache-tomcat-5.5.25.tar.gz

Now, create the following symbolic link.

ln -s /usr/local/apache-tomcat-5.5.25 /usr/local/tomcat

We can then run the Tomcat web server using a seperate user "tomcat". Add the user and group "tomcat".

groupadd tomcat
useradd -g tomcat -c "Tomcat User" -d /usr/local/tomcat tomcat
passwd tomcat <password for user>

Change the ownership of Tomcat installation directories.

chown tomcat:nobody /usr/local/tomcat
chown -R tomcat:nobody /usr/local/apache-tomcat-5.5.25

The installation of Tomcat is now complete. We can start the Tomcat instance using a startup script "/usr/local/tomcat/bin/startup.sh". Also, make sure to define the variable CATALINA_HOME in the script "/usr/local/tomcat/bin/catalina.sh".

CATALINA_HOME=/usr/local/tomcat

The default Tomcat configuration will service HTTP requests on port 8080. You can access this Tomcat instance using the URL http://server_IP:8080/, where server_IP is the address of the machine where we just now installed the Tomcat server.
In order to shut down the Tomcat service, use the script :

/usr/local/tomcat/bun/shutdown.sh

You can access the Tomcat Manager Interface corresponding to this Tomcat installation using the URL:

http://server_IP:8080/manager/

You can also configure the Manager Application Access using a username and password combination that has the role "manager" associated to them. All you have to do to enable this access is edit the Tomcat users configuration file.

/usr/local/tomcat/conf/tomcat-users.xml

By default, the Manager application is completely disabled. To enable access to the Manager web application, add the following entry in /usr/local/tomcat/conf/tomcat-users.xml.

<tomcat-users>
<role rolename="manager"/>
<user username="admin" password="tomcat" roles="manager"/>
</tomcat-users>

Once you restart the Tomcat service after this, you will be able to access the Manager interface using the login details admin/tomcat.

Additional Tomcat Instances

We have already installed one instance of Tomcat in the server.
We can still install multiple instances of Tomcat using the environment variable CATALINA_HOME. Each instance will use its own startup/shutdown scripts, configuration files, log files, etc.

Configure Second Instance

The first instance of Tomcat is installed inside the directory "/usr/local/tomcat". In order to configure an additional instance, create a new directory "/usr/local/tomcat1", assign correct permissions and copy all contents from the old directory to the new one.

mkdir /usr/local/tomcat1
chown tomcat:tomcat /usr/local/tomcat1
cp -pr /usr/local/tomcat/* /usr/local/tomcat1/

The Tomcat configuration is defined by the contents of the server.xml file that is found in the Tomcat's configuration($CATALINA_HOME/conf) directory. In order to configure an additional instance, modify the tomcat configuration file corresponding to the second instance "/usr/local/tomcat1/conf/server.xml"
Change AJP connector port from 8080 to 8081, because the first instance is already using 8080. The AJP connector port is used by Apache to forward requests. Also change the SHUTDOWN port from 8005 to 8115, because the the first instance already is using port 8005. After modifications, it should look something like this:
<Server port="8115" shutdown="SHUTDOWN">
.....
<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />



We are now done with the configuration of the second instance of Tomcat. We can start this instance using the startup script /usr/local/tomcat1/bin/startup.sh. Before that, it is required that you define the variable CATALINA_HOME as /usr/local/tomcat1 in the script /usr/local/tomcat1/bin/catalina.sh.

JAVA_HOME=/usr/local/jdk

export JAVA_HOME

PATH=$JAVA_HOME/bin:$PATH

export PATH

CATALINA_HOME=/usr/local/jakarta/tomcat2/apache-tomcat-7.0.47

CATALINA_BASE=/usr/local/jakarta/tomcat

CONNECTOR_PORT="8081"

Note: Paths can vary in your case
You can access this instance of Tomcat using the URL http://server_IP:8081 and the manager interface at http://server_IP:8081/manager/.

Similar to how we did initially, here too, you will need to manually add the "manager" user in the user configuration file /usr/local/tomcat1/conf/tomcat-users.xml.

Create following two scripts to run Tomcat as a service

1. Create /etc/init.d/tomcat with following instructions
   
#!/bin/bash
# description: Tomcat Start Stop Restart
# processname: tomcat
# chkconfig: 234 20 80
JAVA_HOME=/usr/lib/jvm/jre-openjdk
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/opt/tomcat1
case $1 in
start)
sh $CATALINA_HOME/bin/startup.sh
;;
stop)
sh $CATALINA_HOME/bin/shutdown.sh
;;
restart)
sh $CATALINA_HOME/bin/shutdown.sh
sh $CATALINA_HOME/bin/startup.sh
;;
esac
exit 0
   
2. Create /etc/init.d/tomcat1 with following instructions
   
#!/bin/bash
# description: Tomcat Start Stop Restart
# processname: tomcat
# chkconfig: 234 20 80
JAVA_HOME=/usr/lib/jvm/jre-openjdk
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/opt/tomcat2
case $1 in
start)
sh $CATALINA_HOME/bin/startup.sh
;;
stop)
sh $CATALINA_HOME/bin/shutdown.sh
;;
restart)
sh $CATALINA_HOME/bin/shutdown.sh
sh $CATALINA_HOME/bin/startup.sh
;;
esac
exit 0
   

sysstat and resource monitoring

sysstat is a package of monitoring tools, which includes iostat, mpstat, pidstat, sar, sadc, sa1, sa2 and sadf

iostat

Reports CPU statistics and input/output statistics for devices, partitions and network filesystems.

mpstat

Reports individual or combined processor related statistics.

pidstat

Reports statistics for Linux tasks (processes) : I/O, CPU, memory, etc.

sar

Collects, reports and saves system activity information (CPU, memory, disks, interrupts, network interfaces, TTY, kernel tables,etc.)

sadc

Is the system activity data collector, used as a backend for sar.

sa1

Collects and stores binary data in the system activity daily data file. It is a front end to sadc designed to be run from cron.

sa2

Writes a summarized daily activity report. It is a front end to sar designed to be run from cron.

sadf

Displays data collected by sar in multiple formats (CSV, XML, etc.) This is useful to load performance data into a database, or import them in a spreadsheet to make graphs.

To use this tools, you need to install sysstat apt-get install sysstat
One great feature of this tools is that you can configure it to run as a daemon, and it will log a lot of info about your system. To start it if you are using Debian, edit with your favorite text editor, in my case is vi vim /etc/default/sysstat
And change the line: ENABLED="false" to ENABLED="true", so that file may look like this

#
# Default settings for /etc/init.d/sysstat, /etc/cron.d/sysstat
# and /etc/cron.daily/sysstat files
#

# Should sadc collect system activity informations? Valid values
# are "true" and "false". Please do not put other values, they
# will be overwritten by debconf!
ENABLED="true"

# Additional options passed to sa1 by /etc/init.d/sysstat
# and /etc/cron.d/sysstat
# By default contains the `-d' option responsible for 
# generating disk statisitcs.
SA1_OPTIONS="-d"

# Additional options passed to sa2 by /etc/cron.daily/sysstat.
SA2_OPTIONS=""

sa1 is a variant of sadc, which is designed to work as a cronjob, just like sa2 which is a variant of sar command also designed to be run as cronjob. If you are not using Debian, you will not have the /etc/default/sysstat, so you will have to add to your root's cronjob file this lines:

0 8-18 * * 1-5 /usr/lib/sysstat/sa1 1200 3 &
5 19 * * 1-5 /usr/lib/sysstat/sa2 -A &

The -d option in sa1 makes it to store disks data, which by default are not written. Now you can use sar to see the data stored, in your system, check the page of the project for more information about this performance toolkit

A common task for System Administrators is to monitor and care for a server. That's fairly easy to do at a moment's notice, but how to keep a record of this information over time?  One way to monitor your server is to use the Sysstat package.

Sysstat is actually a collection of utilities designed to collect information about the performance of a linux installation, and record them over time.

It's fairly easy to install too, since it is included as a package on many distributions.
To install on Centos 4.3, just type the following:
yum install sysstat
We now have the sysstat scripts installed on the system. Lets try the sar command.
sar
Linux 2.6.16-xen (xen30) 08/17/2006 11:00:02 AM CPU %user %nice %system %iowait %idle 11:10:01 AM all 0.00 0.00 0.00 0.00 99.99 Average: all 0.00 0.00 0.00 0.00 99.99 Several bits of information, such as Linux kernel, hostname, and date are reported.
More importantly, the various ways CPU time being spent on the system is shown.
%user, %nice, %system, %iowait, and %idle describe ways that the CPU may be utilized.
%user and %nice refer to your software programs, such as MySQL or Apache.
%system refers to the kernel’s internal workings.
%iowait is time spent waiting for Input/Output, such as a disk read or write. Finally, since the kernel accounts for 100% of the runnable time it can schedule, any unused time goes into %idle.
The information above is shown for a 1 second interval. How can we keep track of that information over time?
If our system was consistently running heavy in %iowait, we might surmise that a disk was getting overloaded, or going bad.
At least, we would know to investigate.
So how do we track the information over time? We can schedule sar to run at regular intervals, say, every 10 minutes.
We then direct it to send the output to sysstat’s special log files for later reports.
The way to do this is with the Cron daemon.
By creating a file called sysstat in /etc/cron.d, we can tell cron to run sar every day.
Fortunately, the Systat package that yum installed already did this step for us.
more /etc/cron.d/sysstat
# run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib/sa/sa1 1 1 # generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib/sa/sa2 -A The sa1 script logs sar output into sysstat’s binary log file format, and sa2 reports it back in human readable format.
The report is written to a file in /var/log/sa.
ls /var/log/sa

sa17 sar17

sa17 is the binary sysstat log, sar17 is the report. (Today  date is the 17th)
There is quite alot of information contained in the sar report, but there are a few values that can tell us how busy the server is.
Values to watch are swap usage, disk IO wait, and the run queue.
These can be obtained by running sar manually, which will report on those values.
sar

Linux 2.6.16-xen (xen30)        08/17/2006

11:00:02 AM       CPU     %user     %nice   %system   %iowait     %idle
11:10:01 AM       all      0.00      0.00      0.00      0.00     99.99
11:20:01 AM       all      0.00      0.00      0.00      0.00    100.00
11:30:02 AM       all      0.01      0.26      0.19      1.85     97.68
11:39:20 AM       all      0.00      2.41      2.77      0.53     94.28
11:40:01 AM       all      1.42      0.00      0.18      3.24     95.15
Average:          all      0.03      0.62      0.69      0.64     98.02

There were a few moments where of disk activity was high in the %iowait column, but it didnt stay that way for too long. An average of 0.64 is pretty good.
How about my swap usage, am I running out of Ram? Being swapped out is normal for the Linux kernel, which will swap from time to time. Constant swapping is bad, and generally means you need more Ram.
sar -W

Linux 2.6.16-xen (xen30)        08/17/2006

11:00:02 AM  pswpin/s pswpout/s
11:10:01 AM      0.00      0.00
11:20:01 AM      0.00      0.00
11:30:02 AM      0.00      0.00
11:39:20 AM      0.00      0.00
11:40:01 AM      0.00      0.00
11:50:01 AM      0.00      0.00
Average:         0.00      0.00

Nope, we are looking good. No persistant swapping has taken place.
How about system load? Are my processes waiting too long to run on the CPU?
sar -q

Linux 2.6.16-xen (xen30)        08/17/2006

11:00:02 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
11:10:01 AM         0        47      0.00      0.00      0.00
11:20:01 AM         0        47      0.00      0.00      0.00
11:30:02 AM         0        47      0.28      0.21      0.08
11:39:20 AM         0        45      0.01      0.24      0.17
11:40:01 AM         0        46      0.07      0.22      0.17
11:50:01 AM         0        46      0.00      0.02      0.07
Average:            0        46      0.06      0.12      0.08

No, an average load of .06 is really good.
Notice that there is a 1, 5, and 15 minute interval on the right.
Having the three time intervals gives you a feel for how much load the system is carrying.
A 3 or 4 in the 1 minute average is ok, but the same number in the 15 minute
column may indicate that work is not clearing out, and that a closer look is warranted.
This was a short look at the Sysstat package.
We only looked at the out put of three of sar  attributes, but there are others.
Now, armed with sar in your toolbox, your system administration job just became a little easier.

Log rotation in cPanel

 Files are only rotated when they grow larger than the value 300MB which is set at cpanel >> Tweak >> Log rotation size threshold, currently set as 300 MB default.

You can have the log rotation checked from under

Main >> Service Configuration >> cPanel Log Rotation Configuration


Inorder to  rotate the btmp, chkservd.log and brcm-iscsi.log I have made changes to the logrotate.conf file located in the /etc directory.

/var/log/chkservd.log {
weekly
rotate 1
}
To add insult to injury, cPanel is not rotating its own logs either.  Place this in the same file we have been editing:
/usr/local/cpanel/logs/stats_log {
weekly
rotate 1
}
/usr/local/cpanel/logs/access_log {
weekly
rotate 1
}
/usr/local/cpanel/logs/error_log {
weekly
rotate 1
}
/var/log/xferlog {
weekly
rotate 1
postrotate

/sbin/service pure-ftpd restart > /dev/null 2>/dev/null || true

endscript
}

/var/log/chkservd.log {
weekly
rotate 1
}

/usr/local/cpanel/logs/cpbackup/*.log {
weekly
rotate 1
}

/usr/local/cpanel/logs/*log {
weekly
rotate 1
}

/usr/local/apache/logs/*log {
daily
rotate 7
sharedscripts
postrotate

/sbin/service httpd graceful > /dev/null 2>/dev/null || true

endscript
}

/var/log/btmp {

monthly

minsize 1M

create 0600 root utmp

rotate 1

}

CSF country code blocking

This is where you block country wise in csf

Under section  "# SECTION:Country Code Lists and Settings" in csf.conf

Locate for below and add the code
CC_DENY = "ID"
Check for codes here
http://www.ipdeny.com/ipblocks/

Wordpress memory limit

Did you know, you can update the memory limit, fileseize etc  in wordpress by editing wp-confi.php as well 

Try below and see

define('WP_MEMORY_LIMIT', '64M');
define('upload_max_filesize', '20M');

Installing Tomcat 7 on a cPanel Server

When you have installed tomcat by using Easy-Apache then it installed Tomcat 5.5 and if you want to installed Tomcat 7.0.11 then you need to made some necessary changes on the server.

1) First install Tomcat 5.5 by using Easy-Apache means java is also installed at the time of Easy-Apache. The Tomcat 5 is installed in /usr/local/jakarta/ directory with the symbolic link tomcat. For example:

[~]# ll /usr/local/jakarta

drwxr-xr-x  4 tomcat nobody 4096 Apr  5 17:15 ./

drwxr-xr-x 22 root   root   4096 Mar  5 15:39 ../

drwxr-xr-x 12 tomcat nobody 4096 Apr  4 17:02 apache-tomcat-5.5.30/

lrwxrwxrwx  1 tomcat nobody   39 Apr  4 17:04 tomcat -> /usr/local/jakarta/apache-tomcat-5.5.30/

2)  Then download and extract Tomcat 7 in /usr/local/jakarta directory

[~]# cd /usr/local/jakarta
[/usr/local/jakarta]# wget http://apache.cs.utah.edu/tomcat/tomcat-7/v7.0.11/bin/apache-tomcat-7.0.11.tar.gz
[/usr/local/jakarta]# tar -xzvf  apache-tomcat-7.0.11.tar.gz

3) Then Change the tomcat symbolic link to point to your new version (i.e. /usr/local/jakarta/apache-tomcat-7.0.11)

[/usr/local/jakarta]# ln -s /usr/local/jakarta/apache-tomcat-7.0.11 tomcat

Now it shows

[~]# ll /usr/local/jakarta

drwxr-xr-x  4 tomcat nobody 4096 Apr  5 17:15 ./

drwxr-xr-x 22 root   root   4096 Mar  5 15:39 ../

drwxr-xr-x 12 tomcat nobody 4096 Apr  4 17:02 apache-tomcat-5.5.30/

drwxr-xr-x  9 tomcat nobody 4096 Apr  4 17:01 apache-tomcat-7.0.11/

lrwxrwxrwx  1 tomcat nobody   39 Apr  4 17:04 tomcat -> /usr/local/jakarta/apache-tomcat-5.5.30/

4) Then compile the new Tomcat version on cPanel server.

[~]# cd /usr/local/jakarta/apache-tomcat-7.0.11

[/usr/local/jakarta/apache-tomcat-7.0.11]# cd ./bin

[/usr/local/jakarta/apache-tomcat-7.0.11/bin]# tar xvfz commons-deamon-native.tar.gz

[/usr/local/jakarta/apache-tomcat-7.0.11/bin]# cd commons-daemon-1.0.x-native-src/unix

[/usr/local/jakarta/apache-tomcat-7.0.11/bin/commons-daemon-1.0.x-native-src/unix]# ./configure

[~]# make

[~]# cp jsvc ../..

[~]# cd ../../..

5) Copy over any Host blocks from /usr/local/jakarta/tomcat/conf/server.xml from the old Tomcat install to the new Tomcat install (you may or may not be able to set up new hosts through WHM).

6) Copy over /usr/local/jakarta/tomcat/conf/workers.properties from the old Tomcat install to the new Tomcat install.

7) Restart the server

[/]# reboot

Or

[/]# /usr/local/jakarta/tomcat/bin/shutdown.sh

[/]# /usr/local/jakarta/tomcat/bin/startup.sh

[/]# /etc/init.d/httpd restart

9) Check Tomcat Version

 [/]# sh /usr/local/jakarta/tomcat/bin/version.sh

The cPanel EasyApache system makes it easy to recompile Apache with various add-ons and modules.

If you ever need your old Tomcat back just stop Tomcat, flip the tomcat symbolic link back to the old install, and restart Tomcat.

The only thing I've run into with this is that tomcat won't start using the cpanel commands... I can get it to start by calling startup.sh directly, but the /usr/sbin/starttomcat which is what the /scripts/restartsvc_tomcat calls... it spits out a command for the jsvc that we compiled, but nothing happens... it doesn't actually run anything.
ANS: I managed to fix my own issue by hunting through the log files...

In /usr/sbin/starttomcat you have to modify a line since it's still set up for the old tomcat 5.5

Locate: my $jars = "./bootstrap.jar";
Change to: my $jars = "./bootstrap.jar:./tomcat-juli.jar";

Tomcat 7 requires the additional tomcat-juli.jar to start up... once I added that, it starts up perfectly.