Setting up Apache on Unixware by John Pritchard

Setting up Apache to run on Unixware for WebSpeed

Introduction

The following document describes the procedures performed to install and configure Apache on a Unixware 7.1.1 server.

Procedure

Get and Expand the Source Files

Get the latest versions of the following applications. The versions for which this has been tested are listed:

• Patch (2.5) source - http://www.gnu.org/software/patch/patch.html
• EGD (0.8) source - http://www.lothar.com/tech/crypto/
• Openssl (0.9.6-stable-snap) source - ftp://ftp.openssl.org/snapshot/
• Apache (1.3.19) source - http://httpd.apache.org/dist/httpd/
• Apache+SSL (1.42) source - http://www.apache-ssl.org/ - Download

Set up a /usr/local/source subdirectory and copy the .tar files for each of the applications into that directory. Then 'cd' to that subdirectory and untar (tar xvf) each of the applications (except for Apache+SSL). You may then remove the .tar files. Untarring the files will generate subdirectories in the source subdirectory that contain the source files for the applications.

Build and Install patch

Reference Files: README|INSTALL|patch-2.5.tar

The patch command is used by a script called FixPatch to adjust the location of certain files so that the Apache+SSL make utilities will use the appropriate files to build the programs. FixPatch requires a version of patch later than what is normally distributed with the unixware system.

cd /usr/local/source/patch2.5
./configure
make clean
make
make check
make install
 

Build, Install and run EGD

Reference Files: README|egd-0.8.tar

EGD is the Entropy Gathering Daemon. This is a program that gathers a variety of information from the system and generates random information from it. Random numbers are important for the generation of secure certificates and encryption. Apache+SSL requires a special device (/dev/random) or this daemon running. Since that special device is available (standard) on Linux and not Unixware, we need to build and run this daemon. cd /usr/local/source/egd0.8

perl Makefile.PL
make clean
make
make test
make install
 

To run this program you need to enter the following commands:

/usr/gnu/bin/egd.pl /etc/entropy
 

A couple notes: the location where make install installs the egd.pl perl script can vary. The above is where it installed it for me (I just used defaults). A little confusing since the documentation gives other locations. Also, this program is a perl script which has in the first line the location of the perl interpreter. Make sure that the first line of the egd.pl file refers to a program that exists on your system. One more note: this program is required for certificate generation. If you are unable to successfully create a certificate, make sure that this program is running by entering the command 'ps -ef |more' as root and look for the egd process running.

Build and install openssl in /usr/local/ssl (use defaults)

Reference Files: README|INSTALL|openssl-0.9.6-stable-SNAP-20010531.tar

SSL stands for Secure Socket Layer. This application includes the programs that will generate required files to secure a TCP/IP connection and the programs to encrypt and decrypt those communications. The following is a sample of commands I used to create the application:

cd /usr/local/source/openssl-0.9.6-stable-SNAP-20010531
./config
make clean
make
make test
make install
 

Unpack Apache-SSL into a subdirectory of Apache

Reference Files: README|INSTALL|apache_1.3.19+ssl_1.42.tar

You should have already created a subdirectory for Apache when you untarred the package. Move the Apache+SSL tar file into that subdirectory. Here is a sample of commands that did it for me:

cd /usr/local/source
mv apache_1.3.19+ssl_1.42.tar apache_1.3.19
 

Then move to the Apache subdirectory and unpack the Apache+SSL package. Here are sample commands to do so:

cd /usr/local/source/apache_1.3.19
tar xvf apache_1.3.19_ssl_1.42.tar
 

You may then remove the tar file

Run FixPatch script

Reference Files: (see Apache-SSL documents)

Make sure your pathing is set such that you will be using the appropriate version of patch (the one you just built which will default to /usr/local/bin/patch). You can assure yourself of that by changing the reference to patch within the script to use the absolute path to the new version. You can verify by entering the command 'patch -v' to view the version. To run the FixPatch script, type the following command:

cd /usr/local/source/apache_1.3.19
./FixPatch
 

You will be prompted as follows:

