Install and configure an enterprise-level Web server

IBM HTTP Server is a great starting point for your Web infrastructure

Learn how Web servers are used in modern enterprise environments and how to install and integrate IBM® HTTP Server. This tutorial explains why IBM HTTP Server, a key component of IBM WebSphere® Application Server, is also an excellent choice as a stand-alone Web server because of its standard configuration and seamless upgrade path for evolving enterprise Web environments.

William von Hagen, Systems Administrator, Writer , WordSmiths

William von Hagen has been a UNIX systems administrator for more than 20 years and a Linux advocate since 1993. Bill is the author or co-author of books on subjects such as Ubuntu Linux, Xen Virtualization, the GNU Compiler Collection (GCC), SuSE Linux, Mac OS X, Linux file systems, and SGML. He has also written numerous articles for Linux and Mac OS X publications and Web sites. You can reach Bill at wvh@vonhagen.org.



04 November 2008

Also available in Chinese

Before you start

Learn what to expect from this tutorial and how to get the most out of it.

About this tutorial

Web servers are the cornerstone of the Web architectures used in enterprise computing today. This tutorial provides an overview of today's Web architectures and explains how to install IBM HTTP Server and integrate it into your system's startup process. IBM HTTP Server is a commercially supported Web server that is based on the popular open source Apache Web Server and serves as the core of IBM WebSphere Application Server. After completing this tutorial, you will understand several common Web server configuration scenarios and will have a completely functional Web server.

Objectives

This tutorial provides:

  • A review of Web servers and common Web architectures.
  • An understanding of the software and hardware requirements of IBM HTTP Server.
  • Instructions for installing IBM HTTP Server on various platforms.
  • Details on how to integrate IBM HTTP Server into the system-startup process and how to start and stop the server.

Prerequisites

This tutorial is written for beginning- to intermediate-level systems administrators who may never have installed or configured a Web server and who may be unfamiliar with modern Web server architectures. To complete the examples in this tutorial, you should have a general familiarity with UNIX® command-line shells and text editors.

System requirements

To run the examples in this tutorial, you need administrative (root) privileges on a Linux® system on which no Web server is currently installed. At least 450MB of disk space must be available on the system: A minimum of 200MB must be permanently available in the file system that contains the /opt/ directory, and 250MB more must be temporarily available in the file system from which you install IBM HTTP Server. The system should have a minimum of 512MB of RAM.


Web servers and architectures

Today's enterprise Web environments are much more sophisticated than the simple content-delivery model of a few years ago. Evolving Web software technologies and increasing connectivity between Web servers and other data resources continue to revolutionize what users can do from the Internet and the services that businesses can offer over the Web.

Traditional Web servers

Originally, Web servers delivered static data from Hypertext Markup Language (HTML) files and associated images that were local to the Web server. This system was fine for content that was equally static and is still an important part of many Web sites today.

Unfortunately, a limited amount of content is either static in nature or permanently stored in text files that a Web server can access. This is inherently true of business-related content such as customer information, inventory and pricing information, product data sheets, and other frequently changing information that is stored in a data source other than the Web server's content directory—typically, in an external resource such as a database.

The 2-tier architecture

The need to access dynamic content that is stored in external data sources led to the development of the 2-tier Web architecture. In the 2-tier model, a Web server has direct access to other data resources (such as a database). These resources are typically stored on the same system on which the Web server is running but can also be stored on another system to which the Web application has direct access over a network.

A 2-tier Web application is a standard client-server system in which direct communication between a Web server and an external data source is facilitated by data-interface protocols such as Common Gateway Interface (CGI) and Web scripting languages such as Cold Fusion, Java™ servlets, JavaServer Pages™ (JSP), Microsoft® Active Server Pages (ASP), and PHP. All the connection and business logic for the Web application and associated data sources is encoded in the Web application, and the Web application directly accesses the data that it requires, regardless of whether it is stored locally or remotely.

A 2-tier application is well suited to many interactive Web sites and Web applications, delivering high performance through tight coupling of Web application code and the data sources that an application accesses. Local database access is often faster than remote database access, because network latency is not an issue.

On the downside, 2-tier applications can be inefficient when handling a large number of requests or maintaining state information about large numbers of Web clients. Using databases and other data sources that are local to the Web server makes replication and backups difficult and also increases the load on the Web server. Similarly, the need to store the database or database access information on the machine on which the Web server is running can introduce security problems if that system is penetrated and compromised.

The 3-tier architecture

To access remote data sources, the 3-tier architecture uses middleware known as an application server. The application server can be running on the system on which the Web server is running or on another system. The Web server acts as an intermediary between Web clients and the application server, just as the application server acts as an intermediary between application logic and remote data requirements.

The 3-tier architecture can provide several advantages over 2-tier applications:

  • Improved performance for high-traffic Web servers, because the data that Web applications access is stored on other systems. Not running database (or other data) servers on the same system as the Web or application server reduces the load on those systems. Similarly, administrative tasks such as backups of remote databases, content-management systems (CMS), and other data sources do not affect the performance of the Web or application server.
  • Better server and data resource management through scalability. Web and application servers can easily be replicated for load balancing purposes. The 3-tier architecture can increase Web application availability by implementing automatic failover among multiple Web and application servers. Connections to remote resources can be managed intelligently.
  • Increased security for remote data, because it is always stored on a system other than the one on which the Web server—and typically the application server—is running. Penetrating and compromising a Web server does not directly expose your data.

See the Resources for links to popular 3-tier application servers.

Stand-alone versus multi-tier architectures

Stand-alone Web servers are fine for Web sites on which the content being delivered is also static. The 2-tier architecture supports Web applications with dynamic data-access requirements, can be very fast, and can be simple to administer and debug, because Web applications interact directly with the data they use. The 3-tier architecture supports high-volume Web applications by dividing work among multiple machines and provides increased data security and centralized management.

The 2-tier and 3-tier architectures are generically referred to as multi-tier architectures, because the content being delivered to Web clients comes from multiple data sources, using more than one piece of software.


IBM HTTP Server 6.1

The key to any Web application is a Web server, regardless of whether it runs that application directly or provides access to an application server. Apache Web Server is the best-known platform-independent Web server available today, but as an open source application, it is not commercially supported by its authors. IBM HTTP Server is a free, Apache-based Web server that provides the best of both the open source and commercial worlds for several reasons:

  • It uses the same configuration syntax as Apache, if you want to administer it by directly modifying its configuration files.
  • Commercial support is available through IBM, reducing the chance that configuration or software problems will render your enterprise Web site unavailable.
  • It is tested with and used by IBM WebSphere servers. Adopting IBM HTTP Server as your initial Web server simplifies upgrading your Web environment to the 3-tier Web architecture as the Web-facing requirements of your business grow over time.

Additional capabilities

IBM HTTP Server version 6.1 is based on Apache Web Server version 2.0.47. In addition to the core capabilities that Apache version provides, IBM HTTP Server provides the following features and capabilities:

  • A graphical, Java-based installer
  • Full internationalization
  • A Fast Response Cache Accelerator (FRCA) that improves performance when delivering static content (only available on IBM AIX® and some Microsoft Windows® platforms)
  • A FastCGI plug-in that supports language-independent extensions to CGI, increasing performance and providing persistent application support
  • Integration with WebSphere software that enables you to use the WebSphere administrative console to configure and manage your Web server graphically

Supported platforms

This tutorial discusses installing and configuring IBM HTTP Server 6.1. Version 6.1 is available for and supported on the following operating systems and associated hardware:

  • AIX
  • HP-UX on IA64 and HP-UX PA-RISC
  • Linux (32 bit)
  • Linux for IBM System i™, System p™, and System z™
  • Sun Solaris and Solaris 10 on x86-64
  • Microsoft Windows 2000, Windows Server® 2003, and Microsoft Windows XP

