Continuing on from our last tutorial -- which was about
setting up a Linux box to server as an Internet mail-hub -- in
this installment we take a look at some other Internet services
that can be provided. We will consider three of the most common
and useful services: HTTP (WWW), FTP and Telnet.

HTTP is probably the most likely service you'll want to
provide from your Linux box. FTP and Telnet can be useful
subsidiary services too, especially if you host Web sites for
other users, and need to provide them with some ability to
maintain their site content.

Linux uses the inetd ``super server'' to control what Internet
services your machine makes available. Rather than having all
the network daemons that you might require running all the time,
inetd can handle all incoming requests for service, and start up
the appropriate daemon only when a request for the associated
service arrives. This makes much better use of system resources
for services that a
re not heavily used. It may be appropriate
for example, if you want to offer Telnet access to the host, but
do not expect this to be heavily used.

Inetd consults two files,
/etc/inetd.conf
and
/etc/services
. The
inetd.conf
file is
for daemon configuration and
services
is used to
describe the services that are available from the TCP/IP
subsystem. This latter file specifies the port number and
protocol (tcp, udp) for each service. As we proceed to deal with
individual services, I show how each one can be set to be run
from the inetd server, not just invoked as a stand-alone
application.

The most popular Internet service today is undoubtedly the
World Wide Web. Linux can run any of the popular Unix HTTP
servers. The one we'll be using as an example is Apache,
probably the best of the freeware HTTP daemons.

Apache is the server of choice for most Linux distrib
utions, so
chances are you can install the binary directly from your distribution
CD. If not, both source and binary packages are available from
the Apache web site
.

Information on the latest version of Apache can be found on
the Apache web site
, giving the current release, any more recent beta-test
release, and details of mirror web and anonymous FTP sites. If
you already have a binary distribution, skip to
Installing Apache
; otherwise, read the next
section for how to compile the server.

Compiling Apache actually consists of three steps: selecting
modules, creating a configuration, and finally compiling the
program. All configuration of Apache is performed in the src
directory of the Apache distribution. Change into this directory
first.

Select modules to compile

This is done by editing the configuration file
-- called,
logically enough,
Configuration
. Uncomment those
lines in this file corresponding to those optional modules you
wish to include (among the Module lines at the bottom of the
file), or add new lines corresponding to additional modules you
have downloaded or written.

It is possible to comment out some of the default modules if
you are sure they will not need them (be careful though, because
many of the default modules are vital for the correct operation
and security of the server). You should also read the
instructions in the
Configuration
file to see if you
need to set any of the Rule lines.

Run configure script

Normally, you can just type ``./Configure'' to run the
Configure script as shown (with some sample output):

These steps g
enerate a Make file for use in the next stage.
It also creates a Make file in the support directory, for
compilation of the optional support programs.

make

The modules included with the Apache distribution have been
tested and are used regularly by various members of the Apache
development group. Additional modules, contributed by members or
third parties with specific needs or functions, may be found at
the Apache
Web site contribution page
. There are instructions on that
page for linking these modules into the core Apache code.

If you compiled Apache from source, you will have a binary
file called
httpd
in the src directory. A binary
distribution of Apache will supply this file. The next step is
to configure the program. Apache is designed to be configured
and run from the same set of directories where it is compiled.
If you want to run it from somewhere else, ma
ke a directory and
copy contents of the conf, logs and icons directories there.

Configuring server operation is done by setting directives in
three text-based configuration files with your favorite text or
program editor. By default, these files are located in the conf
directory and are named
srm.conf
,
access.conf
, and
httpd.conf
. Chances
are you'll need to customize all three files.

To help you get started, the conf directory contains
distribution-file templates named
srm.conf-dist
,
access.conf-dist
and
httpd.conf-dist
.
Make copies of these files named
srm.conf
,
access.conf
, and
httpd.conf
,
respectively. Before changing these files read the
comments supplied in these files carefully. Failure to edit
these files correctly could cause your server to quit working or
perhaps operate insecurely. You should also have an additional
f
ile in the conf directory named
mime.types
, but
this file rarely needs changing.

