Tomcat configuration skills --------------------------------- ---------------------------------
Editor Press: Now developing Java web applications, establishing and deploying Web content is a very simple job. People who use Jakarta Tomcat as servlets and JSP containers have spread all over the world. Tomcat has many features such as free, cross-platform, and is updated very quickly, and now very popular.
What you need to do is: Configure Tomcat according to your needs, as long as you are configured correctly, Tomcat is generally suitable for your request. Here is a series of configuration skills about Tomcat, these techniques come from my book: "Tomcat Authoritarian Guide", I hope to help you. ?? jason braittain
1. Configuration System Management (Admin Web Application)
Most commercial J2EE servers provide a powerful management interface, and most of the easy-to-understand web application interfaces. Tomcat also provides a mature management tool in its own way, and is not inferior to those commercial competitors. Tomcat's admin Web Application initially appeared at version 4.1, the functionality included managing Context, Data Source, User, and Group. Of course, you can also manage multiple database management like initialization parameters, User, Group, and Role. In subsequent versions, these features will be extended, but existing features are very practical.
Admin Web Application is defined in the automatic deployment file: Catalina_Base / WebApps / Admin.xml.
(Translator Note: Catalina_base is the server directory under Tomcat installation directory)
You must edit this file to determine that the DocBase parameter in Context is an absolute path. That is, the path of Catalina_Base / WebApps / Admin .xml is an absolute path. As another choice, you can also delete this automatic deployment file, and create a Context of an Admin Web Application in the server.xml file, the effect is the same. You can't manage the application of Admin Web Application. In other words, in addition to deleting Catalina_Base / WebApps / Admin.xml, you may not do anything.
If you use UserDatabaseRealm (default), you will need to add a USER and a role to the catalina_base / conf / tomcat-users.xml file. You edit this file, add a Role called "admin" to the file, as follows:
You also need to have a user, and the role of this user is "admin". To add a user, add a user (changing the password safer):
When you complete these steps, restart Tomcat, access http: // localhost: 8080 / admin, you will see a login interface. Admin Web Application adopts a safe mechanism based on container management and uses a Jakarta Struts framework. Once you log in to the management interface as a "admin" role, you will be able to configure Tomcat using this management interface. 2. Configuration Application Management (Manager Web Application)
Manager Web Application Let you perform some simple web application tasks through a user interface than Admin Web Application.
Manager Web Application is defined in an automatic deployment file:
Catalina_base / WebApps / Manager.xml.
You must edit this file to make sure the CONTEXT's DocBase parameter is an absolute path, that is, the absolute path of Catalina_Home / Server / WebApps / Manager.
(Translator Note: Catalina_Home is Tomcat Installation Directory)
If you are using UserDatabaseRealm, then you need to add a role and a user to the Catalina_base / conf / Tomcat-users.xml file. Next, edit this file, add a role named "Manager" to the file:
You also need a user with a role "manager". To add a new user like the already existing users (change your password safer):
Then restart Tomcat, access http: // localhost / manager / list, you will see a very simple text-type management interface, or visit http: // localhost / manager / html / list, you will see an HMTL management interface . No matter which method, your Manager Web Application is now launched.
Manager Application allows you to install new web applications on the basis of system management privileges for testing. If we have a new web app under / home / user / hello, and want to install it to / hello, in order to test this app, we can do this, enter "/ hello" in the first file box (As the path when access, enter "File: / Home / User / Hello" in the second text box (as a config URL).
Manager Application also allows you to stop, restart, remove, and redeploy a web application. Stop an app that can't be accessed, when some user tries to access this stopped app, will see a 503 error? "503 - this Application IS Not Currently Available".
Remove a web application, just delete the app from Tomcat's running copy, if you restart Tomcat, the deleted application will appear again (that is, removal does not mean 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 content of this web) to the Catalina_Base / WebApps directory. 2> Establish an XML fragment file that includes Context content and put the file in the catalina_base / webapps directory. This web application itself can be stored anywhere on the hard disk.
If you have a WAR file, if you want to deploy it, you just need to copy the file into the Cataalina_base / webapps directory, the file must be ".war" as an extension. Once the Tomcat monitors this file, it will (default) until the file is made as a subdirectory, and the file name of the WAR file as the name of the subdirectory. Next, Tomcat will create a context in memory, just like you have established in the server.xml file. Of course, other required content will be obtained from DefaultContext in Server.xml.
Another way to deploy web applications is to write a context XML fragment file, then copy the file to the catalina_base / webapps directory. A Context fragment is not a complete XML file, but is just a context element, as well as the corresponding description of the application. This piece of fragment is like the Context element cut from Server.xml, so this piece is named "Context Disclosure".
For example, if we want to deploy a application called MyWebapp.war, the app uses Realm as an access control method, we can use this piece:
Context fragment for deploying myWebapp.war
->
Debug = "0" privileged = "true"> ResourceEName = "UserDatabase" /> Name this piece "MyWebApp.xml" and copy it to the catalina_base / webapps directory. This Context snippet provides a convenient way to deploy web applications, you don't need to edit server.xml unless you want to change the default deployment feature, you don't need to restart Tomcat when installing a new web application. 4. Configure virtual hosts (Virtual Hosts) About "Host" elements in Server.xml, only needs to be modified only if you set up a virtual host. A virtual host is a mechanism for serving multiple domain names on a web server. For each domain name, it seems to have an exclusive host. In fact, most small business websites are implemented in virtual hosts, mainly because virtual hosts can connect directly to the Internet and provide corresponding bandwidth to ensure reasonable access response speed, and additional virtual hosts can provide a stable Fixed IP. Name-based virtual hosts can be built on any web server, the method established is to create an alias of the IP address on the Domain Name Server (DNS), and tell the web server to distribute the request to different domain names to the corresponding web directory. Because this article is primarily tomcat, we don't prepare for the way DNS on various operating systems. If you need help in this regard, please refer to "DNS and Bind" book, the author is Paul Albitz and cricket Liu ( Oreilly). For the convenience of demonstration, I will use a static host file because it is the simplest method for testing alias. Using a virtual host in Tomcat, you need to set DNS or host data. In order to test, set an IP alias for local IP. Next, you need to add a few lines of content in Server.xml, as follows: Port = "8080" MINPROCESSORS = "5" maxprocessors = "75" Enablelookups = "True" redirectport = "8443" /> Port = "8443" MINPROCESSORS = "5" maxprocessors = "75" Acceptcount = "10" debug = "0" scheme = "https" secure = "true" /> ClientAuth = "false" protocol = "tls" /> Unpackwars = "true" autodeploy = "true"> Tomcat's server.xml file, in the initial state, only a virtual host, but it is easy to expand to multiple virtual hosts. A simple server.xml version is shown in the previous example, where the bold part is used to add a virtual host. Each Host element must include one or more context elements that must have a default context, which should be empty (for example, path = "). 5. Configuring basic authentication (Basic Authentication) The container management verification method controls how to identify the user's identification when the user accesses the protected web application resource. When a web application uses the Basic Authentication (the Basic parameter is set in the auto-method element in the web.xml file), and when a user access protected web app, Tomcat will pop up a dialog box, request The user enters the username and password. In this verification method, all passwords will be transmitted on the network with a 64-bit encoding. Note: By using Basic Authentication is considered unsafe because it does not have strong encryption, unless use HTTPS or other code on the client and server-side encrypted manner (for example, in a virtual private network). If there is no additional encryption method, the network administrator will be able to intercept (or abuse) the user's password. However, if you just start using Tomcat, or you want to test the container-based security management in your web application, Basic Authentication is also very easy to set up and use. Just add The web.xml in the following example is taken from a club member website system, which is only protected by the Member directory and authenticated using Basic Authentication. Note that this way will effectively replace the .htaccess file in the Apache web server.
Define the Members-Only Area, by Defininga "Security Constraint" on this application, and Mapping it to the subdirectory (url) That We want TO RESTRICT. -> Entire Application 6. Single sign-on (SINGLE SIGN-ON) Once you set up Realm and verification, you need to perform actual user login processing. Generally speaking, the login system for users is a very troublesome thing, you must try to minimize the number of users login verification. As the default, when the user first requests protected resources, each web application requires a user to log in. If you have run multiple web applications, and each application needs to perform separate user authentication, then it looks a bit like you fight with your users. Users don't know how to integrate multiple separate applications into a separate system. All they don't know how many different applications they need, but they are only confused, why should they always log in. Tomcat 4's "Single Sign-ON" feature allows users to log in once when accessing all web applications under the same virtual host. In order to use this feature, you only need to add a SingLesignon Valve element on Host, as shown below: Debug = "0" /> After the initial installation of Tomcat, the Note of Server.xml includes examples of the SingLesignon Valve configuration, you only need to remove the comment, you can use it. Then, any user will be equally valid for all applications under the same virtual host. There are some important limits using Single Sign-on Valve: 1> Value must be configured and nested in the same Host element, and all web applications that need to be single-point validation (definition must be defined via the context element) is located under this host. 2> Realm including shared user information must be set in the same stage Host or outside the nest. 3> Can't be covered by Realm in Context. 4> Using a single-point login web app to best use a Tomcat's built-in authentication method (defined in 6> Single sign-on needs to use cookies. 7. Configure user custom directory (Customized User Directores) Some sites allow individual users to publish web pages on the server. For example, a university's college may want to give every student a public area, or an ISP hopes to give some clients to his client, but this is not a virtual host. In this case, a typical method is to add a special character (~) in front of the username, as a website of each user, such as: http://www.cs.myuniversity.edu/~username Http://members.mybigisp.com/~username Tomcat provides two ways to shoot these personal websites on the host, mainly using a special Listener element. Listener's classname property should be org.apache.catalina.startup.userConfig, the UserClass property should be one of several mapping classes. If your system is UNIX, it will have a standard / etc / passwd file that can be readily read by the account in the file, which specifies the user's home directory, using the PasswduSerDatabase map class. DIRECTORYNAME = "public_html" Userclass = "org.apache.catalina.startup.passwduserDatabase" /> The web file needs to be placed under the directory of / home / users / ian / public_html or / users / jbrittain / 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 home directory. If you don't have a password file, you want to map a username to the subdirectory of the public image / home, you can use the HomesUserDatabase class. DirectoryName = "public_html" HomeBase = "/ home" Userclass = "org.apache.catalina.startup.homesuserDatabase" /> In this way, the web file can be located in the same directory like / home / jasonb / public_html. This form is more advantageous for Windows, you can use a directory like C: Home. These Listener elements, if they appear, must be in the Host element, and cannot be in the Context element, because they are used in Host itself. 8. Use the CGI script in Tomcat Tomcat is primarily as a servlet / jsp container, but it also has many traditional web servers. Support for universal gateway interfaces (CGI) is one of them, CGI provides a set of methods to run some extensions when responding to browser requests. The reason why CGI is called generic because it can be called in most programs or scripts, including: Perl, Python, awk, unix shell scripting, etc., even Java. Of course, you probably not run a Java application as a CGI, after all, this is too primitive. In general, development servlets are always better than CGI, because when the user clicks on a link or a button, you do not need to start from the operating system layer. Tomcat includes an optional CGI servlet that allows you to run the CGI script left. In order to enable Tomcat to run CGI, you have to do the following things: 1. Remove servlets-cgi.renametojar (in catalina_home / server / lib / directory) to servlets-cgi.jar. Handling the servlet of CGI should be located under the classpath of Tomcat. 2. In the Tomcat's Catalina_Base / Conf / Web.xml file, remove the annotation of the paragraph of 3. Similarly, in Tomcat's Catalina_Base / Conf / Web.xml file, the annotation of the paragraph of mapping of CGI is removed (by default, this paragraph is located 299). Note that this content specifies how HTML links to the CGI script. 4. You can place the CGI script in a web-inf / cgi directory (note that web-inf is a safe place, you can put some files that don't want to be seen or safe to expose by the user), Or you can also place the CGI script in other directories under Context and adjust the CGIPATHPREFIX initialization parameters for the CGI Servlet. This is the actual location of the specified CGI Servlet and cannot be rename with the URL specified by the previous step. 5. Restart Tomcat, your CGI can run. In Tomcat, the CGI program is default in the web-INF / CGI directory. As mentioned earlier, the web-INF directory is protected, and the browser through the client cannot spy to the content, so for the placement of the password or This is a very nice place for CGI scripts of other sensitive information. To be compatible with other servers, although you can also save the CGI script in the traditional / cgi-bin directory, you have to know that the files in these directories may be seen by the curious surfers on the Internet. In addition, in UNIX, determine that the user who runs Tomcat has permission to perform the CGI script. 9. Changing the JSP compiler in Tomcat in Tomcat 4.1 (or higher, probably), JSP compiles are executed directly by the ANT controller included in Tomcat. This sounds a little strange, but this is part of ANT intention to use, and an API document guides developers using Ant without launching a new JVM. This is a major advantage in Java development using Ant. In addition, this also means that you can now use any Javac support in Ant, here there is a Javac page list about the APACHE ANT User Manual. It is easy to use because you only need to define a name "Compiler" in the Org.apache.jasper.Servlet.jspservlet Of course, given the compiler must already be installed in your system, and ClassPath may need to set, which is done in what compiler you choose. 10. Restricting a specific host access (Restricting Access To Specific Hosts) Sometimes you might want to limit access to Tomcat web applications, for example, you want only your host or IP address to access your app. In this way, only those specified clients can access the content of the service. To achieve this effect, Tomcat provides two parameters for you to configure: RemotehostValve and RemoteadDrvalve. By configuring these two parameters, you can filter from the requested host or IP address and allow or reject which host / IP. Similarly, there is a permission / rejection specified for each directory in the HTTPD file in Apache. For example, you can set the Admin Web Application to allow local access, set as follows: Allow = "127.0.0.1" deny = "" /> If you do not give the host's designation, the host that does not match the host will be rejected, which is allowed to be allowed. Similarly, if the designation of the reject host is not given, the host that is allowed to match the host will be allowed, in addition to the rejection. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- About the Author: Jason Brittain is a senior software engineer of Collabnet, mainly responsible for the development of software underlying architecture. He has made a lot of contributions to the Apache Jakarta project, and he has been a positive open source software developer for many years. Ian F. Darwin has worked in the computer industry for 30 years: Unix started from 1980, starting using Java in 1995, using OpenBSD from 1998. He is the author of two books Oreilly: Checking C Programs with lint and Java Cookbook, also with Jason Brittain co-author of Tomcat: The Definitive Guide.