IBM HTTP Server is officially supported on the 32-bit versions of Red Flag DC 5.0 SP1; Red Hat Enterprise Linux versions 3, 4, and 5; and SuSE Enterprise Server version 10 Linux distributions, but you should be able to install it cleanly on any Red Hat Package Manager (RPM)-based Linux distribution. IBM HTTP Server is officially supported on the 64-bit versions of Red Hat Enterprise Linux versions 3, 4, and 5 as well as SuSE Enterprise Server version 9 and 10. This tutorial provides tips to enable you to install and run IBM HTTP Server on other Linux distributions.

Note: You can run the 32-bit Linux versions of IBM HTTP Server on a 64-bit Linux system as long as you have installed the 32-bit Intel® architecture compatibility libraries (the ia32-libs package) on that system.

Downloading IBM HTTP Server

IBM HTTP Server is available as a free download and can be used as a personal or commercial Web server at no charge. See Resources for a link to an archive file for IBM HTTP Server.


Installing IBM HTTP Server

Thanks to its graphical installer, installing IBM HTTP Server is quite simple. See the section, "Before you start," to review the basic requirements for this tutorial.

Extract the downloaded file

After downloading the archive file containing IBM HTTP Server, change to the directory in which the downloaded file resides. The name of the downloaded file differs depending on the platform you're using. On UNIX or UNIX-like systems, the name of the file is ihs.610.os.architecture.tar, where os is the name of your operating system and architecture is the hardware architecture for which the download of IBM HTTP Server was built. For example, on a Linux system, the name of the downloaded file will be ihs.6100.linux.ia32.tar.

Note: No 64-bit Linux version seems to be available for download. See the section, "Supported platforms," for information about how to use the 32-bit Linux build on a 64-bit Linux system.

Extract the contents of the archive file using the command:

tar xvf ihs.6100.linux.ia32.tar

on a UNIX or Linux system, or use a ZIP-compatible utility to extract the contents of the downloaded archive on a Windows system. The result is an IHS_6.1.0.0 directory that contains three subdirectories:

  • GSKit: The Global Security Kit (GSKit) is a required component for Secure Sockets Layer (SSL) enablement within the Web server. You must install this package if you want IBM HTTP Server to support SSL.
  • IHS: This directory contains the installer and archive file for IBM HTTP Server.
  • JDK: The Java software development kit (JDK) infrastructure that the installer uses.

Start the installer

Change to the IHS directory that was created during the extraction. Depending on your platform, perform one of the following tasks:

  • On UNIX and Linux systems that enable you to assume the identity of the root user, use the su command to become the root user on the system. Then, execute the ./install command to begin the installation process.
  • On Linux systems that use the sudo command to execute commands as the root user, execute the sudo ./install command to begin the installation process.
  • On Windows systems, double-click install.exe to begin the installation process.

The graphical installer for IBM HTTP Server displays its welcome page, shown in Figure 1.

Figure 1. The installer's welcome page
The Installer's welcome page

The welcome page shows that the graphical installer is working correctly and provides a link to the IBM HTTP Server Installation Guide located in the file InstallGuide_en.html. This file resides in the IHS/docs, which was extracted from the archive file.

Note: If you're installing IBM HTTP Server on a Linux system, the installation guide won't display correctly from this link unless the Konqueror Web browser is installed on your system. You can resolve this problem by creating a symbolic link—/usr/bin/konqueror—that points to your browser of choice, such as /usr/bin/firefox. Clicking links in the installer then opens the associated documents in Mozilla Firefox.

Click Next to proceed with the installation process.

Resolving problems starting the installer

The JDK that's included with the IBM HTTP Server installation package doesn't work correctly on Debian and Ubuntu Linux systems. On these and related Linux distributions, you must install a working JDK or Java Runtime Environment (JRE), then execute the following command as the root user or through the sudo command to run the Java-based installer manually:

java -cp `pwd`/setup.jar -Xms48m -Xmx384m run

Note: The punctuation around the pwd command must be backwards single quotation marks, not single quotation marks.

Accept the license terms and check your system

