Red Hat Linux Networking , System Administration (P2) pot

xxviii Contents Configuring Apache 519 Apache’s Startup Process Configuring Global Behavior Configuring the Default Server Configuring Virtual Servers Starting and Stopping Apache 520 521 524 537 539 Implementing SSI Enabling CGI Enabling PHP Creating a Secure Server with SSL 540 543 545 546 Understanding SSL and Server Certificates Creating a Self-Signed Certificate Obtaining a Certificate from a Certification Authority 547 549 554 Summary 554 Chapter 24 Providing Web Services Creating Mailing Lists 555 555 Completing the Initial Mailman Configuration Creating a Mailing List Modifying a Mailing List’s Configuration Performing Common Mailman Administrative Tasks Adding Multiple List Members Hiding a Mailing List Restricting Archives Access 556 559 560 561 562 562 563 Setting Up Web-Based Email 563 Connecting to SquirrelMail Reconfiguring SquirrelMail 563 565 Configuring an RSS Feed Selecting Content for an RSS Feed Creating the Feed File Turning on an RSS Feed Adding Search Functionality Getting Started with ht://Dig Summary Chapter 25 Optimizing Internet Services Optimizing LDAP Services Optimizing DNS Services Improving the Performance of DNS Clients Tweaking DNS Servers Logging Optimizing Mail Services Getting More from Sendmail Getting More from Postfix Optimizing FTP Services Optimizing Web Services Summary 567 570 570 572 574 574 579 581 582 583 583 585 586 587 587 588 590 590 593 Contents xxix Part Four System Administration Chapter 26 Keeping Your System Updated with up2date and the Red Hat Network Using the Red Hat up2date Agent Configuring the up2date Agent Updating Your System Registering Your System Accessing the Red Hat Network with a Web Browser Summary Chapter 27 Upgrading and Customizing the Kernel Determining Whether to Upgrade to a New Kernel Upgrading versus Customizing Preparing to Upgrade Installing a Kernel RPM Getting the Kernel Source Using the Kernel Source RPM Using Pristine Kernel Source Verifying and Unpacking the Archive Patching the Kernel Configuring the Kernel Selecting a Kernel Configuration File Configuring the Kernel with xconfig Configuring the Kernel with menuconfig 595 597 598 599 602 605 608 614 615 616 618 618 619 620 621 623 626 627 629 630 633 634 Reviewing the Configuration Options 637 Code Maturity Level Options General Setup Loadable Module Support Processor Type and Features Power Management Options Bus Options Executable File Formats Device Drivers Generic Driver Options Memory Technology Devices Parallel Port Support Plug and Play Support Block Devices ATA/ATAPI/MFM/RLL Support SCSI Device Support Old CD-ROM Drivers Multidevice Support Fusion MPT Device Support IEEE 1394/FireWire Support I2O Device Support Networking Support ISDN and Telephony 637 637 640 640 643 643 644 645 645 645 645 646 646 647 648 648 649 649 649 649 649 653 xxx Contents Input Device Support Character Devices I2C Support Multimedia Devices Graphics Support Sound USB Support MMC/SD Card Support InfiniBand Support File Systems CD-ROM/DVD File Systems DOS/FAT/NT File Systems Pseudo-File-Systems Miscellaneous File Systems Network File Systems Partition Types Native Language Support Profiling Support Kernel Hacking Security Options Cryptography Options Library Routines Saving the Kernel Configuration Compiling the Kernel Installing the Kernel Updating GRUB Summary Chapter 28 Configuring the System at the Command Line Administrating Your System from the Command Line Managing Processes Obtaining Process Information Signaling Processes Modifying Process Priorities Maintaining the File System Working with File Systems Creating and Manipulating Partitions Creating and Manipulating File Systems Working with Files and Directories Managing Disk Space Usage Timekeeping Single-Use Commands Using the Network Time Protocol Automating Scripts Running One-Shot Jobs with at Running Regularly Scheduled Jobs with cron Summary 653 654 654 655 655 656 656 660 660 660 661 661 662 662 662 662 663 663 664 664 664 665 665 666 669 670 671 673 673 675 676 680 682 683 683 683 685 691 695 696 697 702 702 702 704 705 Contents xxxi Chapter 29 Administering Users and Groups Administering User Accounts Working with User Accounts The User Database Files Modifying Multiple Accounts Simultaneously Viewing Login and Process Information Working with Group Accounts Creating Groups Modifying and Deleting Groups Using a Shadowed Group File Using User Private Groups Administering Users and Groups with User Manager Creating User Accounts Modifying and Deleting User Accounts Creating Group Accounts Modifying and Deleting Group Accounts Understanding the Root Account Implementing Sudo Deciphering Sudo’s Configuration File Sudo Configuration and Usage Tips Using File System Quotas Enabling Quotas Creating the Quota Files Turning on Quotas Setting and Modifying Quotas Viewing Quota Utilization Summary Chapter 30 Installing and Upgrading Software Packages Using the Red Hat Package Manager General Options Query Mode Querying Package Dependencies What’s in That RPM? Formatting Query Output Package Installation and Removal Installing RPMs Upgrading RPMs Removing RPMs Verifying RPMs Building Packages Using Source RPMs Checking Software Versions Obtaining Newer Software Using Third-Party Sites to Find RPMs Using Ibiblio.org 707 707 708 708 715 717 718 719 720 722 723 725 726 727 728 729 730 731 733 737 737 738 739 740 740 742 744 745 745 746 748 750 751 754 755 756 757 758 758 761 764 767 768 770 xxxii Contents Installing Software from Source Configuring the Build Environment Unpacking the Source Code Configuring the Source Code Building the Software Package Testing the Build Installing the Software Summary Chapter 31 Backing Up and Restoring the File System Creating a Backup Plan Choosing Media for Backups Understanding Backup Methods Tape Rotation Using Backup Tools Command Line Tools Using mt-st Using the cdrecord Package Using dump Using restore Using tar Advanced Tools Using AMANDA Summary Chapter 32 Performance Monitoring System-Performance-Monitoring Tools Measuring Memory Usage Memory Usage as Seen by Users and Processes Examining Kernel Memory Usage Viewing Running Tasks 771 772 772 773 775 776 777 778 779 779 781 781 783 784 784 784 787 789 790 793 795 795 804 805 805 806 806 810 812 Getting Started with ps Using top 813 817 Monitoring I/O Activity Using sar 822 826 Monitoring Memory with sar Monitoring CPU Usage with sar Summary Part Five System Security and Problem Solving Chapter 33 Exploring SELinux Security Understanding SELinux Mandatory and Role-Based Access Control SELinux Policies Using SELinux Enabling SELinux Manually Modifying the Targeted Policy 827 829 831 833 835 835 836 838 838 842 843 Contents xxxiii Finding More Information about SELinux Summary 845 846 Chapter 34 Implementing Network Security Creating a Firewall Installing, Configuring, and Using LDAP 847 847 851 Overview of LDAP Directory Organization OpenLDAP Packages for Linux Core OpenLDAP Server Files, Daemons, and Utilities Configuring and Starting an OpenLDAP Server Using OpenLDAP for System Authentication Adding User, Password, and Group Entries to an LDAP Server Updating Client Systems to Use LDAP Authentication Installing, Configuring, and Using Kerberos Kerberos Terminology, Machine Roles, and Reliability Kerberos Packages for Linux Core Kerberos Utilities Installing and Configuring a Kerberos Server Enabling Kerberos Clients and Applications Using Kerberos for Login Authentication Summary Chapter 35 Troubleshooting and Problem Solving Troubleshooting Techniques Step 1: Identify the Problem Step 2: Reproduce the Problem Step 3: Look for Changes Step 4: Determine the Most Likely Cause Step 5: Implement a Solution Step 6: Keep Documentation Troubleshooting Resources The Internet System Log Files README Files Solving Common Problems Unable to Log In Resetting a User’s Password Creating a User Account Lost or Forgotten Root Password CD-ROM Drive Not Detected during Installation CD-ROM Drive Does Not Mount after Installation Sound Does Not Work after Installation Unable to Unmount a Drive Shell Commands Don’t Work Solving File System Problems Cannot Delete a File Commands with Multiword Arguments 852 855 856 857 860 860 861 864 865 865 866 867 870 871 874 875 876 876 876 877 877 878 878 878 878 879 882 883 883 883 883 884 884 885 885 887 888 888 889 889 xxxiv Contents Accessing Windows File Systems Working with Floppy Disks Cannot Mount a Partition Avoiding File System Checks at Each System Reboot Solving Networking Problems 890 890 891 891 891 Getting Online with a Modem The Boot Process Hangs Using Two Ethernet Cards 893 895 896 Solving NFS Problems Exploring Miscellaneous Problems 896 898 Solving Boot Problems ht://Dig Won’t Run Starting cyrus-imapd Solving Laptop Video Problems The Signal and Signal 11 Problems Using Screensavers and Power Management Starting the X Window System Making an Emergency Boot Disk Summary 899 900 900 901 902 903 903 904 904 Appendix A Bash Shell Scripting Using Wildcards and Special Characters Using Variables Using Bash Operators 905 906 909 913 Comparison Operators Arithmetic Operators File Test Operators 913 916 917 Understanding Flow Control Conditional Execution Using if Statements Determinate Loops Using the for Statement Indeterminate Loops Using while and until Statements Selection Structures Using case and select Statements The case Statement The select Statement Using Shell Functions Processing Input and Output Redirecting I/O String I/O Working with Command Line Arguments Using Processes and Job Control Summary Index 919 920 922 923 924 925 926 928 929 929 932 934 936 941 943 PA R T One System and Network Administration Defined Chapter 1: Chapter 2: Chapter 3: Chapter 4: Chapter 5: Chapter 6: Chapter 7: Chapter 8: Duties of the System Administrator Planning the Network Standard Installation Kickstart Installation Exploring the Desktops System Startup and Shutdown The File System Explained Examining the System Configuration Files CHAPTER Duties of the System Administrator IN THIS CHAPTER ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ The Linux System Administrator Installing and Configuring Servers Installing and Configuring Application Software Creating and Maintaining User Accounts Backing Up and Restoring Files Monitoring and Tuning Performance Configuring a Secure System Using Tools to Monitor Security Linux is a multiuser, multitasking operating system from the ground up In this regard the system administrator has flexibility — and responsibility — far beyond those of other operating systems Red Hat has employed innovations that extend these duties even for the experienced Linux user This chapter briefly looks at those responsibilities, which are covered in more detail in later chapters The Linux System Administrator Using Linux involves much more than merely sitting down and turning on the machine Often you hear talk of a “steep learning curve” but that discouraging phrase can be misleading Linux is quite different from the most popular commercial operating systems in a number of ways While it is no more difficult to learn than other operating systems are, it is likely to seem very strange even to the experienced administrator of other systems In addition, the sophistication of a number of parts of the Red Hat distribution has increased by an order of Duties of the System Administrator Hardware failures caused by improper configuration can be corrected by properly configuring the device Sometimes hardware failures are caused by the device itself, which typically requires replacing the device Software failures caused by improperly configured system files are usually corrected by properly configuring those files An application can cause the system to fail for many reasons, and finding the root of the problem may require a lot of research on the part of the administrator If you are the administrator of servers and workstations for a business, you should have a disaster recovery plan in place Such a plan takes into account the type of data and services provided and how much fault tolerance your systems require — that is, how long your systems could be down and what effect that would have on your company’s ability to conduct business If you require 100 percent fault tolerance, meaning your systems must be online 24/7, disaster recovery may be unnecessary in some circumstances as your systems never go down and there is no disaster from which to recover Most organizations, though, cannot afford such a high level of fault tolerance; they are willing to accept less stringent standards Based on the level of fault tolerance you require, your disaster recovery plan should list as many possible failures as you can anticipate and detail the steps required to restore your systems In Chapter we describe fault tolerance and disaster recovery in more detail T I P Backing up is only part of the story You need to formulate a disaster recovery plan to bring your system back up in the event of a failure Monitoring and Tuning Performance The default installation of Red Hat Enterprise Linux goes a long way toward capitalizing on existing system resources There is no “one size fits all” configuration, however Linux is infinitely configurable, or close to it On a modern standalone system, Linux runs pretty quickly If it doesn’t, there’s something wrong — something the system administrator can fix Still, you might want to squeeze one last little bit of performance out of your hardware — or a number of people might be using the same file server, mail server, or other shared machine, in which case seemingly small improvements in system performance add up System tuning is an ongoing process aided by a variety of diagnostic and monitoring tools Some performance decisions are made at installation time, while others are added or tweaked later A good example is the use of the hdparm utility, which can increase throughput in IDE drives considerably, but for some high-speed modes a check of system logs shows that faulty or inexpensive cables can, in combination with hdparm, produce an enormity of nondestructive but system-slowing errors 10 Chapter Proper monitoring allows you to detect a misbehaving application that consumes more resources than it should or fails to exit completely upon closing Through the use of system performance tools, you can determine when hardware — such as memory, added storage, or even something as elaborate as a hardware RAID — should be upgraded for more cost-effective use of a machine in the enterprise or for complicated computational tasks such as three-dimensional rendering Possibly most important, careful system monitoring and diagnostic practices give you a heads-up when a system component is showing early signs of failure, so that you can minimize any potential downtime Combined with the resources for determining which components are best supported by Fedora Core and Red Hat Enterprise Linux, performance monitoring can result in replacement components that are far more robust and efficient in some cases In any case, careful system monitoring plus wise use of the built-in configurability of Linux allows you to squeeze the best possible performance from your existing equipment, from customizing video drivers to applying special kernel patches or simply turning off unneeded services to free memory and processor cycles T I P To squeeze the best performance from your equipment, monitor your system carefully and use Linux’s built-in configurability wisely Configuring a Secure System If there is a common thread in Linux system administration, it is the security of the computer and data integrity What does this mean? Just about everything The system administrator’s task, first and foremost, is to make certain that no data on the machine or network is likely to become corrupted, whether by hardware or power failure, misconfiguration or user error (to the extent that the latter can be avoided), or malicious or inadvertent intrusion from elsewhere This means doing all the tasks described throughout this chapter, and doing them well, with a full understanding of their implications No one involved in computing has failed to hear of the succession of increasingly serious attacks on machines connected to the Internet For the most part, these attacks have not targeted Linux systems That doesn’t mean Linux systems have been entirely immune, either to direct attack or to the effects of attacks on machines running other operating systems In one distributed denial of service (DDoS) attack aimed at several major online companies, Duties of the System Administrator for instance, many “zombie” machines — those that had been exploited so that the vandals could employ thousands of machines instead of just a few — were running Linux that had not been patched to guard against a well-known security flaw In the various Code Red attacks during the summer of 2001, Linux machines themselves were invulnerable, but the huge amount of traffic generated by this worm infection nevertheless prevented many Linux machines from accomplishing much Web-based work for several weeks, so fierce was the storm raging across the Internet And few email users have been immune from receiving at least some SirCam messages — nonsensical messages from strangers with randomly selected files attached from their machines While this infection did not corrupt Linux machines per se, as it did those running MS Windows, anyone on a dial-up Internet connection who had to endure downloading several megabytes of infected mail each day would scarcely describe himself or herself as unaffected by the attack Depending on how a Linux machine is connected, and to what; the sensitivity of the data it contains; and the uses to which it is put, security can be as simple as turning off unneeded services, monitoring the Red Hat security mailing list to make sure that all security advisories are followed, regularly using system utilities to keep the system up to date, and otherwise engaging in good computing practices to make sure that the system runs robustly It’s almost a full-time job, involving levels of security permissions within the system and systems to which it is connected; elaborate firewalls to protect not just Linux machines but machines that, through their use of non-Linux software, are far more vulnerable; and physical security — making sure that no one steals the machine itself! For any machine connected to another machine, security means hardening against attacks and making certain that no one else uses your machine as a platform for launching attacks against others If you run Web, FTP, or mail servers, it means giving access to only those who are entitled to it, while locking out everyone else It means making sure that passwords are not easily guessed and not made available to unauthorized persons It means that disgruntled former employees no longer have access to the system and that no unauthorized person may copy files from your machines Security is an ongoing process The only really secure computer is one that contains no data, is unplugged from networks and power supplies, has no keyboard attached, and resides in a locked vault While this is theoretically true, it implies that security diminishes the usefulness of the machine In the chapters that follow, you learn about the many tools that Red Hat provides to help you guard against intrusion, even to help you prevent intrusion into non-Linux machines that may reside on your network Linux is designed from the beginning with security in mind In all your tasks you should maintain that same security awareness 11 12 Chapter T I P Your job as system administrator is to strike the right balance between maximum utility and maximum safety, all the while bearing in mind that confidence in a secure machine today means nothing about the machine’s security tomorrow Using Tools to Monitor Security People who, for purposes of larceny or to amuse themselves, like to break into computers — they’re called crackers — are a clever bunch If there is a vulnerability in a system, they will find it Fortunately, the Linux development community is quick to find potential exploits and to create ways of slamming the door shut before crackers can enter Fortunately, too, Red Hat is diligent in making available new, patched versions of packages in which potential exploits have been found Your first and best security tool, therefore, is making sure that whenever a security advisory is issued, you download and install the repaired package This line of defense can be annoying but it is nothing compared to rebuilding a compromised system As good as the bug trackers are, sometimes their job is reactive Preventing the use of your machine for nefarious purposes and guarding against intrusion are, in the end, your responsibility alone Red Hat equips you with tools to detect and deal with unauthorized access of many kinds As this book unfolds, you’ll learn how to install and configure these tools and how to make sense of the warnings they provide Pay careful attention to those sections and what they say If your machine is connected to the Internet, you will be amazed at the number of attempts made to break into your machine You’ll be struck by how critical the issue of security is Summary As you, the system administrator, read this book, bear in mind that your tasks are ongoing and that there is never a machine that is completely tuned, entirely up to date, and utterly secure for very long The pace of Linux development is quite rapid, so it’s important to keep current in the latest breakthroughs This book gives you the very best information as to the Red Hat distribution you’re using and tells you all you need to know about getting the most from it Even more than that, you should read it with an eye toward developing a Linux system administrator’s point of view, an understanding of how the system works as opposed to the mere performance of tasks As the best system administrators will tell you, system administration is a state of mind CHAPTER Planning the Network IN THIS CHAPTER ■ ■ ■ ■ ■ ■ ■ ■ Deciding How Your Network Will Be Used Planning and Implementing Security Planning for Recovery from Disasters Writing It Down: Good Records Can Save Your Job While you can set up a Fedora Core or Red Hat Enterprise Linux network on the fly, your time will be spent most efficiently if you plan your network Preparation reduces confusion not just now but also in the future, makes provision for expansion later on, and ensures that you make the best use of your resources, both budgetary and system-related Although setting up a huge network of hundreds of nodes requires planning beyond the scope of this chapter, we explore here the fundamentals of planning and preparing for your new network installation Deciding How Your Network Will Be Used By definition and right out of the box, Linux is a network operating system It is also nearly infinitely configurable: You can tailor a network to meet your precise needs That is a tremendous strength but it can also be daunting when compared with systems that are more limited As the philosopher James Burnham said, “Where there is no alternative, there is no problem.” Before you install Fedora Core or Red Hat Enterprise Linux on anything other than a standalone box just to take a look at it, you would be well advised to consider what kind of network you want to install, what it will be used for, what kinds of connections to the outside world it will have, and whether it is something you’re likely to expand later 13 14 Chapter Questions to ask include the following: ■■ What services you wish to provide within your local network? ■■ Will your network be made up entirely of Linux machines or will boxes running other operating systems be connected to it? ■■ What devices (printers, scanners, and DSL, cable modem, or T-1 connections) you plan to share? ■■ Do you intend to host a Web site or an FTP site? ■■ What security implications you foresee? ■■ How many machines will make up your network? It makes sense now to take notes and answer these questions You can find details about setting up your network elsewhere in this book But careful planning now lets you chart a clear path to developing a quick and efficient network and, perhaps even more important, helps you make sure that your network is secure from both internal and external mischief C R O S S-R E F E R E N C E To learn more about setting up your network, see Chapter 11 For example, many people who now enjoy DSL or cable Internet service wish to set up small networks purely to allow the sharing of that broadband connection Having a permanent Internet connection demands that you pay more attention to security, which means making sure that you don’t accidentally run any easily exploited services If the network includes easily exploited operating systems, security becomes even more of a concern Perhaps you will decide to set up a firewall on your Linux machine (or even set up a Linux box solely for firewall purposes) Or you might decide to employ one of the firewall-gateway-router network appliances that are gaining popularity and simply attach a hub to the appliance and attach each machine on the “network” to that hub Such a network may not be big, but it may be all you need or want T I P A good rule of thumb is to provide the services for your network — and only those it needs Chances are good that you want to more Even if your needs are modest at first, adding services is simple in Red Hat Linux Some features, such as printer sharing, you’ll probably set up at the beginning Before you anything else, decide the physical layout, or topology, of your network — how machines are connected — and whether you want a peer-topeer or client-server network These details matter because on the one hand you can overbuild your network so that your equipment isn’t used efficiently; Planning the Network on the other hand you can underestimate the demands on the network and end up slowing down one or more machines to near uselessness Understanding Topologies Your network will probably be one of the first two of the following four commonly used topologies (at least for starters): star, bus, ring, and tree Star Topology Think of this system as resembling a power strip with various devices plugged into it In this case, instead of a power strip you have a network hub, and instead of devices requiring electricity you have devices needing and providing data These devices might include computers, network-equipped printers, cable or DSL modems, a local network backbone, or even other hubs Star topology networks are connected by twisted pair cabling, which looks like the cabling used in modular phone systems Twisted pair cables and other devices are rated according to category (typically just called cat): Cat uses two pairs of twisted wires as the standard for regular telephone service Star topology networks usually use cat twisted pair cabling, which has four twisted pairs and terminates in connectors called RJ-45s (Your phone is connected with RJ11s.) You may have up to 1024 nodes — distinct machines or devices — on a star topology network, at speeds of up to 100 MB per second The newest networking technology provides even faster speeds Figure 2-1 shows an example of a star topology network Hub Figure 2-1 A typical star topology network 15 16 Chapter Bus Topology If star topology resembles a power strip with many devices plugged into it, bus topology physically resembles strings of old-fashioned Christmas tree lights, hooked together one after another Of course, on your network there’s a lot more going on than what happens on a string of lights On a bus topology network one machine is plugged to the next, which is plugged to the next, and so on Two types of coaxial cable hold bus topology networks together: RG-8, often called Thicknet because of the thickness of the cable, and RG-58, often called Thinnet because it is thinner than RG-8 RG-8 is familiar at least in general form to anyone involved in amateur radio or anyone who has ever hooked up cable television With this kind of topology, each end of the cable is specifically terminated by use of a “terminating resistor.” Bus topology networks are limited to 30 machines They were a very common style in early networks While considered highly reliable, bus topology networks are not very fault tolerant because the failure of any device on the cable causes the entire network to fail Also, their potential bandwidth (datahandling capacity) is limited to 10 MB per second Nearly all modern networks use some type of star topology with cat or better cabling Figure 2-2 shows a typical bus topology network Ring Topology Imagine those Christmas tree lights again This time the end of the string plugs into its beginning, creating a loop Popularized by IBM’s Token Ring system, ring networks are relatively difficult to set up but offer high-bandwidth capabilities Figure 2-3 shows a typical ring topology network Terminator Coax Cable Figure 2-2 A typical bus topology network Terminator Planning the Network Figure 2-3 A typical ring topology network Tree Topology Although you almost certainly won’t undertake this system at the outset, you should know about it anyway A tree network involves a high-speed “backbone” that is connected in the fashion of bus topology However, instead of connecting individual machines, it connects groups of star topology subnetworks Many network backbones use fiber-optic cabling to achieve high throughput Figure 2-4 shows a typical tree topology Ultimately, your choice of network is determined by the equipment you already own and the amount of money you have to spend If you are setting up a new network, speed, ease of configuration, and relatively low cost all argue in favor of establishing a star topology network 17 18 Chapter Network Subnet Hub Network Backbone Hub Hub Figure 2-4 A typical tree topology network Client-Server or Peer-to-Peer? In a client-server network, machines are dedicated to performing a variety of functions, in some ways like the old mainframe/dumb terminal days You might, for instance, have a print server that handles print jobs for every computer on the network — a highly useful arrangement if, for example, yours is an enterprise that prepares many invoices, contracts, or other documents Or you might have a file server, whose sole purpose is to serve up “boilerplate” documents or the contents of a huge database, or to serve as the repository of a big project on which many people collaborate If your enterprise has an online presence, you may wish to dedicate one machine (or more) as a Web server, and perhaps one or more machines as a File Transfer Protocol (FTP) server, so that people can download (and upload) files You’ll probably need some kind of mail server to handle both external email and messages sent within the network Clients are machines connected to such a network They are not servers; instead, they rely on network services provided by the server machines Clients are usually full, freestanding workstations, although it is possible to connect dumb terminals — monitor, keyboard, pointing device — to such a network in some circumstances To use the services provided by the server(s), clients need to have accounts on the desired server(s) and must log in to those accounts Planning the Network A peer-to-peer network resembles a client-server network in that the machines are wired to each other and some services are shared But in a peer network, those shared items — a CD reader, perhaps, or a printer — reside on machines that are also used for other purposes If you have a very small, low-traffic network, a peer-to-peer system might be right for you because it requires no dedicated server machine(s) Peer networking can prove impractical for highvolume operations because, for instance, multiple big print jobs will keep the poor soul who shares his printer from getting much else done What’s in the Mix? If you are only a little bit familiar with Red Hat Enterprise Linux, your exposure to it has probably relied on industry press reports extolling its suitability as a server operating system There is no doubt that it is indeed superb for this purpose Don’t make the mistake, though, of thinking that this is all it is good for Red Hat Enterprise Linux comes with a full range of powerful and secure server applications (Secure by industry standards, although security is a process, not a state of being.) It also comes with powerful, attractive, and easyto-use graphical desktops and a wide range of productivity applications, communications tools, and yes, even amusements, which make it an ideal client or peer operating system as well Your network may be a mixed marriage of machines of different architectures and operating systems For instance, your graphics design department would probably rather paint with their fingers on a cave wall than use anything other than a Macintosh Meanwhile your legacy applications, boilerplate documents, and relations with paying customers dictate that you maintain one or more Windows machines In these cases, choose a client-server arrangement with a secure Red Hat box serving as a firewall between your network and the outside world, a mail server (it is now easy with Linux to filter out email attachments of the sort that have caused so much disruption of Windows networks in recent years), a Web server if you have a presence in that milieu, and even perhaps a print server Although many peer functions can be performed on a mixed network, your job as system administrator is much easier if you undertake the more straightforward client-server approach with a mixed installation Additionally, if your network includes machines running Windows and is connected to the Internet, you would be irresponsible not to set up a firewall and let Linux handle Web, FTP, and mail services History has shown that Linux is more secure in its fundamental architecture Beyond that, however, there are thousands of eyes constantly searching for and fixing potential security exploits Red Hat is often first to make these fixes available, usually before the exploits are known to the cracker crowd 19 20 Chapter T I P If your network includes machines running Windows and is connected to the Internet, set up a firewall and let Linux handle your Web, FTP, and mail services A client-server network acts very much like a small Internet: just about any machine can connect to it and make use of its services, irrespective of its architecture or operating system Determining System Requirements Depending on the kind of network you choose, you need, of course, computers and any devices you intend to connect to the hub (if you’re using a star topology network) Don’t forget an appropriate and supported Ethernet card for each machine — two for your firewall machine because it has one line in from the outside world and one line out to the rest of your network You also need the appropriate cabling and, if you go the recommended star topology route, one or more hubs to support the network Fedora Core and Red Hat Enterprise Linux have excellent support for a broad range of Ethernet cards Still, there are some factors to take into consideration If you have old, 8-bit Ethernet adapters, now is the time to replace them They are slow and often difficult to configure Now that 100-Mbps cards are quite inexpensive, it’s probably not a good idea to invest in a slower card that’s slightly cheaper Be sure to check the Red Hat hardware database at www.redhat.com/support/hardware before buying new cards; in fact, it’s a good idea to go here to make sure that the ones you have are fully supported if you’re upgrading to Red Hat Linux (You don’t need to this for Windows machines connected to an existing network because as long as they’re properly configured for use with Windows, and as long as you continue to use Windows with them, they will work on your network, even though it’s served by Red Hat machines Of course, if you use 8-bit or older, slow peer network cards and you’re going to star architecture, you need to replace them too.) T I P If you have old, non-PCI Ethernet adapters, now is the time to replace them At this stage, you need to decide which headaches you’re willing to accept and which ones might more sensibly be placed elsewhere An example of this is Web and FTP hosting For a few dollars per month, you can arrange for your Web site (and FTP site, if you have one) to be hosted by a large and secure commercial enterprise Although it’s fun to host your own site, it may be much more cost-effective to outsource those duties The best ones have strict security Planning the Network rules — assigned passwords and administrator access by SSH or other highly secure methods only — and offer very high bandwidth and professional administration With such an arrangement, you can still have your own domain and still use your own local mail server, with mail downloaded from your hosting company (Your own SMTP mail server for outgoing mail remains on a local machine.) For many smaller companies, the cost of outsourcing is more than covered by the ability to use a low-cost cable or DSL service whose terms of use prohibit Web and FTP servers, meaning that you gain an extra level of professional service at no cost — quite a bargain Of course, if your enterprise is of sufficient size that you have a T-1 line and a huge server farm, there’s little to gain by not hosting your site yourself Planning and Implementing Security We cannot overstate the importance of computer security Practically every day there are new stories of large and small systems’ being cracked by vandals and other criminals Enterprises have been held hostage as criminals threatened to release the credit card numbers of thousands or hundreds of thousands of customers Not long ago, the entire Internet was slowed drastically because hundreds of thousands of machines, many of whose owners weren’t even aware they were running Web server software, were hijacked by a series of increasingly vicious and efficient “worm” programs that tried to corrupt other machines The attack grew to the point where there were so many machines at work scanning the Internet for potential victims that much of the Internet’s bandwidth — practically all of it in some places — was consumed System administrators who allow machines under their control to be vulnerable to this kind of attack, when there is an alternative, are certainly not doing their jobs as completely as they should be Addressing External and Internal Threats The threats from the outside world are very real and very frightening The extent to which data on your network is safe from prying eyes or random acts of destruction is entirely up to you But your concerns cannot stop there While cracker attacks get all the press, there are security concerns just as real that you can find within your own network, whether it’s a 500-node affair in an enterprise or a 3-node setup at home Imagine the damage that a disgruntled employee could or, for that matter, a child disappointed at being grounded Imagine what harm a dishonest employee could bring about, upon gaining access to company accounts or company secrets, or a troubled teenager who finds your credit card number, which you should never put on your computer 21 22 Chapter There is also the security issue of a user who simply makes a mistake that could have destroyed crucial data or brought down the entire system had certain security safeguards not been in place Take advantage of all the multiple lines of defense available, no matter the size of your network, even if you have a single standalone system that is physically accessible to others or that is connected to the Internet Otherwise, assume that anything on your network (or the machines on it) is accessible to anyone else in the world who is a little bit determined to get it Part V deals with security issues in great detail, but much of your security policy needs to be established before you install the network C R O S S-R E F E R E N C E To learn more about security, see Chapters 33 and 34 Formulating a Security Policy What should your security policy consist of? It should encompass an effective password policy, general security rules, security updates, and an appropriate firewall system An Effective Password Policy Although the method brings grumbles from users, assigned, random passwords made up of a combination of numbers and uppercase and lowercase letters, all with no discernable meaning, are safest (This procedure includes, most especially, the root account password.) Who has access to what? Red Hat Enterprise Linux enables you to create special groups and assign users to them This means that some users might have access to devices such as CD burners and modems, while others would not You may have sensitive situations in which you not want users to send files or even carry them from the building on a floppy disk You can provide increased security by using groups Although you don’t necessarily have to set this up first thing, it’s important to plan for and good to keep in mind General Security Rules A server that isn’t running cannot be used to crack your system If you’re not using a server application, don’t run it Change all passwords periodically Be prompt in removing network access of any employee who is discharged Employ intrusion detection software and check your logs regularly for anything unusual Planning the Network Security Updates Do you subscribe to the Red Hat Linux security mailing list? (Find it at www.redhat.com/mailing-lists/linux-security/index.html.) Have you established a procedure that makes sure that every security update is downloaded and installed? Luckily for you, Red Hat has created the Red Hat Network, a program intended to help keep your system updated with the latest security updates C R O S S-R E F E R E N C E Learn how to use the Red Hat Network in Chapter 26 An Appropriate Firewall System If yours is a standalone box on a broadband connection, the bare minimum is an Internet firewall-gateway-router appliance plus iptables If you run a Web site, set up a separate firewall machine (The more experienced administrator could go so far as to create a custom firewall on a bootable CD and then boot the firewall machine from that CD It is impossible to install a root kit on a CD, and the machine can have a hard drive for logging purposes.) Security is a process — a matter of constantly outwitting people who wish your network ill Red Hat Enterprise Linux goes a long way toward helping you beat crackers to the punch It’s up to you to make sure that your machine is not just buttoned up tightly today but continues to be secure tomorrow and the day after Planning for Recovery from Disasters Rare is the professional system administrator who hasn’t been awakened in the middle of the night or who had to work an entire weekend to recover from some tremendous mishap Likewise, rare is the owner of a standalone machine who hasn’t spent frantic hours trying with varying degrees of success to recover from a catastrophic failure of hardware, software, or execution When you plan your systems, it is critical to keep in mind two important terms: fault tolerance and disaster recovery Fault tolerance is the system’s ability to respond automatically to various conditions that can affect system operation and resolve the condition By responding automatically to a problem, fault tolerance reduces the effect of the problem on the system Properly implemented fault tolerance is transparent to users of the system They will continue to work, totally unaware that any problem has occurred Disaster recovery is the ability to restore functionality to the system after a failure has occurred The system administrator must implement this process; it 23 ... decided, also, to assume the control that Linux offers, and the responsibilities that this entails By its very nature as a modern, multiuser operating system, Linux requires a degree of administration. .. Summary As you, the system administrator, read this book, bear in mind that your tasks are ongoing and that there is never a machine that is completely tuned, entirely up to date, and utterly... first, adding services is simple in Red Hat Linux Some features, such as printer sharing, you’ll probably set up at the beginning Before you anything else, decide the physical layout, or topology,