I’ve done a lot of front-end java coding over my career, one particularly annoying aspect is the wait for a build (compile-deploy) cycle in my local developement servers to view or test a small change. One particularly useful tool that I’ve been using for some time is a FileSync plugin for Eclipse. It is useful as you can “map” folders from your Eclipse project to a path on your local filesystem, as such the individual files are automatically copied to your server installation. I’ve personally used this approache with JBoss, Tomcat and WebSphere, but there is no reason that it should not work for other servers.
I’ve recently spent a lot of time reviewing the OWASP documentation, and (like many corporations) realized that I’d neglected to keep up with this configuration item.
By sharing the exact version of each piece of server software you are using, “hackers” are able to quickly identify unpatched systems and their known vulnerabilities.
To make their work harder, there are a few simple steps that the server admin can take to remove this information from the HTTP Headers and error pages.
sudo vi /etc/apache2/conf-enabled/security.conf
- If using virtual hosts, add the following to each one:
sudo service apache2 restart
- Find the <Connector > entry and add:
mkdir -p org/apache/catalina/util
sudo service tomcat7 restart
PHP “X-Powered-By: PHP/5.x.x-1ubuntuX.X”
sudo vi /etc/php5/apache2/php.ini
expose_php = Off
sudo service apache2 restart
Older versions of Apache Tomcat, as well as the older servlet specifications required that several configuration values need to be set. With servlet 3, you can now modify the name of the session cookie (as well as the ‘rewriting’ attribute name) in the web.xml file
In web.xml: (servlet 3.x)
<name>mysessionid</name><!-- default is jsessionid -->
Alternately for Tomcat7, modify
<Context path="/exampleApp" sessionCookieName="myid">
If you are using spring security, then you should try setting
<http>element to true.
I’ve run into this a few times as my web applications got larger. Often this has been seen when builds automated by Jenkins start failing as they increase in size. It has also occurred to me when doing manual deployments as the Jenkins WAR itself is larger than 50MB lately.
Let’s just go in and increase the maximum expected file size…
This change should work on any platform, but the following is from my experience with Ubuntu.
sudo vi /opt/tomcat7/webapps/manager/WEB-INF/web.xml
<!-- 50MB -->
Change to something a bit larger (to your liking):
<!-- 50MB max 62428800, 100MB = 104857600 -->
Restart with either…
sudo /etc/init.d/tomcat7 restart
sudo service tomcat7 restart
After a while it can get tedious to access and review server logs via the command line. There are several tools available that can provide the same information in a graphical manner. Recently I’ve migrated to Splunk as there are both Enterprise and Free versions available.
- Of course, you’ll need a Splunk server installed first, as the forwarder is really just another (lighter) instance that will forward the log information to a central location.
- Download the system appropriate installer from:
- Check to see if you are running 32 or 64 bit OS.
If you see i686 you are 32 bit, if x86_64 you are 64 bit!
- Download, you’ll likely need a different version:
sudo dpkg -i splunkforwarder-6.1.3-220630-linux-2.6-intel.deb
sudo dpkg -i splunkforwarder-6.1.3-220630-linux-2.6-amd64.deb
- Enable auto-start on reboot:
- Start the server:
sudo service splunk start
- Set the password:
The default ‘
admin‘ password is ‘
changeme‘ so we need to change it immediately to do anything else, or we will see errors in future steps.
sudo /opt/splunkforwarder/bin/splunk edit user admin -password YOUR_NEW_PASSWORD -auth admin:changeme
- Set the server:
sudo /opt/splunkforwarder/bin/splunk add forward-server YOUR_SERVER_ADDRESS:9997
NOTE: if you get prompted for a splunk username/password you likely skipped the above step. Remember – the forwarder is a new ‘light’ installation of the server and as such has it’s own users!
- Enable some monitors on the box:
Some common services and log locations to get you started…
- Apache2 HTTPd
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/apache2 -index main -sourcetype Apache2
sudo /opt/splunkforwarder/bin/splunk add monitor /opt/tomcat7/logs -index main -sourcetype Tomcat7
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/mysql -index main -sourcetype MySQL
- Postfix (SMTP)
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/mail.log -index main -sourcetype Postfix
sudo /opt/splunkforwarder/bin/splunk add monitor /opt/sonar/logs -index main -sourcetype Sonar
- (OPTIONAL) Verify configuration by opening file at the following:
- You now should be able to log into your server and see new data flowing from the forwarder.
NOTE: this requires you to enable ‘receiving’ of data on the port specified above, usually 9997.
sudo ./splunk enable boot-start
Shortly after I automated code deployments in my Tomcat7 development testing environment, I found that some larger builds began failing with the following error:
org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (...) exceeds the configured maximum (62428800)
After a little digging, I found that the WAR files were exceeding the default maximum upload size, thankfully, this is trivial to increase.
sudo vi /usr/share/tomcat7-admin/manager/WEB-INF/web.xml
(Change 52428800 to a larger number, perhaps doubled like 104857600)
<!-- 50MB max = 52428800 (100MB = 104857600) -->
Logging is often an overlooked performance drain on systems requiring high throughput. Here’s a simple change to the default Tomcat logging configuration to implement. It works on all operating systems.
In the file:
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler
There are a few steps that I generally take to setup a new Tomcat server instance, this enables the following:
- The manager console
- HTTP compression
- UTF-8 encoding
- tomcat-users.xml – add to bottom:
<user username="tomcat" password="s3cr3t" roles="manager-gui"/>
server.xml – add compression and URIEncoding, change port if desired:
<Connector port="8080" protocol="HTTP/1.1"
redirectPort="8443" compression="on" URIEncoding="UTF-8" />
- server.xml – relocate webapps by adding ../ to appBase
<Host name="localhost" appBase="../webapps"
- Restart your server, on Ubuntu use:
sudo service tomcat7 restart
This is a relatively common problem in JSP based apps as you need to understand the configuration. It’s further complicated if you use Apache HTTPD in front of the Apache Tomcat server to process requests as you need to know where each request is processed.
For this example, we will use the standard 404 error, but you can also intercept other errors for custom pages.
- create 404.jsp
<% final SimpleDateFormat simpleDate = new SimpleDateFormat(“EE MMM dd yyyy hh:mm:ss aa zzz”);
final String dttm = simpleDate.format(new Date()); %>
<title>404 Not Found</title>
<li>Time: <%= dttm %></li>
<li>User-Agent: <%= request.getHeader(“User-Agent”) %></li>
<li>Server: <%= request.getServerName() %></li>
<li>Request: <%= request.getRequestURI() %></li>
<li>Remote: <%= request.getRemoteAddr() %></li>
<li>Referer: <%= request.getHeader(“Referer”) %></li>
- in WEB-INF/web.xml – add the following (NOTE: location within the file is important but outside the scope of this post)
- You might want to force the HTTP Header to give something other than a ‘404 status’ code, otherwise MSIE will show an unstyled ‘friendly error message’ if the user has not turned off the default setting. Unfortunately, this also means that search engines might index these pages that should not exist.
This one escaped me for a long time and I never saw a decent example of it in any of the documentation.
GZip compression saves on network bandwidth as files are compressed during transport between the HTTP Server and browser/client. If you already use Apache HTTP or a similar webserver to front Tomcat, this is not always necessary, but in cases where you expose your appserver directly, even if it is just for testing, you may want to add this configuration item as it increases the perceived speed of the application.
The solution is simple:
- To be safe, first stop the server and backup your configuration files
- Look in the /TOMCAT/conf installation folder.
- In the ‘server.xml’ file, you will find a line resembling…
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
- This one controls the HTTP/1.1 connections, add a new value to the list…
- NOTE You might also see a value for for AJP/1.3, unfortunately compression only works for HTTP:
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
- Restart your server.