The next page of the graphical installer displays the license under which IBM HTTP Server is released, as shown in Figure 2.

Figure 2. Accepting the IBM and excluded component licenses
Accepting license terms

This license contains IBM licensing information and language that excludes open source components of IBM HTTP Server from those terms. Excluded software in IBM HTTP Server includes Apache HTTP Server version 2.0.47, Apache Portable Runtime version 0.9, the zLib compression library version 1.1.4, FAST CGI version 2.4.0, and OpenSSL version 0.9.7c.

Select I accept both the IBM and the non-IBM terms to accept the licensing terms. Click Next to proceed with the installation process. If you did not accept the license terms, a window appears asking you to confirm that fact. If you confirm that you do not accept the license terms, the installer exits.

The next page of the installer either indicates whether your system satisfies the prerequisites for installation. If your system does not satisfy requirements, the installer may display information about any missing patches that you should install. In this case, you can either click Cancel to exit the installer and install the missing prerequisites or simply proceed with the installation.

Click Next to proceed with the installation process.

Supply installation and configuration information

Next, the graphical installer displays the default location in which IBM HTTP Server will be installed—/opt/IBM/HTTPServer on UNIX and Linux systems and C:\Program Files\IBM\HTTPServer on Windows systems. Figure 3 shows this page.

Figure 3. Specifying the installation location
Specifying the installation directory

Note: Changing this location is not recommended, because some internal components of IBM HTTP Server have been compiled to expect this location.

Click Next to proceed with the installation process. The page shown in Figure 4 appears. Here, you can specify the ports on which IBM HTTP Server and its administrative interface listen.

Figure 4. Ports for the HTTP and administration servers
Specifying HTTP and administration ports

Unless you have a specific reason for specifying other ports, accept the default port values by clicking Next to proceed with the installation process.

Configure a Windows service (Windows only)

Note: if you are not installing IBM HTTP Server on a Windows system, proceed to "Specify a user for server administration."

If you're installing IBM HTTP Server on a Windows system, you must specify a Windows service to start IBM HTTP Server and IBM HTTP Administration, as shown in Figure 5.

Figure 5. Defining IBM HTTP Server as a Windows service
Defining a Windows service

On this page, you can configure that service to start these servers automatically when you start your system. You can use a local system account or a user account with sufficient privileges to start the servers.

After supplying this information, click Next to proceed with the installation process.

Specify a user for server administration

The next page of the installer enables you to create a user account on your system for administration from the WebSphere Application Server administrative console, shown in Figure 6.

Figure 6. Defining an administrative user
Defining an administrative user

If you're not planning to use WebSphere Application Server, you can clear the Create a User ID for IBM HTTP administration server authentication check box. However, creating this user will not cause any problems on your system and will be convenient if you subsequently upgrade to WebSphere Application Server.

Note: The IBM HTTP Server administration interface can only be contacted from the WebSphere Application Server administrative console. It cannot be contacted from a standard Web browser.

After supplying information about the administrative user, click Next to proceed with the installation process.

Configure HTTP administration (UNIX and Linux only)

Note: Proceed to "Summary page and actual installation" if you aren't installing IBM HTTP Server on a UNIX or Linux system.

If you're installing IBM HTTP Server on a UNIX or Linux system, you must specify a user and group allowed to administer IBM HTTP Server. Figure 7 shows this configuration page.

Figure 7. Configuring the IBM HTTP administration server
Configuring the IBM HTTP administration server

This page enables you to change the ownership and modes of the files in the IBM HTTP Server directories to enable administration by that user or members of that group. You can skip this step by clearing the Setup IBM HTTP administration server to administer IBM HTTP Server check box.

After identifying a user and group for server administration, click Next to proceed with the installation process.

Summary page and actual installation

A summary page displays the configuration options that you have accepted or specified. Click Next to begin the installation process. A window appears, displaying the status of the installation process. The installation process first creates an uninstaller for IBM HTTP Server to simplify removing the software, if necessary. It then installs IBM HTTP Server, displaying status information as the installation proceeds.