The
httpd.conf
configuration file

First configure
httpd.conf
, which controls
general attributes of the server: the port number the server
listens on, the user-ID the server runs as, and much more.
Each configuration directive in the file is on its own line, and
is often followed by a comment explaining the directive. I've
discussed some of the more important directives below.

ServerType standalone

ServerType is either inetd, or standalone. If you are
running from inetd, the next relevant variable is ``ServerAdmin''
(see below). A Web server should generally run standalone in a
production environment to minimize invocation overhead.

Port 80

The port on which the daemon listens for requests from a
client. For ports less than 1024, you will need to invoke httpd
as root. However, most of these so-called ``well-known ports''
are reserved for ot
her services. Only port 80 is reserved for
the HTTP service, the protocol used by the Web.

Group identity for the child process. If you wish httpd to
run as a user or group different from the default (nobody), you
must invoke httpd as root, and then it will switch user and group
identity during initialization.

ServerAdmin you@your.address

The address to which problems about the server should be
mailed. Displayed for the user during certain error conditions,
such as the 500 class of server errors.

ServerRoot /usr/local/etc/httpd

The directory that contains the httpd binary.
Configuration files and log files are generally contained in
conf and log subdirectories.

ErrorLog logs/error_log

The location of the error log file. If this does path does
not start with /, ServerRoot is assumed prefixed to the path
name.

TransferLog logs/acce
ss_log

The location of the transfer log file. The server
writes an entry in this file for each request made of it.

PidFile logs/httpd.pid

The server writes its process id (pid) number to this
file.

ServerName your.other.name

Use this directive on systems where the gethostbyname() call
may not work on the local host or where the host name returned
should be a DNS alias, such as www.yoyodyne.com instead of, say,
host1.yoyodyne.com. However, such an alias must be defined, say,
with a CNAME DNS aliases record.

The
srm.conf
configuration file

Next configure the
srm.conf
file, which defines
the location of your HTML documents and CGI scripts. It's also
employed to establish special functionality like server-parsed
HTML (server-side includes) or internal imagemap parsing, etc.

DocumentRoot /usr/local/etc/httpd/htdocs

The top-level directory of your document tree, from which
files are served. By default,
/usr/local/etc/httpd/htdocs
. Note that symbolic
links and aliases may be used to point to other locations.

UserDir public_html

Lets users serve documents from their home directories
without necessity of creating links to them. Here's an example:
if you were to specify
UserDir Web
then a request
for the file
~user/foo.gif
would cause the server to
actually retrieve
~user/Web/foo.gif
. Specify
DISABLED to defeat this feature.

DirectoryIndex index.html

This directives specifies the name of the pre-written index
file for a given directory. (This file is returned automatically
if the directory, but not a file in that directory, was specified
in the request).

AccessFileName .htaccess

The name of the file to look for in each directory for access
control information.

DefaultType text/plain

DefaultType is the default MIME type for files of unknown
file-name extension. That is, there's no entry in the
mime.types
file (or entry in
srm.conf
)
that maps the given file-name extension to a MIME type.

AddType type/subtype ext1

AddType allows you to add or override an entry in the
mime.types
file. Generally, you would use this
directive rather than changing the
mime.types
file.

AddEncoding x-compress Z

AddEncoding x-gzip gz

AddEncoding directives define new encoded file types, which
are used by browsers that have the capability to decode
compressed files ``on the fly''. Except for some X Window System-
based browsers, most browsers don't support this uncompression
feature.

Redirect oldpath newURL

Redirect allows you to direct clients to documents that have
been relocated, perhaps to a different server.

Alias /icons/ /usr/local/etc/httpd/icons/

Use this directive to create a virtual document (or
directory). Any accesses to it will be satisfied by a different
file or directory. Multiple Alias directives may appear in the
configuration file, up to 20.

ScriptAlias /cgi-bin
/ /usr/local/etc/httpd/cgi-bin/

Use this directive to create a virtual directory where
accesses to that directory are satisfied by returning the output
of a CGI program in that directory. Multiple ScriptAlias
directives may appear in the configuration file, up to 20.

