APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Setting up Apache on Unixware by John Pritchard

© July 2001 John Pritchard

Setting up Apache to run on Unixware for WebSpeed


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


Get and Expand the Source Files

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

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
make clean
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 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
make clean
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

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
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
make clean
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 
rand /etc/entropy 1024 > secure.pcsco.com.key
cd /usr/local/ssl/certs
/usr/local/ssl/bin/openssl req -new -key ../private/secure.pcsco.com.key > secure.pcsco.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.pcsco.com.key - in secure.pcsco.com.csr > secure.pcsco.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
SSLCertificateFile /usr/local/ssl/certs/pcsuw.pcsco.com.crt
SSLCertificateKeyFile /usr/local/ssl/private/pcsuw.pcsco.com.key
SSLCacheServerPath bin/gcache
SSLSessionCacheTimeout 3600
SSLCacheServerPort /usr/local/ssl/private/pcsuw.pcsco.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 pcsuw.pcsco.com:80>
    Port 80
    ServerAdmin nothing@yahoo.com
    DocumentRoot /usr/local/apache/htdocs
    ServerName pcsuw.pcsco.com
    ErrorLog logs/httpd_error_log
    CustomLog logs/httpd_custom_log.txt common

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

© July 2001 John Pritchard All rights reserved

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Setting up Apache on Unixware by John Pritchard

Inexpensive and informative Apple related e-books:

iOS 8: A Take Control Crash Course

Take Control of iCloud, Fifth Edition

Take Control of iCloud

Take Control of High Sierra

Take Control of Automating Your Mac

More Articles by © John Pritchard

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

A man can be destroyed but not defeated. (Ernest Hemingway)

Linux posts

Troubleshooting posts

This post tagged:








Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode