Linux on System z Web 2.

Setting up a Web 2.0 stack on Red Hat Enterprise Linux 5 Update 2 August 2008

Linux on System z Web 2.0

Setting up a Web 2.0 stack on Red Hat Enterprise Linux 5 Update 2 August 2008

Note Before using this document, be sure to read the information in Notices on page 49.

First Edition August 2008 This edition applies to Red Hat Enterprise Linux 5 Update 2 only. Copyright International Business Machines Corporation 2008. All rights reserved. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents
Chapter 1. Introduction . . . . . . . . 1
What is Web 2.0? . . . . . . . . . The Web 2.0 stack components . . . . Applications exploiting the Web 2.0 stack . Web 2.0 on Linux on System z . . . . System requirements for the Web 2.0 stack Assumptions for this whitepaper . . . Where to find this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 3 4 4 4 Creation of a Ruby Server Page 'Hello World!' example . . . . . . . . . . . . . Database connectors for Ruby . . . . . . Installing additional Ruby libraries using RubyGems . . . . . . . . . . . . Setup of Ruby on Rails . . . . . . . . . 23 . 23 . 23 . 24

Chapter 4. Setup of Apache Tomcat . . 27

Installation of Apache Tomcat . . . . . . Verifying the Java installation . . . . . Verifying the Apache Tomcat installation . Important folders in Apache Tomcat . . . Lifecycle of Apache Tomcat . . . . . . . The Apache Tomcat administration tools. . . Adding support for JSP and Servlet API . . . Installation of JSP and Servlet API libraries . Creation of a JSP 'Hello World!' example . Creation of a Servlet 'Hello World!' example Adding Database connectors. . . . . . . Setup of MySQL connector . . . . . . Setup of PostgreSQL connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 27 28 28 28 30 30 30 31 32 33 33 34

Chapter 2. Setup of Databases . . . . . 5

Setup of MySQL . . . . . . . . . . . . . 5 Installation of MySQL . . . . . . . . . . 5 Lifecycle of MySQL . . . . . . . . . . . 5 Basic configuration of MySQL . . . . . . . 7 Setup of PostgreSQL . . . . . . . . . . . . 8 Installation of PostgreSQL . . . . . . . . . 9 Lifecycle of PostgreSQL . . . . . . . . . . 9 Basic configuration of PostgreSQL . . . . . . 11

Chapter 3. Setup of Apache HTTP Server . . . . . . . . . . . . . . . 13

Installation of Apache HTTP Server . . . . . Verification of the Apache HTTP Server installation . . . . . . . . . . . . Lifecycle of Apache HTTP Server . . . . . . Overview of Apache HTTP server modules . . . Adding support for PHP . . . . . . . . . Installation of mod_php . . . . . . . . Creation of a PHP 'Hello World!' Web example Database connectors for PHP . . . . . . Adding support for Perl . . . . . . . . . Installation of mod_perl . . . . . . . . Creation of a Perl 'Hello World!' example . . Database connectors for Perl . . . . . . . Installing additional Perl modules using CPAN Adding support for Python . . . . . . . . Installation of mod_python . . . . . . . Creation of a Python 'Hello World!' example . Database connectors for Python . . . . . Adding support for Ruby. . . . . . . . . Installation of mod_ruby . . . . . . . . Installation of eRuby . . . . . . . . . Creation of a Ruby CGI 'Hello World!' example . 13 . . . . . . . . . . . . . . . . . 13 13 15 15 16 16 16 16 17 17 18 18 18 18 19 20 20 20 21 22

Chapter 5. Setup of Caches . . . . . . 35

Setup of Squid . . . . . . . . Installation of Squid . . . . . Lifecycle of Squid . . . . . . Basic configuration of Squid . . . Setup of memcached . . . . . . Installation of memcached . . . Lifecycle of memcached . . . . Basic configuration of memcached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 35 35 37 38 38 38 40

Chapter 6. Setup of AJAX support . . . 41

Installation of the Dojo Toolkit . Example for using Dojo . . . . . . . . . . . . . . . . 41 . 41

Appendix. Packages for the Web 2.0 stack . . . . . . . . . . . . . . . 45 Notices . . . . . . . . . . . . . . 49

Trademarks . . . . . . . . . . . . . . 50

Copyright IBM Corp. 2008

iii

iv

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 1. Introduction
In recent years, the traditional way to use the Internet has changed significantly. Web administrators who published information on the Internet invite their community to contribute to the company's Web pages. Applications like Wikis, Blogs, Content Management Systems and a couple of others are providing this new functionality to the Web administrators. The variety of available open source Web 2.0 applications require a proper setup of server components. These server components and their setup for Red Hat Enterprise Linux 5 Update 2 on Linux on System z are described in this whitepaper.

What is Web 2.0?

The key question which needs to be addressed is: What is Web 2.0? Tim OReilly defines the Web 2.0 as
1

Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as platform, and an attempt to understand the rules for success on that new platform. This new perspective changed the usage of the Internet significantly. In the past, system administrators were required to prevent users to access their private application interfaces from Web applications to avoid security issues. Of course, security issues are still required to be prevented, but APIs have been defined to allow reuse by 3rd party Web applications. Data that was earlier only available for customers who paid for it is now opened up for public use. Who imagined ten years ago that satellite images of the whole world would be freely available and accessible by a well defined, public API? Additionally, Web applications are getting more dynamic and more flexible due to new technologies. AJAX is one example to increase the performance of a Web 2.0 application by receiving data asynchronously from different services. Functionality of desktop application like drag and drop are available through JavaScript libraries. All of this created a new spirit around the Internet and this is called Web 2.0.

The Web 2.0 stack components

In general, the Web 2.0 stack is based on the software solution stack called LAMP (acronym for Linux, Apache, MySQL, PHP (Perl and/or Python)). Some enhancements to the LAMP stack are getting into the spotlight when the discussion moves to Web 2.0. The following figure gives an overview about the Web 2.0 stack components

1. see http://radar.oreilly.com/archives/2006/12/web-20-compact-definition-tryi.html Copyright IBM Corp. 2008

Figure 1. Web 2.0 stack components

Database MySQL, PostgreSQL Web server Apache HTTP server, Apache Tomcat Programming Languages PHP, Perl, Python, Ruby, Java Frameworks Dojo (AJAX support), Ruby on Rails Caches memcached, Squid A system administrator does not have to install all Web 2.0 stack components at once. The selection is dependent on the Web 2.0 application and its functionality. i.e. if the Web 2.0 application offers information which is very static, it would make sense to establish a cache, but if the information is updated frequently then a cache is not the best choice. The appendix gives an overview on all packages which are used in this document.

Applications exploiting the Web 2.0 stack

On the Internet, various open source Web 2.0 applications are available. In a follow-up whitepaper, the setup of some popular Web 2.0 applications running on Linux on System z will be described in detail. The Web 2.0 stack which is described in this document enables a system administrator to choose the Web 2.0 application which fits best to the requirements. A list of very popular Web 2.0 applications is shown in the table below.

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Table 1. Open Source Web 2.0 applications Application Type Wiki Application name MediaWiki MoinMoin Confluence XWiki

Blogs

Wordpress Mephisto Movable Type

Content Management Systems (CMS)

Typo3 Drupal OpenCMS Apache Lenya

Business Applications

osCommerce

Web 2.0 on Linux on System z

Why run the Web 2.0 stack on Linux on System z? High availability A System z enterprise mainframe offers a high available environment by default. This reduces system outages which are related to hardware issues. Resource utilization Rarely used Linux on System z virtual server machines running on z/VM are swapped out and the resources are made available for other virtual machines. The swap in of a Linux on System z virtual server is hardly noticed by the user. Vertical Scalability By default, Linux on System z virtual servers running on z/VM are enabled for vertical scalability. This means a Linux on System z virtual server can be empowered with additional memory or CPU power on the fly. Rapid deployment If the vertical scalability is not sufficient, a new Linux on System z virtual server can be deployed within a couple of minutes. Performance Connections between virtual servers on System z can make use of the HiperSockets technology to speed up communication. Consolidation/TCO The different Web 2.0 stack components might be running on dedicated server machines. Linux servers can be consolidated to run on one physical System z machine. This saves power, space in the computer center and reduces the administration effort.
Chapter 1. Introduction

System requirements for the Web 2.0 stack

The system requirements for a Web 2.0 stack setup are closely related to the requirements of the Web 2.0 application. An application which is based on a large database requires more system resources like CPU and memory than an application which is running the application logic as client-side JavaScript. The system requirements are investigated in more detail in a follow-up whitepaper which explains the Web 2.0 applications in more detail.

Assumptions for this whitepaper

System administrators who read this document should be familiar, how to setup YUM to include the Red Hat Enterprise Linux 5 Update 2 DVD image and the related supplementary ISO image as repositories.

Where to find this document

You can find the latest version of this document on the developerWorks Web site at http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 2. Setup of Databases

