Assignment 3 - Source Tarball Installations of OpenSSL and Apache on Redhat 7.3 System
INLS 183 - Distributed Systems (new window)
October 7, 2002
Send comments to: bhayes@email.unc.edu

Assignments Index Page
nbsp;

Background

I am interested in setting up my home computer to serve as a web server using open source web server, database and middleware/scriping software available for the Linux platform. When I installed Linux 7.3 on this system (assignment 1), I elected not to install web server, database (MySQL) or PHP packages so that I could install the latest versions at a later date. After the Linux OS itself, installing Apache is the next step.

Given the recent CERT advisory about a Worm-exploitable security vulnerability in 0.9.6d or earlier versions of OpenSSL on Intel systems running Apache with the OpenSSL module (mod_ssl), I upgraded OpenSSL to the patched version prior to installing Apache. The OpenSSL program is a command line utility for using the functions of the OpenSSL cryptography library to implement secure network communications constructs such as X.509 certificates and SSL/TLS client and server tests. The OpenSSL library or toolkit implements the SSL (Secure Sockets Layer and TLS (Transport Layer Security) network protocols and related cryptography standards that they require. I don't anticipate using the OpenSSL capabilty with my server in the shortrun, I am interested in researching it use and implementation further and perhaps using in the future.


Part I: OpenSSL Installation (see script)

CONFIRM VERSION of OPENSSL INSTALLED
I first determined which version of OpenSSL installed on my system with an rpm query:
$ rpm -qa | grep -i ssl

OpenSSL 0.9.6b is installed.

I ran "locate openssl" to identify where files were installed:
$ locate openssl

The OpenSSL executable is installed in /usr/bin with supporting files in /usr/share/doc/, /usr/share/man/, /usr/include/openssl and a config file in /usr/share/ssl/ .

LOCATE, RETRIEVE & PREPARE TO INSALL LATEST OPENSSL PACKAGE
I used a graphical web browser on my Gnome desktop to locate the latest OpenSSL package on the OpenSSL site. Since I wanted to install the new version over the old one, I moved to the /usr/bin directory and ran wget from the command line of a terminal session to download openssl-0.9.6g.tar.gz into that directory. I had to sudo wget to successfully download/write to /usr/bin

$ sudo wget http://www.openssl.org/source/openssl-0.9.6g.tar.gz

Unzip and detar openssl-0.9.6g.tar.gz package:
$ sudo tar -xzf openssl-0.9.6g.tar.gz

This create an openssl-0.9.6g directory in /usr/bin. CD into this directory to read documenation and to eventually run installation steps.

CONSULT OPENSSL README AND INSTALL FILE
Per INSTALLATION file, the usual install location is /usr/local/ssl Recommended installation steps include a make test between the make (compilation) step and the make install (installation) step. Per configuration options section of the INSTALL file, to install in /usr/bin/ instead of default /usr/local/ssl, I need to add appropriate --prefix=DIR and --openssldir=DIR options to the ./Configure (configuration) step to have binary install in /DIR/bin and the configuration file install in /usr/bin/openssl. Use ./Configure with option for linux-elf (modern linux OS) system instead of ./config which guesses at the system OS. I ran ./config to see what would happen; the system responded that the OS was i686-whatever-linux2, Configuring for linux-elf, /usr/bin/perl ./Configure linux-elf

INSTALL OPENSSL
First configure:
$ sudo ./Configure --prefix=/usr --openssldir=/usr/openssl linux-elf

Compile:
$ sudo make

Compilation took a few minutes. When I mistakenly ran make rather than sudo make, an error was logged at the end of the configuration routine; buildinf.h file/dir was not found as expected in /bin/sh. I reran the command as sudo make and no errors were reported this time.

$ make error;

/bin/sh: buildinf.h: No such file or directory
make[1]: *** [buildinf.h] Error 1
make[1]: Leaving directory `/usr/bin/openssl-0.9.6g/crypto'
make: *** [sub_all] Error 1
.
Test Compilation per INSTALL file recommendation:
$ sudo make test

Took about 15 seconds. All seems to have went well; all tests went ok per transcript. I will continue to run make test or comparable checks as part of installation processes when available; they are reassuring, particularly to an installation novice. In the case of the openssl tests, some of them gave a more concrete idea of what openssl does (e.g. certificate creation) because they had the software execute test routines.

Install:
$ sudo make install

Took less than a minute. No errors.

VERIFY THE NEW OPENSSL INSTALLATION
I ran "which openssl" and "ls -l !$" to confirm that openssl was installed in /usr/bin and that it was the newly installed version. The new version is installed:

-rwxr-xr-x    1 root     root      1188632 Oct  4 21:53  /usr/bin/openssl
FUNCTIONALITY
I have no plans to use this software at this point; I installed it as a security step in case I might use it in the future. I hope to revisit openssl functions later in this course.

Part II: Apache Web Server Installation (see script)

CHECK FOR EXISTING APACHE INSTALLATION; RETRIEVE TARBALL
I ran ps -ef | grep http to see if a http process is currently running. No http processes are running.

I tried to telnet to port 80 to see if if would respond. The connection was refused.

I had previously downloaded the "best available" version of Apache from Apache.org. The version had been updated from our class install to Apache 2.0.43.tar.gz into a /tmp in my home directory; it fixes a security bug and some bugs from Apache 2.0.42.

$ wget http://apache.mirrorcentral.com/dist/httpd/httpd-2.0.43.tar.gz

Download completed before script begun.

PREPARE TO INSTALL
I copied the Apache package into /usr/local where I wanted to install it; I de-tarred and unzipped it there. Sudo required. Apache created its own httpd-2.0.43 directory in /usr/local.

$sudo cp httpd-2.0.43.tar.gz /usr/local
$cd /usr/local
$sudo tar xzf httpd-2.0.43.tar.gz

cd into the new directory and read the README and INSTALL files. Consult ./configure --help A PREFIX= option is available to set the install directory if different than the default. Other enable/disable options of interest outlined in the ./configure --help included --enable-usertrack, --enable-SSL, --enable-cgi, --disable-autoindex I configured Apache with only the --enable-so option to enable sharable objects as done with the class install and --disable-autoindex to prevent browsing to a file listing within a directory without an index.html file. I noted the others to read further about in more extensive Apache documentation (beginning with http://httpd.apache.org/docs-2.0/install.html).

INSTALL APACHE
First, configure:
$ sudo ./configure --enable-so --disable-autoindex

Configure process to about a minute. No errors.

Compile the application:
$sudo make

The make process generated an segmentation fault error when compiling mod_negotiation: Per intro to /usr/local/httpd-2.0.43/modules/mappers/mod_negotiation file, it keeps track of MIME types the client is willing to accept and contains code to handle type arbitration.

mod_negotiation.c: In function `parse_negotiate_header':
mod_negotiation.c:662: Internal error: Segmentation fault.
Please submit a full bug report.
See  for instructions.
make[3]: *** [mod_negotiation.lo] Error 1
make[3]: Leaving directory `/usr/local/httpd-2.0.43/modules/mappers'

Per error instructions I both searched for and reported the bug (mod_negotiation) at bugzilla.redhat.com/bugzilla. I retrieved no previous reports on this error.

I attempted the "make test" command that OpenSSL INSTALL file recommended; this command was not recognized by Apache. So, I proceeded with the install despite the unresolved error.
$sudo make install

I inadvertantly ran "make install" from the modules/mappers directory within /httpd-2.0.43. I moved up to the main /httpd-2.0.43 level and repeated make install. Installation (both times) completed without errors.

APACHE CONFIGURATION
Per class example install, I edited the /usr/local/apache2/conf/httpd.conf file after saving a backup copy.
$sudo vi httpd.conf

I reduced number of StartServers and MinServers from 5 to 1, set my document root to /home/htdocs and set the server admin email to my email address. My changes to httpd.conf can be see in the diff file.

Next, I created /htdocs under /home (I entered /home/htdocs as my doc root in httpd.conf) and created a test index.html file there.

Apache Functionality
The first test of functionality was to successfully start the Apache service. During initial attempts, $ /usr/local/apache2/bin/apachectl start evoked a "could not determine server's fully qualified domain name, using 127.0.0.1" error. After reading man pages for hostname, domainname and hosts, I edited /etc/hosts to include a line defining the current IP address (DHCP so I'll need to make other configuration changes to get this right) and the hostname for my computer. When I executed the start command again I received the same error but with the added message that httpd was already running. So even though I have domainname issues to follow up on, Apache was successfully running. I confirmed this by checking the processes and using lynx browser to browse to my server index page in the document root location.
$ ps -ef | grep | httpd yielded these running 3 httpd processes
root     10292     1  0 Oct04 ?        00:00:00 
/usr/local/apache2/bin/httpd -k
nobody   10293 10292  0 Oct04 ?        00:00:00 
/usr/local/apache2/bin/httpd -k
nobody   10325 10292  0 Oct04 ?        00:00:00 
/usr/local/apache2/bin/httpd -k
As a second test of Apache function, I then successfully browsed to the index page in my /home/htdocs document root location by using Lynx to browse to http://127.0.0.1, the IP address the server declared it was using as its IP in the apache start error message.

Finally, I edited /etc/rc.d/rc.local to add the apache start command to the rc.local service initialization script. Apache now starts successfully when the server is booted up.

This assignment/installation went fairly smoothly in an of itself; the software works. However it left me with host/domain name and ip assignment questions to follow-up on...always a sign of a worthwhile assignment. Linuxconf is discussed by the text as a command line utility I can use to review and change network configuration setting. That will be one of the installation I hope to complete this week.
nbsp; Send comments to: bhayes@email.unc.edu