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:
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:
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.)
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:
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.
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.
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.