Notice: This material is excerpted from Running A Perfect Internet Site with Linux, ISBN: 0-7897-0514-1. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290 or at support@mcp .com.

Chapter 7 - Installing Web Server Software

One of the hottest services available on the Internet right now is the World Wide Web. Everyone seems to be creating home pages and reveling in the multimedia experience of it all. If you'd like to offer Web pages from your site, you must have a WWW server running to handle the page requests. If you don't intend to run a WWW server, feel free to skip ahead to the next chapter.

Why wouldn't you want to run a Web server? Primarily, if you don't intend to offer Web pages, there is no reason to run a Web server. You and your users can still look at Web pages outside of your site without a Web server. Some reasons to not offer Web pages on your site might be:

You have limited bandwidth and disk space and can't afford to strain it with the added service of providing WWW pages.
Neither you nor your users are interested in offering WWW pages at the moment.
Your provider stores Web pages for free or at virtually no cost, and you'd rather use their bandwidth for access than your own.

In this chapter, you learn how to:

Compile your Web server
Configure your Web server
Select server scripts
Move all of your server files to the proper places
Start up your Web server
Test your Web server

Compiling Your Web Server

With Linux, you'll find that, more often than not, you're going to have to compile source rather than fetch binaries. There's no need to panic, however! You'll get plenty of practice in this book at setting up systems. Your programming skills will especially improve over time as you fulfill your duties as system administrator.

I'll go into a discussion of HTML and browsers later in the chapter. First, let's get the server set up! If you need extra help and have access to a Web browser (or want to jump ahead and install X Windows and Netscape), you can go to HOOHOO for online assistance with this process.

Finding and Decompressing the Server Source

The Web server you're going to use is the NCSA's (National Center for Supercomputing Applications) httpd version 1.4.2. This is a daemon, which runs in the background and waits for Web page requests to come in.

Locate the file httpd_1.4.2_source.tar.Z on the CD-ROM and copy it to a directory, such as /usr/src. To deal with the .Z (which means the file is compressed and can be taken apart with gunzip), type gunzip httpd_1.4.2_source.tar.Z.

A good habit to develop is keeping source code around when you can. Putting it into /usr/src means it's immediately where you can find it at a later date. If you update your libraries later, you'll need to recompile it.

There are precompiled binaries available as well of httpd, but I highly recommend you compile the server yourself. For one thing, as a sysadmin you're going to have to compile a lot of programs as time goes by, so the more experience you get in the beginning, the better. For another, the risk of getting precompiled binaries instead of source is that they may not be compiled for a system that's set up the way you have yours set up. It may be compiled for a different set of source libraries than you have, and in this case the binaries don't come with some of the nice extra scripts that the source does.

If you want to try the binary, you can find it via FTP on ftp.ncsa.uiuc.edu in /Web/httpd/Unix/ncsa_httpd/httpd_1.4/ httpd_1.4.2_linux.Z. While this file does contain the source code, it also contains a precompiled binary.

