Section 9.1. Too Many Options for Services

9.1. Too Many Options for Services

As you can tell from a glance at sites such as SourceForge that offer free software applications, the free-flowing creativity of the free software community has led to an explosion of choice. Developers have created for Linux users a broad selection of choices for the Web, FTP file sharing, email, remote access, and more. You may find a dozen or more options for running a service such as a web server. While Apache is the dominant web server on the Internet, there are excellent alternatives, including:

• AOLServer (http://www.aolserver.com)

• Boa (http://www.boa.org)

• Caudium (http://www.caudium.net)

• Jigsaw (http://www.w3.org/Jigsaw)

• Resin (http://www.caucho.com)

• Roxen (http://www.roxen.com)

• Zeus (http://www.zeus.com/products/zws).

Because it's hard to tell how the services differ and which ones are most reliable, this degree of choice can turn into an annoyance. For many, it feels like the first time someone from a poorer country shops in a modern supermarket (or the first time I visited Fry's Electronics, a U.S. high-tech superstore); the choice can be overwhelming. To keep things simple, you could stick with a "brand name," such as BIND for DNS or Apache for web services, but the results may not be best suited for your needs.

In the following sections, I'll describe some of the issues you should consider in selecting the right server:

• Servers vary in functionality.

• Some options are included with your preferred distribution, or integrated well with it, while others are not.

• Servers have different levels of support from their developers and user communities.

• Some servers are proprietary, while others are somewhat open but may be encumbered with license clauses that may not be acceptable to some users.

9.1.1. Distribution Support

The developers behind each Linux distribution may include one or many options for servers. For example, if you're looking for an FTP server, Red Hat Enterprise (RHEL) includes only the vsFTP package. To drive the point home, if you've purchased a RHEL subscription, you may get technical support if you install vsFTP but not for any other FTP server. Debian repositories allow you to install WU-FTPd, OFTPd, PureFTPd, and TwoFTPd, but Debian does not provide any official support. Generally, if a server is included with your distribution, you know it will work. However, watch carefully between releases, as the default servers may change when you least expect it.

If your distribution includes a binary package for your desired server, use it. The developers behind your distribution have configured it with customized locations for scripts, configuration files, logs, and more. While these file locations are supposed to conform to the Linux Standard Base (http://www.linuxbase.org), there are variations between distributions, so you should stick to services released for your distribution whenever possible.

If there isn't a package available for a server you've decided you need, check its associated web site. You may be able to find a binary package customized for your distribution. Otherwise, you may need to live with putting configuration files and other resources in directories that differ from other services.

Consider particularly whether distribution support makes it easier to handle security updates. This should be a high priority, because vulnerabilities are discovered in nearly every server from time to time, and patching the server on your system must be done quickly. When a distribution supports a service, the team is more likely to notify you directly when a vulnerability is found and to provide an easy-to-install fix. (In fact, you can generally get the fix through a routine update operation, if you feel comfortable automating system administration to such an extent.)

Your distribution should provide security updates for every service it supports. But for mission-critical services, that may not be enough. Go to the web site associated with the service. You may be able to sign up for security-related mailing lists or news updates for that service.

If your service isn't supported by your distribution, it may be more difficult to keep up with critical security updates. The developers at the distribution, or at the project developing the server, may or may not create a package promptly that you can download and install with the fix. You may or may not be notified. (Luckily, many independent services report security flaws and fixes, so you should subscribe to one of those.)

A couple of options for security alert services include the SANS @RISK newsletter at http://www.sans.org/newsletters/risk/ and the Linux Weekly News security alert database at http://lwn.net/Alerts/.

9.1.2. Functionality

Check feature lists in server documentation to find out whether they can meet your specialized needs, and follow mailing lists or newsgroups associated with the servers to find out whether they truly support key features in a robust manner. For example, while both sendmail and Postfix perform the central task of transferring email to destination servers, they offer a wide range of extras that most sites need in modern mail environments and solve major problems such as spam in different ways. Trial and error may be required to find out whether a service is good enough for you. Some measures of functionality include:

• Does it do what you want?

• Will it still meet your needs as your network grows (scalability)?

• Are there problems interacting with other services?

These are just general measures. Functionality varies by your needs and the service you're assessing.

9.1.3. Developer and User Support

Many sites pay consultants for server support, and that may be the safest option even if you're a geek. But you should be aware of two community sources of support: the people behind a distribution and the developers behind a service.

Open source software generally gives rise to a range of support options of varying cost and responsiveness. If you have a problem with your sendmail server, for example, you may be able to get some level of support from the volunteers on the mailing lists at http://www.sendmail.org. Alternatively, you may be able to get dedicated support with the proprietary version of Sendmail through http://www.sendmail.com.

Users are generally delighted to help one other with the typical Linux service. You can find such volunteer support on at least two types of mailing lists: those associated with your distribution and those associated with the particular service. In addition, most distributions and many services maintain IRC (Internet Relay Chat) channels that Linux users monitor constantly. IRC may be the quickest way to an answer. One list of Linux IRC channels is available from http://www.linux.org/docs/irc.html.

Before you ask questions on a mailing list or IRC channel, do your homework. Read through applicable documents. Search the archives for the list and do generalized web searches with your error message or symptoms as search terms. Try various options and make careful notes of the output. Prepare your question with backup information, citing the research that you've done. If you've helped others on these mailing lists before, others will be more willing to help you. For more information on this process, see the last annoyance in Chapter 5.

9.1.4. Licensing

For many in the Linux community, licensing is critical. People associated with Richard Stallman's Free Software Foundation (FSF) at http://www.fsf.org are loath to use any software that does not meet their standard for freedom. And now the difference between free and proprietary software is embedded in Linux technology. For example, I find a number of messages similar to the following in my SUSE /var/log/messages:

 Jan 24 11:45:33 suse1 kernel: bluetooth: unsupported module, tainting kernel. 

This message refers to a Bluetooth module, not licensed to the GPL, installed in the default version of SUSE 9.2.

Tainting in the Kernel

What does "tainting" mean in this context? Every developer of a module (such as a driver) must decide whether the module meets the GPL requirements for free distribution. Many modules do not meet these requirementsfor example, because the vendor wants to hide information about the functioning of the device, or because government agencies such as the FCC require hiding information that could be used to make a wireless device dangerousso the developers do not release their source code.

Linux developers, and many distribution developers, prefer all code to be freely viewable and distributable. They point out, with some logic, that any problem reported with a proprietary part of a kernel may be due to binary code whose source they can't examine. The practical ideal of seeing all source code in order to debug a problem reinforces the idea that non-free code is bad. And this is why Linux developers insist that a single piece of non-free code taints the kernel. Many developers refuse to help someone with a kernel problem if the kernel is thus tainted.

The dividing line between free and proprietary can be bridged in many ways. For example, there are two versions of the email server, one free and one proprietary, available from the Sendmail organization. The commercial version is known as Sendmail, available from http://www.sendmail.com. The open source version is known as sendmail (lowercase), available from http://www.sendmail.org.

On the other hand, a substantial number of self-described "open source" services do not conform to GPL license specifications. For example, the djbdns service for DNS described later in this chapter includes a license that does not allow others to modify and redistribute the associated source code. Many open source licenses do allow modification and redistribution; for a full list, see http://www.opensource.org.