Linux All-in-One For Dummies, 5th Edition (2014)

Book IV. The Internet

Chapter 4. Hosting Internet Services

In This Chapter

Finding out about Internet services

Controlling servers through inetd or xinetd

Using chkconfig or update-rc.d to manage servers

Using GUI utilities to configure services to start at boot time

The Internet is a world of clients and servers. Clients make requests to servers, and servers respond to the requests. For example, your web browser is a client that downloads information from web servers and displays it to you. Of course, the clients and servers are computer programs that run on a wide variety of computers. A Linux system is an ideal system to run different types of servers — from a web server to a Windows file and print server. This chapter provides an overview of a typical Internet service and its client/server architecture, and discusses how to manage the servers in Linux. You can use the information in this chapter to manage any server running on your Linux system.

Understanding Internet Services

Internet services are network applications designed to deliver information from one system to another. By design, each Internet service is implemented in two parts — a server that provides information and one or more clients that request information.

Such a client/server architecture is the most common way to build distributed information systems. The clients and servers are computer programs that run on these computers and communicate through the network. The neat part is that you can run a client at your desktop computer and access information from a server running on a computer anywhere in the world (as long as it’s on the Internet).

The web itself, e-mail, and FTP (File Transfer Protocol) are examples of Internet services that use the client/server model. For example, when you use the web, you use the web browser client to download and view web pages from the web server.

Client/server architecture requires clients to communicate with the servers. That’s where the Transmission Control Protocol/Internet Protocol — TCP/IP — comes in. TCP/IP provides a standard way for clients and servers to exchange packets of data. The next few sections explain how TCP/IP-based services communicate.

TCP/IP and sockets

Client/server applications such as the web and FTP use TCP/IP for data transfers between client and server. These Internet applications typically use TCP/IP communications utilizing the Berkeley sockets interface (so named because the socket interface was introduced in Berkeley Unix around 1982). The sockets interface is nothing physical — it’s simply some computer code that a computer programmer can use to create applications that can communicate with other applications on the Internet.

Even if you don’t write network applications using sockets, you may have to use or set up many network applications. Knowledge of sockets can help you understand how network-based applications work, which in turn helps you find and correct any problems with these applications.

Socket definition

Network applications use sockets to communicate over a TCP/IP network. A socket represents one end-point of a connection. Because a socket is bidirectional, data can be sent as well as received through it. A socket has three attributes:

· The network address (the IP address) of the system

· The port number, identifying the process (a process is a computer program running on a computer) that exchanges data through the socket

· The type of socket, identifying the protocol for data exchange

Essentially, the IP address identifies a computer (host) on the network; the port number identifies a process (server) on the node; and the socket type determines the manner in which data is exchanged — through a connection-oriented (stream) or connectionless (datagram) protocol.

Connection-oriented protocols

The socket type indicates the protocol being used to communicate through the socket. A connection-oriented protocol works like a normal phone conversation. When you want to talk to your friend, you have to dial your friend’s phone number and establish a connection before you can have a conversation. In the same way, connection-oriented data exchange requires both the sending and receiving processes to establish a connection before data exchange can begin.

In the TCP/IP protocol suite, TCP — Transmission Control Protocol — supports a connection-oriented data transfer between two processes running on two computers on the Internet. TCP provides reliable two-way data exchange between processes.

As the name TCP/IP suggests, TCP relies on IP — Internet Protocol — for delivery of packets. IP does not guarantee delivery of packets; nor does it deliver packets in any particular sequence. IP does, however, efficiently move packets from one network to another. TCP is responsible for arranging the packets in the proper sequence, detecting whether errors have occurred, and requesting retransmission of packets in case of an error.

TCP is useful for applications intended to exchange large amounts of data at a time. In addition, applications that need reliable data exchange use TCP. (For example, FTP uses TCP to transfer files.)

In the sockets model, a socket that uses TCP is referred to as a stream socket.

Connectionless protocols

A connectionless data-exchange protocol does not require the sender and receiver to explicitly establish a connection. It’s like shouting to your friend in a crowded room — you can’t be sure that your friend hears you.

In the TCP/IP protocol suite, the User Datagram Protocol (UDP) provides connectionless service for sending and receiving packets known as datagrams. Unlike TCP, UDP does not guarantee that datagrams ever reach their intended destinations. Nor does UDP ensure that datagrams are delivered in the order they’re sent.

UDP is used by applications that exchange small amounts of data at a time or by applications that don’t need the reliability and sequencing of data delivery. For example, SNMP (Simple Network Management Protocol) uses UDP to transfer data.