Your version of patch is OK.
Searching for a usable OpenSSL installation or source directory
Looks like you are using OpenSSL, adjusting app name
OpenSSL sources were found in: /apache/openssl-0.9.6-stable-SNAP-20010531
OpenSSL needs updating to include a function to read a specified number of
bytes from EGD - if you haven't applied the patch already and are using
OpenSSL 0.9.5a, then it needs applying
Do you want me to apply the OpenSSL EGD patch for you? [n] n
OK, I won't apply the OpenSSL patch.
OpenSSL installation found in: /usr/local/ssl
Using the source version of OpenSSL found in /apache/openssl-0.9.6-stable-SNAP-20010531
If this is not what you want stop now and specify the path to OpenSSL
explicitly.
Do you want me to apply the fixed-up Apache-SSL patch for you? [n] y
 

Build and install Apache-SSL

Reference Files: (see Apache and Apache-SSL references)

Actually this is building Apache, but since the Apache+SSL information has been untarred within Apache, it should build the Apache+SSL package. Here are the commands that worked for me:

cd /usr/local/source/apache_1.3.19
./configure
make clean
make
make install
 

You will want to watch the output and see that the compilation refers to the OpenSSL libraries developed earlier.

Create a Test/Live Certificate that can be used to bring up an HTTP SSL server

Reference Files: Verisign Document on CSR Generation and Installation

Apache-SSL uses a key pair (private and public key) to secure the server. The normal process is to create a private key, then a CSR (certificate services request). The CSR is used to generate the public key. Dual keys are the key to security (gotta have both). This process will follow the SSL CSR Generation and Installation Instructions put out by Verisign (see the link here). In short, what I did was:

cd /usr/local/ssl/private
/usr/local/ssl/bin/openssl genrsa 
des3 
rand /etc/entropy 1024 > secure.pccaldera.com.key
cd /usr/local/ssl/certs
/usr/local/ssl/bin/openssl req -new -key ../private/secure.pccaldera.com.key > secure.pccaldera.com.csr
 

You now have a private key and CSR. You can generate your own self-signed certificate to allow you to test without purchasing a third-party certificate. You can do so by entering the following command:

cd /usr/local/ssl/certs
/usr/local/ssl/bin/openssl req -x509 -key ../private/secure.pccaldera.com.key - in secure.pccaldera.com.csr > secure.pccaldera.com.crt
 

The .crt file just created and the .key file created earlier will be referred to in the configuration files (http.conf or https.conf) to secure a web server. If you are setting up a production server, you will need to purchase a certificate from a third party (like Verisign). In this case you will submit a request to Verisign for the certificate. As part of that process you will provide them with the .csr file. They will send you a .crt file which you will use in your configuration files (http.conf or https.conf).

Configure .conf files to support a public (non-secure) and secure sites

Reference Files: (see the /usr/local/apache/conf/*.conf files) | Apache-SSL Documentation|Short httpd.conf Example

The Apache web server reads any configurable parameters from the a file specified when the server is started. This file is normally httpd.conf or httpds.conf. In my particular case, I took the file httpd.conf and made some additions and modifications to set it up to serve both secure and public web server instances. Refer to the httpd.conf file for details. Listed below are the areas that were significant in the setup of the secure (primary) and public (virtual) web servers.

# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpsd to be run as root initially.
PORT 443
SSLVerifyClient 0
SSLVerifyDepth 10
SSLEnable
SSLCertificateFile /usr/local/ssl/certs/pcsuw.pccaldera.com.crt
SSLCertificateKeyFile /usr/local/ssl/private/pcsuw.pccaldera.com.key
SSLCacheServerPath bin/gcache
SSLSessionCacheTimeout 3600
SSLCacheServerPort /usr/local/ssl/private/pcsuw.pccaldera.com.csp
# Use name-based virtual hosting.
#NameVirtualHost *
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#<VirtualHost *>
#    ServerAdmin webmaster@dummy-host.example.com
#    DocumentRoot /www/docs/dummy-host.example.com
#    ServerName dummy-host.example.com
#    ErrorLog logs/dummy-host.example.com-error_log
#    CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>
<VirtualHost pcsuw.pccaldera.com:80>
    SSLDisable
    Port 80
    ServerAdmin nothing@yahoo.com
    DocumentRoot /usr/local/apache/htdocs
    ServerName pcsuw.pccaldera.com
    ErrorLog logs/httpd_error_log
    CustomLog logs/httpd_custom_log.txt common
</VirtualHost>
 

Publish your articles, comments, book reviews or opinions here!

More Articles by John Pritchard

Macworld Digital Music & Video Superguide $12.95

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.