9.11.2Environment variable PRINTER

The BSD print command and some application programs read the environment variable PRINTER to determine which printer destination to send data to. The System V print command lp does not.

9.11.3BSD print queue

•lpr -p printer file Send file to named print queue.

•lpq Show the printer queue for the default printer, or the printer specified in the environment variable PRINTER if this is set. This lists the queue-ids.

•lprm queue-id Remove a job from the print queue. Get the queue-id using lpq.

•lpd Start the print service. (Must be killed to stop again.)

•lpc An old and unreliable interface to the print service.

9.11.4SysV print queue

•lp -d printer file Send a file to the named print queue.

•lpstat -o all Show the printer queue for the default printer. This lists the queue-ids.

•lpstat -a Tells lies about when the print service was started.

•lpsched Start the print service.

•lpshut Stop the print service.

•cancel queue-id Remove a job from the print queue. Get the queue-id using lpstat.

The Solaris operating system used to have an optional printing system called Newsprint in addition to the SVR4 printing commands.

9.12 Java web and enterprise services

Java services are becoming increasingly important in the world of the network. The most important services are those connected to the Web, but any Java program can, in principle, make use of Java services. Java Server Pages (JSP) are Java’s dynamical web page framework. Accompanying this are Java Servlets (the server counterpart of Applets) that house JSP-based services, mediated by the Web on port 80 or 8080. Java servlets are applications, based on the standard Java libraries and a class/object approach to services, in which services are objects called by object invocation.

The naming service attaches objects to services and routes requests to dependent services, such as databases to the correct host and port number. Enterprise Beans are essentially wrappers that provide transaction locking and security of data transfer for Java services that employ them. They are the ‘heavyweight’ side of Java services and are mediated by an enterprise application server.

Java has a close relationship with XML, and the configuration files that configure Java software and services are generally written in this eclectic framework. In spite of what XML followers would have us believe, XML was designed to be parsed by machines, not humans, and some of the XML configuration files one finds strain the credibility of their claims.

Java services require the Java Runtime Environment in order to work. Java virtual machines are provided by several sources, including Sun Microsystems, IBM, Microsoft and others, so there is no single recipe for making Java work. However, the basic Java compiler and virtual machine have to be installed and working in order for the related services to work.

9.12.1Java development kit

As an example, we consider the Java Development Kit from Sun Microsystems. It is collected as an archive from the net. Once installed in some location, e.g. /usr/local, it lives in a directory that needs to be pointed to by the environment variable JAVA HOME. Java’s libraries are called classes and they have a library path analogous to LD LIBRARY PATH. For example,

JAVA_HOME=/local/jdk1.3.1 CLASSPATH=/usr/local/mm.mysql.jdbc-1.2c: \ /usr/lib/jdk1.3.1/lib/classes.zip: \ /usr/local/iu/JSDK2.0/lib/jsdk.jar: \ /usr/local/jserv/lib/ApacheJServ.jar:.

Once these variables have been set, the compiler javac and runtime environment java can be tested with the following test-program:

// File has same name as class, i.e. JavaTest.java

public class JavaTest

{

// An application class must include a ‘‘main’’ method

public static void main ( String args[] )

{

System.out.println("This is a compiler test program\n");

}

}

This program is compiled and run as follows:

host% /usr/lib/jdk1.3/bin/javac JavaTest.java

host% /usr/lib/jdk1.3/bin/java JavaTest This is a compiler test program

9.12.2Web containers: Jserv and Tomcat

A Java ‘web container’ is an executable environment for Java Server Pages (JSP). Java Server Pages are Java program elements that are embedded into HTML pages, in order to create dynamic content. These are stripped out and compiled on the fly as mini-servers or ‘servlets’, Java programs linked to HTML pages, allowing dynamic content in HTML pages, with ‘custom tag’-technology. Tomcat is the reference Java example of such a container; another example container is Jserv.

Tomcat can be used ‘stand-alone’ or as a module for an Apache web server. The connection between Tomcat and Apache is managed by an Apache Dynamic Share Object (DSO).

The Tomcat server goes by the name of CATALINA and it has environment variables that correspond to the Java variables:

CATALINA_HOME=/usr/local/jakarta-tomcat

CATALINA_TMPDIR=/var/run/tomcat

Installing Tomcat is simply a matter of unpacking it under /usr/local, for instance, and starting the server. A non-privileged tomcat user should be created:

host% cd /usr/local/jakarta-tomcat/bin/ host% ./startup.sh

or on Windows:

host% ./startup.bat

Somewhat inconveniently, executable code for servlets is placed under the distribution itself:

The example structure must be reproduced for any additional startup-pages or users. Tomcat needs writable temporary workspace in its distribution, so file permissions need to be set like this when running in non-privileged mode:

Here is an example cfengine script to manage some of these issues: The server needs to be restarted regularly, to notice updates.

#

#A configuration for tomcat -

#to be run on port 8080 (conf/server.xml)

#servlet server runs as user "tomcat"

#

#to call up:

#http://host.example.org:8080/mark/servlet/HelloWorldExample

#(note no s in servlets!!!)

#

# Server config is in conf/server.xml (careful here!)

#

control:

#editfilesize = ( 90000 )

#actionsequence = ( files links processes )

catalina_base = ( /local/jakarta-tomcat-4.0.2 )

#####################################################################

#

#For now copy -r webapps/examples to ~user/servlets

#to get started, and then link that area below

#to webapps/user

#

######################################################################

links:

$(catalina_base)/webapps/mark -> /iu/nexus/ud/mark/servlets