In the sockets model, a socket that uses UDP is referred to as a datagram socket.

Sockets and the client/server model

Two sockets are needed to complete a communication path. When two processes communicate, they use the client/server model to establish the connection. (Figure 4-1 illustrates the concept.) The server application listens on a specific port on the system — the server is completely identified by the IP address of the system where it runs and the port number where it listens for connections. The client initiates a connection from any available port and tries to connect to the server (identified by the IP address and port number). When the connection is established, the client and the server can exchange data according to their own protocol.

Figure 4-1: Client and server processes use two sockets to communicate.

The sequence of events in socket-based data exchanges depends on whether the transfer is connection-oriented (TCP) or connectionless (UDP).

For a connection-oriented data transfer using sockets, the server listens on a specific port, waiting for clients to request connection. Data transfer begins only after a connection is established.

For connectionless data transfers, the server waits for a datagram to arrive at a specified port. The client does not wait to establish a connection; it simply sends a datagram to the server.

Regardless of whether it’s a server or a client, each application first creates a socket. Then it associates (binds) the socket with the local computer’s IP address and a port number. The IP address identifies the machine (where the application is running), and the port number identifies the application using the socket.

Servers typically listen to a well-known port number so that clients can connect to that port to access the server. For a client application, the process of binding a socket to the IP address and port is the same as that for a server, but the client can use 0 as the port number — the sockets library automatically uses an unused port number for the client.

For a connection-oriented stream socket, the communicating client and server applications have to establish a connection. The exact steps for establishing a connection depend on whether the application is a server or a client.

In the client/server model, the server has to be up and running before the client can run. After creating a socket and binding the socket to a port, the server application sets up a queue of connections, which determines how many clients can connect to the server. Typically, a server listens to anywhere from one to five connections. However, the size of this listen queue is one of the parameters you can adjust (especially for a web server) to ensure that the server responds to as many clients as possible. After setting up the listen queue, the server waits for a connection from a client.

Establishing the connection from the client side is somewhat simpler. After creating a socket and binding the socket to an IP address, the client establishes a connection with the server. To make the connection, the client must know the hostname or IP address of the server, as well as the port on which the server accepts connection. All Internet services have well-known standard port numbers.

After a client establishes a connection to a server via a connection-oriented stream socket, the client and server can exchange data by calling the appropriate sockets’ API functions. Like a conversation between two persons, the server and client alternately send and receive data — the meaning of the data depends on the message protocol that the server and clients use. Usually, a server is designed for a specific task; inherent in that design is a message protocol that the server and clients use to exchange necessary data. For example, the web server and the web browser (client) communicate using HTTP (HyperText Transfer Protocol).

Internet services and port numbers

The TCP/IP protocol suite is the lingua franca of the Internet because the Internet services speak TCP/IP. These services make the Internet tick by making possible the transfer of mail, news, and web pages. Each Internet service has its own protocol that relies on TCP/IP for the actual transfer of the information. Each service also has one or more assigned port numbers that it uses to do whatever it’s designed to do. Here are some well-known Internet services and their associated protocols:

· DHCP (Dynamic Host Configuration Protocol): Dynamically configures TCP/IP network parameters on a computer. DHCP is used, primarily, to assign dynamic IP addresses and other networking information such as name server, default gateway, and domain names that are needed to configure TCP/IP networks. The DHCP server listens on port 67.

· FTP (File Transfer Protocol): Transfers files between computers on the Internet. FTP uses two ports: Data is transferred on port 20, and control information is exchanged on port 21.

· HTTP (HyperText Transfer Protocol): Sends documents from one system to another. HTTP is the underlying protocol of the web. By default, the web server and client communicate on port 80.

· SMTP (Simple Mail Transfer Protocol): Exchanges e-mail messages between systems. SMTP uses port 25 for information exchange.

· NNTP (Network News Transfer Protocol): Distributes news articles in a store-and-forward fashion across the Internet. NNTP uses port 119.

· SSH (Secure Shell): Enables secure remote login and other secure network services over an insecure network. SSH uses port 22.

· TELNET: Enables a user on one system to log in to another system on the Internet. (The user must provide a valid user ID and password to log in to the remote system.) TELNET uses port 23 by default, but the TELNET client can connect to any specified port.

· NFS (Network File System): Shares files among computers. NFS uses Sun’s Remote Procedure Call (RPC) facility, which exchanges information through port 111.

· NTP (Network Time Protocol): Synchronizes the system time on a client computer with that on a server that has a more accurate clock. NTP uses port 123.