AddType text/x-server-parsed-html .shtml

If the server supports server-side includes, then it
recognizes this special MIME type to identify files (by file-name
extension) subject to inclusion. Specify .html or .htm to
support server-side inclusion in most of your documents.
Caution:
This approach can place a significant
additional load on the server.

AddType application/x-httpd-cgi .cgi

Specify this MIME type to have the server execute files whose
names end with .cgi as CGI programs, instead of displaying their
contents. Although, any available (not already used) file-name
extension could be used here, .cgi is commonly used.

The
access.conf
configuration file

Finally, configure the
access.conf
file. The
default configuration enables all features for all external users
without any restrictions. Chances are you'll want to impose some
security restrictions, such as to prevent directory indexing. In
the examples that follow, assume that
/usr/local/etc/httpd
is the document root
directory.

To illustrate the file structure, the following directives
could be used to impose the default minimal-security
configuration:

Change the sectioning Directory directives as necessary
if you don't employ the directories we use in our example.

Remove the Indexes optio
n to prevent users from listing
files.
Recommendation:
at least disable directory
indexing for the CGI bin directory because users don't need to
list files in that directory for security reasons.

Change the parameter for the AllowOverride option from All to
None to disallow override of your security directives in the
access.conf
file by a per-directory access-control
file (often named
.htaccess
) that could be installed
by another local system user.

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

All entries in the
access.conf
file are
specified on a directory basis using the
<Directory>...</Directory> sectioning directives.
All the directives within a section only apply to the specified
directory (and all subdirectories, unless overridden with another
sectioning directive).

Options

This directive may have values ``None'', ``All'', or any
combination of ``Indexes'', ``Includes'', or ``FollowSymLinks''.
Th
e specification of ``Indexes'', ``Includes'', or
``FollowSymLinks'' enables directory indexing, server-side
includes, or the ability to follow symbolic links to locate a
document, respectively.

<Limit GET>
order allow,deny
allow from all
</Limit>

Limit is a sectioning directive used within the Directory
sectioning directive to control the resources a client can
access. The argument to Limit can be one of GET, PUT, or POST to
specify the request method. The order and allow subdirectives in
this example specify that the server will allow resource access
to any user (from any system).

There are many more directives available for customizing
server operation, but their discussion is beyond the scope of this
article. More information about these directives can be found
at this
Web page
.

The Per-Directory Access-Control File

In addition to the three configuration files discussed above,
serv
er behavior can be configured on a per-directory basis by
using the per-directory access control file named
.htaccess
, by default. This name can be changed
with the
AccessFileName
directive in the
srm.conf
configuration file.

The
mime.types
File

This file defines the relationship between file-name
extensions for files on the server and the MIME type associated with
the file. When a browser requests a file, the MIME type of
that file is sent from server to browser so the browser
knows how to handle the file.

Generally, you don't need to edit this file. If you need to
define a new MIME type, then use the AddType directive discussed
earlier.

Nowadays, FTP (File Transfer Protocol) service is often
handled through a Web server. Of course, it can be provided as a
stand-alone service, though, and -- as such -- is particularly
useful as a means of uploading files to the server.

The FTP daemon developed at Washington University in St.
Louis and named wu-ftpd is the FTP server daemon chosen by most
Linux distributions, so it may well be on your system already.
If not, it is available on many Linux and other FTP sites
throughout the world. Its home (primary) site starts at
this
directory at the Washington University FTP site
.

