Tomcat configuration tips Top10

 

1. Admin web application)

Most commercial J2EE servers provide a powerful management interface that is easy to understand. Tomcat provides a mature management tool in its own way, and is no inferior to its competitors. The Admin web application of Tomcat was first available in version 4.1. The functions at that time included management context, data source, user, and group. Of course, you can also manage databases such as initialization parameters, user, group, and role. In subsequent versions, these functions will be greatly extended, but the existing functions are very practical. Admin
The Web application is defined in the automatic deployment file catalina_base/webapps/admin. xml. (Translator's note: catalina_base is the server directory under the tomcat installation directory)

You must edit this file to make sure that the docbase parameter in context is an absolute path. That is, Catalina

The path of _ base/webapps/admin. XML is absolute. As another option, you can also delete the automatic deployment file, and set up an Admin web application context in the server. xml file. The effect is the same. You cannot manage the Admin web application. In other words, you may not be able to do anything except to delete catalina_base/webapps/admin. xml.

If you use userdatabaserealm (default), you will need to add a user and a role to the catalina_base/CONF/tomcat-users.xml file. Edit the file and add a role named "admin" to the file, as shown below:

<Role name = "admin"/>

You also need a user whose role is "admin ". Add a user as an existing user (change the password to make it more secure ):

<Ser name = "admin"
Password = "deep_dark_secret"
Roles = "admin"/>

After completing these steps, restart Tomcat and access http: // localhost: 8080/admin. You will see a logon interface. Admin web application adopts the container-based security mechanism and uses the Jakarta Struts framework. Once you log on to the management interface as a user of the "admin" role, you can use this management interface to configure tomcat.

2. Configure Application Management (Manager Web Application)

Manager Web application allows you to execute some simple web application tasks through a simpler user interface than Admin web application. The Manager Web application is defined in an automatic deployment file:

Catalina_base/webapps/manager. xml

You must edit this file to ensure that the docbase parameter of context is the absolute path, that is, the absolute path of catalina_home/Server/webapps/manager. (Translator's note: catalina_home is the tomcat installation directory)

If you are using userdatabaserealm, you need to add a role and a user to the catalina_base/CONF/tomcat-users.xml file. Next, edit the file and add a role named "manager" to the file:

<Role name = "manager">

You also need to have a user with the role "manager. Add a new user as an existing user (change the password to make it safer ):

<User name = "manager"
Password = "deep_dark_secret"
Roles = "manager"/>

Restart Tomcat and access http: // localhost/manager/list. A simple text management interface or http: // localhost/manager/html/list. A management interface of hmtl is displayed. Either method indicates that your Manager Web application has been started.

The Manager application allows you to install new Web applications for testing without the privileges of system management. If a new Web application is located under/home/user/hello and you want to install it under/Hello, we can do this to test the application, in the first file box, enter "/Hello" (as the path for access), and in the second text box, enter "file:/home/user/Hello" (as the config URL ).

The Manager application also allows you to stop, restart, remove, and redeploy a web application. Stopping an application makes it inaccessible. when a user attempts to access the application, a 503 error is displayed ?? "503-this application is not currently available ".

To remove a web application, the application is deleted from the running copy of Tomcat. If you restart tomcat, the deleted application will appear again (that is, removal does not mean deletion from the hard disk ).

3. Deploy a web application

There are two ways to deploy Web Services in the system.

1. Copy your war file or your web application folder (including all the content of the Web) to the $ catalina_base/webapps directory.

2. Create an XML fragment file that only contains context content for your web service and put the file in the $ catalina_base/webapps directory. This web application can be stored anywhere on the hard disk.

If you want to deploy a war file, simply copy the file to the catalina_base/webapps directory. The file must use ". War" as the extension. Once Tomcat listens to this file, it will (by default) unbind the package as a sub-directory and use the war file name as the sub-directory name.

Next, Tomcat creates a context in the memory, as if you have created a context in the server. xml file. Of course, other necessary content will be obtained from defaultcontext in server. xml.

Another way to deploy a web application is to write a context XML fragment file and copy the file to the catalina_base/webapps directory. A context fragment is not a complete XML file, but a context element and the corresponding description of the application.

This type of fragment file is like the context element removed from server. xml. Therefore, this fragment is named "context fragment ".

For example, if we want to deploy an application named mywebapp. War, which uses realm as the access control method, we can use the following piece:

<! --
Context fragment for deploying mywebapp. War
-->
<Context Path = "/demo"
Docbase = "webapps/mywebapp. War"
DEBUG = "0" privileged = "true">
<Realm classname =
"Org. Apache. Catalina. realm. userdatabaserealm"
Resourcename = "userdatabase"/>
</Context>

Name the clip "mywebapp. xml" and copy it to the catalina_base/webapps directory.

This context snippet provides a convenient way to deploy Web applications. You do not need to edit the server. XML, unless you want to change the default deployment feature, you do not need to restart Tomcat when installing a new Web application.

4. Configure Virtual Hosts)

The "host" element in server. xml must be modified only when you set the virtual host. A vm is a mechanism that serves multiple domain names on a Web server. For each domain name, it seems that the entire host is exclusive. In fact, most small business websites use virtual hosts. This is mainly because virtual hosts can directly connect to the Internet and provide the appropriate bandwidth to ensure a reasonable access response speed, in addition, the VM can provide a stable fixed IP address.

A name-based virtual host can be created on any Web server by creating an IP address alias on the Domain Name Server (DNS, the Web server is also notified to distribute requests to different domain names to the corresponding web directory. This article is mainly about tomcat. We are not going to introduce how to set up DNS on various operating systems. If you need help in this regard, please refer to the book DNS and bind, the author is Paul albitz and cricket Liu (O 'Reilly ). For ease of demonstration, I will use a static host file because this is the easiest way to test aliases.

To use a VM in Tomcat, you need to set DNS or host data. To test, it is enough to set an IP alias for the local IP address. Next, you need to add several lines of content in server. XML, as shown below:

<Server port = "8005"
Shutdown = "shutdown" DEBUG = "0">
<Service name = "tomcat-standalone">
<Connector classname =
"Org. Apache. Coyote. tomcat4.coyoteconne"
Port = "8080"
Minprocessors = "5" maxprocessors = "75"
Enablelookups = "true"
Redirectport = "8443" type = "regxph" text = "yourobjectname"/>
<Connector classname =
"Org. Apache. Coyote. tomcat4.coyoteconne"
Port = "8443" minprocessors = "5"
Maxprocessors = "75"
Acceptcount = "10" DEBUG = "0"
Scheme = "HTTPS" secure = "true"/>
<Factory classname = "org. Apache. Coyote.
Tomcat4.coyoteserversocketfactory"
Clientauth = "false" protocol = "TLS"/>
</Connector>
<Engine name = "standalone"
Defaulthost = "localhost" DEBUG = "0">
<! -- This host is the default host -->
<Host name = "localhost"
DEBUG = "0" appbase = "webapps"
Unpackwars = "true" autodeploy = "true">
<Context Path = "" docbase = "root" DEBUG = "0"/>
<Context Path = "/orders"
Docbase = "/home/ian/orders" DEBUG = "0"
Reloadable = "true" crosscontext = "true">
</Context>
</Host>

<! -- This host is the first
"Virtual Host": http://www.example.com/-->
<Host name = "www.example.com"
Appbase = "/home/example/webapp">
<Context Path = "" docbase = "."/>
</Host>

</Engine>
</Service>
</Server>

Tomcat's server. xml file contains only one virtual host in the initial state, but it is easy to expand to support multiple virtual hosts. The preceding example shows a simple server. XML version. The bold section is used to add a VM. Each host element must contain one or more context elements. The contained context element must have a default context. The display path of this default context should be blank (for example, path = "").

5. Configure Basic Authentication)

The container management authentication method controls how users perform identity authentication when they access protected web application resources. When a web application uses basic authentication (the basic parameter is stored on the web. when a user accesses a protected web application, Tomcat will pop up a dialog box through HTTP basic authentication, enter the user name and password. In this authentication method, all passwords are transmitted over the network in 64-bit encoding mode.

Note: using basic authentication is considered insecure because it does not have robust encryption methods, unless you use https or other password and password methods on both the client and server (for example, in a virtual private network ). Without any additional encryption method, the network administrator can intercept (or misuse) the user's password.

However, if you are using tomcat or want to test container-based security management in your web application, basic authentication is very easy to set and use. You only need to add and two elements to your web application's web. xml file, and add the appropriate sum to the catalina_base/CONF/tomcat-users.xml file, and then restart tomcat.

The Web. XML in the following example is taken from a club member website system. In this system, only the member directory is protected and basic authentication is used for identity authentication. Note that this method will effectively replace the. htaccess file on the Apache Web server.

<! --
Define
Members-only area,
By defining
A "security constraint"
On this application, and
Mapping it to
Subdirectory (URL) that we want
To restrict.
-->
<Security-constraint>
<Web-resource-collection>
<Web-resource-Name>
Entire Application
</Web-resource-Name>
<URL-pattern>/members/* </url-pattern>
</Web-resource-collection>
<Auth-constraint>
<Role-Name> Member</Role-Name>
</Auth-constraint>
</Security-constraint>
<! -- Define the login
Configuration
This application -->
<Login-config>
<Auth-method> basic </auth-method>
<Realm-Name> my club
Members-only area </realm-Name>
</Login-config>

6. Configure Single Sign-on)

Once you have set the realm and authentication methods, you need to perform the actual user logon process. Generally, it is very troublesome for users to log on to the system. You must minimize the number of user login verification times. By default, when a user requests a protected resource for the first time, each web application requires the user to log on.

If you run multiple web applications and each application requires separate user authentication, it looks a bit like you are fighting with your users. Users don't know how to integrate multiple separated applications into a single system, and they don't know how many different applications they need to access, why do you always log on without stopping.

The Single Sign-On Feature of Tomcat 4 allows users to log on only once to access all web applications on the same virtual host. To use this function, you only need to add a singlesignon valve element to the host, as shown below:

<Valve classname =
"Org. Apache. Catalina.
Authenticator. singlesignon"
DEBUG = "0"/>

After the initial installation of Tomcat, the comments of server. xml include examples of singlesignon valve configuration. You only need to remove the comments to use them. Therefore, any user who has logged on to an application is equally valid for all applications on the same virtual host. Using Single Sign-On valve has some important restrictions:

1> value must be configured and nested in the same host element, and all web applications that require spof (must be defined by the context element) are located under this host.

2> realm, which includes shared user information, must be set in the same level of host or nested.

3> cannot be overwritten by realm in context.

4> for Web applications that use single sign-on, it is best to use a built-in Tomcat verification method (defined on the web. in XML), which is better than the custom authentication method. Tomcat's built-in authentication methods include basic, digest, form, and client-cert.

5> if you use single sign-on, you also want to integrate a third-party web application to your website, and the new web application uses its own authentication method, without the use of Container Management Security, you are basically no choice. Each time your user logs on to all the original applications, You need to log on again when requesting a new third-party application.

Of course, if you have the source code of this third-party web application, and you are a programmer, you can modify it, but it may not be easy to do.

6> cookies are required for single-point logon.

7. Configure the custom directory (customized user Directores)

Some sites allow individual users to publish webpages on the server. For example, a college may want to give each student a public area, or an ISP wants to give some web space to his customers, but this is not a VM. In this case, a typical method is to add a special character (~) before the user name (~), As a website for each user, for example:

Http://www.cs.myuniversity.edu /~ Username

Http://members.mybigisp.com /~ Username

Tomcat provides two methods to map these personal websites on the host, mainly using a pair of special listener elements. The classname attribute of listener should be org. Apache. Catalina. startup. userconfig, And the userclass attribute should be one of several ing classes.

If your system is UNIX, it will have a standard/etc/passwd file. The account in this file can be easily read by running tomcat, this file specifies the user's home directory and uses the passwduserdatabase ing Class.

<Listener classname =
"Org. Apache. Catalina. startup. userconfig"
Directoryname = "public_html"
Userclass = "org. Apache. Catalina.
Startup. passwduserdatabase "/>

Web files must be stored in directories like/home/users/ian/public_html or/users/jbritain/public_html. Of course, you can also change public_html to any other subdirectory.

In fact, this user directory does not necessarily need to be in the user's main directory. If you do not have a password file, but you want to map a user name to a common subdirectory like/home, you can use the homesuserdatabase class.

<Listener classname =
"Org. Apache. Catalina. startup. userconfig"
Directoryname = "public_html"
Homebase = "/home"
Userclass = "org. Apache. Catalina.
Startup. homesuserdatabase "/>

In this way, the Web file can be located in the same directory as/home/ian/public_html or/home/jasonb/public_html. This form is more advantageous for windows. You can use a directory like c: \ home.

If these listener elements appear, they must be in the host element, but not in the context element, because they are all applied to the host itself.

8. Use CGI script in Tomcat

Tomcat is mainly used as a Servlet/JSP Container, but it also has the performance of many traditional Web servers. Common Gateway Interface (CGI) is one of them. cgi provides a set of methods to run some extensions in response to browser requests.

CGI is called generic because it can be called in most programs or scripts, including Perl, Python, awk, Unix shell scripting, and even Java.

Of course, you probably won't run a Java application as CGI. After all, this is too primitive. Generally, developing servlets is always more efficient than CGI, because when you click a link or button, you do not need to start from the operating system layer.

Tomcat includes an optional CGI servlet that allows you to run the legacy CGI script.

To enable tomcat to run CGI, you must do the following:

1. Change the servlets-cgi.renametojar (under the catalina_home/Server/lib/directory) to the servlets-cgi.jar. The servlet for processing CGI should be located in the classpath of Tomcat.

2. In the catalina_base/CONF/Web. xml file of Tomcat, remove the comments about the CGI section (This section is located in 241st rows by default ).

3. Similarly, in the catalina_base/CONF/Web. xml file of Tomcat, remove the comments about the CGI ing to CGI (by default, this segment is located in line 299th ). Note: This section specifies the access method for HTML-to-CGI scripts.

4. you can place CGI scripts in the WEB-INF/cgi Directory (note that WEB-INF is a safe place, you can put some files that you do not want to be seen by users or that you do not want to expose based on security considerations), or you can place CGI scripts in other directories in the context, modify the cgipathprefix initialization parameters for the CGI servlet. This specifies the actual location of the CGI Servlet and cannot be the same as the URL specified in the previous step.

5. Restart tomcat to run your CGI.

In tomcat, the CGI program is placed under the WEB-INF/cgi Directory by default, as prompted earlier, the WEB-INF directory is protected and cannot be snooped into through the client browser, this is a good place for CGI scripts containing passwords or other sensitive information.

To be compatible with other servers, although you can store CGI scripts in the traditional/cgi-bin directory, you must be aware that the files in these directories may be viewed by curious online surfers. In addition, in UNIX, make sure that the user running tomcat has the permission to execute the CGI script.

9. Change the JSP compiler (JSP compiler) in Tomcat)

In Tomcat 4.1 (or later, probably), JSP compilation is directly executed by the ant Program Controller included in Tomcat. This may sound a little strange, but this is part of ant's intention. There is an API document that instructs developers to use ant without starting a new JVM.

This is a major advantage of using ant for Java development. In addition, this also means that you can now use any javac-supported compilation methods in ant. Here is a javac page list for the Apache ant user manual.

It is easy to use, because you only need to define an element named "compiler", and there is a compiler name that supports compilation in value. The example is as follows:

<Servlet>
<Servlet-Name> JSP </servlet-Name>
<Servlet-class>
Org. Apache. Jasper. servlet. jspservlet
</Servlet-class>
<Init-param>
<Param-Name> logverbositylevel
</Param-Name>
<Param-value> warning </param-value>
</Init-param>
<Init-param>
<Param-Name> compiler </param-Name>
<Param-value> jikes </param-value>
</Init-param>
<Load-on-startup> 3 </load-on-startup>
</Servlet>

Of course, the given compiler must have been installed in your system, and classpath may need to be set, which is the type of compiler you choose.

10. Restrict access to a specific host (restricting access to specific hosts)

Sometimes, you may want to restrict access to Tomcat web applications. For example, you want only the host or IP address specified by you to access your applications. In this way, only the specified clients can access the service content. To achieve this, Tomcat provides two parameters for you to configure: remotehostvalve and remoteaddrvalve.

By configuring these two parameters, you can filter the requested host or IP address and allow or deny the host/IP address. Similarly, each directory is allowed/denied in the httpd file of Apache. For example, you can set Admin web application to allow local access only, as follows:

<Context Path =
"/Path/to/secret_files"...>
<Valve classname = "org. Apache.
Catalina. Valves. remoteaddrvalve"
Allow = "127.0.0.1" deny = ""/>
</Context>

If you do not specify the allowed host, the host that matches the rejected host will be denied. Similarly, if you do not specify a denial host, the host that matches the allowed host will be allowed. Otherwise, the host will be rejected.