Network servers and services are programs that allow a remote user to make use of your Linux machine. Server programs listen on network ports. Network ports are a means of addressing a particular service on any particular host. They are how a server knows the difference between an incoming telnet connection and an incoming ftp connection. The remote user establishes a network connection to your machine. The server program (the network daemon program) listening on that port accepts the connection and then executes. There are two ways that network daemons may operate. Both are commonly employed in practice. The two ways are:
stand-alone
The network daemon program listens on the designated network port. When an incoming connection is made, the daemon manages the network connection itself to provide the service.
slave to the inetd or xinetd server
The inetd and xinetd servers are special network daemons that specialize in managing incoming network connections. Each has a configuration file which tells it what program needs to be run upon receiving an incoming connection. Any service port may be configured for either of the tcp or udp protocols. The ports are described in another file that we will soon review. Depending upon which Linux you are using, you may be using inetd or xinetd.
We will only be focusing on inetd in this class, but we will return for the more complex (yet capable) xinetd in future courses.
There are two important files that need to be configured. They are the /etc/services file (which assigns names to port numbers), and the /etc/inetd.conf file (the configuration file for the inetd network daemon).
/etc/services
The /etc/services file is a simple database that associates a human friendly name to a machine friendly service port. Its format is quite simple. The file is a text file where each line represents and entry in the database. Each entry is comprised of three fields separated by any number of whitespace (tab or space) characters. The fields are:
name port/protocol aliases # comment
name
A single word name that represents the service being described.
port/protocol
This field is split into two subfields.
port
A number that specifies the port number where the named service will be available. Most of the common services have assigned service numbers. These are described in RFC-1340.
protocol
This subfield may be set to either tcp or udp.
It is important to note that an entry of 18/tcp is very different from an entry of 18/udp There is no technical reason why the same service needs to exist on both. Normally common sense prevails. It is only if a particular service is available via both tcp and udp that you will see an entry for both.
aliases
Other names that may be used to refer to this service entry.
Any text appearing in a line after a `#' character is ignored, and it is treated as a comment.
Take a look at /etc/services now.
/etc/inetd.conf
The /etc/inetd.conf file is the configuration file for the inetd server daemon. Its function is to tell inetd what to do when it receives a connection request for a particular service. For each service that you wish to accept connections, you must tell inetd what network server daemon to run (and how to run it).
Its format is also fairly simple. It is a text file with each line describing a service that you wish to provide. Any text in a line following a `#' is both ignored, and it is considered a comment. Each line contains seven fields separated by any number of whitespace (tab or space) characters. The general format is as follows:
service socket_type proto flags user server_path server_args
service
Is the service relevant to this configuration as taken from the /etc/services file.
socket_type
This field describes the type of socket that this entry will consider relevant. Allowable values are: stream, dgram, raw, rdm, or seqpacket. This is a little technical in nature. As a rule of thumb nearly all tcp based services use stream, and nearly all udp based services use dgram. It is only very special types of server daemons that would use any of the other values.
proto
The protocol to be considered valid for this entry. This should match the appropriate entry in the /etc/services file. It will typically be either tcp or udp. Sun RPC (Remote Procedure Call) based servers will use eitherrpc/tcp or rpc/udp.
flags
There are really only two possible settings for this field. This field setting tells inetd whether the network server program frees the socket after it has been started (whether inetd can start another one on the next connection request), or, whether inetd should wait and assume that any server daemon already running will handle the new connection request. This is a little tricky to work out, but as a rule of thumb all tcp servers should have this entry set to nowait. Most udp servers should have this entry set to wait. Be warned there are some notable exceptions.
user
This field describes which user account from /etc/passwd will be set as the owner of the network daemon when it is started. This is often useful if you want to safeguard against security risks. You can set the user of an entry to the nobody user. If the network server security is breached, the possible damage is minimized by using nobody. Often, however, this field is set to root, because many servers require root privileges in order to function correctly (we will see ways to deal with this security problem in the future).
server_path
This field is pathname to the athoughctual server program to execute for this entry.
server_args
This field comprises the rest of the line and it is optional. This field is where you place any command line arguments that you wish to pass to the server daemon program when it is launched.
This file is complicated and easy to break. So we will not spend any more time looking at it for now. We will return to it several times during the next two courses once we start implimenting servers and can provide concrete examples of its usage. But for now, it's simply important to know it exists and where to find it.