Compiling the FTP server is simple. There are a whole set of
path names that can be changed in
src/pathnames.h
,
but, it is quite sensible to leave them set to their default
values. So, without further ado, type ``build lnx'' (No, I don't
know why it isn't ``build linux''). Once the compile is over,
change user identity (with
su
) to the root account
and type ``build install'' to install the new FTP server
programs.

Copy the
ftpconversions
,
ftpusers
, and
ftpgroups
files to the locations specified in
pathnames.h
. There are examples of these files in the
doc/examples
directory.

Create the directory for the SITE EXEC programs, as specified
in
pathnames.h
. Put any executables that you want
anonymous users to be able to run in this directory. However, be
careful what you put here for obvious security reasons.

Note that if you are using the pre-compiled wu-ftpd that comes
with Slackware, be aware that some versions of this distribution
have an incorrect setting for _PATH_EXECPATH in the ftpd binary
(/bin). Recompile with this set to a special path, such as
/bin/ftp-exec.

Run
bin/ckconfig
to make sure that all the
support files are properly installed.

The ftpd(8) man page that came with your operating system
should do a goo
d job of explaining how to set up the anonymous
FTP hierarchy. If you don't have the man pages on your system,
they are
available on-line
.

At the very least, you will need the directory
~ftp/bin
set to execute-only (mode 111) with a copy of
ls
also
set to execute-only, and the directory
~ftp/etc
set
to execute-only, with an edited copy of
/etc/passwd
and
/etc/group
. The only reason for the password
files is so that directory listings will show user and group names
rather than numbers. The directories are execute-only to prevent
the curious from snooping around. We are following the general
principle of not giving more authority than is actually needed.

The
~ftp/pub
,
~ftp/usr
, and
~ftp/var
directories should all be set to
mode 555 (read and execute permission enabled for all user
categories), and
/incoming
to set to mode 0333
(write and execute permission enabled). Make sure that you have
an
/etc/shells
file that lists all valid shells on
your system. Otherwise, those who have shells not listed there
will not be able to use this FTP facility.

/etc/ftpaccess

This is the main ftpd configuration file. In what follows,
I've extracted lines from a typical file, and followed them with
a discussion of the sample lines:

The first directive here is one that denies access to the FTP
server from certain hosts (those in the ``example.com'' domain).
The three example lines are commented out, but left in the file
to serve as aide memories. The general form is
deny
address message-file
, where, by convention, the
message file contains an explanation of why access is being
denied.

loginfails 3

The loginfails directive specifies the maximum number of
unsuccessful log-in attempts that will be tolerated until the
server logs a ``repeated login failures'' message and terminates
the connection. The default value is 5.

The class directive sets up a class of users. Here, the third
field (which we call the
type list
) can have the value
``real'' for users that already have accounts on the system,
``anonymous'' for anonymous FTP access, and ``guest'' for
guest accounts. The guest account keyword is for use with the
``guestgroup'' directive, which allows real user accounts to be
restricted.

guestgroup ftponly

In the example, if a real user is a member of ftponly, the
session is set up exactly as with anonymous FTP. In other words,
a change root system call (
chroot()
) is done, and
the user is no longer permitted to issue the USER and PASS
commands. The user
's home directory must be properly set up,
exactly as anonymous FTP would be. The home directory field of
the passwd file entry is divided into two directories: first, the
root directory, which will be the argument to the
chroot()
call, and second, the user's home directory
relative to the root directory, with the two halves separated by
a dot.

The standard use for this directive is to allow greater access
for local users than for remote users, especially if it's
unlikely that real users will be using their accounts from remote
locations. You can add a bit of security by not allowing the
``real'' user to log in from remote locations, as in the example
above.

passwd-check rfc822 enforce

Here, we specify the level of password checking that should be
done. Remember, the password for anonymous FTP is the user's
electronic mail address. The syntax is as follows:

The limit directive serves to control the load on the machine
by limiting the number of users who can be connected at any one
time. The general meaning is, ``limit
class
to
n
users at times
times
, displaying
message_file
if the user is denied access''. The check
is performed at log-in time only. Multiple limit commands can be
specified, but only the first applicab
le one is used. Failing to
define a valid limit, or a limit of -1, is equivalent to allowing
unlimited access.

The next two directives deal with informational messages
for users. Some sites are required to have these. The
readme
directive tells the user when the message file
was last changed, while the
message
directive holds
the actual text to be shown to the user.

readme README* login
readme README* cwd=*

The FTP daemon will notify the user at log-in time or upon using
the change working directory command that the file exists and was
modified on such-and-such date. The format of the entries is
readme
path when user-class
.

The
when
parameter (field three) may be ``login'' or
``cwd=
directory
''. The users affected are listed in the
fourth field. If this field is omitted all users are affected.

If
when
is cwd=
dir
,
dir
specifies
the new default directory that
will trigger the notification.
The message will only be displayed once, to avoid bothering
users. Remember, that when read-me messages are triggered by an
anonymous FTP user, the path name must be relative to the base of
the anonymous FTP directory tree. The optional
class
specification allows the message to be displayed only to members
of a particular class, where more than one class may be specified.

These message lines define various messages that are displayed
to the user when logging in or changing working directory, as
controlled by the
when
parameter. If
when
is
CWD=
dir
,
dir
specifies the new default directory
that will trigger the notification. The optional
class
specification allows the message to be displayed only to members
of a particular class. More than one class may be specified.

There can be ``magic cookie
s'' in the read-me file that cause the
FTP server to replace the cookie with a specified text string, as
specified here:

%T local time (format: Thu Nov 15 17:12:42 1990)
%F free space in partition of CWD (in kilobytes)
%C current working directory
%E the maintainer's email address as defined in ftpaccess
%R remote host name
%L local host name
%U username specified at log-in time
%M maximum allowed number of users in this class
%N current number of users in this class

The message will only be displayed once to avoid annoying the
user. When messages are triggered by an anonymous FTP user, the
path must be relative to the base of the anonymous FTP directory
tree.

log commands real

There are two types of ``log'' directives. One type (denoted
by ``commands'' in field two) enables logging of individual
commands by users. Here, the third field contains a comma-separated
list of keywords that denote the class of users -- either anonymous,
guest, or real -- for anonymous
FTP, guest-account, and
real-account access, respectively.

log transfers anonymous,real inbound,outbound

The second type enables logging of file transfers. The third
field in our example above denotes the user classification, like
in type-one logging. Here, the fourth fields denotes the
transfer direction. Thus, logging of transfers to the server
(incoming) can be enabled separately from transfers from the
server (outbound).

There are other directives in the file which I have not
mentioned, restricting my comments to the most important ones.
See the
ftpaccess(5)
man page for details of the
others. If you don't have the man pages on your system, they are
available on-line
.

ftphosts

The
ftphosts
file, also known as the FTP daemon
host-access file, has entries are of the form:

allow
username addrglob
deny
username addrg
lob

Where,
addrglob
can be any pattern representing one or
more Internet addresses, either hostnames or IP-address
numbers. For example:

allow bartm example.com
deny fred example.com 131.211.32.*

allows user ``bartm'' to connect from the host or domain
example.com, while denying access requests from user ``fred'' at
example.com or the IP address range 131.211.32.1-131.311.32.254.

ftpusers

This file describes the names of the users who are not allowed
to log into the system via the FTP server. This usually includes
accounts, such as ``root'', ``bin'', ``uucp'', ``news'' and other
system-related accounts. These accounts are used for
administrative purposes, and are not meant for general system
access.

Little configuration is necessary for the Telnet daemon, once
Linux is correctly installed. The
/etc/ttys
file
controls the default terminal type for the pseudo-terminals that
Telnet uses, and should normally be set to vt100, like so:

Generally, one would run the HTTP daemon standalone in a
production environment, typically started from one of the
run-command files on boot-up. However, you may wish to have it
invoked by inetd for occasional, testing purposes. To accomplish
the latter, add the following line to the
/etc/inetd.conf
file:

www stream tcp nowait root /sbin/tcpd /usr/local/etc/httpd

Please note the specification of Wietses Venema's
tcpd
``wrapper'' program in the fifth column. A traditional Unix entry
here would be the
name of the daemon program itself. Running all
the daemons from
tcpd
is a better approach.

Now,
tcpd
logs the client host name of incoming
Telnet, Ftp, Rsh, Rlogin, Finger and related requests. Further
security options available include: access control based on host,
domain and/or service; detection of host name spoofing or host
address spoofing; booby traps to implement an early-warning
system.