Linux, Unix, /etc

Danger Will Robinson! You are now entering a condescending Unix user zone!

Linux Internet Server: Providing Internet Services

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.

This article builds on my three earlier articles on installing and configuring Linux for Internet access, listed here: Set Up a Linux Internet Server Set Up a Firewall Set Up a Mail Hub

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 are 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 distributions, 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):

/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 generate 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, make 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 file 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 other 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/access_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.

The Per-Directory Access-Control File

In addition to the three configuration files discussed above, server 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.

Getting 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"). [PAUL: Cause all the other platform abbreviations are three character names, that's why. ;-)] 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 good job of explaining how to set up the anonymous FTP hierarchy. If you don't have the man pages on your system, they are <A HREF="http://www.landfield.com/wu-ftpd/man.html">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 priniciple of not giving more authority that is 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 memoires. 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 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 entry is divided into two directories. Firstly, the root directory which will be the argument to the chroot() call, and secondly, the user's home directory relative to the root directory, the two halves being separated by a . [PAUL: Say a few words about this type of guest account. Thanks.] [ED: I rewritten the above so that it explains what a guest account is.] 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 allowed 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 applicable 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} {class of user}.

The when parameter (field three) may be login or cwd=directory, being respectively when the users listed in the fourth field, lcass (all users by default if omitted) log-in, or when they change to the directory in which the readme file is located. 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 cookies" 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  addrglob

Where addrglob can be any pattern representing one or more Internet addresses, either hostnames or IP-address numbers. [PAUL: Please provide a few actual examples.] 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 use of Wietse's 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. tcpd logs the client host name of incoming telnet, ftp, rsh, rlogin, finger etc. 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 TCPD wrappers 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 changed 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}'`

Conclusion

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 1997

[back to Linux, Unix, /etc]