When the installation finishes, a window displays the success or failure of installation. If any errors occurred, this window shows the location of a log file that you can examine to identify the problems and determine whether they were meaningful.

Click Finish to exit the installer. Congratulations: You've installed IBM HTTP Server.

The only remaining tasks are to install the IBM GSKit (if you want to support SSL access to the server) and to start IBM HTTP Server (and, optionally, the IBM HTTP administration server, if you are also running WebSphere Application Server).

Install the Global Security Kit

The GSKit is a required component for SSL enablement within the Web server. You must install this package if you want IBM HTTP Server to support SSL. To install GSKit, perform the following steps:

  1. Change to the GSKit directory that was created when you extracted the contents of the IBM HTTP Server archive file.

    How you install GSKit depends on the platform on which you have installed IBM HTTP Server and are now installing GSKit:

    • On a Windows system, double-click the Setup utility icon.
    • On UNIX and Linux systems that enable you to assume the identity of the root user, use the su command to become the root user on the system, and execute the ./gskit.sh command to begin the installation process.
    • On RPM-based Linux systems that use the sudo command to execute commands as the root user, execute the sudo ./gskit.sh command to begin the installation process.

    Note: The Linux version of the gskit.sh script assumes that you are installing GSKit on a system that uses the RPM Package Manager and therefore installs GSKit from an RPM package. You can still install GSKit on non-RPM-based Linux distributions such as Debian or Ubuntu, but doing so requires a bit of extra work, as described in the rest of this section.

  2. Extract a tarball from the RPM package.

    Installing an RPM on a non-RPM-based Linux system requires that you either convert the RPM package to the package format your system uses or that you extract a standard tar-format archive file (known as a tarball) from the RPM package, extract its contents, and manually execute the installation scripts that it contains. You use the latter approach in this section, because you have to modify the installation scripts so that they work correctly.

  3. Install the Alien utility on your non-RPM Linux system to extract the contents of an RPM package.

    You can do this using your Debian or Ubuntu system's aptitude utility:

    • On Debian Linux systems, where the sudo command enables you to assume the identity of the root user, use the su command to become the root user on the system, and execute the aptitude -y install alien command to install the Alien utility and its prerequisites.
    • On Ubuntu Linux systems, where the sudo command is used to execute commands as the root user, execute the sudo aptitude -y install alien command to install the Alien utility.
  4. Extract an archive file in .tar format from the gsk7bas-7.0-3.20.i386.rpm file using the command:
    alien -t -c gsk7bas-7.0-3.20.i386.rpm

    as the root user or using the sudo command. This produces the gsk7bas-7.0.tgz file.

  5. Extract the contents of the tar archive using the command:
    tar zxvf gsk7bas-7.0.tgz

    This command creates a directory named usr and another directory named install, which contains two installation scripts.

  6. Install the GSKit binaries by executing the command:
    mv usr/local/ibm /usr/local

    as the root user or using the sudo command.

  7. Change to the install directory, and execute the ./predelete.sh command as the root user or use the sudo command.
  8. Use a text editor to modify the doinst.sh script.

    The first five lines of the script initially look like Listing 1.

    Listing 1. Lines 1 through 5 of doinst.sh
    #!/bin/sh
    if [ -n "`rpm --version|grep 4.1`" ] 
    then export RPM_INSTALL_PREFIX=/usr/local 
    fi
    SRC=$RPM_INSTALL_PREFIX/ibm/gsk7
    1. Delete the second, third, and fourth lines.
    2. Modify the fifth line, replacing the string $RPM_INSTALL_PREFIX with the string /usr/local.

      The beginning of the doinst.sh script now looks like Listing 2.

      Listing 2. Revised doinst.sh
      #!/bin/sh
      SRC=/usr/local/ibm/gsk7
    3. Save your changes to the script, and exit the text editor.
  9. Execute the ./doint.sh. command as the root user, or use the sudo command.

Starting and stopping IBM HTTP Server

