By Paul Dunne
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.
Questions regarding this article should be directed to
the author
This article builds on my three earlier articles on installing
and configuring Linux for Internet access, listed here:
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):
tiny1:/usr/src/apache_1.2b10/src$
./Configure
Using config file: Configuration
Using Makefile template file: Makefile.tmpl
+ configured for Linux platform
+ setting C compiler to gcc
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.
- User www
- User identity for child process instance that serves the
request. User nobody employed by default.
- Group wwwgroup
- 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:
<Directory /usr/local/etc/httpd/cgi-bin>
Options Indexes FollowSymLinks
</Directory>
<Directory /usr/local/etc/httpd/htdocs>
Options Indexes FollowSymLinks
AllowOverride All
<Limit GET>
order allow,deny
allow from all
</Limit>
</Directory>
Here are some modifications you may need to make:
- 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
compress
binary to the
~ftp/bin/compress
location.
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:
#deny *.example.com /var/spool/ftpd/message.deny
#deny 0.0.0.0 /var/spool/ftpd/message.deny
#deny * /var/spool/ftpd/msg.dead
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.
class local real,guest,paul 192.168.1.*
class remote guest,anonymous *
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:
passwd-check <none|trivial|rfc822> (<enforce|warn>)
The meaning of the allo
wed values can be described:
- none
- no password checking performed.
- trivial
- password must contain an @ character.
- rfc822
- password must be an RFC822-compliant address.
- warn
- warn the user, but allow them to log in.
- enforce
- warn the user, and then log them out.
limit dead 0 Any /var/spool/ftpd/msg.dead
limit local 2 Any /var/spool/ftpd/msg.toomany
limit remote 2 SaSu|Any1800-0600 /var/spool/ftpd/msg.toomany
limit remote 6 Any /var/spool/ftpd/msg.toomany
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.
message /etc/mirrors.msg cwd=/mirrors
message /etc/welcome.msg login
message .message cwd=*
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.
Telnet provides interactive log-in (shell) sessions on the
server. It is a basic network application that should always
come ready-installed with a Linux distribution.
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:
vt100 ttyp0
vt100 ttyp1
vt100 ttyp2
vt100 ttyp3
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.
More about ``Wrappers'' package can be found in
Wietse's
collection of tools and papers
.
The
/etc/services
file line -- which you shouldn't
need to change -- looks like this:
www 80/tcp httpd # WWW
The line to add to
/etc/inetd.conf
is this:
ftp stream tcp nowait root /sbin/tcpd /usr/local/etc/ftpd
Where the final field value must be change
d to point to where
the FTP daemon is actually installed, in case you moved it from
its original location.
The lines in
/etc/services
(again, they should
already be there) looks like this:
ftp-data 20/tcp
ftp 21/tcp
The line to add to
/etc/inetd.conf
appears:
telnet stream tcp nowait root /sbin/tcpd /sbin/in.telnetd
Where the final argument would need to point to the actual
location of the Telnet daemon.
The line in
/etc/services
(which you should not
have to change) looks like this:
telnet 23/tcp
Remember to send the hangup (HUP) signal to inetd, to make it
re-read the updated
/etc/inetd.conf
file. You can
do this semi-automatically using the command line:
kill -HUP `ps ax|egrep '?.*inetd'|awk '{print $1}'`
This article has examined how some of the more popular
Internet services that can be provided for a Linux system. It
contains the information you need to get all three services
up and running.
Paul Dunne is a writer and consultant who specializes in Linux.
He has a
home page
that describes in more detail what he does.
|
