Traditionally, Linux’s strength has been as a server OS. Many businesses rely upon Linux to handle email, share files and printers, assign IP addresses, and so on. Linux provides a plethora of open source programs to handle each of these server tasks, and many more. Before you attempt to deploy a Linux server, though, you should understand Linux’s strengths and weaknesses in this role, what type of hardware you’re likely to need, and what types of software you’ll need.
As seen in Figure 1-1, Linux can be deployed in many different ways. Indeed, Figure 1-1 presents an incomplete picture because it focuses on only those roles described in this book. Linux firewalls, web servers, databases, and more are all available. Still, Linux has certain strengths and weaknesses as a server that you should understand as you plan where to use it. Linux’s greatest strengths as a server include the following:
Linux has earned a reputation as a very reliable OS, which, of course, is a critically important characteristic for servers.
You can download Linux from the Internet at no cost (aside from connect charges), which can be important in keeping costs down. Of course, the up-front purchase price (or lack of it) is only part of the equation; support costs, hardware costs, and other factors can be much more important. Linux’s total cost of ownership (TCO) is a matter of some debate, but most studies give Linux high marks in this area.
The Linux kernel is licensed under the GNU General Public License (GPL), and much of the rest of Linux uses the same license. Most other Linux programs use other open source licenses. The result is that you’re not bound by restrictive commercial license terms; as a user or administrator, you can do anything with Linux that you can do with a commercial OS, and then some. If you want to redistribute changes to a program, though, some open source licenses impose restrictions, so you should check the license to see how you’re permitted to distribute the changes. (Of course, most commercial OSs don’t even let you see the source code!)
Linux isn’t vulnerable to the worms and viruses that plague the Internet today; almost all of these pests target Windows systems. Of course, a Linux server can still be inconvenienced by worms and viruses because it may need to process them in some way; a Linux mail server may still need to accept email with worms and perhaps then identify and delete the worm. Linux won’t be infected by the worm, though—at least, not by any worm that’s known to be spreading as I write.
As a Unix-like OS, Linux has inherited many popular Unix servers, such as sendmail and Samba. In fact, some of these, including Samba, were written using Linux as a primary target OS.
Linux provides several remote administration methods, ranging from remote logins using text-mode tools such as Secure Shell (SSH) or Telnet to tools designed for remote administration via web browsers, such as Webmin (http://www.webmin.com). Of course, remote administration isn’t unique to Linux, but Linux presents more options than do most non-Unix OSs.
With Linux, you have fine control over what programs you run, which enables you to trim a system of unnecessary items to help get the most out of your hardware. For instance, most servers don’t need to run a local GUI, so Linux enables you to run a system without one, and even to omit the X files and programs from the hard disk.
In addition to customizing the system to minimize resource use, you can modify Linux to achieve other ends. For instance, you can recompile the kernel to add or omit features that help the system operate as a router, or you can alter the startup sequence to accommodate special needs. Taken to the extreme, these features help those who run Linux on specialized embedded devices, but such uses are well beyond the scope of this book.
Linux is available on a variety of hardware, ranging from specialized embedded versions of Linux to supercomputers. This book is designed to help those running Linux on fairly traditional small- to mid-sized servers and desktop systems using conventional Intel Architecture 32 (IA-32; a.k.a. x86) hardware or other hardware of comparable power. Even in this realm, Linux is very flexible; you can run it on AMD64, PowerPC (PPC), Alpha, and other CPUs, which lets you standardize your OS even if you happen to have different hardware platforms.
Most of these advantages are advantages of Unix-like OSs generally, and so apply to other OSs, such as Solaris and FreeBSD. Compared to such OSs, Linux’s greatest strengths are its hardware flexibility, open source licensing, and low cost (although several other low-cost and open-source Unix-like OSs exist).
Of course, no good thing is without its problems, and Linux is no exception to this rule. Fortunately, Linux’s problems are minor, particularly when the OS is used on a server:
Linux requires more in the way of administrative expertise than do some alternatives. For most organizations, this factor ultimately boils down to one of the variables in TCO calculations: Linux administrators are likely to demand higher salaries than Windows administrators do. On the other hand, Linux’s reliability, scalability, and other factors frequently more than compensate for this problem in the TCO equation.
Although immunity to infection by common Windows worms and viruses is a Linux advantage, Linux has its own security drawbacks. Crackers frequently attempt to break into Linux servers, and they sometimes succeed. In theory, this should be difficult to do with a well-administered system, but neglecting a single package upgrade or making some other minor mistake can leave you vulnerable. Of course, Linux isn’t alone in this drawback, but it’s one to which you should be alert at all times.
The term hacker is used by the popular media to refer to computer miscreants—those who break into computers and otherwise wreak havoc. This term has an older and honorable meaning as referring to skilled and enthusiastic computer experts, and particularly programmers. Many of the people who wrote the Linux kernel and the software that runs on it consider themselves hackers in this positive sense. For this reason, I use an alternative term, cracker , to refer to computer criminals.
Overall, Linux’s strengths as a server far outweigh its weaknesses. The OS’s robustness and the number of server programs it runs are powerful arguments in its favor. Indeed, those are the reasons commercial Unix variants have traditionally run many important network services. Linux has been slowly eroding the commercial Unix market share, and its advantages can help you fill the gaps in a Windows-dominated network or even replace existing Windows servers.
As noted earlier, one of Linux’s strengths is that it runs on a very wide range of hardware. Of course, this isn’t to say that you can use any hardware for any particular role; Linux won’t turn a 10-year-old 80486 system with a 1-GB hard disk into a powerhouse capable of delivering files to thousands of users.
Linux most commonly runs on IA-32 hardware, and much Linux documentation, including this book, frequently presents IA-32 examples. IA-32 hardware is inexpensive, and it’s the original and best-supported hardware platform for Linux. Still, other options are available, and some of these are well worth considering for a Linux server.
One of the problems with IA-32 is that it’s a 32-bit platform. Among other things, this means that IA-32 CPUs are limited to addressing 232 bytes, or 4 GB, of RAM. (Intel Xeon processors provide a workaround that involves page swapping , or hiding parts of memory to keep the total available to the CPU at just 4 GB.) Although a 4-GB memory limit isn’t a serious problem for many purposes, some high-powered servers—particularly those that support many user logins—need more RAM. For them, using a 64-bit CPU is desirable. Such CPUs can address 264, or 1.8x1019, bytes of RAM, at least in theory. (In practice, many impose lower limits at the moment, but those limits are still usually in the terabyte range.
Several 64-bit CPUs are available, including the DEC (now Compaq) Alpha, several AMD and Intel CPUs that use the AMD64 architecture, Intel’s IA-64 Itanium, the IBM Power64 (the first of which is the PowerPC G5), and the SPARC-64. Of these, the Power64 and AMD64 platforms are likely to become more common in the next few years. With AMD and Intel both producing AMD64 CPUs, they are likely to take over the market dominated by IA-32 CPUs through most of the 1990s and early 2000s. Apple is rapidly shifting its Macintosh line to the Power64, and IBM and a few others are producing Power64-based servers. Of course, if you already have another type of 64-bit system, or you have an opportunity to get one at a good price, you can run Linux on it quite well. Linux support for the AMD64 and Power64 platforms is likely to be more mature than for other 64-bit platforms, though.
Of course, not all servers need 64-bit CPUs. For them, IA-32 CPUs, such as Intel’s Pentium 4 or AMD’s Athlon, are perfectly adequate. In fact, many systems can make do with much weaker CPUs. A DHCP server can run quite well on an old 80386, for instance. Just how much CPU power you need depends on the function of the server. Functions such as handling thin-client or other remote logins, converting PostScript into non-PostScript printer formats (particularly for multiple heavily used printers), and handling hundreds or thousands of clients, are likely to require lots of CPU power. Lighter duties, such as running a DHCP server, a local Domain Name System (DNS) server, or even a remote login server for a network with a dozen or so computers, requires much less in the way of CPU power. For such purposes, you can probably run Linux on a spare or retired computer. Even a system that’s too weak to run a modern version of Windows can make a good small server.
Disk space requirements also vary with the server’s intended role. Most obviously, a file server is likely to require lots of disk space. Precisely what “lots” is, though, depends on how many users you have and what types of files they store. Disk-intensive servers frequently use Small Computer Systems Interface (SCSI) hard disks rather than Advanced Technology Attachment (ATA) disks, because SCSI disks scale better in multidisk setups and because disk manufacturers often offer higher-performance disks in SCSI form only. SCSI disks cost more than do ATA disks, though. You’ll have to judge for yourself whether your budget permits the use of SCSI disks. Recently, Serial ATA (SATA) disks have started to emerge as an alternative to traditional parallel ATA disks and SCSI. Depending on the drivers, SATA disks may appear to be SCSI disks in Linux, but they aren’t.
Although servers can vary greatly in their major hardware components and needs, network connectivity is a common factor. All servers require good network links. On a LAN, this most commonly means 100- or 1000-Mbps (1-Gbps, or gigabit) Ethernet. Linux ships with excellent Ethernet support; chances are any Ethernet adapter will work. Modern motherboards frequently come with built-in Ethernet, too. Of course, not all Ethernet adapters are created equal: some are more stable, produce better throughput, or consume less CPU time. As a general rule, Ethernet adapters from major manufacturers, such as Intel, 3Com, and Linksys, are likely to perform best. No-name bargain-basement Ethernet cards will almost certainly work, but they may give more problems or perform less well under heavy network loads.
Most servers have similar video display capabilities. In this case, though, servers’ needs are unusually light; because a server’s primary duty is to deliver data over a network, a high-end graphics card is not a requirement. You might want something that’s at least minimally supported by Linux (or by a Linux X server, to be precise) so you can administer the computer at the console using GUI administration tools; however, this isn’t a requirement.
When deciding how to deploy Linux on a LAN, you must consider what hardware and software to use. Linux isn’t a monolithic beast you can decide to install and be done with; you must make choices about your Linux installation. These choices begin with your decision about a Linux distribution —a collection of software and configuration files that’s bundled together with an installation program. Some distributions are better suited than others to use on a server, although with enough extra effort, you can use just about any Linux distribution on a server computer. Beyond the distribution, you must pick individual server programs. These choices are very specific for the purpose of the computer. For instance, if you run a mail server computer, you need to decide which mail server program to run, and this decision can have important consequences for everything else you do on the computer. Such a decision is likely to be relatively unimportant on other types of server computers.
The term server can have multiple meanings; it can refer to either an individual program that delivers network services or to the computer on which that program runs. (A similar dual meaning applies to the word client on the other end of the connection.) In most cases, the meaning is obvious from the context, but when necessary, I clarify by explicitly specifying a server computer or program. Some people use the term service to refer to server programs or to the features that they provide.
Your choice of distribution depends partly on your choice of hardware platform. Some distributions, such as Debian GNU/Linux, are available on a wide range of CPU architectures, whereas others, such as Slackware Linux, are available for just one CPU. If you’re already familiar with a distribution, and you want to use it for your server, you may want to plan your hardware purchases around this fact. If you already have the hardware, though, or if you’re constrained to use a particular platform for policy or budget reasons, you may need to narrow the range of your hardware choices. Broadly speaking, the IA-32 platform has the most choices for distributions, although a few distributions run only on other platforms. The most popular Linux distributions used on servers include the following:
This distribution, headquartered at http://freshmeat.net/projects/centos/, is a community-based fork of Red Hat’s Enterprise Linux. As such, it’s technically very similar to Red Hat, but support details are quite different.
This distribution is one of the few completely noncommercial distributions; it’s maintained entirely by volunteers. It uses the Debian package format and is well-respected for its stable main (“stable”) branch. This branch is on a very long release cycle, though, so it sometimes lags when major new versions of component packages are released. (Bug-fix and security updates are prompt, however.) Debian’s “unstable” branch is much more up to date, but it’s not as well-tested as the reliable main “stable” branch. Keeping up to date is fairly simple because of Debian’s Advanced Package Tools (APT) package, which enables software updates over the Internet by typing a couple of commands. Because Debian doesn’t sell official packages with support, obtaining outside support requires you to hire an independent consultant. To configure Debian, you normally edit text-mode configuration files in a text editor rather than use a GUI configuration tool. Overall, Debian is a good choice for servers, which usually must be stable above all else. Debian is available for an unusually wide range of CPUs, including IA-32, SPARC, PowerPC, Alpha, IA-64, and several other platforms. To learn more, check Debian’s web site, http://www.debian.org.
This distribution is the freely redistributable version of Red Hat. Its development cycle is faster than that of the official Red Hat releases, and part of Fedora’s purpose is to serve as a test bed for new packages that will eventually work their way into Red Hat. Fedora can be a good choice if you like Red Hat, don’t have a lot of money to spend on a commercial distribution, and don’t mind doing without the official Red Hat support. Fedora Core is available for IA-32 and AMD64 CPUs; you can find it at http://fedora.redhat.com.
Like Debian, Gentoo is maintained by volunteers. This distribution emphasizes building packages from source code; its package manager, known as portage, enables you to type a one-line command that downloads the source code and patches, compiles the software, and installs it. (This system is similar to the ports system of FreeBSD.) Portage can be a good way to tweak compiler settings for your CPU, installed libraries, and so on, but the time spent compiling packages can be a drawback. Also, if you maintain many systems with differing hardware, you may have trouble cloning a system, because the optimizations used on your original system may not work on other systems. One advantage of Gentoo is that it’s easy to keep up to date with the latest packages, but you can make your system unstable if the latest version of an important package breaks other programs. Like Debian, Gentoo eschews GUI configuration tools in favor of raw text-mode configuration file editing. Gentoo is available for IA-32, AMD64, SPARC, and PowerPC CPUs. You can learn more at http://www.gentoo.org.
Red Hat is probably the most popular distribution in North America, particularly if you include its Fedora variant. This distribution originated the RPM Package Manager (RPM) package format. Even many programs that don’t ship with Red Hat are available in IA-32 and source RPM packages, which makes software installation easy. Many third-party programs are released with Red Hat in mind, making Red Hat a safe bet for running such programs. With the release of Fedora 1, Red Hat has been focused its main product line (Red Hat Enterprise) on the business market, especially servers, although it can certainly be used on desktops. The main selling point of Red Hat Enterprise is its support, including system updates and maintenance via the Red Hat Network. These include GUI update tools that can grab updates over the Internet. Red Hat ships with a number of Red Hat-specific GUI configuration tools, but they’re often limited enough that you’ll need to bypass them and edit configuration files by hand. IA-32 is the primary Red Hat platform, although some versions are available for AMD64, Itanium, and certain IBM servers. Some older versions ran on SPARC and Alpha CPUs, but these versions are very outdated. The official Red Hat web site is http://www.redhat.com.
Slackware is the oldest of the common Linux distributions. It uses tarballs as its package distribution format and eschews GUI configuration tools. Slackware ships with fewer packages than most Linux distributions; to install more exotic programs, you may need to compile them from source. Slackware may be a good choice if you’re used to “old-style” Unix system administration, but if you’re relatively new to Linux, you may want to pick something else. Slackware is available only on the IA-32 platform. You can learn more at http://www.slackware.com.
This distribution is RPM-based but isn’t derived from Red Hat directly. It’s a good choice for both server and desktop use, and it includes a GUI administration tool called YaST. You can update packages over the Internet with this tool, as well as administer the local system. SuSE is primarily an IA-32 and AMD64 distribution, although an older PowerPC release is also available. Check http://www.suse.com for more information. SuSE was originally an independent German company, but it was purchased by Novell in early 2004.
Ultimately, any of these distributions (or various other less popular ones) can be configured to work equally well, assuming you’re using IA-32 hardware. You may be better able to get along with a particular distribution depending on your system administration style and particular needs, though. If you like to tweak your system to get the very best possible performance, Gentoo’s local-build approach may be appealing. If you like GUI configuration tools for handling the simple tasks, Red Hat or SuSE should work well. For an extremely stable system, Debian is hard to beat. If your hardware is old, consider Debian or Slackware, which tend to install less extraneous software than the others. If you want to use the most popular distribution, look at Red Hat. If the package management tool is important, pick a distribution that uses the tool you like.
Although the Linux kernel and most Linux tools are open source, some distributions include small amounts of proprietary software. This inclusion makes redistribution of the OS illegal. For this reason, you should check license terms before doing so or before installing it on many systems. Most distributions are freely redistributable, although most of them are available for sale. Buying a full package helps provide financial support to the distributions, which helps to advance future development. (Debian and Gentoo are exceptions; no commercial packages of these distributions are available, although you can buy them on cut-rate CDs that provide little or no profit to the actual developers. CentOS and Fedora have no for-sale versions, either, unless you count Red Hat in that role.)
Distribution choice is a highly personal matter. What works well for one administrator may be a poor choice for another. You may also run into policy issues at your workplace; for instance, you may need to buy a package from a vendor that offers certain support terms, which might rule out some distributions. If you haven’t used Linux extensively in the past, you should study the options, focusing on distributions that provide GUI configuration tools you can use to get the basics up and running quickly. For more experienced administrators, I recommend whatever you’ve used in the past, provided you found it satisfactory. If you’ve used other Unix-like OSs but not Linux, try to find a Linux distribution with an administrative style similar to what you’ve used before. You should also try to minimize the number of Linux distributions you use, ideally to just one; this helps simplify system administration because you’ll have just one set of distribution-specific tools and packages to learn, and you can retrieve package updates from just one source.
Once you’ve picked and installed a Linux distribution, you’ll need to decide what server programs to use. For most major server classes, most distributions provide a single default choice, such as the sendmail mail server. It’s usually easiest to stick with the default, but if the server in question is the primary function of the computer, and if the default choice isn’t what you’d like to use, you can change it.
Sometimes the alternative programs work with the same protocol as the default; for instance, the Postfix, Exim, and qmail servers are all popular alternatives to sendmail. All are implementations of the Simple Mail Transfer Protocol (SMTP), and you can replace one package with another without changing the server computer’s interactions with other computers. (You usually need to implement minor or major changes to the server system’s local configuration, though, and perhaps replace some support programs.) Other protocols for which multiple server program implementations are available in Linux include pull email using the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP), the File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP; a.k.a. web server protocol), the Kerberos authentication protocol, the Remote Frame Buffer (RFB) remote GUI login protocol, and the DNS protocol. This book covers many, but not all, of these protocols. In some cases, alternative servers are configured in similar ways, but sometimes configuration is very different for the various server programs.
Other times, you may need to choose between two incompatible protocols that accomplish similar tasks. For instance, POP and IMAP are two different ways to deliver email received by an SMTP server to client systems (that is, users running mail programs such as Outlook Express or KMail). Other examples include RFB and X11R6 for remote GUI access; Telnet and SSH for remote text-mode access; the Server Message Block/Common Internet File System (SMB/CIFS), Network File System (NFS), and AppleShare for remote file-sharing protocols; SMB/CIFS, AppleShare, Line Printer Daemon (LPD), and Common Unix Printing System (CUPS) for printer sharing; SSH and FTP for remote file transfers; and NetBIOS domain logins, Lightweight Directory Access Protocol (LDAP), Kerberos, and Network Information Services (NIS) for remote authentication. In all these cases, the competing protocols have their own advantages and disadvantages. For instance, SSH provides encryption whereas FTP and Telnet do not. Some protocols are closely associated with particular OSs; for instance, SMB/CIFS and NetBIOS most commonly are used on Windows-dominated networks, whereas NFS is used in Unix-to-Unix file sharing and AppleShare is used most often with Mac OS systems. This book covers many of these protocols, but it focuses on those that are used most commonly on Windows-dominated networks, or at least that have potential to enhance such networks.
Chapter 2 describes in greater detail when you’re likely to deploy each server covered in this book, and subsequent chapters describe the protocols and servers themselves.