In general, Web applications deal with a lot of information which is displayed to the user. To get a structured and stable environment in place which guarantees consistency and persistency, databases are used. By default, Red Hat Enterprise Linux 5 Update 2 includes two popular databases: MySQL and PostgreSQL. MySQL is one of the key components of the software solution stack called LAMP. Many Web 2.0 applications support both databases, so it is up to the system administrator which one to use.

Setup of MySQL
MySQL is a SQL database management system (DBMS), which has become one of the most popular open source database systems. Some key characteristics - ease of use, reliability, security and performance at close to zero cost - increased the usage of MySQL, especially in Web applications. Detailed information about MySQL is available at http://www.mysql.org

Installation of MySQL
The installation of the MySQL is straight forward as the packages are included in Red Hat Enterprise Linux 5 Update 2. Install the MySQL server and the MySQL client packages by using the following command:
# yum install mysql mysql-server

The mysql package includes a command line client for MySQL. This client is required for administration purposes of the database server. To access the MySQL database from a Web application, a client for the related programming language is required. For the programming languages mentioned in this document, different client implementations are available. The setup of these clients are described in the section where the setup of the programming languages is described.

Verifying the MySQL installation

To verify MySQL has been installed correctly, run the following command:
# mysql -V mysql Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (s390x) using readline 5.0

The output should look similar to the above.

Lifecycle of MySQL
Lifecycle operations of Linux services like starting/stopping are basic functionality. In general, the lifecycle functionality is supported by a command line tool named service. The tool allows, dependent on the supported functionality of the service specific script, to start, stop and restart a server. Apart from that, the current status

Copyright IBM Corp. 2008

of a server can be displayed. In the following, a walkthrough is shown for the MySQL server. This walkthrough assumes that this is the initial startup right after the packages have been installed. 1. Verifying the current status of the server To get the current status of the MySQL server, run the following command:
# service mysqld status mysqld is stopped

This indicates that the MySQL server is not started. 2. Starting the server for the first time To start the MySQL server, run the following command
# service mysqld start Initializing MySQL database: OK Filling help tables... OK Installing MySQL system tables...

To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/bin/mysqladmin -u root password new-password /usr/bin/mysqladmin -u root -h localhost.localdomain password new-password See the manual for more instructions. You can start the MySQL daemon with: cd /usr ; /usr/bin/mysqld_safe & You can test the MySQL daemon with mysql-test-run.pl cd mysql-test ; perl mysql-test-run.pl Please report any problems with the /usr/bin/mysqlbug script! The latest information about MySQL is available on the web at http://www.mysql.com Support MySQL by buying support/licenses at http://shop.mysql.com [ OK ] Starting MySQL: [ OK ]

The output displays some initialization steps which indicate that the MySQL server has been started for the first time. After the startup is completed, verify the status of the MySQL server by running:
# service mysqld status mysqld (pid 10040) is running...

As shown, the MySQL server is running as expected. Note that the PID varies after each startup 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the MySQL server, run the following command:
# service mysqld restart Stopping MySQL: Starting MySQL: [ [ OK OK ] ]

Once the restart completes, verify the status of the MySQL server by running:

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

# service mysqld status mysqld (pid 14585) is running...

As expected, the MySQL server is running again. Note that the PID varies after each restart 4. Stopping the server To stop the MySQL server, run the following command:
# service mysqld stop Stopping MySQL: [ OK ]

Again, the status can be verified by running:

# service mysqld status mysqld is stopped

As expected, the MySQL server is not running anymore. To start the MySQL server at boot time, the command chkconfig is used. Decide first in which runlevel the MySQL server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 mysqld on

To verify the setup use

# chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Now, the MySQL server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
# chkconfig mysqld off

Again, to verify the setup use

# chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Basic configuration of MySQL

MySQL delivers several example configuration files in its packages. At least four different flavours of the server configuration are available. These additional configuration files are located in the folder /usr/share/mysql and are named: v my-small.cnf v my-medium.cnf v my-large.cnf v my-huge.cnf The MySQL documentation offers additional information on which configuration file to choose for a given scenario. For example, the my-small.cnf file can be used
Chapter 2. Setup of Databases

as the configuration for the MySQL server. The following steps should be processed to activate the predefined configuration:
# cp /usr/share/mysql/my-small.cnf /etc/my.cnf # chown root:root /etc/my.cnf # chmod 644 /etc/my.cnf

One of the first issues when dealing with any common resource is to ensure its security. At the beginning the password for the database superuser is set properly by running the following commands:
# mysqladmin -u root password <new-password> # mysqladmin -u root -h 127.0.0.1 password <new-password> # mysqladmin -u root -h <your_host_name> password <new-password>

or by using the MySQL console:

# mysql -u root mysql> SET PASSWORD FOR root@localhost = PASSWORD(<new_password>); mysql> SET PASSWORD FOR [email protected] = PASSWORD(<new_password>); mysql> SET PASSWORD FOR root@<your_host_name> = PASSWORD(<new_password>); mysql> quit

Note: As this is the superuser for all databases, use a strong password The second recommended security measure is to remove anonymous accounts from the server. Access is granted only to those users specifically enabled.
# mysql -u root -p mysql> DELETE FROM mysql.user WHERE User = ; mysql> FLUSH PRIVILEGES; mysql> SELECT Host, User FROM mysql.user; mysql> quit

To get the list of users which have database access privileges, run the following command:
# mysql -u root -p mysql> select user,host from mysql.user; +------+----------------------------------+ | user | host | +------+----------------------------------+ | root | 127.0.0.1 | | root | localhost | | root | machine.example.com | +------+----------------------------------+ mysql> quit

Note: Applications connecting to the MySQL servers databases should use an account with minimum privileges required for its actions. This helps to prevent malicious code from accessing other databases and data. The configuration shown in this chapter does not cover all security aspects of MySQL. For more detailed information, refer to the MySQL documentation.

Setup of PostgreSQL
PostgreSQL is an advanced object-relational database management system.

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Numerous features such as stored procedures, functions and triggers are included. All of these are blocks of code to be executed by the server and can be written in SQL or some compatible languages like C, C++, Java, PHP, Perl, Python, Ruby, etc. PostgreSQL provides a MVCC (Multi-Version Concurrency Control), eliminating read locks efficiently, different rules to rewrite incoming queries, etc. These features are very advanced, and very similar to the ones offered by commercial alternatives. Detailed information about PostgreSQL and the supported functionality is available at http://www.postgres.org

Installation of PostgreSQL
PostgreSQL has been included in various Linux distributions for some time. The installation process is straight forward. The database server can be installed by running the following command:
# yum install postgresql postgresql-server

Next to the PostgreSQL server, the client which is required to maintain the databases is installed also. To access the PostgreSQL database from a Web application, a client for the related programming language is required. For the programming languages mentioned in this document, different client implementations are available. The setup of these clients are described in the section where the setup of the programming languages is described.

Verifying the PostgreSQL installation

Checking whether the PostgreSQL package has been installed is done in the same way as with other servers. To retrieve the version of PostgreSQL the following command is performed:
# postgres -V postgres (PostgreSQL) 8.1.11

The output should look similar to the above.

Lifecycle of PostgreSQL
Once these basic PostgreSQL packages are installed, lifecycle operations can be performed like starting/stopping the server. In the following, a walkthrough is shown for the PostgreSQL server. This walkthrough assumes that this is the initial startup right after the packages have been installed. 1. Verifying the current status of the server To get the current status of the PostgreSQL server, run the following command:
# service postgresql status postmaster is stopped

This indicates that the PostgreSQL server is not started. 2. Starting the server for the first time To start the PostgreSQL server, run the following command

Chapter 2. Setup of Databases

# service postgresql start Initializing database: Starting postgresql service:

[ OK ] [ OK ]

The output displays an initialization step which indicates that the PostgreSQL server has been started for the first time. After the startup is completed, verify the status of the PostgreSQL server by running:
# service postgresql status postmaster (pid 18586 18585 18584 18582 18577) is running...

As shown, the PostgreSQL server is running as expected. Note that the PIDs vary after each startup. 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the PostgreSQL server, run the following command:
# service postgresql restart Stopping postgresql service: Starting postgresql service: [ [ OK OK ] ]

Once the restart completes, verify the status of the PostgreSQL server by running:
# service postgresql status postmaster (pid 18792 18791 18790 18788 18786) is running...

As expected, the PostgreSQL server is running again. Note that the PIDs vary after each restart. 4. Stopping the server To stop the PostgreSQL server, run the following command:
# service postgresql stop Stopping postgresql service: [ OK ]

Again, the status can be verified by running:

# service postgresql status postmaster is stopped

As expected, the PostgreSQL server is not running anymore. To start the PostgreSQL server at boot time, the command chkconfig is used. Decide first in which runlevel the PostgreSQL server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 postgresql on

To verify the setup use

10

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

# chkconfig --list postgresql postgresql 0:off 1:off

2:off

3:on

4:off

5:on

6:off

Now, the PostgreSQL server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
# chkconfig postgresql off

Again, to verify the setup use

# chkconfig --list postgresql postgresql 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Basic configuration of PostgreSQL