# $(catalina_base)/webapps/frodes -> /iu/nexus/uc/frodes/servlets

9.12.3Enterprise Java Beans

JBoss, Websphere and Weblogic are examples of Enterprise Java Beans (EJB) containers, an execution environment for EJB. JBoss has attracted a lot of attention since it not only is free software, but also has a very simple deployment mechanism that avoids the need for extra XML configuration to be supplied. Once archived into a ‘jar’ file, the bean can be deployed simply, by placing it into the deployment directory. This contrasts with commercial rivals that need extra XML files and specialized tools for deploying software.

Some additional configuration is needed to couple the server to a database backend. Connection to a PostgreSQL database, for instance, takes place through Java Data Base Connectivity (JDBC). The basics of this are provided by a Java Archive (‘jar’ file) distributed with the PostgreSQL Database Management Software.

Dynamical HTML/JSP content first contacts a servlet in order to access methods written in Java. Servlets, employing Enterprise Beans, contact the Bean Container (e.g. JBoss) for code and service. The connection between Tomcat and JBoss takes the form of an EJB Client connecting to an EJB Server. Tomcat and JBoss can thus be separate and several Tomcat installations can feed into several JBoss installations. This allows the scheme to scale, by load-distribution, to the limitations of hardware and the database manager. In the default configuration available from JBoss web pages, however, both Tomcat and JBoss reside on the same machine with a single connection.

EJB Clients need to find a number of Java archive (‘jar’) files containing classes to allow them to function. They need to find the Java Class files which define the interface between Client and Server too. This is accomplished by placing them somewhere in the CLASSPATH environment.

The Tomcat based EJB Clients also need Java Naming and Directory Interface (JNDI) information to allow them to connect to their Servers. This is accomplished by having a properties file (jndi.properties) somewhere within CLASSPATH. The contents of this file specify a local address (e.g. localhost) for the JNDI service.

Installation of JBoss is simplicity itself. Assuming that the service will run as a non-privileged user jboss:

cd /usr/local

tar zxf jboss-3.0.tar.gz

ln -s /usr/local/jboss-3.0 /usr/local/jboss

/bin/su -s /bin/sh jboss --command="whoami"

/bin/su -s /bin/sh jboss --command="sh /usr/local/jboss/bin/run.sh"

The server can be tested by using a web browser to access the portals:

http://host.example.org:8080

http://host.example.org:8082

9.12.4Multi-user deployment

The Tomcat servlet environment is set up to provide only for a single user. The presumed model is a production environment with a single web server per company – not a college environment, with many students, for example. Thus, on a multi-user system where every user has their own servlets and JSP files, it is awkward to allow them to add and delete servlets without causing problems for one another. A single error seems to be able to cause the whole server to fail inexplicably.

However, it is possible to coax the server to look in more than one location for servlet and JSP files, so it is, in principle, possible to create a directory for every user with the necessary environment; although an error by one user can easily affect all the others; also the server must be frequently restarted to register errors.

To the configuration file $CATALINA_HOME/conf/server.xml, we must add an additional document base, one for each user. These are analogous to the ‘examples’ area described above, and provided by the Tomcat distribution.

<Context path="/mark" docBase="mark" debug="0" reloadable="true" /> <Context path="/frode" docBase="frode" debug="0" reloadable="true" />

and then link the directory

mark -> ~mark/servlets/ frode -> ~frode/servlets/

The whole webapps directory structure of Tomcat must then be reproduced under each user’s servlet directory.

An example applet is then referred to, for instance, as:

http://host.example.org:8080/mark/servlet/HelloWorldExample

Exercises

Self-test objectives

1.What is a network application service?

2.What is an application server?

3.What is an application proxy?

4.What issues are involved in installing a new service on Linux?

5.What issues are involved in installing a new service on Windows?

6.What role does inetd play for application services?

7.What is TCP wrappers? How is it used?

8.Create a checklist for setting up a nameserver.

9.Create a checklist for setting up a web server.

10.Explain the principle of using a private user ID for each application service.

11.What is a privileged port?

Problems

1.Compare the Berkeley mailbox format with the IMAP mailbox format. Discuss the advantages and disadvantages of each.

2.Set up an Apache web server.

3.Build a tree of documents, where some files are public and others are restricted to access by your local organization, using the .htaccess file capability.

4.Show that a CGI-script can always be written which reveals all of the files restricted using .htaccess. This shows that untrusted CGI-scripts are a security risk.

5.Write a Perl script for handling WWW errors at your site.

6.Estimate the number of megabytes transferred per week by the file-servers at your domain. Could any of this traffic be avoided by reorganizing the network?

7.Where are the default nameservers placed around your network? Is there a nameserver on each subnet, i.e. does DNS lookup traffic have to pass through a router?

8.Set up TCP wrappers on your system (Unix-like OSs only).

9.Install the Java Development kit from Sun Microsystems. Compile the test program above, and then install Tomcat. Test the example servlets and JSP pages using a web browser to access port 8080.

10.Delete the Tomcat distribution in the previous exercise and collect the JBoss–Tomcat combined distribution from www.jboss.org. Install this, and check that it is working by using a web-browser to access the main web pages at ports 8080 and 8082.

11.Discuss the role of Java and .NET services in consolidating network application services in the future. What is the difference between multiple services over many IP ports, and having multiple services brokered over a single port? Think of security, reliability and ease of management in your answer.

12.Java’s reliance on XML for configuration information is typical of a trend in current practice. Discuss the advantages and disadvantages of XML for configuration information.