Installing IBM HTTP Server and the GSKit software doesn't start the IBM HTTP Server process on your system. This section explain how to manually start and stop IBM HTTP Server and the optional IBM HTTP administration server as well as how to integrate automatically starting these servers into the boot process for your system.

Note: Before starting IBM HTTP Server on a UNIX or Linux system, you must create the group under which it will run. This group, identified in the IBM HTTP Server's configuration file, is nobody, which you can create with whatever software package you system uses. For example, on a Linux system, you can add the nobody group by executing the addgroup nobody command as the root user or using the sudo command.

Start IBM HTTP Server

Starting IBM HTTP Server involves two utilities. You must use the apachectl utility to start IBM HTTP Server itself, then use the adminctl utility if you're using IBM HTTP application server to administer IBM HTTP Server.

The apachectl utility

The apachectl utility is the standard utility used on UNIX and Linux systems for starting, stopping, and restarting Apache-based Web servers. If you installed IBM HTTP Server in the default location, this utility resides in /opt/IBM/HTTPServer/bin.

To start IBM HTTP Server using the apachectl utility, execute the command:

/opt/IBM/HTTPServer/bin/apachectl start

as the root user, or use the sudo command.

After IBM HTTP Server has started, you can use a browser to connect to your system by its hostname or loopback address to verify that IBM HTTP Server is running. You should see an initial page similar to Figure 8.

Figure 8. The default page of IBM HTTP Server
The default IBM HTTP Server page

The adminctl utility

Note: It is only necessary to start IBM HTTP administration server if you are also using WebSphere Application Server. The IBM HTTP Server administration interface can only be contacted from the WebSphere Application Server administration console, not from a standard Web browser.

The adminctl utility is the standard utility used to start, stop, and restart IBM HTTP administration server. If you installed IBM HTTP Server in the default location, this utility resides in /opt/IBM/HTTPServer/bin.

To start IBM HTTP administration server using the adminctl utility, execute the command:

/opt/IBM/HTTPServer/bin/adminctl start

as the root user, or use the sudo command.

After IBM HTTP administration server has started, you can use the WebSphere Application Server administration console to connect to your system (using port 8008, by default).

System startup integration

After installing a Web server on your system, you typically want it to start automatically any time you restart your system. When installing IBM HTTP Server on a Windows platform, the window shown in Figure 5 enables you to define the server and administration server as Windows services that will be started automatically when your system starts. Unfortunately, the UNIX and Linux installers don't provide any equivalent integration into the startup processes for those systems. Therefore, you must integrate IBM HTTP Server into the startup process on UNIX and Linux systems.

All UNIX and Linux systems use a system mechanism composed of a series of shell scripts that are executed as the system boots. On most UNIX and Linux systems, these scripts are organized in the way specified by the SysVInit (that is, System V Init, which refers to an old version of UNIX) system startup mechanism. In this mechanism, the primary startup scripts for the system all reside in /etc/init.d, and the specific scripts that are executed as the system boots into a specific level of operation (known as a runlevel) are symbolic links from the directories with names of the form /etc/rcrunlevel.d to the scripts in the /etc/init.d directory. Ubuntu Linux systems use a different startup mechanism.

Note: The following sections explain how to integrate the apachectl utility into your system's startup process. If you're using the WebSphere Application Server administration console to administer IBM HTTP Server, you also want to integrate the adminctl utility into your system startup process. You can do this by following the instructions in whichever of the next sections is appropriate for your system but using a different name for the startup script (perhaps ibm-http-admin), using parallel names for the symbolic links to that script, and setting the apachectl variable in the script to /opt/IBM/HTTPServer/bin/adminctl.

Create a SysVInit script