PostgreSQL does not allow remote connections by default. To enable remote connections a parameter needs to be set in the file /etc/sysconfig/pgsql/ postgresql. This file governs optional PostgreSQL startup parameters and needs to be created if it does not already exist on the system. In the file find the reference to PGOPTS or create one if it does not exist. This should be changed to set the -i parameter at startup. The example below shows an extract of the file with PGOPTS set to -i:
# Enabled remote access for PostgreSQL PGOPTS="-i"

Run the following command to restart the PostgreSQL server:

# service postgresql restart

The client authentication is controlled by a configuration file, which traditionally is named pg_hba.conf. This file is stored in the database folder /var/lib/pgsql/data. One possible scenario is to allow connections from local and from a specific subnet. The following example shows how this works for the subnet 192.168.12.0/24. Local users can connect only to their own databases (databases with the same name as their database user name), administrators can connect to all databases and client connections from a subnet of 192.168.12.x can connect to the databases db1 and db2. For all users, authentication is required.
# TYPE local local host DATABASE sameuser all db1,db2 USER all @admins all CIDR-ADDRESS METHOD md5 md5 md5

192.168.12.0/24

The configuration shown in this chapter does not cover all security aspects of PostgreSQL. For more detailed information, refer to the PostgreSQL documentation.

Chapter 2. Setup of Databases

11

12

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 3. Setup of Apache HTTP Server

The Apache HTTP Server, also known as Apache, is a secure, reliable and efficient Web server. It is highly configurable and extensible with lots of third party modules and Apache is available for a wide variety of operating systems including Linux, UNIX, Mac OS X, Microsoft Windows and several others. Apache became the Web server component of the popular software solution stack called LAMP. Extending this concept, the Apache HTTP Server is a key component of the defined Web 2.0 stack also. The Apache HTTP server is well documented. A good reference is the Apache Web page at http://httpd.apache.org

Installation of Apache HTTP Server

Apache is one of the key components of the World Wide Web, and is included in Red Hat Enterprise Linux 5 Update 2. The installation is performed using the following command:
# yum install httpd httpd-manual

This installs the Apache HTTP server with some documentation and an example page.

Verification of the Apache HTTP Server installation

To verify the installation of Apache, run the following command:
# apachectl -v Server version: Apache/2.2.3 Server built: Jan 11 2008 08:20:49

The output should look similar to the above. To connect with a Web browser to the Apache HTTP server, the server needs to be started. Use the following command to start the server:
# service httpd start

Open a Web browser and enter the URL http://localhost. A default Web page gets displayed indicating that the Apache HTTP server is running properly.

Lifecycle of Apache HTTP Server

Once these basic Apache HTTP server packages are installed, lifecycle actions can be performed like starting/stopping the server. In the following, a walkthrough is shown for the Apache HTTP server. This walkthrough assumes that this is the initial startup right after the packages have been installed and the server is not running. 1. Verifying the current status of the server
Copyright IBM Corp. 2008

13

To get the current status of the Apache HTTP server, run the following command:
# service httpd status httpd is stopped

This indicates that the Apache HTTP server is not started. 2. Starting the server for the first time To start the Apache HTTP server, run the following command
# service httpd start Starting httpd: [ OK ]

After the startup is completed, verify the status of the Apache HTTP server by running:
# service httpd status httpd (pid 8608 8607 8606 8605 8604 8602 8601 8600 8599) is running...

As shown, the Apache HTTP server is running as expected. Note that the PIDs vary after each startup. 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the Apache HTTP server, run the following command:
# service httpd restart Stopping httpd: Starting httpd: [ [ OK OK ] ]

Once the restart completes, verify the status of the Apache HTTP server by running:
# service httpd status httpd (pid 8666 8665 8664 8663 8662 8661 8660 8659 8657) is running...

As expected, the Apache HTTP server is running again. Note that the PIDs vary after each startup. 4. Stopping the server To stop the Apache HTTP server, run the following command:
# service httpd stop Stopping httpd: [ OK ]

Again, the status can be verified by running:

# service httpd status httpd is stopped

As expected, the Apache HTTP server is not running anymore.

14

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

To start the Apache HTTP server at boot time, the command chkconfig is used. Decide first in which runlevel the Apache HTTP server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 httpd on

To verify the setup use

# chkconfig --list httpd httpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Now, the Apache HTTP server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
# chkconfig httpd off

Again, to verify the setup use

# chkconfig --list httpd httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Overview of Apache HTTP server modules

The Apache server modules are software elements which extend Apaches functionality. There are modules available to add server-side programming language support, authentication schemes and a lot of additional functionality. By default, the Apache HTTP server has already some modules loaded, statically and dynamically. To display the list of configured modules, run the following command:
# apachectl -t -D DUMP_MODULES

During the installation of Apache HTTP server extensions additional modules are installed, but those might not be enabled. To enable or disable a module, configuration files have to be modified. In general those configuration files are the /etc/httpd/conf/httpd.conf and files located in the folder /etc/httpd/conf.d/.

Adding support for PHP

One of the general purposes for the development of PHP was to create a scripting language which suites Web development requirements perfectly. For this reason, PHP is supported in most Web server environments running on various operating systems. The extendible approach for PHP allows to install additional functionality which a Web application can make use of, like clients for databases. Further information about PHP and additional libraries is available at http://php.net

Chapter 3. Setup of Apache HTTP Server

15

Installation of mod_php
The Apache HTTP server can be enhanced by installing the package php. This is processed by using the following command:
# yum install php

Apart from the php package other dependent packages such as php-common are installed if they are not available on the system. The installation of the php package enabled the Apache HTTP server to server PHP pages. To activate the PHP support, restart the Apache HTTP server
# service httpd restart

During the installation process of PHP, one additional configuration file is created in the Apache server configuration folder. This file is located at /etc/httpd/conf.d/php.conf and includes a definition for the module to configure the interpreter to do its work when a PHP page is requested.

Creation of a PHP 'Hello World!' Web example

To check whether PHP is working correctly within Apache, create a file named /var/www/html/test.php with the following content:
<html> <head> <title>Hello, World! - PHP</title> </head> <body> <?php print 'Hello, World!<br>'; print 'The time on the server is '; print strftime('%H:%M:%S'); ?> </body> </html>

This newly created PHP script can be accessed by opening up a Web browser at http://localhost/test.php. A Web page is shown which displays 'Hello World!' along with the current time.

Database connectors for PHP

As an example for additional libraries, PHP provides database connectors to the MySQL and PostgreSQL databases. These can be installed using the following command:
# yum install php-mysql php-pgsql

These two PHP extensions can be installed separately also.

Adding support for Perl

One of the most popular scripting languages is Perl. In general, Perl is based on other programming languages such as C, shell scripting (sh), AWK and Lisp. This enables users to make use of a very powerful text manipulation engine.

16

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Another benefit is the amount of additional modules which are available for Perl. These modules add ease of use and interoperability with other tools or software components to the portfolio of the basic Perl functionality. Further information about Perl is available at http://www.perl.org.

Installation of mod_perl
mod_perl is an Apache enhancement which integrates the Perl interpreter into the Apache HTTP server. One benefit of the integration from Perl with Apache is that the startup time for any HTTP request for a Web page returned by a Perl script is reduced. The Perl scripts are compiled once and rerun every time a request occurs. To install the Perl module for Apache, run the following command:
# yum install mod_perl

Apart from the mod_perl package other dependent packages such as the core Perl package are installed if they are not available on the system. The installation of mod_perl integrates the configuration file /etc/httpd/conf.d/ perl.conf into the Apache HTTP setup. This file includes the setup for the Perl interpreter which is not enabled by default. Therefore, remove the leading # characters for the following configuration entries:
Alias /perl /var/www/perl <Directory /var/www/perl> SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI </Directory>

To enable the Perl support in the Apache HTTP server, restart the Apache server by running:
# service httpd restart

To get more information about the setup of mod_perl, refer to the documentation at http://perl.apache.org

Creation of a Perl 'Hello World!' example

Based on the previously explained configuration, setup a 'Hello World!' example. Therefore create a file named /var/www/perl/hello.pl with the following content:
#!/usr/bin/perl # Hello.pl print "Content-type: text/html\n\n"; print "<html>"; print "<head><title>Hello World! - Perl</title></head>"; print "<body>Hello, World!<br>"; ($sec,$min,$hr) = localtime(); print "The time on the server is $hr:$min:$sec"; print "</body></html>";

Chapter 3. Setup of Apache HTTP Server

17

Once the file is created, open up a Web browser on the system where the Web server is running and use the following URL: v http://localhost/perl/hello.pl

Database connectors for Perl

As an example for additional libraries, Perl provides database connectors to the MySQL and PostgreSQL databases. Install the connectors by running the following command:
# yum install perl-DBI perl-DBD-MySQL perl-DBD-Pg

For Perl, the generic database interface needs to be installed to be able to use the MySQL or PostgreSQL interfaces of Perl. The MySQL and PostgreSQL interfaces can be installed separately also.

Installing additional Perl modules using CPAN

