|
1.2. Linux as a ServerTraditionally, 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. 1.2.1. Linux Server CapabilitiesAs 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:
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:
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. 1.2.2. Typical Linux Server HardwareAs 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 serversparticularly those that support many user loginsneed 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. 1.2.3. Typical Linux Server SoftwareWhen 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 distributiona 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.
1.2.3.1 Picking a distribution for server useYour 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:
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. 1.2.3.2 Picking individual server programsOnce 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. |
|