< Zurück | Inhalt | Weiter >

Chapter 20


Open Source

Web Application Servers


image

Servlets and JSP need to be served up by something; that something is a Web application server. What started as simple Web servers serving up little more than HTML pages developed into Java application servers—the backbone of the enterprise IT environment.

image



20.1 WHAT YOU WILL LEARN


In this chapter, we will describe the installation of both the JBoss and Geroni- mo Java application servers on a Linux platform. These servers not only run servlets and JSP, but they are also, as we shall see in later chapters, J2EE EJB containers, so the installation part of this chapter is important for using the technologies and examples covered in the remaining chapters. We will review the System V init system and explain how to add JBoss to the regular system of services on your Linux box. We will show you how to use groups and permis- sions to enable a number of nonroot users to do the basic application server administration.


443


20.2 DOWNLOADING JBOSS


JBoss1 is a complete application server. It provides a full, production-ready, J2EE environment. Be aware that as of this writing JBoss 4.0 has just passed the Sun J2EE certification tests, but even prior to the certification JBoss has been one of the most widely used J2EE application servers.

image

A great deal of JBoss information can be found on the JBoss Web site.2 Visit the site’s download page3 to download the product.



NOTE

Version 4.0 of JBoss has only just become available, so you will see us using the prior production stable version, 3.2.3. By the time you read this, however, version 4.0 will be the better choice. What we describe should apply equally well to both.


First off, you must choose what form of the product to download. The choice is really between a binary and source distribution. Within that choice, you can choose between a number of compression methods. We will download and install a binary. Just click on jboss-3.2.3.tgz and save the file. Before we install, we need to consider some issues of management.


20.3 BE AN ENABLER, OR “LETS BE CODEPENDENT!”


People often give inadequate consideration to the issues of management of software systems. This is especially true of Java systems, which are, by their na- ture, cross-platform. We have the luxury of dealing only with Linux systems here, so we can make some practical suggestions most books ignore.


image

1. JBoss is actually a combination of two distinct projects: JBoss, the EJB container and JMS server, and Tomcat, the servlet and JSP server. You can install and use Tomcat alone. We won’t bother to do that in this book. We’ll install JBoss and use JBoss for everything. We are also lazy typists who do not like to keep typing JBoss/Tomcat, so we’ll refer to it merely as JBoss from now on. If you are deploying only servlets and JSP, then, by all means, download and install Tomcat only. It is part of the Apache Jakarta project.

2. http://www.jboss.org/index.php

3. http://www.jboss.org/downloads/


Up to this point, we have largely been considering a situation where the Java developer is working on an individual workstation where he or she has root access. Now that we are talking about application servers, we are dealing with systems where, as the software progresses from development through rounds of testing to production, we will want to limit the people who are able to change certain elements of the system. Often, the “quick and dirty” strategy is to share out the root password to a number of users. This is a serious security risk, even when all parties are trusted. Why? Because root isn’t a person. When someone logs in as root, we do not know who that person is. We only know that it is someone who knows the root password. In some businesses, this is an unacceptable ambiguity in audit.

A common alternative is to restrict root login to the console only, and to require the use of the su (“set user”) command to promote an already logged- in user to root status. This provides a link back to the individual, so actions can be traced to single person. That improves auditability.

This strategy is better, but since root is an all-or-nothing proposition, it is a fairly blunt instrument. Once someone can su to root, that someone can do anything. That’s a lot of power to give to someone who just needs to be able to install WAR files.

Yet another strategy is to set up the sudo system.4 Using sudo, you can specify what people can execute which commands as root, and where they may do it from. In other words, you might let user alice start and stop the Web server and mount and unmount filesystems when she is logged in to a local machine, but only to start the Web server when she is logged in on a machine outside your network. Check out the manpage for sudo to learn more. Even this isn’t the best solution for the present issue.

The best solution is not to require root power at all if you can avoid it. Remember that permissions on files in Linux are assigned to users, groups, and others. Most people do not think about the middle tier, groups. But groups are the best way to give control over parts of the filesystem to a collection of users without requiring them to share an account and password.


 


20.3.1 Nonroot-Installed Software

1. Create the group.

20.3.2 Finer Grained Control

20.5.1 System V Init System

20.5.2 RedHat/Fedora chkconfig

20.5.3 Other Distributions

20.5.4 IDE Integration