Web applications might require additional Perl modules to be installed, which are not part of Red Hat Enterprise Linux 5 Update 2. For this case the CPAN interactive shell can be used to add the missing module to the system in a comfortable way. At the first time, CPAN runs through an initialization process. This process analyzes the system and offers default settings which work for most environments. To install e.g. the Perl-CGI-Session library with CPAN, perform as follows:
# perl -MCPAN -e shell cpan> install CGI::Session ... cpan> quit

This installs the perl-CGI-Session module which is now ready to use.

Adding support for Python

Python is another popular scripting language. Some key characteristics are that the language is very easy to learn and the code is required to be well structured which eases up the maintenance. Support for Python is available on most of the platforms, including Linux, Unix, Mac OS X, Windows, OS/2, etc. Further information about Python is available at http://www.python.org.

Installation of mod_python
The Apache HTTP server can easily be equipped to support Python. The required packages are all included in Red Hat Enterprise Linux 5 Update 2. To install the Python module for Apache, run the following command:
# yum install mod_python

Apart from the mod_python package other dependent packages such as the core Python package are installed if they are not available on the system.

18

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

The installation of mod_python integrates the configuration file /etc/httpd/conf.d/python.conf into the Apache setup. This file includes the setup for the interpreter to run Python scripts in specific folders. By default none of the folders are enabled to serve Python scripts. The configuration file offers configurations for the Publisher and the PSP handlers which need to be enabled. Using the Publisher handler To enable the Publisher handler, open the /etc/httpd/conf.d/python.conf file and remove the leading # character for the following configuration:
<Location /python> SetHandler python-program PythonHandler mod_python.publisher </Location>

This configuration enables the folder /var/www/python to deliver Python scripts using the Publisher handler. Using the PSP handler To enable the Python Server Pages handler, open the /etc/httpd/conf.d/ python.conf file and remove the leading # character for the following configuration:
<Directory /var/www/html> AddHandler mod_python .psp PythonHandler mod_python.psp </Directory>

This configuration enables the folder /var/www/html and all subfolders to deliver PSP files using the PSP handler. To enable the Python support in Apache restart the Apache HTTP server:
# service httpd restart

To get more information about mod_python, refer to the documentation at http://www.modpython.org

Creation of a Python 'Hello World!' example

For the two Python specific handlers separate 'Hello, World!' examples need to be created. The environment for the examples is based on the configuration described above. For the Publisher handler example, create a file named /var/www/html/python/ index.py with the following content:
from mod_python import apache import time def index(req): req.content_type = 'text/html' req.write('<html>') req.write('<head><title>Hello, World! - Python</title></head>') req.write('<body>Hello, World!<br>') req.write('The time on the server is ') req.write(str(time.strftime("%H:%M:%S"))) req.write('</body></html>')

Chapter 3. Setup of Apache HTTP Server

19

The PSP handler is slightly different since it allows embedding Python code into HTML code. A file named /var/www/html/hello.psp is created with the following content:
<html> <head> <title>Hello, World! - Python PSP</title> </head> <body> <% import time %> Hello, World!<br> The time on the server is <%=time.strftime("%H:%M:%S")%> </body> </html>

To give the two 'Hello, World!' examples a try, open a Web browser on the machine where the Web server is running and have a look at the result of the following two URLs: The Publisher handler 'Hello, World!' v http://localhost/python v http://localhost/python/index v http://localhost/python/index/index The PSP handler 'Hello, World!' http://localhost/hello.psp

Database connectors for Python

As an example for additional libraries, Python provides database connectors to the MySQL and PostgreSQL databases. These can be installed using the following command:
# yum install MySQL-python postgresql-python

These two Python extensions can be installed separately also.

Adding support for Ruby

Ruby is a object-oriented programming language. The language gained large popularity boost in 2004 when the Web application framework Ruby on Rails was released. Additionally, implementations for virtual machines also became very popular. Such implementations are for example JRuby for the Java virtual machine or IronRuby for the .NET framework. Interpreters for Ruby are available for Windows, Mac OS X, Linux and several other operating systems. To get more information about Ruby, refer to the project Web page at http://ruby-lang.org.

Installation of mod_ruby
mod_ruby enables the execution of Ruby scripts by the Apache HTTP server. It embeds the Ruby interpreter to run the scripts natively in the Apache HTTP server. The mod_ruby package is not part of Red Hat Enterprise Linux 5 Update 2. To enable the Apache HTTP server with native Ruby support, a tarball needs to be

20

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

downloaded from the Internet at http://www.modruby.net/en/index.rbx/ mod_ruby/download.html. During time of writing the stable version of mod_ruby was 1.2.6. Prior to compiling mod_ruby some dependencies need to be resolved. Install the Ruby interpreter and the Apache Portable Runtime libraries along with the related development packages by using the following command:
# yum install apr-devel apr apr-util-devel apr-util httpd-devel ruby-devel ruby

To install mod_ruby perform the following steps:

# # # # # tar xzf mod_ruby-1.2.6.tar.gz cd mod_ruby-1.2.6/ ./configure.rb --with-apr-includes=/usr/include/apr-1 make make install

The 'make install' step integrates mod_ruby into the Apache HTTP server infrastructure. During this step the configuration for mod_ruby is not enabled and needs to be done manually. A file which includes the configuration needs to be created in the Apache HTTP server environment. Create the file /etc/httpd/conf.d/ruby.conf with the following content:
LoadModule ruby_module modules/mod_ruby.so <IfModule mod_ruby.c> RubyRequire apache/ruby-run <Location /ruby> SetHandler ruby-object RubyHandler Apache::RubyRun.instance Options +ExecCGI </Location> <Files *.rbx> SetHandler ruby-object RubyHandler Apache::RubyRun.instance </Files> </IfModule>

To enable the configuration for mod_ruby, use the following command:

# service httpd restart

Installation of eRuby
eRuby allows embedding of Ruby code into HTML files similar to other approaches like ASP, JSP or PSP. To install eRuby support for Apache HTTP server use the following command:
# yum install eruby eruby-libs ruby ruby-devel

In the previous section, mod_ruby was setup to serve Ruby CGI scripts. To setup eRuby, the configuration file /etc/httpd/conf.d/eruby.conf is created with the following content:

Chapter 3. Setup of Apache HTTP Server

21

AddType application/x-httpd-eruby .rhtml Action application/x-httpd-eruby "/cgi-bin/eruby"

This requires adding the eRuby executable to the /cgi-bin directory. A symbolic link is created by using
# ln -s $(which eruby) /var/www/cgi-bin/eruby

Once this symbolic link is in place, the folder cgi-bin needs to be allowed to follow symbolic links. In the file /etc/httpd/conf/httpd.conf append the '+FollowSymLinks' value to the Options attribute of the <Directory "/var/www/cgi-bin"> entry. This new functionality is activated once the Apache HTTP server is restarted. Use the following command to restart the server:
# service httpd restart

Note: SELinux might reject the execution of eRuby because of the symbolic link. One possible solution is to disable SELinux for the Apache HTTP server. In many environments, disabling SELinux is not acceptable; therefore refer to the documentation at http://www.nsa.gov/selinux/ on how to setup SELinux properly.

Creation of a Ruby CGI 'Hello World!' example

Based on the previously explained environment, setup a 'Hello World!' example for CGI Ruby. Create a folder named /var/www/html/ruby:
# mkdir /var/www/html/ruby

In this folder, create a file named /var/www/html/ruby/hello.rbx with the following content:
require "cgi" cgi = CGI.new("html4") cgi.out { cgi.html { cgi.head { cgi.title {"Hello, World! - Ruby"} } + cgi.body { "Hello, World! <br>" + Time.now.strftime("The time on the server is %H:%M:%S") } } }

This file requires the executable flag to be set

# chmod +x /var/www/html/ruby/hello.rbx

The Web page is reached by a locally started Web browser at the URL http://localhost/ruby/hello.rbx

22

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Creation of a Ruby Server Page 'Hello World!' example

Based on the previously explained environment, setup a 'Hello World!' example for eRuby. Create a file named /var/www/html/hello.rhtml with the following content:
<html> <head> <title>Hello, World! - eRuby</title> </head> <body> <%= "Hello, World!" %><br> <%= Time.now.strftime("The time on the server is %H:%M:%S") %> </body> </html>

The Web page is reached by a locally started Web browser at the URL http://localhost/hello.rhtml

Database connectors for Ruby

As an example for additional libraries, Ruby provides database connectors to the MySQL and PostgreSQL databases. These are not available on the Red Hat Enterprise Linux 5 Update 2 images but Fedora EPEL provides source RPM packages which can be rebuild and installed by using the following procedure:
# > # # # > # # wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/ruby-mysql-2.7.3-1.el5.src.rpm rpmbuild --rebuild ruby-mysql-2.7.3-1.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/s390x/ruby-mysql-2.7.3-1.s390x.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/ruby-postgres-0.7.1-5.el5.src.rpm rpmbuild --rebuild ruby-postgres-0.7.1-5.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/s390x/ruby-postgres-0.7.1-5.s390x.rpm