Then, to get rid of the .tar (a utility that groups items together, but doesn't compress) type tar -xvf httpd_1.4.2_source.tar.

Some tarred files are set to create a particular directory for themselves, and some are not. If they create their own directory, you want to untar them straight in /usr/src. However, if they don't, you'll end up with a bunch of files directly in /usr/src instead of a subdirectory. I know httpd creates its own directory. If you're not sure about a program, you may want to create a directory for it, untar the file inside that directory, and if it creates its own directory more the tar file back to /usr/src and erase the untarred version. You can then untar it again and let it create its own directory.

In Linux, you'll use tar to cluster items into one file and then gzip (or the UNIX command compress) to compress the file. These two commands are like PKZip in the MS-DOS world.

Compiling Your Web Server

Now you can actually compile the server. With any luck, it will be a painless process, but you may have to use some of your programming skills to put it together. Yes, programming skills. As a system administrator, you will find that if you don't have them, you will slowly develop them as a necessity.

First, make sure that your Makefile is in your current directory. Then, type make linux to begin the compilation, and watch what happens. Don't worry too much about the warnings unless there's an overwhelming number of them. If any serious errors occur, the compilation will stop.

When you see an error kill your compilation that claims that a particular header file with an .h extension doesn't exist, that's often not true. Take a look in /usr/include and /usr/include/linux (for example), and see if you can find that particular file somewhere else.

When you find the file that was missing, you'll need to edit the source file (with a .c extension) referenced when the error was displayed and change the call to the file so it's correct.

If you get an error that says something about an undefined function, a particular function is probably in a different .h file than it used to be in. Instead of looking through every header file you can find, go to directories like /usr/include and /usr/include/linux and type the following:

grep 'string you are searching for' *.h

For example, if I were looking for the function foo(), I would type grep 'foo' *.h in each directory until I found what I was looking for.

Now the initial installation is complete!

Configuring Your Web Server

Now that the server is compiled, you need to configure it to suit your system and needs. Once you finish with this process, it's not something you'll have to worry about again until you have a need to change your configurations. You may need to change your configurations if you decide to offer a different set of features, or change your system in a significant way.

It's become common practice for people to alias their site's Web server to www.your.domain_name. This is because it makes it simple for people to guess at the URL for your site's main Web page. If you don't want people to be able to easily locate your site's main Web pages then you probably don't want to alias it to www.your.domain_name. In fact, if you only want key people to be able to access it, you may want to alias it to an obscure machine name that others won't guess.

As I covered in chapter 5, "Setting Up Your Site for General Use," you can set aliases for a machine in the /etc/named.d/named.hosts file by simply adding the new machine name right after the other ones in its list. Then, after you've added the new alias, you need to kill your named process and restart it. For example, if the process ID for your named is 210, type kill -HUP 210. HUP tells your system to reload the config files without actually killing the process.

General httpd Configuration File Rules

There are three configuration files you need to set up. All of them observe the following rules:

The only place where case matters within these files is in file paths and names.
To comment out a line, use a pound (#) sign.
When you use the directive command (discussed in the next section), you can only have one directive per line.
To make your directive and following data statements easier to follow at a glance, you can include extra white space. It will be ignored by the Web server.

Setting Up the Server Configuration File

The first configuration file you'll set up is for your Web server. Use the file httpd.conf-dist (listed here) as a template for suggestions, but you won't want to use it as is.

# This is the main server configuration file. It is best to
# leave the directives in this file in the order they are in, or
# things may not go the way you'd like. See URL http://hoohoo.ncsa.uiuc.edu/
# for instructions.
# Do NOT simply read the instructions in here without understanding
# what they do, if you are unsure consult the online docs. You have been
# warned.
# NCSA httpd (comments, questions to httpd@ncsa.uiuc.edu)
# ServerType is either inetd, or standalone.
ServerType standalone
# If you are running from inetd, go to "ServerAdmin".
# Port: The port the standalone listens to. For ports < 1023, you will
# need httpd to be run as root initially.
Port 80
# StartServers: The number of servers to launch at startup. Must be
# compiled without the NO_PASS compile option
StartServers 5
# MaxServers: The number of servers to launch until mimic'ing the 1.3
# scheme (new server for each connection). These servers will stay around
# until the server is restarted. They will be reused as needed, however.
# See the documentation on hoohoo.ncsa.uiuc.edu for more information.
MaxServers 20
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
# User/Group: The name (or #number) of the user/group to run httpd as.
User nobody
Group #-1
# ServerAdmin: Your address, where problems with the server should be
# e-mailed.
ServerAdmin you@your.address
# ServerRoot: The directory the server's config, error, and log files
# are kept in
ServerRoot /usr/local/etc/httpd
# ErrorLog: The location of the error log file. If this does not start
# with /, ServerRoot is prepended to it.
ErrorLog logs/error_log
# TransferLog: The location of the transfer log file. If this does not
# start with /, ServerRoot is prepended to it.
TransferLog logs/access_log
# AgentLog: The location of the agent log file. If this does not start
# with /, ServerRoot is prepended to it.
AgentLog logs/agent_log
# RefererLog: The location of the referer log file. If this does not
# start with /, ServerRoot is prepended to it.
RefererLog logs/referer_log
# RefererIgnore: If you don't want to keep track of links from certain
# servers (like your own), place it here. If you want to log them all,
# keep this line commented.
#RefererIgnore servername
# PidFile: The file the server should log its pid to
PidFile logs/httpd.pid
# ServerName allows you to set a host name which is sent back to clients for
# your server if it's different than the one the program would get (i.e. use
# "www" instead of the host's real name).
#
# Note: You cannot just invent host names and hope they work. The name you
# define here must be a valid DNS name for your host. If you don't understand
# this, ask your network administrator.

#ServerName new.host.name

Build your personalized config file, conf/httpd.conf, and fill it in following the same order as the example above. The following is a walk-through of the choices I made for my server configuration file:

# ServerType is either inetd, or standalone.
When reading this line, it's easy to think you want inetd because you'll be running a site on the Internet. However, you want to use standalone because you will have a lot less CPU load by letting httpd handle itself than you will if inetd has to take care of it. Therefore, the first line in your conf/httpd.conf file is the following:
ServerType standalone
# Port: The port the standalone listens to.
The standard httpd port is 80. Generally, you'll want to stick with standard ports, as doing this will make it easier for people to access your services. So, your second line reads as follows:
Port 80
# StartServers: The number of servers to launch at startup.
Although there is a compiled default for the number of server processes that initially fork off, it's best to go ahead and set a number anyway so you know what you're using. If you accept the defaults, you won't know what settings you're using unless you dig through the source code to find what they are.
I chose to use the same number of servers (five) used in the example configuration file. My system can easily handle five HTTP requests simultaneously without having to use extra resources to start up more httpd processes. Also, five idle daemons won't hog your resources. Therefore, the next line in your configuration file is the following:
StartServers 5
# MaxServers: The number of servers to launch until mimic'ing the 1.3
# scheme (new server for each connection).
Once again, there is a compiled default available to you, but I recommend that you include a value for this variable in your configuration file as well. The value included in the sample config file is 20. This may seem like a lot of servers to run at once, but remember that the more inline image, bullets, etc., on a Web page, the more server processes are needed to load that page. So, for example, if you have a page with three pictures, five bullets, and text, it would need a total of 9 server processes to send all of that information to the person accessing the page. I'll stick with the default, so my next line is:
MaxServers 20
# User/Group: The name (or #number) of the user/group to run httpd as.
The defaults for ownerships for httpd are nobody and nogroup. However, some people prefer to have it run as owned by another known process, such as FTP. To set mine up to run as user ftp and group bin, my next two lines are:
User ftp
Group bin

Be sure that the user and group you select exist in your /etc/passwd file.

# ServerAdmin: Your address, where problems with the server should be
# e-mailed.
Make it easy for people to contact you about your services. It is, of course, great to hear positive comments, but it is also a good idea to make it simple for people to complain or offer "constructive" criticisms. If it takes users a while to figure out how to contact you to make a complaint or comment, they tend to be more irate than they might otherwise have been.
Therefore, include the e-mail address of the person in charge of maintaining your Web services. If this person may change often, then you might want to go back to your aliases file (discussed in Chapter 5, "Setting Up Your Site for General Use") and add an alias for an address like webadmin or webmaster, so you don't risk forgetting to change it in the httpd config file later. I used the following:
ServerAdmin webadmin@renaissoft.com
# ServerRoot: The directory the server's config, error, and log files
# are kept in
Here you tell your system where it can find your httpd files. Where you keep them really depends on your preferences, but instead of making up something like /servers/httpd, stick with the default so you become familiar with Linux file organization:
ServerRoot /usr/local/etc/httpd
Now tell your system where it can find your httpd log files. If you don't start the paths with a slash (/) it is assumed that the directory starts in the directory assigned by ServerRoot. The log files are as follows:

Errorlog keeps track of clients that take time out, scripts that produce no output, .htaccess files that try to override items they don't have the permissions to override, serious server bugs (producing segmentation faults or bus errors), and problems with user authentication.
TransferLog keeps track of the following information on accesses: client host, identd info offered, user authentication if used, date and time of access, first line of the HTTP request, server status code, and the total number of bytes sent.
AgentLog keeps track of the client agent software that is used. This is mostly employed for gathering statistics and for tracking which clients follow protocol that cause errors in your server.
RefererLog keeps track of the documents that referred people to your links.
There is a variable associated with this log file called ReferIgnore, which overlooks references to particular referring links. You use it if you don't want to record every time someone looks at one of your pages following a link on your own site, for example. Because I have www.renaissoft.com set up, I'd tell it to ignore that host.
PidFile keeps track of your server process ID numbers.

You can chose to keep your logs in some sort of central log area. Because I decided that I want to keep my logs with the other htppd items, the next few items in my config file will be the following:
ErrorLog logs/error_log
TransferLog logs/access_log
AgentLog logs/agent_log
RefererLog logs/referer_log
RefererIgnore www.renaissoft.com
PidFile logs/httpd.pid
ServerName tells your system another name for the location of your Web server. Once again, a good example of this is our site, where the real name of the server is davinci.renaissoft.com, but we like the world to see it as www.renaissoft.com for simplicity's sake. So, for the last line of the server configuration file, I'd have:
ServerName www.renaissoft.com

Setting Up the Resource Configuration File

The second configuration file you'll set up is used to tell your Web server where to find documents, scripts, and aliases. Use the file srm.conf-dist (listed here) as a template for suggestions as you did with the server configuration file, but don't use it as is.

# With this document, you define the name space that users see of your http
# server.
# See the tutorials at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/ for
# more information.
# NCSA httpd (httpd@ncsa.uiuc.edu)
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
DocumentRoot /usr/local/etc/httpd/htdocs
# UserDir: The name of the directory which is appended onto a user's home
# directory if a ~user request is received.
UserDir public_html
# DirectoryIndex: Name of the file to use as a pre-written HTML
# directory index
DirectoryIndex index.html
# FancyIndexing is whether you want fancy directory indexing or standard
FancyIndexing on
# AddIcon tells the server which icon to show for different files or filename
# extensions
AddIconByType (TXT,/icons/text.xbm) text/*
AddIconByType (IMG,/icons/image.xbm) image/*
AddIconByType (SND,/icons/sound.xbm) audio/*
AddIcon /icons/movie.xbm .mpg .qt
AddIcon /icons/binary.xbm .bin
AddIcon /icons/back.xbm ..
AddIcon /icons/menu.xbm ^^DIRECTORY^^
AddIcon /icons/blank.xbm ^^BLANKICON^^
# DefaultIcon is which icon to show for files which do not have an icon
# explicitly set.
DefaultIcon /icons/unknown.xbm
# AddDescription allows you to place a short description after a file in
# server-generated indexes.
# Format: AddDescription "description" filename
# ReadmeName is the name of the README file the server will look for by
# default. Format: ReadmeName name
## The server will first look for name.html, include it if found, and it will
# then look for name and include it as plaintext if found.
## HeaderName is the name of a file which should be prepended to
# directory indexes.
ReadmeName README
HeaderName HEADER
# IndexIgnore is a set of filenames which directory indexing should ignore
# Format: IndexIgnore name1 name2...
IndexIgnore */.??* *~ *# */HEADER* */README*
# AccessFileName: The name of the file to look for in each directory
# for access control information.
AccessFileName .htaccess
# DefaultType is the default MIME type for documents which the server
# cannot find the type of from filename extensions.
DefaultType text/plain
# AddType allows you to tweak mime.types without actually editing it, or to
# make certain files to be certain types.
# Format: AddType type/subtype ext1
# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
#AddEncoding x-compress Z
#AddEncoding x-gzip gz
# Redirect allows you to tell clients about documents which used to exist in
# your server's namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
# Format: Redirect fakename url
# Aliases: Add here as many aliases as you need, up to 20. The format is
# Alias fakename realname
Alias /icons/ /usr/local/etc/httpd/icons/
# ScriptAlias: This controls which directories contain server scripts.
# Format: ScriptAlias fakename realname
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/
# If you want to use server side includes, or CGI outside
# ScriptAliased directories, uncomment the following lines.
#AddType text/x-server-parsed-html .shtml
#AddType application/x-httpd-cgi .cgi
# If you want to have files/scripts sent instead of the built-in version
# in case of errors, uncomment the following lines and set them as you
# will. Note: scripts must be able to be run as if the were called
# directly (in ScriptAlias directory, for instance)
# 302 - REDIRECT
# 400 - BAD_REQUEST
# 401 - AUTH_REQUIRED
# 403 - FORBIDDEN
# 404 - NOT_FOUND
# 500 - SERVER_ERROR
# 501 - NOT_IMPLEMENTED
#ErrorDocument 302 /cgi-bin/redirect.cgi
#ErrorDocument 500 /errors/server.html
#ErrorDocument 403 /errors/forbidden.html

Build your personalized config file, conf/srm.conf, and fill it in following the same order as the example above. The following is a walk-through of the choices I made for my server resource configuration file:

# DocumentRoot: The directory out of which you will serve your
# documents.
With this variable, you specify the main directory that your server will show files from. As usual, I am going to stick with the standards (though if you prefer to keep all of your log files in one central place, you can certainly change this to suit your needs), so this configuration file will start with the following:
DocumentRoot /usr/local/etc/httpd/htdocs
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.
This directive is used to assign a directory that will exist in user directories where the users can keep their own HTML files for Web access. The standard is the directory public_html: any time someone follows a link to, say, SERVER they would actually be going to SERVER. It's mostly a way of keeping things tidy and keeping the proper security, so outsiders can't get into user directories.
The next line in my config file, because I'm using the default, will be as follows:
UserDir public_html
# DirectoryIndex: Name of the file to use as a pre-written HTML
# directory index.
With this directive, you can set an assumed file name when an outside user follows a link into someone's home directory. In the example URL's above, note that there were no file names listed. That is because a default file name is set, so the server looks at that file first (generally, index.html). I'm going to use the default once again, so my next line will be:
DirectoryIndex index.html
# FancyIndexing determines whether you want fancy directory indexing or standard.
FancyIndexing refers to showing directories and files with icons and file sizes. If you want to display your files and directories in this fashion, turn this option on. If not, set it to off. My next line, setting it to on, is as follows:
FancyIndexing on
# AddIcon tells the server which icon to show for different files or file names.
# extensions
You can use this directive to define what icons your Web server will use to display the types of files in a directory. This is simply a way to jazz up your directory displays a bit. There are no defaults, so if you don't define something, no icons will be used.
The path you use to the icons will be taken to be inside the value of the DocumentRoot variable that you defined at the beginning of this configuration file (which I set to be /usr/local/etc/httpd/htdocs). Therefore, the first variable refers to the directory you want to keep the icons in, and this directory will be inside your DocumentRoot directory. So, for example, if you want the icons in /usr/local/etc/httpd/htdocs/icons, just enter /icons for the directory.
The next item is the particular icon. While there are no defaults, the server does come with icons you can use, which are in the /icons subdirectory of your server files. The icons available are shown in figure 7.1.

Fig. 7.1 You can use these icons to show what kind of file is in a directory listing.

For example, if I wanted to use the icon sound.xbm for my sound files, I'd add sound.xbm to the path statement, making it /icons/sound.xbm (which would really refer to /usr/local/etc/httpd/htdocs/icons/sound.xbm).
Finally, the last piece of the icon statement is where you'll identify which file types to use the icon with. In the case of our sound file example, I would now add *.au. This makes the entire statement /icons/sound.xbm *.au.
Other examples of icon definitions are:
AddIcon /icons/dir.xbm ^^DIRECTORY^^
AddIcon /icons/image.xbm .gif .jpg .xbm
# DefaultIcon determines which icon to show for files that do not have an icon
# explicitly set.
Here, you tell the server what icon to use for file types that you didn't define. A pretty standard one is the unknown icon that comes with the other default icons. I'll use this one, so the next line in my config file is as follows:
DefaultIcon /icons/unknown.xbm
# AddDescription allows you to place a short description after a file in
# server-generated indexes.
If you want to add a line of description for specific files, you'll use this directive. Say you have the file dogs.txt, and you want to make sure people read it. You might add the following:
AddDescription "Description and discussion of various breeds of dogs" dogs.txt
# ReadmeName is the name of the README file the server will look for by
# default.
You can use this directive to define the HTML file that will contain a list of descriptions of the files in the current directory. These file descriptions would be displayed right next to the file names in the directory listing, even though they were stored in a separate file.
You will need to create the HTML file containing the descriptions at a later date. Just to make my life easy, I'll name mine readme.html, so the line I'll add to my resource config file is as follows:
ReadmeName readme
Note that I didn't include the .html. When you don't include the extension, the server will first look for readme.html, and then look for the plain text file readme.
# HeaderName is the name of a file that should be prepended to
# directory indexes.
You can use this directive to define the HTML file that will contain a custom header for the current directory. The header will be displayed at the top of the directory listing. You will need to create the HTML file containing the header at a later date. To make things easy to remember, I'll name mine header.html, so the line I'll add to my resource config file is the following:
HeaderName header
Once again, note that the .html extension is assumed first, and if it can't find header.html, it will look for header without an extension.
10. # IndexIgnore is a set of file names that directory indexing should ignore.
If you don't want certain files to show up in directory listings, use IndexIgnore. For example, if I want to disregard the readme.html and header.html files (they're used by the server itself, and users don't need to access them by hand), I would use the following line next in my resource configuration file:
IndexIgnore readme.html header.html
When you test this, you may find that there are other files you don't want displayed. Just come back to this line and add them to the IndexIgnore list. For example, you may want to use IndexIgnore readme.html header.html # ~.
Now, all emacs autosave and backup files are no longer included.
11. # AccessFileName: The name of the file to look for in each directory
# for access control information.
This directive refers partially to the next section, "Setting Up the Access Configuration File." It tells your server where to look for access control files, which are the files you'll configure to set up what directories people need higher than generic guest access to get to, etc.
I'm going to stick with the default file for this one, so my next resource config line is the following:
AccessFileName .htaccess
12. # DefaultType is the default MIME type for documents that the server
# cannot find the type of from file name extensions.
You can use this directive to assign a default file type when your server cannot determine the actual file type. I will stick with the default setting on this one for now, and see if I consistently run into another file type that I should use here instead. My next line will be the following:
DefaultType text/plain
In this case, text refers to the file type (standard file type), and plain refers to the subtype (what MIME calls the file type).
13. # AddType allows you to tweak mime.types without actually editing it, or to
# make certain files to be certain types.
If you want to assign a particular type to files with certain extensions, you'll use this directive. The types you assign here override the types already listed in your TypesConfig file. This file already contains a list of file types and corresponding MIME types.
Although you may want to take a look at it (you can find it in conf/mime.types), you shouldn't need to edit this file. Instead, make your changes by using the AddType directive here.
Let's say, for example, that I intend to use the extension .help a lot, and all .help files will be text files. I would therefore add the following to my resource config file:
AddType text/plain help
14. # AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) decompress
# information on the fly.
If you want to enable your server to decompress files as it sends them (so you can use less drive space storing the files), use this directive. For example, let's say I want my server to be able to decompress UNIX compressed (.Z) files and gzipped (.gz) files (as shown as an example in the resource configuration file listing). I would enter the following in my config file:
AddEncoding x-compress Z
AddEncoding x-gzip gz
15. # Aliases: Add here as many aliases as you need, up to 20.
If you want to add an alias that you can use for paths later in your HTML files, use this directive. To alias the path /ftp/pub/docs to /docs, you would add the following line to your resource config file:
Alias /docs /ftp/pub/docs

Setting Up the Access Configuration File

The third configuration file that you'll set up is used to tell your Web server which clients can get to which directories and which services are available in other directories. Use the file access.conf-dist (see below for file listing) as a template for suggestions as you did with the server configuration file, but don't to use it as is.

# access.conf: Global access configuration
# Online docs at http://hoohoo.ncsa.uiuc.edu/
# I suggest you consult them; this is important and confusing stuff.
# /usr/local/etc/httpd/ should be changed to whatever you set ServerRoot to.
<Directory /usr/local/etc/httpd/cgi-bin>
Options Indexes FollowSymLinks
</Directory>
# This should be changed to whatever you set DocumentRoot to.
<Directory /usr/local/etc/httpd/htdocs>
# This may also be "None", "All", or any combination of "Indexes",
# "Includes", or "FollowSymLinks"
Options Indexes FollowSymLinks
# This controls which options the .htaccess files in directories can
# override. Can also be "None", or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit"
AllowOverride All
# Controls who can get stuff from this server.
<Limit GET>
order allow,deny
allow from all
</Limit>
</Directory>
# You may place any other directories you wish to have access
# information for after this one.

Build your personalized config file, conf/access.conf, and fill it in following the same order as the example above. In a way, this is your most important configuration file because it controls access to your system, so take your time. The following is a walk-through of the choices I made for my server access configuration file:

# /usr/local/etc/httpd/ should be changed to whatever you set ServerRoot to.

<Directory /usr/local/etc/httpd/cgi-bin>

Options Indexes FollowSymLinks

</Directory>

Rather than just being a one line item, the Directory directive is a statement. It begins with setting the directory. Just take a look in your server configuration file and see what you set ServerRoot to, in case you changed it from /usr/local/etc/httpd/. Then, add cgi-bin after it. In my case, I left it at the default, so I'll just enter:
<Directory /usr/local/etc/httpd/cgi-bin>
Now, tell your server the features available in this directory (Options). Your choices are the following:

None enables no features in this directory. This is the ultimate security, as someone using your Web server would be completely unable to do anything in this directory.
All enables all features in this directory. Don't use this one unless you really want to give users access to everything in the particular directory, including users' home directories. In fact, if a simlink is created from a user's home directory to a directory that you don't want outsiders to be in, this option will let outside Web users employ that link.
FollowSymLinks enables the server to follow simlinks out of this directory. Watch out, though, because if the simlink is in a user's home directory, a link may created to something that you don't want outsiders to access.
SymLinksIfOwnerMatch enables the server to follow simlinks out of this directory if the file the link points to is owned by the same person who made the link. This one takes care of part of the simlink problems mentioned above. Outsiders won't be able to follow a link unless the file it's linked to is also owned by the user.
Indexes enables the server to let people request indexes of the current directory and lets outside users get HTML indexes of the directory they're in. If you don't use this option, outside users won't be able to get HTML indexes, but would be able to load any other index files in this directory. If you intend to offer HTML file indexes with descriptions, use this option.
Includes enables the server to let users offer information on the fly, such as the date a file was last modified.

After taking a look at the options that are available, and knowing that I have full control over this directory as root, I choose to have the following as my next line:
Options Indexes FollowSymLinks
I'm not too worried at the moment about simlinks in user home directories because this isn't one.
Now, I end this particular item with the following:
</Directory>

# This should be changed to whatever you set DocumentRoot to.

This Directory directive is also a full statement rather than a one line item. Follow the same pattern as before, but this time in reference to the directory you used for ServerRoot (I used /usr/local/etc/httpd/htdocs). My first line for this section will be the following:
<Directory /usr/local/etc/httpd/htdocs>
In this case, I have full control over the directory again as root, and I want people to be able to access all of the documents here. I'll use the following option:
Options All
Now enter the term that will control which .htaccess options the server can override in individual directories. Although you have a number of options available, I highly recommend the following:
AllowOverride All
This way, if you want to override something, it will be in the .htaccess files. If not, nothing is overridden.
Now set the limits on who can get files from the server, as follows:
<Limit GET>
You can both deny and allow. Tell your server which list to look at first: the deny list or the allow list. Notice that there is no space between deny and allow in the following code:
order deny,allow
Unless you actually do want to deny any hosts access, all you need to add now to finish this section is the following:
allow from all
</Limit>
</Directory>
Now set user home directory access.

If you want to set permissions for other directories, just add a new directory statement for each one after the one you just added.

Instead of doing an individual statement for every user's home directory, focus instead on /home. The first line of the directory statement is the following:
<Directory /home>
In this case, you don't want any .htaccess files to override anything because a user could just create one and weaken your security. So, instead of allowing anything to be overridden, specify none as follows:
AllowOverride None
Now, set what kinds of files people can access in the home directories. I recommend using the Indexes option and the Includes option (in case a user would like to write a small script to keep track of access numbers, date last modified, etc.)
The only other items in users' directories that outsiders will be able to access through the Web servers will be pages in their public_html directories (unless you changed public_html to another directory name). So, the next lines (as this is the end of this section) are the following:
Options Indexes Includes
</Directory>

Pat yourself on the back. You have finally finished configuring your server!

Selecting Server Scripts

There are a number of scripts that come with the Web server software that allow you to personalize your setup a bit. Even if you don't want to use any of these scripts, they can serve as examples. The cgi-bin directory of your server files contains a number of sample scripts, which can provide useful lessons on how to write your own.

The Date Script

The script date is a simple but useful one for seeing how httpd scripts work.

#!/bin/sh

DATE=/bin/date

echo Content-type: text/plain
echo

if [ -x $DATE ]; then
         $DATE
else
         echo Cannot find date command on this system.
fi

This script breaks down as follows:

#!/bin/sh
This runs the sh shell to interpret everything that follows in this script.
DATE=/bin/date
Setting the variable DATE to the full path for the program that determines the date.
echo Content-type: text/plain
This code displays Content-type: text/plain on your screen.
echo
This shows a blank line on your screen.
if [ -x $DATE ]; then
$DATE
If there is a program at the location assigned to DATE, the program is run, and the output is displayed.
else
echo Cannot find date command on this system.
fi
If there isn't a program at the location assigned to DATE, Cannot find date command on this system. is displayed, and the program ends.

If you want to make a script to run other small programs similar to date (which require no input and have plain text output), all you need to do is replace the appropriate terms and you've got a new script!

The Finger Script

The finger script is useful to see how forms are handled.

#!/bin/sh

FINGER=/usr/ucb/finger

echo Content-type: text/html
echo
if [ -x $FINGER ]; then
     if [ $# = 0 ]; then
          cat << EOM
<HTML><HEAD><TITLE>Finger Gateway</TITLE></HEAD><BODY>
<H1>Finger Gateway</H1>

<ISINDEX>

This is a gateway to "finger". Type a user@host combination in your browser's
search dialog.<P>
EOM
     else
          echo \<PRE\>
          $FINGER "$*"
          echo \</PRE\>
     fi
else
     echo Cannot find finger on this system.
fi
cat << EOM
</BODY></HTML>
EOM

Once again, let's take this script apart. Notice the similarities to the date script:

#!/bin/sh
This command runs the sh shell, which will interpret the rest of the script.
FINGER=/usr/ucb/finger
This sets the variable FINGER to the full path where the finger program is found.
echo Content-type: text/html
echo
This displays Content-type: text/html and a blank line on your screen.
if [ -x $FINGER ]; then
This code looks to see if there's really a program where the value of FINGER claims there is. If nothing is found at this location, the script proceeds to item 15.
if [ $# = 0 ]; then
This starts a statement that prints out a header for the finger program if no arguments ( $# = 0) were entered. If arguments were entered, the script jumps to item 11.
cat << EOM
The script displays what it sees until it reaches the letters EOM, then continues normally.
<HTML><HEAD><TITLE>Finger Gateway</TITLE></HEAD><BODY>
<H1>Finger Gateway</H1>
This assigns an HTML header, title, and smaller (H1) header line to the results page.
<ISINDEX>
A precursor to the HTML <FORM> command, this will provide an input form block where the user can enter an account to finger.
This is a gateway to "finger." Type a user@host combination in your browser's
search dialog.<P>
This is another HTML formatted statement for the results page.
10. EOM
This marks the end of this if statement. The script jumps to fi if no parameters were entered.
11. else
This begins the statement that will happen if item 5 did find parameters.
12. echo \<PRE\>
This displays "<PRE>" on the screen. The slashes (/) are necessary to tell the script that you want to actually print the brackets (< and >).
13. $FINGER "$*"
This executes the program the FINGER variable points to. The $* refers to the parameters passed to finger.
14. echo \</PRE\>
fi
This displays </PRE> on your screen then ends the inner if statement.
15. else
This continues with the portion of the program that handles the absence of a FINGER program.
16. echo Cannot find finger on this system.
This displays Cannot find finger on this system. on the screen.
17. fi
This ends the outer if/then statement.
18. cat << EOM
The script displays everything it sees until it comes to EOM.
19. </BODY></HTML>
This closes the body of the results page.
20. EOM
This command ends the script.

Note that the first four items of this script are virtually identical to the date script. You will start every script in a similar way.

The source for the other sample scripts is available in the cgi-bin directory. Take a look at them to see what kinds of programs you can write.

Moving Server Files Where They Need to Be

Now for a bit of cleanup work: you've got everything set up, but your files are still sitting in the directory that you decompressed them to.

Look in your server configuration file and remind yourself of what you used for ServerRoot. Now, move all of the following into the appropriate directory (in my case I used /usr/local/etc/httpd):

The file httpd
The conf directory
The logs directory
The support directory
The cgi-bin directory

Make sure your logs directory's permissions and ownerships are set so it can be written to by whoever the Web server is set to run as. In my case, this user is ftp, and the group is bin (set with the User directive in the configuration file).

Starting Your Web Server

Here's the final step: actually starting your Web server! You may want to find a friend out on the Internet to help you test it when it's up.

Set things up so that the server will automatically start every time you boot your system. To set this, do the following:

If you configured your server as standalone instead of inetd, you don't need to follow this process.

Edit the file /etc/services.
Add the following line:
http 80/tcp
You don't have to use port 80, but it's the standard http port, and people will have to use the port number in the URL's going to your links if you use another number.
Save and exit /etc/services.
Edit the file /etc/inetd.conf.
Add the line:
http stream tcp nowait nobody /usr/local/etc/httpd/httpd httpd

Look to see if this line already exists first. It may already be there.

If you didn't use /usr/local/etc/httpd/httpd, be sure to use the proper path.

If you didn't use FTP for the user the server runs as (remember, I used FTP), be sure to replace it with the proper user.

Close and save /etc/inetd.conf.
Log on as root.

Type su at your prompt if you're not already root, and then type your root password.

Type ps aux.
Find the process number for inetd.
10. Type kill <process#> -HUP.

You may see some warnings about unsupported features (such as max servers) as your httpd starts up. However, if it starts and works okay otherwise, don't worry about it. I ran into this myself and had no problems

If you used su, remember to type exit to leave the superuser mode at this point.

From now on, one of the processes that starts automatically when you reboot your system will be httpd.

Setting up X Windows

Before we can proceed to setting up Web clients, we'll want to set up X Windows. After all, while there is a non-graphics oriented Web clients (lynx), but the beauty of the World Wide Web is in the graphics!

Also, X Windows is to Linux what MS-Windows is to MS-DOS: a graphical interface. Yet another reason to install it!

Remember, you need to have purchased the proper monitor and graphics card to run X Windows (see the Hardware How-To for which hardware is appropriate).

Also, you need to have at least 8M of RAM on the machine you're running X Windows on, and at least another 8M of swap space. If you're one to do 5 things at a time while using a GUI (Graphical User Interface, like MS-Windows), you'll likely want 16M of RAM.

Setting Up the XF86Config File

The main part to setting up X Windows is the XF86Config file. Follow the instructions in this section carefully. If you find you're getting confused or are unsure of what to do, consult the documents in /usr/X386/lib/X11/doc.

Read through this whole setup section before you proceed.

To set up your XF86Config file, do the following:

Log in as root, then go to the directory /usr/X11R6/bin.
Type SuperProbe. This program will take a look at your video card and tell you the details you need to know. Write this information (chipset, memory, and RAMDAC) down for use while running the next program.
Type xf86congfig. This will start a program that makes your life much easier. It configures most of your X Windows items for you, especially the graphics-intensive ones! Hit Enter to continue and follow the instructions. I'll walk you through the items I entered during my configuration.
First is the mouse configuration. I have a Logitech mouse that's Microsoft compatible, so I'll choose the Logitech MouseMan (Microsoft compatible) option-number 6. As a side note, I also select Yes to ChordMiddle, which lets my middle mouse button (it's a 3 button mouse) function as a double-click from the right button. I then say No to Emulate3Buttons because I already have a three button mouse. Finally, I enter my mouse's device name, which is /dev/mouse.
Next is keyboard configuration. I don't need International character support for my keyboard, so I select No.
Now we reach the monitor section. You'll need your monitor manual for this, unless your monitor is in the following file: /usr/X11R6/lib/X11/doc/Monitors. If it's in this file you can find the numbers you need there. In either your manual or the Monitors file, find the Horizontal and Vertical synch rates your monitor is capable of.

Don't select a synch rate for either horizontal or vertical that's higher than your monitor can support! You can potentially damage your equipment this way.

You're given a table with ranges to choose from for the Horizontal synch rate. Pick the item in the table that best suits your monitor and card. In my case, I chose 31.1 - 64.3; Monitor that can do 1280x1024 @ 60 Hz. I chose this option because my monitor manual tells me that I can go as high as 64 khz horizontally, and vertically 50 to 90 Hz. The numbers from my manual fall into both of the ranges listed, and my monitor is capable of 1280?.

If your monitor doesn't match at all with the Horizontal options offered, you can enter your own numbers (same goes for the Vertical options).

Now I choose my Vertical synch rate from a table. Once again, make sure you don't overstretch what your monitor can do! My monitor falls into the option 50 to 90 Hz.
Now you need to assign the following information to your monitor:

Identifier string Give a name to the monitor. It can be technical (Exact type of monitor), or nontechnical (Dee's Monitor).
Vendor The manufacturer of your monitor. This is displayed, but not actually used by X Windows.
Model The model of your monitor. Once again, this is simply for display.

Next you configure the video card. You have the option to look through a database, and I chose to do so. Let's say my card is a Paradise/WD 90C33, I look through the table and find Paradise/WD 90CXX. I choose this option.

If you're not sure, you can either call the vendor where you bought the machine, the manufacturer who made the card, or pick the generic VGA option.

The program now gives you information about your card, and tells you which server you need to use. It tells me that I'm using the XF86_SVGA server, which is the generic VGA server.
10. Let the program install the server it recommended after you gave it the card information. Let it set up the symbolic link, and let it put the symbolic link in the default location.
11. Now, you're asked how much VRAM (Video RAM) you have. SuperProbe would have told you this information. In my case, it's 1024K (1M).
12. Now, just like you did with the monitor, you need to enter a Identification, Vendor and Model information. Once again, this is used for display, not by any software.
13. Next it asks you about programmable clock chips. If SuperProbe told you that you have one, you need to select the proper one. If it didn't (my card doesn't have one), then hit Enter to skip this option.
14. Now the setup server probes your monitor and video card (if it refers to clock probing, this is what it means). Let it run its probe program, and you can watch the monitor go through all sorts of graphics modes, with some clicking and static noises that can be a little frightening your first time around. Once it's done, it gives you a list of clock numbers, which are timing values for your monitor and video card. Having this information ahead of time lets you avoid having to go through this process every time you start X Windows.
15. The next option you're given is to re-order the default graphic modes and order they're used in. In my case, I'm happy with the initial defaults, so I choose Ok.
16. Finally, you're asked where to write the config file! Select No for the first option it gives you. Select Yes to write it to the default of /usr/XllR6/lib/X11/XF86Config. Once finished, the configuration program exits.

Starting X Windows

Now, to start X Windows, you just type startx. It will start up in your first default graphics mode (see figure 7.2).

Fig. 7.2 Here's the initial X Windows window.

You can use Alt-+ to switch between graphics modes.

To get a menu of options from X Windows, click the left mouse button.

In the upper left hand corner of your window is a box divided into nine parts. Each of these parts is a virtual console, where basically you're using one huge screen that's nine times bigger than your monitor. You can click each of the small parts to jump to a different part of the larger screen.

To exit X Windows, click the mouse button for the menu and drag to Exit Fvwm, and then to Yes, really quit.

Installing Netscape

There are a few Web browsers out there you can choose from. There's lynx, which is already installed on your system and is text only. There's also Netscape for Linux, which you can find by FTP at ftp1.netscape.com in the file /netscape/unix/netscape-v112-export.i486-unknown-linux.tar.Z (the version number may be different than 112 when you go to fetch the file). If you can't get into the server I listed here, you'll be given a list of mirror sites you can use instead.

You don't have to leave X Windows to do this process. You can open a shell window within X Windows. To do this, click your left mouse button (while on the blue background) to get the menu, go to Shells, and choose one of the shells.

When you get the file, uncompress it, gunzip it, and follow the instructions in the README file. These instructions are:

Go to the directory /usr/X386/lib/X11. If there isn't an nls directory there, copy the nls directory and its contents that came with Netscape into this directory. The items in this directory are required for Netscape to run, and since you can only get Netscape as a binary instead of as source, they've provided them just in case.
Copy the netscape binary to /usr/X11/bin. This is where all X Windows binaries go. Also copy moz2_0.car (a JAVA applet program Netscape needs to have handy) to /usr/local/netscape/java/classes.
Now, let's add Netscape to our X Windows menu. Go to the directory /usr/X11/lib/X11/fvwm.
Edit the file system.fvwmrc. Every Netscape menu is contained in this file, and pointers to every program you'll use.
Go to the Applications section. Where in this section you put it is your choice, the items it contains will show in the menu in the order they're listed in the file.
Add the following line:
Exec "Netscape" exec netscape &
This tells it that when you choose the Netscape menu option, X Windows should run the program /usr/X11/bin/netscape. Without the &, Netscape would try to replace X Windows instead of running within X Windows.

Testing Your Web Server

Now that you have two Web browsers (lynx and Netscape) you can test your server! First, we'll create a very simple Web page, and then we'll use it to test the server out.

Creating a Test Page

Now, I'll show you how to create a simple Web page so you can use it to test out your server. To create this page, do the following:

Log in as root
Change to the directory you set DocumentRoot to. The default was /usr/local/etc/httpd/htdocs.
Edit the file index.html.
Enter the following:
<HTML>
<Head><Title>My first test page</Title></Head>
<BODY>
This is my test page.
</BODY>
</HTML>
This is the format for your most basic possible Web page. Note that each item has <ITEM> and </ITEM>. The first statement opens, the second closes, and what's in the middle is defined by the items surrounding it. For example, everything within the document is within HTML. Everything within HTML is within BODY.
Save and exit the page.

Accessing the Page To Test Your Server

Now that you've created your test page, you can use Netscape to access it as your test. To test your server, do the following within X Windows:

Click the left mouse button, and drag down to Netscape (see figure 7.3)

Fig. 7.3 Choosing Netscape from your X Windows menu.

You'll get a license agreement. Read it and click Accept.
Netscape will open (see fig. 7.4)

Fig. 7.4 Netscape in Linux X Windows.

Click the Open button. A dialog box appears.
Enter the URL for your main page. For example, RENAISSOFT Since you're using Netscape, you can drop the index.html, the program assumes it as its default.

You should also test your Web pages from lynx, the text browser. To do so, you just need to get to a shell prompt and type lynx <URL> (for example, lynx http://www.renaissoft.com/index.html, and this time you would have to include the index.html). The reason you should also test in lynx is that errors you made in your HTML coding don't always show up in Netscape, which is somewhat forgiving. However, they will show up in lynx.

Help on creating Web pages using HTML can be found all over the Web. A helpful reference is KRYPTON.

QUE Home Page

For technical support for our books and software contact support@mcp.com