· SNMP (Simple Network Management Protocol): Manages all types of network devices on the Internet. Like FTP, SNMP uses two ports: 161 and 162.

· TFTP (Trivial File Transfer Protocol): Transfers files from one system to another. (It’s typically used by X terminals and diskless workstations to download boot files from another host on the network.) TFTP data transfer takes place on port 69.

Each service is provided by a server process — a computer program that runs on a system awaiting client requests that arrive at the well-known port associated with its service. Thus the web server expects client requests at port 80, the standard port for HTTP service.

The /etc/services text file on your Linux system stores the association between a service name and a port number (as well as a protocol). Here is a small subset of entries in the /etc/services file from a Linux system:

ftp-data 20/tcp
ftp 21/tcp
fsp 21/udp fspd
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
tacacs 49/tcp # Login Host Protocol (TACACS)

A quick look through the entries in the /etc/services file shows the breadth of networking services available under TCP/IP.

Port number 80 is designated for web services. In other words, if you set up a web server on your system, that server listens to port 80. By the way, IANA — the Internet Assigned Numbers Authority (www.iana.org) — is the organization responsible for coordinating the assignment of port numbers below 1,024.

Using the Internet Super Server

The client/server architecture of Internet services requires that the server be up and running before a client makes a request for service. It’s probably a bad idea to run all the servers all the time — doing so is impractical because each server process uses up system resources in the form of memory and processor time. Besides, you don’t really need all the services up and ready at all times. Instead, run a single server that listens to all the ports and then starts the appropriate server when a client request comes in. Such a server is known as the Internet super server because it starts various services on demand.

The two Internet super servers are inetd and xinetd. The inetd server is the older one and is still used in some Linux distributions such as Debian, Knoppix, Ubuntu, and Xandros. The xinetd server is a replacement for inetd, offering improved access control and logging. The name xinetd stands for extended inetd. Distributions such as Fedora and SUSE use xinetd.

Using inetd

In Linux distributions that use inetd, the system starts inetd when the system boots. The inetd server reads a configuration file named /etc/inetd.conf at startup. This file tells inetd which ports to listen to and what server to start for each port. For example, the entry in the/etc/inetd.conf file that starts the IMAP (Internet Message Access Protocol) on one server looks like this:

imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/imapd

The first item on this line, imaps, tells inetd the name of the service. inetd uses this name to look up the port number from the /etc/services file. If you type grep imaps /etc/services, you find that the port number of the IMAP service is 993. This tells inetd to listen to port 993 for FTP service requests.

The rest of the fields on the IMAP entry have the following meanings:

· The second and third fields of the entry, stream and tcp, tell inetd that the FTP service uses a connection-oriented TCP socket to communicate with the client. For services that use the connectionless UDP sockets, these two fields are dgram andudp.

· The fourth field, nowait, tells inetd to start a new server for each request. If this field is wait, inetd waits until the server exits before starting the server again.

· The fifth field provides the user ID that inetd uses to run the server. In this case, the server runs the FTP server as root.

· The sixth field specifies the program to run for this service and the last field is the argument that inetd passes to the server program. In this case, the /usr/sbin/tcpd program is provided /usr/sbin/imapd as an argument.

The /usr/sbin/tcpd program is an access-control facility, or a TCP wrapper, for Internet services. Because unnecessary Internet services are often the sources of security vulnerabilities, you may want to turn off any unneeded services or at least control access to the services. The tcpd program can start other services, such as FTP and TELNET, but before starting the service, tcpd consults the /etc/hosts.allow file to see if the host requesting service is allowed that service. If nothing is in /etc/hosts.allow about that host, tcpdchecks the /etc/hosts.deny file to see if the service should be denied. If both files are empty, tcpd allows the host access to the requested service. You can place the line ALL:ALL in the /etc/hosts.deny file to deny all hosts access to any Internet services.