The MySQL and PostgreSQL interfaces can be installed separately also.

Installing additional Ruby libraries using RubyGems

RubyGems is a packaging system for Ruby, similar to the CPAN tool of Perl. RubyGems allows the installation of additional Ruby libraries from a dedicated server. This is a very useful mechanism to increase the functionality of the Ruby installation if a package is missing in the distribution. RubyGems is not available on the Red Hat Enterprise Linux 5 Update 2 images. It can be downloaded from Fedora EPEL at http://download.fedora.redhat.com/ pub/epel/5/SRPMS/rubygems-0.9.4-1.el5.src.rpm. Prior to compiling RubyGems some dependencies need to be resolved. These dependent packages are available on the Red Hat Enterprise Linux 5 Update 2 images:
# yum install ruby-rdoc ruby-irb

To build and install RubyGems, perform the following steps:

# > # # wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygems-0.9.4-1.el5.src.rpm rpmbuild --rebuild rubygems-0.9.4-1.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/s390x/rubygems-0.9.41.el5.rpm

Chapter 3. Setup of Apache HTTP Server

23

Once RubyGems is installed on the system it can be used to enhance the Ruby installation with additional libraries such as tzinfo:
# gem install tzinfo --remote

This installs the Ruby tzinfo package.

Setup of Ruby on Rails

Ruby on Rails is a ruby-based framework for developing Web applications. It emphasizes convention over configuration, is following the MVC (Model-View-Controller) pattern, making Web development faster and more efficient and Web applications easier to maintain. To get more information on Rails refer to the project Web page at http://rubyonrails.org.

Installation of Ruby on Rails

Ruby on Rails is not available from the Red Hat Enterprise Linux 5 Update 2 images. It can be downloaded from Fedora EPEL at http:// download.fedora.redhat.com/pub/epel/5/SRPMS/. Other dependent packages such as rubygem-rake are available on Fedora EPEL also. Download and install Rails by performing the following steps:
# > # # # > # # # > # # # > # # # > # # # > # # # > # # wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-rake-0.7.3-2.el5.src.rpm rpmbuild --rebuild rubygem-rake-0.7.3-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-rake-0.7.3-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-activesupport-2.0.2-1.el5.src.rpm rpmbuild --rebuild rubygem-activesupport-2.0.2-1.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-activesupport-2.0.2-1.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-actionpack-2.0.2-2.el5.src.rpm rpmbuild --rebuild rubygem-actionpack-2.0.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-actionpack-2.0.2-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-actionmailer-2.0.2-2.el5.src.rpm rpmbuild --rebuild rubygem-actionmailer-2.0.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-actionmailer-2.0.2-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-activerecord-2.0.2-2.el5.src.rpm rpmbuild --rebuild rubygem-activerecord-2.0.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-activerecord-2.0.2-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-activeresource-2.0.2-2.el5.src.rpm rpmbuild --rebuild rubygem-activeresource-2.0.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-activeresource-2.0.2-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-rails-2.0.2-2.el5.src.rpm rpmbuild --rebuild rubygem-rails-2.0.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-rails-2.0.2-2.noarch.rpm

Verifying the Ruby on Rails installation: Check the version number by running the following command:
# rails -v Rails 2.0.2

24

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

The output should look similar to the above.

Creation of a Ruby on Rails example

One way to run a Rails application in a production environment is to start the default Ruby application server on port 80. This approach - while being sufficient for a small installation - has the drawback of the default HTTP port now being bound exclusively to one single Rails application. The following example session shows how to create and run a Rails application.
# service httpd stop # cd /var/www/html # rails www.rubytest.example.com .... # cd www.rubytest.example.com # RAILS_ENV=production ruby script/server -p 80

To verify the Rails example, start a Web browser on the machine where the Rails application server is running and direct to the URL http://localhost. A 'Welcome aboard' screen comes up with some information how to proceed further activities on the Web application.

Deployment of Ruby on Rails applications

By default, the Rails application server is bound exclusively to a single port. This indicates that, if a Rails application is bound to port 80, the Apache HTTP server is not able to make use of this port anymore. A number of deployment options have been established to address this issue, including: running the Web application as a FastCGI process, using JRuby to deploy to a Java application server or forwarding requests from Apache or another Web server to a Ruby application server like Mongrel. The latter method is used in the configuration example given below: requests are forwarded by the Apache HTTP server to a single Mongrel backend server using mod_proxy. For further information about Mongrel visit the project Web site at http://mongrel.rubyforge.org The Mongrel Web server package is not available on the Red Hat Enterprise Linux 5 Update 2 images. Fedora EPEL offers source packages which have to be rebuilt for Linux on System z. Use the following steps to download and install the Mongrel server:
# > # # # > # # # > # # # > # # wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-daemons-1.0.7-2.el5.src.rpm rpmbuild --rebuild rubygem-daemons-1.0.7-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-daemons-1.0.7-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-fastthread-1.0-1.el5.src.rpm rpmbuild --rebuild rubygem-fastthread-1.0-1.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/s390x/rubygem-fastthread-1.0-1.s390x.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-gem_plugin-0.2.2-2.el5.src.rpm rpmbuild --rebuild rubygem-gem_plugin-0.2.2-2.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/noarch/rubygem-gem_plugin-0.2.2-2.noarch.rpm wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/rubygem-mongrel-1.0.1-6.el5.src.rpm rpmbuild --rebuild rubygem-mongrel-1.0.1-6.el5.src.rpm rpm -ivh /usr/src/redhat/RPMS/s390x/rubygem-mongrel-1.0.1-6.s390x.rpm

Chapter 3. Setup of Apache HTTP Server

25

Then, the configuration for the Apache HTTP needs to be modified. Add a new virtual host by modifying the /etc/httpd/conf/httpd.conf to include the following content2:
ProxyRequests off <VirtualHost *:80> ServerName www.rubytest.example.com ProxyPass / http://127.0.0.1:8000/ ProxyPassReverse / http://127.0.0.1:8000 ProxyPreserveHost on </VirtualHost>

Additionally, the Apache HTTP server needs to be setup to map requests for the new server name to the new virtual host. Therefore, the NameVirtualHost attribute needs to be configured in the file /etc/httpd/conf/httpd.conf. Since this is dependent on the individual Network setup, refer to the documentation of Apache HTTP server. Start the rails application in production mode on port 8000 by executing the following commands:
# cd /var/www/html/www.rubytest.example.com # mongrel_rails start -d -p 8000 -e production

Note: When multiple Ruby on Rails Web applications are intended to run simultaneously on the same system, each Web application must be assigned to a unique port number. Therefore the configuration of the virtual host given in the rubytest.conf file needs to be duplicated with another ServerName. Additionally the ports of the ProxyPass and ProxyPassReverse attributes have to match the port specified during startup of the Web application. Finally, restart Apache:
# service httpd restart

Make sure the application is running by opening http://localhost in a browser. The default Welcome aboard page should now appear.

2. This configuration is taken from http://mongrel.rubyforge.org/wiki/Apache where additional information is available about the integration of Mongrel into Apache

26

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 4. Setup of Apache Tomcat

Apache Tomcat is a Servlet container which is compliant with the official specifications for the Java Servlet and JavaServer Pages technologies, providing an environment for Java code to run in cooperation with a Web server. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. The two Java Specification Requests, JSR53 and JSR154 specify the Servlet API and the Java ServerPages API. Further information about Apache Tomcat is available at the project Web page http://tomcat.apache.org.

Installation of Apache Tomcat

Apache Tomcat is a Web server which supports the JSP and Servlet standards. Java needs to be installed as a prerequisite to the Apache Tomcat server. In this document Java 1.5.0 from IBM is used. This is included on the supplementary image of Red Hat Enterprise Linux 5 Update 2. Install the Java packages by using the following command:
# yum install java-1.5.0-ibm java-1.5.0-ibm-devel jpackage-utils

Verifying the Java installation

Confirm that Java has been installed successfully by running the following command:
# java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxz64dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxi6423-20080315 ... J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314

The output should look similar to the above. Note: If the output reports a different version of Java, but the 1.5.0 version has been installed, it might be the case that the version 1.5.0 is not set to be the one used by the system. The tool alternatives is used to switch the Java version used by the system. Use 'alternatives --config java' to select the right Java version. Once the correct Java version has been installed, install Apache Tomcat by running:
# yum install tomcat5 tomcat5-admin-webapps tomcat5-webapps

This installs the Apache Tomcat server and some administrative Web applications which allow some basic configuration of the Apache Tomcat server. Additionally, several example Web applications for Apache Tomcat are installed.

Copyright IBM Corp. 2008

27

Verifying the Apache Tomcat installation

To verify if the Apache Tomcat server is working properly, the server itself needs to be started. Therefore, run the following command:
# service tomcat5 start

Open a Web browser on the server where the Apache Tomcat server is running and open the URL http://localhost:8080. The default Apache Tomcat Web page is shown which offers some examples, documentation and administration pages.

Important folders in Apache Tomcat

