Make your own free website on Tripod.com
CMPnet Click here to visit Adaptec!



networkcomputing
 Site Guide
 Latest Updates
 '96-'98 Articles Index

 Search NWC:
 
 date
 best match
 

 Technology Guides
 Internet/Intranet
 Infrastructure
 Wide Area Systems
 Network Management
 Collaborative Computing
 OSes & Services
 Security
 Middleware
 Servers & Peripherals

 On Our Site
 UnixWorld
 Network Design Manual
 WANsites
 Careers 
 Interactive Buyer's Guide
 Interactive Report Card
 Online News
 Real-World Labs
 E-Mail Poll
 Frezza's Forum
 Workgroup Computing
 ITpro Downloads
 Well-Connected Awards

Sponsored by:

 CMPnet 3-D Site Map

 Site Services
 Advisory Forum
 Network Computing Links
 Best Jobs USA
 Subscriptions
 Advertising
and Marketing

 N+I
Visionary Articles

 Web Connection
 Industry White Papers
 Special Supplements
 Bookstore
 Newsletter
 Reprints

CMPnet Resources
 Home
 Site Map
 Search
 Ad Info

 Free E-mail
 Sign Up Now 

Get PointCast - free!



Linux Internet Server: Providing Internet Services Part 4

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:

Introduction

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.

Internet Services And Linux

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.

HTTP

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.

Getting Apache

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

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.

Installing Apache

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 Apache

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.

FTP

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.

Gettin g wu-ftpd

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 wu-ftpd

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.

Configuring wu-ftpd

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

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.

Configuring telnetd

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

Invoking Services with inetd

httpd

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

FTP

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

Telnet

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

Telling inetd about your changes

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}'`

Con clusion

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.

Author Biography

Paul Dunne is a writer and consultant who specializes in Linux. He has a home page that describes in more detail what he does.

Print This Page


e-mail Send as e-mail


NWC Home Site Guide WANsites UnixWorld Network Design Manual
Technology
Guides
Careers Network Computing Links ITpro Downloads Interactive Buyer's Guide
Online News Latest Updates Real World Labs Subscriptions WorkGroup Computing



HOME



CMPnet Click here to visit Adaptec!