Browse through the /etc/inetd.conf file on your system to find out the kinds of services that inetd is set up to start. Nowadays, most inetd services are turned off, and many others, such as FTP, are started by standalone servers. In any case, if you should see any services that you want to turn off, simply place a hash mark (#) at the beginning of the lines that start these services. When you make such a change to the /etc/inetd.conf file, type /etc/init.d/inetd restart to restart the inetd server.

Using xinetd

Linux distributions that use xinetd start xinetd when the system boots. The xinetd server reads a configuration file named /etc/xinetd.conf at startup. This file tells xinetd which ports to listen to and what server to start for each port. The file can contain instructions that include other configuration files. In Linux, the /etc/xinetd.conf file looks like the following:

# Simple configuration file for xinetd
#
# Set some defaults and include /etc/xinetd.d/
defaults
{
instances = 30
log_type = FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
cps = 50 10
}
includedir /etc/xinetd.d

Comment lines begin with the hash mark (#). The defaults block of attributes, enclosed in curly braces ({ … }), specifies default values for some attributes. These default values apply to all other services in the configuration file. The instances attribute is set to 30, which means that no more than 30 servers can be simultaneously active for any service.

The last line in the /etc/xinetd.conf file uses the includedir directive to include all files inside the /etc/xinetd.d directory, excluding files that begin with a period (.). The idea is that the /etc/xinetd.d directory contains all service-configuration files — one file for each type of service the xinetd server is expected to manage. Type ls /etc/xinetd.d to see the xinetd configuration files for your system. Each file in /etc/xinetd.d specifies attributes for one service that xinetd can start.

For example, SUSE Linux uses xinetd to start some services, including the vsftpd (Very Secure FTP daemon) server. (A daemon is a process that runs continuously and never dies.) Type cat /etc/xinetd.d/vsftpd to see the xinetd configuration for the vsftpd service. Here’s a typical listing of that file on a SUSE system:

# default: off
# description:
# The vsftpd FTP server serves FTP connections. It uses
# normal, unencrypted usernames and passwords for authentication.
# vsftpd is designed to be secure.
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/vsftpd
}

The filename (in this case, vsftpd) can be anything; what matters is the service name that appears next to the service keyword in the file. In this case, the line service ftp tells xinetd the name of the service. xinetd uses this name to look up the port number from the/etc/services file.

The attributes in /etc/xinetd.d/vsftpd, enclosed in curly braces ({ … }), have the following meanings:

· The socket_type attribute is set to stream, which tells xinetd that the FTP service uses a connection-oriented TCP socket to communicate with the client. For services that use the connectionless UDP sockets, this attribute is set to dgram.

· The wait attribute is set to no, which tells xinetd to start a new server for each request. If this attribute is set to yes, xinetd waits until the server exits before starting the server again.

· The user attribute provides the user ID that xinetd uses to run the server. In this case, the server runs the TELNET server as root.

· The server attribute specifies the program to run for this service. In this case, xinetd runs the /usr/sbin/vsftpd program to provide the FTP service.

Browse through the files in the /etc/xinetd.d directory on your Linux system to find out the kinds of services xinetd is set up to start. If you want to turn off any service (many are already disabled), you can do so by editing the configuration file for that service and adding the following line inside the curly braces that enclose all attributes:

disable = yes

When you make such a change to the xinetd configuration files, you must restart the xinetd server by typing the following command:

/etc/init.d/xinetd restart

You can typically configure services to run under xinetd or as a standalone service. For example, SUSE starts the Very Secure FTP daemon (vsftpd) under the control of xinetd. Debian and Fedora, however, run vsftpd as a standalone server.

Running Standalone Servers

Starting servers through inetd or xinetd is a smart approach but not always efficient. A web server controlled by inetd or xinetd would be started often because every time a user clicks a link on a web page, a request arrives for the web service. For such high-demand services, starting the server in a standalone manner is best. In standalone mode, the server can run as a daemon. That means the server listens on the assigned port, and whenever a request arrives, the server handles it by making a copy of itself. In this way, the server keeps running as long as the machine is running — in theory, forever. A more efficient strategy, used for web servers, is to run multiple copies of the server and let each copy handle some of the incoming requests.

You can easily configure your Linux system to start various standalone servers automatically, as shown in this section.

Starting and stopping servers manually

To start a service that’s not running, use the server command. For example, if the web server (called httpd in Fedora) isn’t running, you can start it by issuing a special shell script with the following command:

/etc/init.d/httpd start

That command runs the /etc/init.d/httpd script with start as the argument. If the httpd server is already running and you want to stop it, run the same command with stop as the argument, like this:

/etc/init.d/httpd stop

To stop and start a server again, just use restart as the argument:

/etc/init.d/httpd restart

You can also check the status of any service by using status as the argument:

/etc/init.d/httpd status

In Debian, Ubuntu, and SUSE, where the web server program is called apache2, type /etc/init.d/apache2 start to start the web server. In Knoppix and Xandros, type /etc/init.d/apache start. Use that same command with arguments stop or restart to stop the web server or restart it.

What are all the services that you can start and stop? Well, the answer is in the files in the /etc/init.d directory. To get a look at it, type the following command:

ls /etc/init.d

All the files you see listed in response to this command are the services ins-talled on your Linux system — and you can start and stop them as needed. You typically find 65 to 70 services listed in the /etc/init.d directory.

Starting servers automatically at boot time

You can start, stop, and restart servers manually by using the scripts in the /etc/init.d directory, but you want some of the services to start as soon as you boot the Linux system. You can configure servers to start automatically at boot time by using a graphical server-configuration utility or a command.

The command for configuring services to start automatically depends on the distribution. In Debian, Knoppix, Ubuntu, and Xandros, use the update-rc.d command. In Fedora and SUSE, use the chkconfig command. Both commands are explained in the following sections.

Using the chkconfig command in Fedora and SUSE

The chkconfig program is a command-line utility in Fedora and SUSE for checking and updating the current setting of servers in Linux. Various combinations of servers are set up to start automatically at different run levels. Each run level represents a system configuration in which a selected set of processes runs. You’re usually concerned about run levels 3 and 5 because run level 3 is for text mode login and run level 5 is for logging in through a graphical interface.

The chkconfig command is simple to use. For example, suppose that you want to automatically start the named server at run levels 3 and 5. All you have to do is log in as root and type the following command at the shell prompt:

chkconfig --level 35 named on

To see the status of the named server, type the following command:

chkconfig --list named

You see a line of output similar to the following:

named 0:off 1:off 2:off 3:on 4:off 5:on 6:off

The output shows you the status of the named server at run levels 0 through 6. As you can see, named is set to run at run levels 3 and 5.

If you want to turn off named, you can do so with this command:

chkconfig --level 35 named off

You can use chkconfig to see the status of all services, including the ones started through xinetd. For example, you can view the status of all services by typing the following command:

chkconfig --list | more

The output shows the status of each service for each of the run levels from 0 through 6. For each run level, the service is either on or off. At the very end of the listing, chkconfig displays a list of the services that xinetd controls. Each xinetd-based service is also marked on oroff, depending on whether xinetd is configured to start the service.

Using the update-rc.d command in Debian, Knoppix, Ubuntu, and Xandros

In Debian, Knoppix, Ubuntu, and Xandros, you can use the update-rc.d command to set up services that should start when the system boots at specific boot levels. The easiest way to set up is to use the defaults option in a command of this form:

update-rc.d service defaults

where service is the name of the script file in the /etc/init.d directory that starts and stops the service, among other things.

When you use the defaults option, update-rc.d sets up symbolic links — shortcuts, in other words — to start the service in run levels 2, 3, 4, and 5 and stop the service in run levels 0, 1, and 6. A sequence number controls the order in which each service is started. (Services with smaller sequence numbers start before those with larger sequence numbers, and the numbers typically range from 00 through 99.) If you do not specify a sequence number explicitly, update-rc.d uses a sequence number of 20 when you use the defaults option.

You can also start and stop a service at specific run levels as well as in a specific sequence. For example, to start a service at run levels 2 and 5 at a sequence number of 85 and stop it at run levels 0, 1, and 6 at a sequence of 90, use the following command:

update-rc.d service start 85 2 5 . stop 90 0 1 6 .

Remember that service must be the name of a script file in the /etc/init.d directory.

If you need to stop a service from starting at system startup, type update-rc.d -f service remove in a terminal window, where service is the name of the script file in /etc/init.d that starts or stops that service.

Using a GUI service-configuration utility

If you don’t like typing commands, you may be able to use a GUI tool to configure the services. Fedora and SUSE include tools such as YaST and the service-configuration utility to manage the services.

The service-configuration utility shows the names of services in a scrolling list. Each line in the list shows the name of a service with a check box in front of the name. A check mark in the box indicates that the service is selected to start at boot time for the current run level. When the dialog box first appears, many services are already selected.

You can scroll up and down the list and click the check box to select or deselect a service. If you click the check box, the check mark alternately turns on and off. Additionally, the utility also shows you whether the selected service is currently running.

After you select all the servers you want to start when the system boots, click the Apply button on the toolbar to save the changes.

By default, the service-configuration utility configures the selected services for the current run level. That means if you’re selecting services from the graphical desktop, the system is in run level 5 and the services you configure are set to start at run level 5. If you want to set up the services for a different level, choose that run level from the Edit Runlevel menu.

Table 4-1 shows a list of the services, along with a brief description of each one. The first column shows the name of the service, which is the same as the name of the program that has to run to provide the service. You may not see all these services listed when you run the GUI service-configuration utility on your system because the exact list of services depends on what is installed on your Linux system.

Table 4-1 Some Common Services in Linux