There is an environment variable with special importance, $CATALINA_HOME. This environment variable is defined in /etc/tomcat5/tomcat5.conf and points to the root of the Apache Tomcat server installation the default is /usr/share/tomcat5. These are some of the key Apache Tomcat folders, all relative to $CATALINA_HOME: v $CATALINA_HOME/bin - Startup, shutdown, and other scripts. v $CATALINA_HOME/conf - Configuration files and related DTDs. The most important file is the server.xml which is the main configuration file for Apache Tomcat. v $CATALINA_HOME/logs - Default location of log files. v $CATALINA_HOME/webapps - This is where additional Web applications are installed. Important folders for storing library files are: v $CATALINA_HOME/common/lib - Library files used by Apache Tomcat and Web applications. v $CATALINA_HOME/shared/lib - Library files used across Web applications only.

Lifecycle of Apache Tomcat

Once these basic Apache Tomcat server packages are installed, lifecycle actions can be performed like starting/stopping the server. In the following, a walkthrough is shown for the Apache Tomcat server. This walkthrough assumes that this is the initial startup right after the packages have been installed and the server is not running. 1. Verifying the current status of the server To get the current status of the Apache Tomcat server, run the following command:
# service tomcat5 status /etc/init.d/tomcat5 is stopped

This indicates that the Apache Tomcat server is not started. 2. Starting the server To start the Apache Tomcat server, run the following command
# service tomcat5 start Starting tomcat5: [ OK ]

28

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

After the startup is completed, verify the status of the Apache Tomcat server by running:
# service tomcat5 status /etc/init.d/tomcat5 is already running (13847)

As shown, the Apache Tomcat server is running as expected. Note that the PID varies after each startup. 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the Apache Tomcat server, run the following command:
# service tomcat5 restart Stopping tomcat5: Starting tomcat5: [ [ OK OK ] ]

Once the restart completes, verify the status of the Apache Tomcat server by running:
# service tomcat5 status /etc/init.d/tomcat5 is already running (14661)

As expected, the Apache Tomcat server is running again. Note that the PID varies after each restart. 4. Stopping the server To stop the Apache Tomcat server, run the following command:
# service tomcat5 stop Stopping tomcat5: [ OK ]

Again, the status can be verified by running:

# service tomcat5 status /etc/init.d/tomcat5 is stopped

As expected, the Apache Tomcat server is not running anymore. To start the Apache Tomcat server at boot time, the command chkconfig is used. Decide first in which runlevel the Apache Tomcat server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 tomcat5 on

To verify the setup use

# chkconfig --list tomcat5 tomcat5 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Now, the Apache Tomcat server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
Chapter 4. Setup of Apache Tomcat

29

# chkconfig tomcat5 off

Again, to verify the setup use

# chkconfig --list tomcat5 tomcat5 0:off 1:off 2:off 3:off 4:off 5:off 6:off

The Apache Tomcat administration tools

Two main administration tools are included in the package tomcat5-adminwebapps called admin and manager. The admin tool is used to configure the Apache Tomcat server itself. It provides functionality for user, group and role management. Additionally the debug level can be modified for an application or the whole server. The manager tool provides functionality for the Web application lifecycle. Web applications can be deployed, started, stopped and Web application specific options can be modified. By default, user access to these tools is not configured and has to be granted manually. The installation of Apache Tomcat includes a file called /etc/tomcat5/tomcat-users.xml which is used to assign roles to groups or users. For example, the user tomcat is assigned to the roles tomcat, admin and manager. Another user admin is assigned to the role admin and the user manager to the role manager. Such a setup is shown in the following:
<?xml version=1.0 encoding=utf-8?> <tomcat-users> <role rolename="tomcat"/> <role rolename="admin"/> <role rolename="manager"/> <user username="tomcat" password="tomcat1" roles="tomcat,admin,manager"/> <user username="admin" password="tomcat2" roles="admin"/> <user username="manager" password="tomcat3" roles="manager"/> </tomcat-users>

Afterwards the two administration applications can be accessed by using the URL http://localhost:8080/admin and http://localhost:8080/manager/html.

Adding support for JSP and Servlet API Installation of JSP and Servlet API libraries
The Apache Tomcat installation requires the JSP and Servlet libraries. Therefore an installation of additional packages is not required. In general the JSP implementation classes and the JSP Standard Tag Library are included in the following packages: v tomcat5-jsp-2.0-api v tomcat5-servlet-2.4-api The content of these packages is included into the Apache Tomcat environment during their installation.

30

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Creation of a JSP 'Hello World!' example

The verification of the JSP installation is a bit more complex than the other verification processes. First, create a folder where the JSP file is stored. This example uses the folder named /usr/share/tomcat5/webapps/sample-jsp:
# mkdir /usr/share/tomcat5/webapps/sample-jsp

Once this folder is created, create a file named /usr/share/tomcat5/webapps/ sample-jsp/hello.jsp which contains:
<%@page import="java.util.Date" %> <%@page import="java.text.DateFormat" %> <DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html> <head> <title>Hello, World! - JSP</title> </head> <body> <% String hwStr = "Hello World!\n"; %> <% String timeStr = "The time on the server is "; %> <% DateFormat currentTime = DateFormat.getTimeInstance(DateFormat.FULL); %> <%= hwStr %><br> <%= timeStr + currentTime.format(new Date()) %> </body> </html>

As well as the JSP file, create a folder which includes information about the Web application:
# mkdir /usr/share/tomcat5/webapps/sample-jsp/WEB-INF

This folder includes one additional file - web.xml - which can define various settings for the Web application. To keep this example simple it only includes the application name. The file /usr/share/tomcat5/webapps/sample-jsp/WEB-INF/ web.xml needs to be created with the following content:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/dtd/web-app_2_2.dtd"> <web-app> <display-name>JSP - Hello, World!</display-name> </web-app>

To complete the setup the new Web application needs to be deployed into the Apache Tomcat server. This is done by using the manager application. In the page at http://localhost:8080/manager/html, the application stored in the path sample-jsp needs to be started. Once the application is running, it can be accessed at http://localhost:8080/sample-jsp/hello.jsp. Note: Depending on the setup of Apache Tomcat the Web application example might be auto-deployed. In this case, the Web application is activated once the Apache Tomcat server is restarted.

Chapter 4. Setup of Apache Tomcat

31

Creation of a Servlet 'Hello World!' example

The verification of the Servlet follows the same procedure as the JSP example. First, create a folder where the Servlet and related filers are stored. This example uses the folder named /usr/share/tomcat5/webapps/sample-servlet.
# # # # mkdir mkdir mkdir mkdir /usr/share/tomcat5/webapps/sample-servlet /usr/share/tomcat5/webapps/sample-servlet/WEB-INF /usr/share/tomcat5/webapps/sample-servlet/WEB-INF/classes /usr/share/tomcat5/webapps/sample-servlet/WEB-INF/classes/sample

The Servlet file is named /usr/share/tomcat5/webapps/sample-servlet/WEBINF/classes/sample/HelloWorldServlet.java and includes the following content:
package sample; import java.io.*; import java.util.Date; import java.text.*; import javax.servlet.http.*; import javax.servlet.*; public class HelloWorldServlet extends HttpServlet { public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); out.println("<html>"); out.println("<head><title>Hello, World! - Servlet</title></head>"); out.println("<body>"); out.println("Hello, World!<br>"); DateFormat currentTime = DateFormat.getTimeInstance(DateFormat.FULL); out.println("The time on the server is " + currentTime.format(new Date())); out.println("</body></html>"); out.close(); } }

This Java source file needs to be compiled by using the following commands:
# cd /usr/share/tomcat5/webapps/sample-servlet/WEB-INF/classes # javac -cp /usr/share/java/tomcat5-servlet-2.4-api.jar sample/HelloWorldServlet.java

In the folder /usr/share/tomcat5/webapps/sample-servlet/WEB-INF, a web.xml file needs to be created with the following content:

32

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/dtd/web-app_2_2.dtd"> <web-app> <display-name>Servlet - Hello, World!</display-name> <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>sample.HelloWorldServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>hello-servlet</url-pattern> </servlet-mapping> </web-app>

To complete the setup, the new Web application needs to be deployed into the Apache Tomcat server. This is done by using the manager application. In the page at http://localhost:8080/manager/html, the application stored in the path sample-servlet needs to be started. Once the application is running, it can be accessed at http://localhost:8080/sample-servlet/hello-servlet. Note: Dependent on the setup of Apache Tomcat, the Web application example might be auto-deployed. In this case, the Web application is activated once the Apache Tomcat server is restarted.

Adding Database connectors

Web applications which are deployed into the Apache Tomcat server may need to connect to databases. This section explains how to add database connectors for MySQL and PostgreSQL into the Apache Tomcat environment.

Setup of MySQL connector

