Deciding Which Method to

For the most part, you'll do well to use whichever startup method is implemented or assumed in the server package you install. If a package ships with a working SysV startup script, use it; if it ships with a xinetd definition file in /etc/xinetd.d, use it; and if it ships with no such file but the documentation refers to uncommenting an /etc/inetd.conf entry, do so or create an equivalent entry in a file in /etc/xinetd.d. Using the default or expected configuration involves the least effort on your part and involves following the advice of the server author or distribution maintainer. These people probably know more about the server than you do, so unless you have good cause to do things differently, following their lead makes sense.

Some servers, though, run equally well stand-alone or from a super server, and you may have a reason to run a server in a nonstandard way. Sometimes you may be forced to do things differently, particularly when installing a server from a source tarball or from a package intended for a distribution other than the one you're using. Some specific cases in which you may want to do things differently include:

Saving Memory on Little-Used Servers If a server is seldom used, you may want to try running it from a super server even if it's normally run stand-alone. Doing so involves disabling the server using the normal SysV runlevel tools and enabling a super server configuration.

Applying Extra Security If you want to apply security features offered by TCP Wrappers or xinetd, running the server via a super server makes sense. Some servers, though, support TCP Wrappers directly, or they include similar features of their own. You can also use packet-filter firewall rules to protect any server. Of course, extra security can be good, but the security you gain by using a super server may be marginal if you're already using other measures.

Using Runlevel-Specific Options If you want to run the server only in some runlevels, the simplest approach is to use SysV startup scripts. You must disable the super server configuration and write a SysV

This document was created by an unregistered ChmMagic, please go to to regist* startup script.

Installing from a Nonnative Package If you install a server from a package intended for a distribution other than the one you're using, it may include SysV startup scripts in the wrong location, or worse, the startup script may not work on your distribution. In this case, the simplest solution is generally to use a local startup script. Sometimes a super server configuration is the next-best solution. If you want to retain the SysV startup script benefits, you must write one yourself, modify one intended for another server, or modify the one that came with the server so that it works with your distribution.

Installing from Source Code The problems of installing a nonnative package are largely the same as those of installing a package from source code. One exception is that source tarballs seldom come with sample SysV startup scripts, so you may not have a base script to even try.

Remember that some servers have very specific needs. For instance, Apache 2.0 and later can't run from a super server, and Samba runs poorly from a super server. Other servers, such as many FTP and Telnet servers, are designed to run from a super server and may not work correctly if run from a SysV or local startup script. Consult your server's documentation for details. You may also want to experiment to learn how the server performs when it is run in different ways.

Team LIB

^ previous

0 0

Post a comment