Pre-Requirements
First you need to install Sun JDK and you can follow the instructions given in Installing Sun JDK 1.6 on CentOS

After Java is on place it’s time to get ready for Tomcat.

Download Apache Ant and Tomcat

1. Download apache-ant and apache-tomcat -packages.
2. Extract those packages to /opt/

   • #[root@srv ~]# cd /opt
     # tar -xzf apache-tomcat-6.0.26.tar.gz
     # tar -xzf apache-ant-1.7.1-bin.tar.gz
     

3. Create a symbolic link for Ant

   • # ln -s /opt/apache-ant-1.7.1/bin/ant /usr/bin/
     

Create start script

1. Create a tomcat user so that we don’t need root privileges for Tomcat

   • # useradd -d /opt/apache-tomcat-6.0.26/ tomcat
     

2. Create start script to /etc/init.d for starting and stopping Tomcat

   • #  vim /etc/init.d/tomcat
     

3. The script is (via Build a safe cage for Tomcat)

   • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

     #!/bin/bash # # tomcat Starts Tomcat Java server. # # # chkconfig: 345 88 12 # description: Tomcat is the server for # Java servlet applications. ### BEGIN INIT INFO # Provides: $tomcat ### END INIT INFO   JAVA_HOME=/usr/java/jdk1.6.0_18 export JAVA_HOME TOMCAT_HOME=/opt/apache-tomcat-6.0.26/bin START_TOMCAT=/opt/apache-tomcat-6.0.26/bin/startup.sh STOP_TOMCAT=/opt/apache-tomcat-6.0.26/bin/shutdown.sh   # Source function library. . /etc/init.d/functions   [ -f $START_TOMCAT ] || exit 0 [ -f $STOP_TOMCAT ] || exit 0   RETVAL=0   umask 077   start() { echo -n $"Starting Tomcat Java server: " daemon su -c $START_TOMCAT tomcat echo return $RETVAL } stop() { echo -n $"Shutting down Tomcat Java server: " daemon su -c $STOP_TOMCAT tomcat echo return $RETVAL } restart() { stop start } case "$1" in start) start ;; stop) stop ;; restart|reload) restart ;; *) echo $"Usage: $0 {start|stop|restart}" exit 1 esac   exit $?

4. Give executable rights for that script

   • # chmod 755 /etc/init.d/tomcat
     

5. Add the script to CentOS services

   • # chkconfig --add tomcat
     

6. Check the changes

   • # chkconfig --level 234 tomcat on
     # chkconfig --list tomcat
     
     tomcat 0:off 1:off 2:on 3:on 4:on 5:off 6:off
     

7. You should see that the service uses levels 2, 3 and 4
8. Test that the script is working and it gives no errors

   • # service tomcat start
     # service tomcat stop
     

9. Everythings ready

Related journal entries

• Redirect HTTP and HTTPS traffic to Tomcat’s ports
• Installing Sun JDK 1.6 on CentOS

Step 1. Initial setup for building RPM
-!- Do this with a non-root user

1. Create ~/.rpmmacros

   • $ vim ~/.rpmmacros
     %_topdir /home//rpmbuild
     %_tmppath %{_topdir}/tmp
     

2. Create needed folders:

   • $ mkdir -p ~/rpmbuild/{SOURCES,SRPMS,SPECS,RPMS,tmp,BUILD}
     

3. Build environment needs to be complete. Some needed packages are:

   • $ sudo yum install -y rpm-build gcc gcc-c++ redhat-rpm-config
     

Step 2. Installing your favorite JDK

1. Download Sun JDK 1.6 update 14 from Sun Java download or the Sun JDK archive.
   • Choose the correct platform (for me it’s Linux x64) and download jdk-6u18-linux-x64-rpm.bin
2. Give it executable rights: $ chmod 755 jdk-6u18-linux-x64-rpm.bin
3. Run the binary to extract it into RPM form: $ ./jdk-6u18-linux-x64-rpm.bin
4. Install it:

   • $ sudo rpm -Uvh jdk-6u18-linux-amd64.rpm
     

5. Log out and in again to make the changes in the paths take effect
6. Check the install

   • $ java -version
     java version "1.6.0_18"
     Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
     Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
     

7. Java is now installed on /usr/bin/java

Related journal entries

• Installing Apache Tomcat 6 on CentOS
• Using RichFaces 3 dataScroller and dataTable -components
• Redirect HTTP and HTTPS traffic to Tomcat’s ports