The MySQL JDBC driver which is called 'MySQL Connector/J' is not included in Red Hat Enterprise Linux 5 Update 2. An archive is available at the MySQL development download page http://dev.mysql.com/downloads/connector/j/ 5.1.html . To allow system-wide access to the MySQL Connector/J, the JAR file included in the archive needs to be integrated into the Java system environment. This file needs to be copied into the /usr/share/java folder which is a well known folder for Java libraries, created during the installation of Java and JPackage. The following example shows how to setup the connector for system-wide usage:
# # # # # # tar zxf mysql-connector-java-5.1.6.tar.gz cd mysql-connector-java-5.1.6 cp mysql-connector-java-5.1.6-bin.jar /usr/share/java/ cd /usr/share/java chmod 644 mysql-connector-java-5.1.6-bin.jar ln -s mysql-connector-java-5.1.6-bin.jar mysql-connector-java.jar

Note: Version 5.1.5 is used in the examples throughout this document To integrate MySQL Connector/J integrated into the Apache Tomcat environment, create a link from the JAR file into the folder $CATALINA_HOME/common/lib of the Apache Tomcat server. Create the link as follows:
Chapter 4. Setup of Apache Tomcat

33

# ln -s /usr/share/java/mysql-connector-java.jar /usr/share/tomcat5/common/lib/

The JDBC driver is available for usage after a restart of the Apache Tomcat server has been performed.
# service tomcat5 restart

Setup of PostgreSQL connector

The PostgreSQL JDBC driver is included in Red Hat Enterprise Linux 5 Update 2 and can be installed using the following command:
# yum install postgresql-jdbc

The installed package includes different versions of the JDBC driver for PostgreSQL. The different versions belong to the different version of the Java installation. This document is based on Java 1.5.0 which requires making use of the JDBC3 driver for PostgreSQL. To add this specific JDBC driver to the Apache Tomcat configuration, a link from the JDBC driver into the folder $CATALINA_HOME/common/lib of the Apache Tomcat server needs to be created. Create the link as follows:
# ln -s /usr/share/java/postgresql-jdbc3.jar /usr/share/tomcat5/common/lib/

The JDBC driver is available for usage after restarting the Apache Tomcat server.
# service tomcat5 restart

34

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 5. Setup of Caches

Setup of Squid
Squid is a caching proxy for the Web supporting various protocols like HTTP, HTTPS, FTP and more. It is mainly used for two different purposes, Web caching reducing bandwidth and response times on the client side, and speeding up the delivery of Web elements by caching frequently-repeated requests on the server side. Nevertheless, it fits perfectly with roles such as proxying Secure Sockets Layer (SSL) requests and caching of Domain Name Server (DNS) lookups, and perform transparent caching. Squid also supports a wide variety of caching protocols, such as Internet Cache Protocol, (ICP) the Hyper Text Caching Protocol, (HTCP) the Cache Array Routing Protocol (CARP), and the Web Cache Coordination Protocol (WCCP). Squid has extensive granular access control mechanisms and allows monitoring of critical parameters via the Simple Network Management Protocol (SNMP). To get more information on Squid refer to the documentation at http://www.squid-cache.org

Installation of Squid
The Squid server is also part of Red Hat Enterprise Linux 5 Update 2. Use the following command to install the package:
# yum install squid

Note: The Squid server requires the network setup to provide a fully qualified domain name (FQDN). Review /etc/hosts to make sure that a FQDN is provided.

Verification of the Squid installation

To verify the installation of Squid, use the following command:
# squid -v Squid Cache: Version 2.6.STABLE6 (...)

The output in this document shows the version number. From the output of the command, several configuration parameters and values are displayed also.

Lifecycle of Squid
Once these basic Squid server packages are installed, lifecycle actions can be performed like starting/stopping the server. In the following, a walkthrough is shown for the Squid server. This walkthrough assumes that this is the initial startup right after the packages have been installed. 1. Verifying the current status of the server To get the current status of the Squid server, run the following command:

Copyright IBM Corp. 2008

35

# service squid status squid is stopped squid: ERROR: No running copy

This indicates that the Squid server setup is not complete. The initialization has not taken place yet. 2. Starting the server for the first time To start the Squid server, run the following command
# service squid start init_cache_dir /var/spool/squid... Starting squid: . [ OK ]

The output displays an initialization steps which indicate that the Squid server has been started for the first time. After the startup is completed, verify the status of the Squid server by running:
# service squid status squid (pid 25404) is running...

As shown, the Squid server is running as expected. Note that the PID varies after each startup. 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the Squid server, run the following command:
# service squid restart Stopping squid: . Starting squid: . [ [ OK OK ] ]

Once the restart completes, verify the status of the Squid server by running:
# service squid status squid (pid 25478) is running...

As expected, the Squid server is running again. Note that the PID varies after each restart. 4. Stopping the server To stop the Squid server, run the following command:
# service squid stop Stopping squid: . [ OK ]

Again, the status can be verified by running:

# service squid status squid is stopped squid: ERROR: No running copy

As expected, the Squid server is not running anymore.

36

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

To start the Squid server at boot time, the command chkconfig is used. Decide first in which runlevel the Squid server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 squid on

To verify the setup use

# chkconfig --list squid squid 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Now, the Squid server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
# chkconfig squid off

Again, to verify the setup use

# chkconfig --list squid squid 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Basic configuration of Squid

In Red Hat Enterprise Linux 5 Update 2 a version of Squid 2.6 is included. The Web page of Squid includes a lot of documentation for this version. Examples for possible configurations are included in the documentation which is available at http://www.squid-cache.org/Versions/v2/2.6/cfgman. To cover all the configuration scenarios is beyond the scope of this whitepaper. As an example for a Squid configuration, the setup for a reverse proxy is given. Refer to the documentation for additional information.

Configuring the Squid server as a reverse proxy

Reverse proxy cache, also known as Web server acceleration, is a method of reducing the load on a busy Web server by using a Web cache between the server and the Internet. Another benefit is improved security. Additionally it is one of many ways to improve the scalability without increasing the maintenance of the server too much. A good use case of a reverse proxy is to reduce the workload on a Web server that provides both static and dynamic content. The static content can be cached on the reverse proxy while the Web server is freed up to better handle the dynamic content. In the scenario where the Web server is running on a different machine, the configuration of the Squid server in /etc/squid/squid.conf looks like the following:
http_port 80 accel defaultsite=<your.main.page> cache_peer <your_webservers_ip> parent 80 0 no-query originserver

If the Web server runs on the same machine as the Squid server is running, the Web server must be re-configured to listen on a different IP address, e.g. the loopback address. The configuration of /etc/squid/squid.conf needs to be modified to allow Squid to listen on the Web servers IP address.
Chapter 5. Setup of Caches

37

http_port <your_webservers_ip>:80 accel defaultsite=<your.main.page> cache_peer 127.0.0.1 parent 80 0 no-query originserver

Setup of memcached
Memcached is a distributed memory system for caching purposes. In general it is used to speed up communication between a Web application and a database. The result is to reduce response time for highly frequented Web pages and lesser load of the database server. There are several client APIs available to access the memcached server. All of the programming languages described in this book, Java, PHP, Perl, Python and Ruby, are supported with a memcached client API. There are various public Web sites which make use of memcached such as SourceForge, Wikipedia, YouTube, Facebook and many others. More information is available on the memcached project Web page at http://www.danga.com/memcached.

Installation of memcached
Memcached is not part of Red Hat Enterprise Linux 5 Update 2 itself. At the moment, the Fedora EPEL project includes a package for memcached. At the time of writing this the available version is 1.2.3. To build a package for Linux on System z the source RPM needs to be rebuilt. The procedure to get a binary RPM in place is the following:
# # > # yum install libevent-devel rpm-build wget -c\ http://download.fedora.redhat.com/pub/epel/5/SRPMS/memcached-1.2.3-7.el5.src.rpm rpmbuild --rebuild memcached-1.2.3-7.el5.src.rpm

To install memcached, run the following command:

# rpm -ivh /usr/src/redhat/RPMS/s390x/memcached-1.2.3-7.el5.s390x.rpm

Verification of the memcached installation

To verify the installation of memcached run the following command:
# memcached -h memcached 1.2.3 (...)

Note that the version is displayed in the first line of output, followed by a list of available options.

Lifecycle of memcached
Once the memcached server package is installed, lifecycle actions can be performed like starting/stopping the server. In the following, a walkthrough is shown for the memcached server. This walkthrough assumes that this is the initial startup right after the packages have been installed. 1. Verifying the current status of the server To get the current status of the memcached server, run the following command:

38

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

# service memcached status memcached is stopped

This indicates that the memcached server setup is not complete. The initialization has not taken place yet. 2. Starting the server for the first time To start the memcached server, run the following command
# service memcached start Starting memcached: [ OK ]

The output displays an initialization steps which indicate that the memcached server has been started for the first time. After the startup is completed, verify the status of the memcached server by running:
# service memcached status memcached (pid 8012) is running...

As shown, the memcached server is running as expected. Note that the PID varies after each startup. 3. Restarting the server Another useful functionality is the restart where it is possible to stop and start the server with one single command. To restart the memcached server, run the following command:
# service memcached restart Stopping memcached: Starting memcached: [ [ OK OK ] ]

