Why Use a Super Server

When you run a server via a SysV or local startup script, you load that server into memory and have the server listen to the port or ports it uses to communicate with the outside world. Super servers enable you to run servers in a different way. Instead of keeping a server permanently loaded, you load the super server and have it run the server you want to use only when an incoming call requests it. This approach has several consequences that influence system performance and security:

Memory Use Super servers tend to be fairly small, so they consume little memory. Many servers, by contrast, consume a lot of RAM. If you can replace a dozen RAM-hungry servers with one super server, overall demand for RAM will drop, and hence system performance will improve. This analysis, though, assumes that the servers are used only sporadically. If servers are constantly in use, the RAM savings will be minimal or nonexistent.

Request Response Time Launching a server takes a certain amount of time, and so servers run from a super server tend to respond more slowly than do servers that are run directly. This effect tends to be very small for small servers, but it can be noticeable for larger servers. For instance, Apache 1 .x can be run from a super server, but doing so can add a lag of roughly half a second (depending on disk speed, system load, and other factors) to Apache's responses. Small servers that run and then maintain a connection, such as most login servers, show only a tiny fraction of a second's lag at launch, and then they perform as well as if they'd been run directly.

Maintaining Information Across Calls Some servers must maintain information across calls, or they must run continuously in order to maintain information. For instance, a Network Time Protocol (NTP) server (as described in Chapter 27, "Miscellaneous Servers") must run continuously in order to monitor the drift in your system's clock and so that it can periodically synchronize itself with other NTP servers. Domain Name System (DNS) servers maintain caches of prior name lookups. Running such a server from a super server loses this cache, which increases name lookup times.

Server User IDs All Linux processes run with the authority of a specific user. Most servers must be started as root in order to connect to the privileged ports (those numbered below 1024). Some such servers spawn subprocesses that run with lower privileges, but the initial connection as root poses at least a theoretical vulnerability. When you use a super server, you can launch a server using any user ID (UID) you like, providing the server can function under that UID. This approach means that server bugs are less likely to result in system compromise. On the other hand, security bugs in the super server itself become a potential threat.

Runlevel Considerations Super servers don't enable you to configure servers to run only in particular runlevels, except by the very crude standard that all the super server-mediated servers run in precisely the runlevels in which the super server itself runs. If you want a server to run only in a particular set of runlevels, you must run it via a SysV startup script.

Security Screening As described in Chapter 20, "Controlling Network Access," you can use features of super servers to block incoming accesses that don't meet certain criteria. You can use TCP Wrappers in conjunction with either inetd or xinetd to accomplish this goal, or you can use xinetd's own controls to much the same effect.

On the whole, super servers are good for small and seldom-used servers, as well as those that lack security features you want to implement via TCP Wrappers or xinetd's security tools. Super servers are less ideal for large servers that should respond quickly to incoming requests and for those that work best when they can maintain their state across calls. Many servers work best when run in a particular way; consult your server's documentation for details. Some servers can be run in either way, but some of them must be told how they're being run via a configuration file entry or a parameter passed on the command line.

RPM Package Manager (RPM) and Debian packages for servers frequently include either SysV startup scripts or xinetd configurations. (Because inetd is configured through a single file, distributions that use inetd don't usually include inetd configuration files in their packages, although Debian packages sometimes include scripts that can enable inetd configurations.) For this reason, explicitly configuring a server to start up when you next boot is seldom necessary, although you may need to start the server once or restart the super server to get the server to respond immediately after you install it.

0 0

Post a comment