Luckily it is easy to tell the system to redirect the traffic from some port to other. Just define some new xinetd services in /etc/xinetd.d/tomcat.

# vim /etc/xinetd.d/tomcat

# Redirects any requests on port 80 to port 8080 (where Tomcat is listening)
service tomcat-http
{
        disable                 = no
        flags                   = REUSE
        wait                    = no
        user                    = root
        socket_type         = stream
        protocol                = tcp
        port                    = 80
        redirect                = localhost 8080
        log_on_success  -= PID HOST DURATION EXIT

        #per_source = UNLIMITED
        #instances = UNLIMITED
}

# Redirects any requests on port 443 to port 8443 (where Tomcat is listening)
service tomcat-https
{
        disable                 = no
        flags                   = REUSE
        wait                    = no
        user                    = root
        socket_type         = stream
        protocol                = tcp
        port                    = 443
        redirect                = localhost 8443
        log_on_success  -= PID HOST DURATION EXIT

        #per_source = UNLIMITED
        #instances = UNLIMITED
}

(via Securing Linux for Java services: The port dilemma)

Xinetd puts a connection limit per source IP, by default and this causes the service to become unresponsive when there are dozens of queries a second. You see the following kind of line in your messages log file: “xinetd[2049]: FAIL: tomcat-https per_source_limit from=123.456.789.123″. To correct this, uncomment the per_source and instances lines in your xinet.d file and restart it.

Also add those xinetd services to /etc/services.

# vim /etc/services
http        80/tcp     www www-http tomcat-http # WorldWideWeb http
http        80/udp     www www-http tomcat-http # WorldWideWeb HTTP
http        443/tcp    tomcat-https # WorldWideWeb HTTPS
http        443/udp    tomcat-https # WorldWideWeb HTTPS

And now just restart the xinetd and admire how your traffic is redirected to Tomcat’s ports.

# service xinetd restart

Force everything to transmit through HTTPS
If you also want to redirect all HTTP traffic to HTTPS you can add the following section to you Tomcat web.xml:

<web-resource-collection>
    <web-resource-name>Protected Context</web-resource-name>
    <url-pattern>/*</url-pattern>
</web-resource-collection>
<!-- auth-constraint goes here if you requre authentication -->
<user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

If you are using this redirection of all traffic to HTTPS with JIRA and want to attachments working also with Internet Explorer then you must add the following to your jira.xml (f. ex. /opt/tomcat/conf/Catalina/localhost/jira.xml). This is a Internet Explorer bug, for more information see http://jira.atlassian.com/browse/JRA-8179.

<Context ...>
...
<!-- for IE bug, see http://jira.atlassian.com/browse/JRA-8179-->
<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="false" />
...
</Context>

Related journal entries

• Installing Apache Tomcat 6 on CentOS
• Installing Sun JDK 1.6 on CentOS

Simply say in the command line of domU:
echo 1 > /proc/sys/xen/independent_wallclock

Or if you have noclobber on:
echo 1 >! /proc/sys/xen/independent_wallclock

To reenable tracking of Xen wallclock:
echo 0 > /proc/sys/xen/independent_wallclock

And to keep the setting between reboots, just add it to the /etc/sysctl.conf:
xen.independent_wallclock = 1

Although, it is better if the Xen dom0 syncs the clock frequently so all the domains (domU) don’t need to do it by themselves and thus wasting resources. Why do things multiple times when it could be done just once.

Related journal entries

• No Related Post

My Samba service had worked fine for a long time but after a kernel update and a reboot, the performance was horrible. It was really slow to do anything. Fortunately I wasn’t the only one to come by with this problem and there was a topic Samba Performance Problem Due to Changing Linux Kernel in Samba Performance Tuning -guide which provided a solution to my problem. Just restarted the network interface and the performance was as good as before.

Earlier this month Samba Team Received Microsoft Protocol Docs so maybe in the near future we will get better and faster software.

The Protocol Freedom Information Foundation (PFIF), signed an agreement with Microsoft to receive the protocol documentation needed to fully interoperate with the Microsoft Windows workgroup server products and to make them available to Free Software projects such as Samba.

Microsoft was required to make this information available to competitors as part of the European Commission March 24th 2004 Decision in the antitrust lawsuit, after losing their appeal against that decision on September 17th 2007.
- Samba Team

Related journal entries

• Eclipse: Class file name must end with .class exception in search