Once the restart completes, verify the status of the memcached server by running:
# service memcached status memcached (pid 8078) is running...

As expected, the memcached server is running again. Note that the PID varies after each restart. 4. Stopping the server To stop the memcached server, run the following command:
# service memcached stop Stopping memcached: [ OK ]

Again, the status can be verified by running:

# service memcached status memcached is stopped

As expected, the memcached server is not running anymore.

Chapter 5. Setup of Caches

39

To start the memcached server at boot time, the command chkconfig is used. Decide first in which runlevel the memcached server should start. Runlevels are used to coordinate the startup of services during boot time. In the following example, the runlevels 3 and 5 are used as both support networking:
# chkconfig --level 35 memcached on

To verify the setup use

# chkconfig --list memcached memcached 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Now, the memcached server starts during boot time of runlevels 3 and 5. To deactivate this behavior again, run:
# chkconfig memcached off

Again, to verify the setup use

# chkconfig --list memcached memcached 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Basic configuration of memcached

The memcached package includes a configuration file named /etc/sysconfig/ memcached. This file is used to change the server settings. Following, the default values of the configuration file are shown:
PORT="11211" USER="nobody" MAXCONN="1024" CACHESIZE="64" OPTIONS=""

These settings define to run memcached as user nobody at port 11211. At most 1024 connections are allowed and the cache size is limited to 64MB. The OPTIONS variable is used to pass additional parameter to the memcached. Refer to the documentation to get more information.

40

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Chapter 6. Setup of AJAX support

Web 2.0 applications are getting more flexible and more dynamic due to the enablement of functionalities like "Asynchronous JavaScript and XML" (AJAX) or "Drag and Drop". Several frameworks have been created to offer a set of these functionality in a bundled package. The Dojo toolkit is one of the most popular frameworks which offers a lot of support to the developer of Web 2.0 applications.

Installation of the Dojo Toolkit

The installation of the Dojo toolkit is easy to handle. Right now there are no RPM packages available, but a tarball is available from the Dojo project Web site at http://dojotoolkit.org. Extract the tarball and move the extracted files into a folder where the Web server has access to. The example below shows how to extract the tarball and move the content into the folder /var/www/html.
# tar xzf dojo-release-1.1.1.tar.gz # mv dojo-release-1.1.1 /var/www/html

Example for using Dojo

This section shows how to create an example which displays the current time, updated every second. The Apache HTTP server needs to be setup to support PHP and Dojo as previously described. PHP scripts need to have the executable flag set. To give an example, two files need to be created. The first, time.html, should be placed in the /var/www/html folder. It should include the following source code:

Copyright IBM Corp. 2008

41

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Dojo example: AJAX clock</title> <script type="text/javascript" src="dojo-release-1.1.1/dojo/dojo.js" djConfig="parseOnLoad: true"></script> <style type="text/css"> @import "dojo-release-1.1.1/dijit/themes/tundra/tundra.css"; @import "dojo-release-1.1.1/dojo/resources/dojo.css"; </style> <style type="text/css"> #error, #main { margin: auto; margin-top: 120px; text-align: center } #error { font-size: 120%; } #main input,button { font-size: 400%; width: 250px }

</style> <script type="text/javascript"> dojo.require("dojo.parser"); dojo.require("dojox.timing"); dojo.require("dijit.form.TextBox"); dojo.require("dijit.form.Button"); var timer; var startClock = function() { timer.start(); } var stopClock = function() { timer.stop(); } var getCurrentTime = function() { console.debug("Timer ticked: Requesting time from server") // Performs the AJAX request to the URL specified; // After the request is sent and the response is received, // the load event is triggered, which in turn sets the new // value of the clock widget. dojo.xhrGet( { url: "http://localhost/time.php", handleAs: "text", timeout: 4000, load: function(response) { dojo.byId("error").innerHTML = ""; dijit.byId("clock").setValue(response); }, error: function(response) { dojo.byId("error").innerHTML = response; } } ); }

42

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

dojo.addOnLoad(function() { // Create a new timer that fires a tick every second timer = new dojox.timing.Timer(1000); // Every tick will lead to updating the text box with the current //time value from the server timer.onTick = getCurrentTime; dojo.connect(dojo.byId("clock-start"), onclick, startClock); dojo.connect(dojo.byId("clock-stop"), onclick, stopClock); }); </script> </head> <body class="tundra"> <div id="error"></div> <div id="main"> <input id="clock" dojoType="dijit.form.TextBox" style="" value="" /><br/> <button id="clock-start" dojoType="dijit.form.Button">Start the clock</button><br/> <button id="clock-stop" dojoType="dijit.form.Button">Stop the clock</button> </div> </body>

The second file, time.php, is stored in the /var/www/html folder also. It should include the following source code:
<?php // Returns the server time as HH:MM:SS echo (date ("H").":".date("i").":".date("s")); ?>

To run the example, a Web browser needs to be opened on the machine where the Web server is running and pointed to the URL http://localhost/time.html

Chapter 6. Setup of AJAX support

43

44

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Appendix. Packages for the Web 2.0 stack

The following table includes an overview of all packages used in this document
Table 2. Package overview of Web 2.0 stack in Red Hat Enterprise Linux 5 Update 2 Component MySQL Package Name mysql mysql-server Version 5.0.45-7 5.0.45-7 Source RHEL5 U2 RHEL5 U2

PostgreSQL

postgresql postgresql-server

8.1.11-1 8.1.11-1

RHEL5 U2 RHEL5 U2

Apache HTTP server

httpd httpd-manual httpd-devel mod_perl mod_python php (includes mod_php) mod_ruby

2.2.3-11 2.2.3-11 2.2.3-11 2.0.2-6.3 3.2.8-3.1 5.1.6-20 1.2.6

RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2 Internet Download at http:// www.modruby.net/ en/index.rbx/ mod_ruby/ download.html RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2

apr apr-devel apr-util apr-util-devel

1.2.7-11 1.2.7-11 1.2.7-11 1.2.7-11

Apache Tomcat

tomcat5 tomcat5-webapps tomcat5-adminwebapps tomcat5-jsp-2.0-api tomcat5-servlet-2.4api

5.5.23-0 5.5.23-0 5.5.23-0 5.5.23-0 5.5.23-0

RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2

PHP

php-mysql php-pgsql

5.1.6-20 5.1.6-20

RHEL5 U2 RHEL5 U2

Perl

perl-DBI perl-DBD-Mysql

1.52-1 3.0007-1

RHEL5 U2 RHEL5 U2

Copyright IBM Corp. 2008

45

Table 2. Package overview of Web 2.0 stack in Red Hat Enterprise Linux 5 Update 2 (continued) Component Package Name perl-DBD-Pg Version 1.49-1 Source RHEL5 U2

Python

MySQL-python postgresql-python

1.2.1-1 8.1.11-1

RHEL5 U2 RHEL5 U2

Java

java-1.5.0-ibm java-1.5.0-ibm-devel jpackage-utils mysql-connector-java

1.5.0.7-1 1.5.0.7-1 1.7.3-1 5.1.6

RHEL5 U2 supplementary RHEL5 U2 supplementary RHEL5 U2 Internet Download at http:// dev.mysql.com/ downloads/ connector/j/5.1.html RHEL5 U2

postgresql-jdbc

8.0.1-407

Ruby

ruby ruby-devel ruby-rdoc ruby-irb rubygems rubygem-rake rubygem-rails rubygemactivesupport rubygem-actionpack rubygemactionmailer

1.8.5-5 1.8.5-5 1.8.5-5 1.8.5-5 0.9.4-1 0.7.3-2 2.0.2-2 2.0.2-2 2.0.2-2 2.0.2-2

RHEL5 U2 RHEL5 U2 RHEL5 U2 RHEL5 U2 Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL Download from Fedora EPEL

rubygem-activerecord 2.0.2-2 rubygemactiveresource rubygem-daemons rubygem-fastthread 2.0.2-2 1.0.7-2 1.0-1

rubygem-gem_plugin 0.2.2-2 rubygem-mongrel 1.0.1-6

46

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Table 2. Package overview of Web 2.0 stack in Red Hat Enterprise Linux 5 Update 2 (continued) Component Package Name eruby eruby-libs eruby-devel ruby-mysql ruby-postgres Version 1.0.5-1 1.0.5-1 1.0.5-1 2.7.3-1 0.7.1-5 Source RHEL5 U2 RHEL5 U2 RHEL5 U2 Download from Fedora EPEL Download from Fedora EPEL

Squid

squid

2.6.STABLE6-5

RHEL5 U2

memcached

memcached

1.2.37

Download from Fedora EPEL

Dojo

dojo-release

1.1.1

Internet Download at http:// dojotoolkit.org/ downloads

Appendix. Packages for the Web 2.0 stack

47

48

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the

Copyright IBM Corp. 2008

49

names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBMs application programming interfaces.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: developerWorks, HiperSockets, IBM, OS/2, System z, z/VM The following terms are trademarks of other companies: Java, JavaScript, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.

50

Setting up a Web 2.0 stack on RHEL5.2 (August 2008)