Showing posts with label Webservers. Show all posts
Showing posts with label Webservers. Show all posts

Thursday, March 20, 2014

Hide tomcat Web Server Version Information



Hide tomcat Web Server Version Information

Replace the server version string from HTTP headers in server responses, by adding the server keyword in your Connectors in CATALINA_HOME/conf/server.xml


            server="Apache" /> 

Remove version string from HTTP error messages by repacking CATALINA_HOME/server/lib/catalina.jar with an updated ServerInfo.properties file.

Unpack catalina.jar

cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

Update ServerInfo.properties by changing server.info line to server.info=Apache Tomcat

Repackage catalina.jar

jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties

Remove CATALINA_HOME/server/lib/org (created when extracting the ServerInfo.properties file)

Restart the tomcat server.

Wednesday, March 19, 2014

Hide Apache Information from Intruders



Hide Apache Information

To hide the information, add the following two apache directives in Apache Configuration file httpd.conf

ServerTokens ProductOnly
ServerSignature Off

Now you need to restart your web server using the following command

#/etc/init.d/httpd  restart

Now the output for apache header looks like below
# Curl -I  http://localhost
Server: Apache

Tuesday, July 3, 2012

Frontend Apache with Tomcat?

Many people has  asked me the same question again and  again  so its better to document it.

Took this from apache wiki http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

Why should I integrate Apache with Tomcat? (or not)
There are many reasons to integrate Tomcat with Apache. And there are reasons why it should not be done too. Needless to say, everyone will disagree with the opinions here. With the performance of Tomcat 5 and 6, performance reasons become harder to justify. So here are the issues to discuss in integrating vs not.
  • Clustering. By using Apache as a front end you can let Apache act as a front door to your content to multiple Tomcat instances. If one of your Tomcats fails, Apache ignores it and your Sysadmin can sleep through the night. This point could be ignored if you use a hardware loadbalancer and Tomcat's clustering capabilities.
  • Clustering/Security. You can also use Apache as a front door to different Tomcats for different URL namespaces (/app1/, /app2/, /app3/, or virtual hosts). The Tomcats can then be each in a protected area and from a security point of view, you only need to worry about the Apache server. Essentially, Apache becomes a smart proxy server.
  • Security. This topic can sway one either way. Java has the security manager while Apache has a larger mindshare and more tricks with respect to security. I won't go into this in more detail, but let Google be your friend. Depending on your scenario, one might be better than the other. But also keep in mind, if you run Apache with Tomcat - you have two systems to defend, not one.
  • Add-ons. Adding on CGI, perl, PHP is very natural to Apache. Its slower and more of a kludge for Tomcat. Apache also has hundreds of modules that can be plugged in at will. Tomcat can have this ability, but the code hasn't been written yet.
  • Decorators! With Apache in front of Tomcat, you can perform any number of decorators that Tomcat doesn't support or doesn't have the immediate code support. For example, mod_headers, mod_rewrite, and mod_alias could be written for Tomcat, but why reinvent the wheel when Apache has done it so well?
  • Speed. Apache is faster at serving static content than Tomcat. But unless you have a high traffic site, this point is useless. But in some scenarios, tomcat can be faster than Apache httpd. So benchmark YOUR site. Tomcat can perform at httpd speeds when using the proper connector (APR with sendFile enabled). Speed should not be considered a factor when choosing between Apache httpd and Tomcat
  • Socket handling/system stability. Apache has better socket handling with respect to error conditions than Tomcat. The main reason is Tomcat must perform all its socket handling via the JVM which needs to be cross platform. The problem is socket optimization is a platform specific ordeal. Most of the time the java code is fine, but when you are also bombarded with dropped connections, invalid packets, invalid requests from invalid IP's, Apache does a better job at dropping these error conditions than JVM based program. (YMMV)

Friday, July 2, 2010

Performance Tunning Your Application Server

Instruction to performance tune OS for JBOSS/Tomcat/WebSphere/Oracle AS

First, you need to set the kernel parameter for shared memory to be at least as big as you need for the amount of memory you want to set aside for the JVM to use as large page memory. Personally, I like to just set it to the maximum amount of memory in the server, so I can play with different heap sizes without having to adjust this every time. You set this by putting the following entry into /etc/sysctl.conf:

Set the kernel Parameter for Shared memory in /etc/sysctl.conf to maximum amount of memory in the system so u don’t have to worry about the heap sizes adjustment .


kernel.shmmax = n for 4 GB server use 4294967296

where n is the number of bytes.

Set a virtual memory kernel parameter of how many large memory pages you want


vm.nr_hugepages = n

where n is the number of pages, based on the page size listed in /proc/meminfo for
Hugepagesize: 2048 kB

So, I wanted to set this to 3GB. I set the parameter to 1536, which is (1024*1024*1024*3)/(1024*1024*2). Which is 3GB divided by 2MB, since 2048 KB is 2MB.

Set another virtual memory parameter, to give permission for your process to access the shared memory segment. In /etc/group, created a new group, called hugetablespace let suppose guid is 1501

Put that group id in /etc/sysctl.conf as follows:
vm.hugetlb_shm_group = 1501

This GUID should be attached to the same user as that with which JBOSS is running .

/etc/security/limits.conf as follows:
jboss soft memlock n
jboss hard memlock n

where n is equal to the number of huge pages, set in vm.nr_hugepages, times the page size from /proc/meminfo, , 1536*2048 = 3145728. This concludes the OS setup, and now we can actually configure the JVM.

The JVM parameter for the Sun JVM is -XX:+UseLargePages use the same large pages /proc/meminfo

Saturday, April 10, 2010

All Web Servers Tutorials Will be publish Under this category

All Web Servers Tutorials Will be publish Under this category