To create a SysVInit script for IBM HTTP Server, you can simply copy an existing script for Apache Web Server and modify it to refer to your IBM HTTP Server installation. To do so, perform the following steps:

  1. Download the sample startup script, then copy the same script shown there into a text editor.
  2. Modify the following lines of that script:
    apachectl=/usr/local/apache/bin/apachectl
    httpd=/usr/local/apache/bin/httpd

    to look like the following:

    apachectl=/opt/IBM/HTTPServer/bin/apachectl
    httpd=/opt/IBM/HTTPServer/bin/httpd
  3. Save this file to your system, and copy it to /etc/init.d as the root user or use the sudo command, giving it a name such as ibm-http.
  4. Make the file executable using the command:
    chmod 755 /etc/init.d/ibm-http

    as the root user or by using sudo.

  5. Create symbolic links to this file from /etc/rc5.d by using the following command:
    ln -s /etc/init.d/ibm-http /etc/rc5.d/S85ibm-http
    ln -s /etc/init.d/ibm-http /etc/rc5.d/K15ibm-http

The next time you shut down your system, the K15ibm-http symbolic link that you created will automatically stop IBM HTTP Server as part of the shutdown process. The next time you start your system, the S85ibm-http symbolic link automatically starts IBM HTTP Server as part of the boot process.

Create a Ubuntu Upstart script

The Ubuntu Linux distribution uses an alternate startup mechanism to the SysVInit mechanism. The Ubuntu startup mechanism is known as Upstart (see Resources) and is a relatively new, event-driven startup mechanism that was created for Ubuntu but is being adopted by other distributions such as Fedora and, therefore, eventually Red Hat and Centos. Upstart is becoming popular largely because of its support for concurrency and responsiveness to system events.

At the moment, Upstart is implemented to be compatible with the traditional SysVInit model. See Downloads for a simple Upstart module that you can put in the /etc/init.d directory on your system and use for IBM HTTP Server.

After downloading this file, perform the following steps:

  1. Save the file to your system, and copy it to /etc/init.d as the root user or by using the sudo command, giving it a name such as ibm-http.
  2. Make the file executable by using the command:
    chmod 755 /etc/init.d/ibm-http

    as the root user or by using the sudo command.

  3. Create symbolic links to this file from /etc/rc5.d directory by using the following command:
    ln -s /etc/init.d/ibm-http /etc/rc2.d/S91ibm-http
    ln -s /etc/init.d/ibm-http /etc/rc2.d/K15ibm-http

The next time you shut down your system, the K15ibm-http symbolic link that you created automatically stops IBM HTTP Server as part of the shutdown process. The next time you start your system, the S91ibm-http symbolic link automatically starts IBM HTTP Server as part of the boot process.


Summary

Conclusion and summary

Congratulations on having installed IBM HTTP Server and integrated it into your system. You're now ready to add content, customize the server's configuration, and so on. Providing the content for your Web server is outside the scope of this tutorial. However, here's some general information that you will find useful when populating and running IBM HTTP Server:

  • The default location for static Web content in IBM HTTP Server is /opt/IBM/HTTPServer/htdocs.
  • The configuration files for IBM HTTP Server reside in /opt/IBM/HTTPServer/conf. The primary server configuration file for IBM HTTP Server is httpd.conf. The primary configuration file for IBM HTTP administration server is admin.conf.
  • If you're having trouble getting the server to display your content, consult the IBM HTTP Server logs for information about any errors that are occurring. These log files reside in /opt/IBM/HTTPServer/logs. The access_log file in this directory contains information about every attempt to access IBM HTTP Server. The error_log file contains information about any errors that occur during access or content requests from IBM HTTP Server.
  • Because IBM HTTP Server is based on Apache Web Server, you can use any information about configuring version 2.0 of Apache Web Server to obtain detailed configuration suggestions and related information.

A Web server is the core of any enterprise Web installation, regardless of the content you're delivering, the type of data you provide access to over the Web, and the architectural tier you're using. As a standard Apache-compliant and well-supported browser that is also a key component of WebSphere Application Server, IBM HTTP Server provides a great starting point for any Web installation.


Download

DescriptionNameSize
Sample Upstart moduleibm-http.zip2KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=348605
ArticleTitle=Install and configure an enterprise-level Web server
publish-date=11042008