Red Hat Linux Networking and System Administration / Edition 2

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (16) from $1.99   
  • New (4) from $4.00   
  • Used (12) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$4.00
Seller since 2011

Feedback rating:

(31)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
PAPERBACK New 0764544985 Your book ships the next business day.

Ships from: Cleveland, OH

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$12.50
Seller since 2011

Feedback rating:

(3)

Condition: New
New Condition not used

Ships from: Murphy, TX

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$4.00
Seller since 2010

Feedback rating:

(1796)

Condition: New
0764544985 BRAND NEW. Includes unopened CD-ROM. We are a tested and proven company with over 900,000 satisfied customers since 1997. Choose expedited shipping (if available) for ... much faster delivery. Delivery confirmation on all US orders. Read more Show Less

Ships from: Nashua, NH

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$17.08
Seller since 2008

Feedback rating:

(167)

Condition: New
0764544985 BRAND NEW NEVER USED IN STOCK 125,000+ HAPPY CUSTOMERS SHIP EVERY DAY WITH FREE TRACKING NUMBER

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

  • Starts with the basics of Red Hat, the leading Linux distribution in the U.S., such as network planning and Red Hat installation and configuration
  • Offers a close look at the new Red Hat Enterprise Linux 4 and Fedora Core 4 releases
  • New chapters cover configuring a database server, creating a VNC server, monitoring performance, providing Web services, exploring SELinux security basics, and exploring desktops
  • Demonstrates how to maximize the use of Red Hat Network, upgrade and customize the kernel, install and upgrade software packages, and back up and restore the file system
  • The four CDs contain the full Fedora Core 4 distribution
Read More Show Less

Product Details

  • ISBN-13: 9780764544989
  • Publisher: Wiley, John & Sons, Incorporated
  • Publication date: 1/23/2004
  • Edition description: REV
  • Edition number: 2
  • Pages: 1008
  • Product dimensions: 7.40 (w) x 9.10 (h) x 2.03 (d)

Meet the Author

Terry Collings is the owner of TAC Technology, located in eastern Pennsylvania. He provides Linux consulting and training services to a variety of clients. Terry has been an adjunct faculty member at several colleges in his area where he has taught A+ and Network + certification courses. He also has taught courses on Unix, Linux, TCP/IP, and Novell Netware.

Terry is the author of Red Hat Enterprise Linux 4 For Dummies and has co-authored and contributed to several other Linux books. He has been a technical editor for the following books: KDE Bible, The Samba Book, Unix Weekend Crash Course, Red Hat Linux 9 For Dummies, Solaris 9 For Dummies, Fedora Linux 2 For Dummies, and Linux Timesaving Techniques For Dummies.

Kurt Wall first touched a computer in 1980 when he learned FORTRAN on an IBM mainframe of forgotten vintage; things have improved since then. A professional technical writer by trade, a historian by training, and an all-around Linux guy by avocation, Kurt’s work history is diverse. These days, Kurt works in the Customer Engineering group at TimeSys Corporation in Pittsburgh, Pennsylvania. His primary responsibilities include building and maintaining TimeSys’s Developer Exchange and working with portal customers and users. He also fixes broken servers, writes documentation, and builds TimeSys software.

Kurt, who dislikes writing about himself in the third person, receives entirely too much e-mail at kwall@kurtwerks.com.

Read More Show Less

Read an Excerpt

Red Hat Linux Networking and System Administration


By Terry Collings

John Wiley & Sons

ISBN: 0-7645-9949-6


Chapter One

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 magnitude, so even an experienced Linux administrator is likely to find much that is new and unfamiliar. Fortunately, there are new tools designed to make system administration easier than ever before.

Make no mistake: Every computer in the world has a system administrator. It may be - and probably is - true that the majority of system administrators are those who decided what software and peripherals were bundled with the machine when it was shipped. That status quo remains because the majority of users who acquire computers for use as appliances probably do little to change the default values. But the minute a user decides on a different wallpaper image or adds an application that was acquired apart from the machine itself, he or she has taken on the role of system administration.

The highfalutin' title of system administrator brings with it some responsibilities. No one whose computer is connected to the Internet, for instance, has been immune to the effects of poorly administered systems, as demonstrated by the distributed denial of service (DDoS) and email macro virus attacks that have shaken the online world in recent years. The scope of these acts of computer vandalism (in some cases, computer larceny) would have been greatly reduced if system administrators had a better understanding of their duties.

Linux system administrators are likely to understand the necessity of active system administration more than those who run whatever came on the computer, assuming that things came properly configured from the factory. The user or enterprise that decides on Linux has 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 greater than that of less robust, home-market systems. This means that even if you use just a single machine connected to the Internet by a dial-up modem - or not even connected at all - you have the benefits of the same system employed by some of the largest businesses in the world, and will do many of the same things that IT professionals employed by those companies are paid to do. Administering your system does involve a degree of learning, but it also means that in setting up and configuring your own system you gain skills and understanding that raise you above mere "computer user" status. The Linux system administrator does not achieve that mantle by purchasing a computer but by taking full control of what the computer does and how it does it.

You may end up configuring a small home or small office network of two or more machines, perhaps including ones that are not running Linux. You may be responsible for a business network of dozens of machines. The nature of system administration in Linux is surprisingly constant, no matter how large or small your installation. It merely involves enabling and configuring features you already have available.

By definition, the Linux system administrator is the person who has "root" access, which is to say the one who is the system's "superuser" (or root user). A standard Linux user is limited to whatever he or she can do with the underlying engine of the system. But the root user has unfettered access to everything - all user accounts, their home directories, and the files therein; all system configurations; and all files on the system. A certain body of thought says that no one should ever log in as "root," because system administration tasks can be performed more easily and safely through other, more specific means, which we discuss in due course. Because the system administrator has full system privileges, your first duty is to know what you're doing, lest you break something.

NOTE By definition, the Linux system administrator can be anyone who has "root" access - anyone who has root access is the system's "superuser."

The word duty implies a degree of drudgery; in fact, it's a manifestation of the tremendous flexibility of the system measured against the responsibility to run a tight organization. These duties do not so much constrain you, the system administrator, as free you to match the job to the task. Let's take a brief look at them.

Installing and Configuring Servers

When you hear the word server to describe a computer, you probably think of a computer that offers some type of service to clients. The server may provide file or printer sharing, File Transfer Protocol (FTP) or Web access, or email-processing tasks. Don't think of a server as a standalone workstation; think of it as a computer that specifically performs these services for many users.

In the Linux world, the word server has a broader meaning than what you might be used to. For instance, the standard Red Hat graphical user interface (GUI) requires a graphical layer called XFree86. This is a server. It runs even on a standalone machine with one user account. It must be configured. (Fortunately, Red Hat has made this a simple and painless part of installation on all but the most obscure combinations of video card and monitor; gone are the days of anguish as you configure a graphical desktop.)

Likewise, printing in Linux takes place only after you configure a print server. Again, this has become so easy as to be nearly trivial.

In certain areas the client-server nomenclature can be confusing, though. While you cannot have a graphical desktop without an X server, you can have remote Web access without running a local Web server, remote FTP access without running a local FTP server, and email capabilities without ever starting a local mail server. You may well want to use these servers, all of which are included in Red Hat; then again, maybe not. Whenever a server is connected to other machines outside your physical control, there are security implications to consider. You want your users to have easy access to the things they need, but you don't want to open up the system you're administering to the whole wide world.

NOTE Whenever a server is connected to machines outside your physical control, security issues arise. You want users to have easy access to the things they need but you don't want to open up the system you're administering to the whole wide world.

Linux distributions used to ship with all imaginable servers turned on by default. Just installing the operating system on the computer would install and configure - with default parameters - all the services available with the distribution. This was a reflection of an earlier, more innocent era in computing when people did not consider vandalizing other people's machines to be good sportsmanship. Unfortunately, the realities of this modern, more dangerous world dictate that all but the most essential servers remain turned off unless specifically enabled and configured. This duty falls to the system administrator. You need to know exactly which servers you need and how to employ them, and to be aware that it is bad practice and a potential security nightmare to enable services that the system isn't using and doesn't need. Fortunately, the following pages show you how to carry out this aspect of system administration easily and efficiently.

Installing and Configuring Application Software

Although it is possible for individual users to install some applications in their home directories - drive space set aside for their own files and customizations - these applications may not be available to other users without the intervention of the user who installed the program or the system administrator. Besides, if an application is to be used by more than one user, it probably needs to be installed higher up in the Linux file hierarchy, which is a job that only the system administrator can perform. (The administrator can even decide which users may use which applications by creating a "group" for that application and enrolling individual users in that group.)

New software packages might be installed in /opt if they are likely to be upgraded separately from the Red Hat distribution itself. Doing this makes it simple to retain the old version until you are certain that the new version works and meets your expectations. Some packages may need to go in /usr/src or even /usr if they are upgrades of packages installed as part of Red Hat. (For instance, there are sometimes security upgrades of existing packages.) The location of the installation usually matters only if you compile the application from source code; if you use a Red Hat Package Manager (RPM) application package, it automatically goes where it should.

Configuration and customization of applications is to some extent at the user's discretion, but not entirely. "Skeleton" configurations - administrator-determined default configurations - set the baseline for user employment of applications. If there are particular forms, for example, that are used throughout an enterprise, the system administrator would set them up or at least make them available by adding them to the skeleton configuration. The same applies to configuring user desktops and in even deciding what applications should appear on user desktop menus. For instance, your company may not want to grant users access to the games that ship with modern Linux desktops. You may also want to add menu items for newly installed or custom applications. The system administrator brings all this to pass.

Creating and Maintaining User Accounts

Not just anyone can show up and log on to a Linux machine. An account must be created for each user and - you guessed it - no one but the system administrator can do this. That's simple enough.

But there's more. It involves decisions that either you or your company must make. You might want to let users select their own passwords, which would no doubt make them easier to remember but which probably would be easier for a malefactor to crack. You might want to assign passwords, which is more secure in theory but increases the likelihood that users will write them down on a conveniently located scrap of paper - a risk if many people have access to the area where the machine(s) is located. You might decide that users must change their passwords periodically - something you can configure Red Hat Enterprise Linux to prompt users about.

What happens to old accounts? Suppose that someone leaves the company. You probably don't want that person to gain access to the company's network, but you also don't want to delete the account wholesale, only to discover later that essential data resided nowhere else.

To what may specific users have access? It might be that there are aspects of your business that make Web access desirable, but you don't want everyone spending their working hours surfing the Web. If your system is at home, you may wish to limit your children's access to certain Web sites.

These and other issues are part of the system administrator's duties in managing user accounts. Whether the administrator or his or her employer establishes policies governing accounts, these policies should be delineated - preferably in writing for a company - for the protection of all concerned.

Backing Up and Restoring Files

Until computer equipment becomes infallible, until people lose the desire to harm others' property, and - truth be told - until system administrators become perfect, there is considerable need to back up important files so that the system can be up and running again with minimal disruption in the event of hardware, security, or administration failure. Only the system administrator may do this. (Because of its built-in security features, Linux doesn't allow even users to back up their own files to removable disks.)

It's not enough to know that performing backups is your job. You need to formulate a strategy for making sure your system is not vulnerable to catastrophic disruption. This is not always obvious. If you have a high-capacity tape drive and several good sets of restore disks, you might make a full system backup every few days. If you are managing a system with scores of users, you might find it more sensible to back up user accounts and system configuration files, figuring that reinstallation from the distribution CDs would be quicker and easier than getting the basics off a tape archive. (Don't forget about applications you install separately from your Red Hat distribution, especially those involving heavy customization.)

Once you decide what to back up, you need to decide how frequently to perform backups, whether to maintain a series of incremental backups - adding only files that have changed since the last backup - or multiple full backups, and when these backups should be performed. Do you trust an automated, unattended process? If you help determine which equipment to use, do you go with a redundant array of independent disks (RAID), which is to say multiple hard drives all containing the same data as insurance against the failure of any one of them, in addition to other backup systems? (A RAID is not enough because hard drive failure is not the only means by which a system can be brought to a halt.)

You don't want to become complacent or foster a lackadaisical attitude among users. Part of your strategy should be to maintain perfect backups without ever needing to resort to them. This means encouraging users to keep multiple copies of their important files in their home directories so that you won't be asked to mount a backup to restore a file that a user corrupted. (If your system is a standalone one then, as your own system administrator, you should make a habit of backing up your configuration and other important files.)

Restoring files from your backup media is no less important than backing them up in the first place. Be certain you can restore your files if the need arises by testing your restore process at least once during a noncritical time. Periodically testing your backup media is also a good idea.

Chances are good that even if you work for a company, you'll be the one making these decisions. Your boss just wants a system that runs perfectly, all the time. Backing up is only part of the story, however. You need to formulate a plan for bringing the system back up after a failure. A system failure could be caused by any number of problems, either related to hardware or software (application, system configuration) trouble, and could range from a minor inconvenience to complete shutdown.

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.

(Continues...)



Excerpted from Red Hat Linux Networking and System Administration by Terry Collings Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Pt. 1 System and network administration defined 1
Ch. 1 Duties of the system administrator 3
Ch. 2 Planning the network 13
Ch. 3 Standard installation 29
Ch. 4 Kickstart installation 71
Ch. 5 Exploring the desktops 97
Ch. 6 System startup and shutdown 127
Ch. 7 The file system explained 141
Ch. 8 Examining the system configuration files 163
Pt. 2 Network services 203
Ch. 9 Managing the X Window system 205
Ch. 10 Configuring printers 217
Ch. 11 TCP/IP networking 229
Ch. 12 The network file system 265
Ch. 13 The network information system 309
Ch. 14 Connecting to Microsoft and Novell networks 339
Ch. 15 Configuring a database server 351
Ch. 16 Creating a VNC server 381
Ch. 17 Providing additional network services 393
Ch. 18 Optimizing network services 415
Pt. 3 Internet services 427
Ch. 19 What are Internet services? 429
Ch. 20 Configuring BIND : the domain name system 443
Ch. 21 Configuring mail services 467
Ch. 22 Configuring FTP services 491
Ch. 23 Configuring a Web server 511
Ch. 24 Providing Web services 555
Ch. 25 Optimizing Internet services 581
Pt. 4 System administration 595
Ch. 26 Keeping your system updated with up2date and the Red Hat network 597
Ch. 27 Upgrading and customizing the kernel 615
Ch. 28 Configuring the system at the command line 673
Ch. 29 Administering users and groups 707
Ch. 30 Installing and upgrading software packages 745
Ch. 31 Backing up and restoring the file system 779
Ch. 32 Performance monitoring 805
Pt. 5 System security and problem solving 833
Ch. 33 Exploring SELinux security 835
Ch. 34 Implementing network security 847
Ch. 35 Troubleshooting and problem solving 875
App. A Bash shell scripting 905
Read More Show Less

First Chapter

Red Hat Linux Networking and System Administration


By Terry Collings Kurt Wall

John Wiley & Sons

ISBN: 0-7645-4498-5


Chapter One

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. In this chapter, we briefly look at those responsibilities, which we'll cover 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. Instead, 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, 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 magnitude, so even an experienced Linux administrator is likely to find much that is new and unfamiliar. Fortunately, there are new tools designed to make system administration easier than ever before.

Make no mistake: Every computer in the world has a system administrator. It may be-and probably is-true that the majority of system administrators are those who decided what software and peripherals were bundled with the machine when it was shipped. That status quo remains because the majority of users who acquire computers for use as appliances probably do little to change the default values. But the minute a user decides on a different wallpaper image or adds an application that was acquired apart from the machine itself, he or she has taken on the role of system administration.

The highfalutin title of system administrator brings with it some responsibilities. No one whose computer is connected to the Internet, for instance, has been immune to the effects of poorly administered systems, as demonstrated by the Distributed Denial of Service (DDoS) and e-mail macro virus attacks that have shaken the online world in recent years. The scope of these acts of computer vandalism (in some cases, computer larceny) would have been greatly reduced if system administrators had a better understanding of their duties.

Linux system administrators are likely to understand the necessity of active system administration more than those who run whatever came on the computer, assuming that things came properly configured from the factory. The user or enterprise that decides on Linux has decided, too, 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 greater than that of less robust, home-market systems. This means that even if you use just a single machine connected to the Internet by a dial-up modem - or not even connected at all - you have the benefits of the same system employed by some of the largest businesses in the world, and will do many of the same things that IT professionals employed by those companies are paid to do. Administering your system does involve a degree of learning but it also means that in setting up and configuring your own system you gain skills and understanding that raise you above mere "computer user" status. The Linux system administrator does not achieve that mantle by purchasing a computer but by taking full control of what the computer does and how it does it.

You may end up configuring a small home or small office network of two or more machines, perhaps including ones that are not running Linux. You may be responsible for a business network of dozens of machines. The nature of system administration in Linux is surprisingly constant, no matter how large or small your installation. It merely involves enabling and configuring features you already have available.

By definition, the Linux system administrator is the person who has "root" access, which is to say the one who is the system's "super user" (or root user). A standard Linux user is limited to whatever he or she can do with the underlying engine of the system. But the root user has unfettered access to everything - all user accounts, their home directories, and the files therein; all system configurations; and all files on the system. A certain body of thought says that no one should ever log in as "root," because system administration tasks can be performed more easily and safely through other, more specific means, which we discuss in due course. Because the system administrator has full system privileges, your first duty is to know what you're doing, lest you break something.

NOTE

By definition, the Linux system administrator is the person who has "root" access - the one who is the system's "super user."

The word duty implies a degree of drudgery; in fact, it's a manifestation of the tremendous flexibility of the system measured against the responsibility to run a tight organization. These duties do not so much constrain you, the system administrator, as free you to match the job to the task. Let's take a brief look at them.

Installing and Configuring Servers

When you hear the word server to describe a computer, you probably think of a computer that offers some type of service to clients. The server may provide file or printer sharing, File Transfer Protocol (FTP) or Web access, or e-mail processing tasks. Don't think of a server as a standalone workstation; think of it as a computer that specifically performs these services for many users.

In the Linux world, the word server has a broader meaning than what you might be used to. For instance, the standard Red Hat graphical user interface (GUI) requires a graphical layer called XFree86. This is a server. It runs even on a standalone machine with one user account. It must be configured. (Fortunately, Red Hat has made this a simple and painless part of installation on all but the most obscure combinations of video card and monitor; gone are the days of anguish as you configure a graphical desktop.)

Likewise, printing in Linux takes place only after you configure a print server. Again, this has become so easy as to be nearly trivial.

In certain areas the client-server nomenclature can be confusing, though. While you cannot have a graphical desktop without a server, you can have Web access without a Web server, FTP access without running an FTP server, and e-mail capabilities without ever starting a mail server. You may well want to use these servers, all of which are included in Red Hat; then again, maybe not. Whenever a server is connected to other machines outside your physical control, there are security implications to consider. You want your users to have easy access to the things they need but you don't want to open up the system you're administering to the whole wide world.

NOTE

Whenever a server is connected to machines outside your physical control, security issues arise. You want users to have easy access to the things they need but you don't want to open up the system you're administering to the whole wide world.

Linux distributions used to ship with all imaginable servers turned on by default. Just installing the operating system on the computer would install and configure - with default parameters - all the services available with the distribution. This was a reflection of an earlier, more innocent era in computing when people did not consider vandalizing other people's machines to be good sportsmanship. Unfortunately, the realities of this modern, more dangerous world dictate that all but the most essential servers remain turned off unless specifically enabled and configured. This duty falls to the system administrator. You need to know exactly which servers you need and how to employ them, and to be aware that it is bad practice and a potential security nightmare to enable services that the system isn't using and doesn't need. Fortunately, the following pages show you how to carry out this aspect of system administration easily and efficiently.

Installing and Configuring Application Software

Although it is possible for individual users to install some applications in their home directories - drive space set aside for their own files and customizations - these applications are not available to other users without the intervention of the system administrator. Besides, if an application is to be used by more than one user, it probably needs to be installed higher up in the Linux file hierarchy, which is a job that only the system administrator can perform. (The administrator can even decide which users may use which applications by creating a "group" for that application and enrolling individual users in that group.)

New software packages might be installed in /opt if they are likely to be upgraded separately from the Red Hat distribution itself. Doing this makes it simple to retain the old version until you are certain that the new version works and meets your expectations. Some packages may need to go in /usr/local or even /usr if they are upgrades of packages installed as part of Red Hat. (For instance, there are sometimes security upgrades of existing packages.) The location of the installation usually matters only if you compile the application from source code; if you use a Red Hat Package Manager (RPM) application package, it automatically goes where it should.

Configuration and customization of applications is to some extent at the user's discretion, but not entirely. "Skeleton" configurations - administrator - determined default configurations - set the baseline for user employment of applications. If there are particular forms, for example, that are used throughout an enterprise, the system administrator would set them up or at least make them available by adding them to the skeleton configuration. The same applies to configuring user desktops and in even deciding what applications should appear on user desktop menus. For instance, your company may not want to grant users access to the games that ship with modern Linux desktops. You may also want to add menu items for newly installed or custom applications. The system administrator brings all this to pass.

Creating and Maintaining User Accounts

Not just anyone can show up and log on to a Linux machine. An account must be created for each user and - you guessed it - no one but the system administrator can do this. That's simple enough.

But there's more. It involves decisions that either you or your company must make. You might want to let users select their own passwords, which would no doubt make them easier to remember but which probably would be easier for a malefactor to crack. You might want to assign passwords, which is more secure in theory but increases the likelihood that users will write them down on a conveniently located scrap of paper - a risk if many people have access to the area where the machine(s) is located. You might decide that users must change their passwords periodically - something you can configure Red Hat Enterprise Linux to prompt users about.

What happens to old accounts? Suppose someone leaves the company. You probably don't want him or her to gain access to the company network, but you also don't want to delete the account wholesale, only to discover later that essential data resided nowhere else.

To what may specific users have access? It might be that there are aspects of your business that make Web access desirable, but you don't want everyone spending their working hours surfing the Web. If your system is at home, you may wish to limit your children's access to certain Web sites.

These and other issues are part of the system administrator's duties in managing user accounts. Whether the administrator or his or her employer establishes policies governing accounts, these policies should be delineated - preferably in writing for a company - for the protection of all concerned.

Backing Up and Restoring Files

Until computer equipment becomes infallible, until people lose the desire to harm others' property, and - truth be told - until system administrators become perfect, there is considerable need to back up important files so that the system can be up and running again with minimal disruption in the event of hardware, security, or administration failure. Only the system administrator may do this. (Because of its built-in security features, Linux doesn't allow users even to back up their own files to removable disks.)

It's not enough to know that performing backups is your job. You need to formulate a strategy for making sure your system is not vulnerable to catastrophic disruption. This is not always obvious. If you have a high-capacity tape drive and several good sets of restore disks, you might make a full system backup every few days. If you are managing a system with scores of users, you might find it more sensible to back up user accounts and system configuration files, figuring that reinstallation from the distribution CDs would be quicker and easier than getting the basics off a tape archive. (Don't forget about applications you install separately from your Red Hat distribution, especially those involving heavy customization.)

Once you decide what to back up, you need to decide how frequently to perform backups, whether to maintain a series of incremental backups - adding only files that have changed since the last backup - or multiple full backups, and when these backups should be performed. Do you trust an automated, unattended process? If you help determine which equipment to use, do you go with a redundant array of independent disks (RAID), which is to say multiple hard drives all containing the same data as insurance against the failure of any one of them, in addition to other backup systems? (A RAID is not enough because hard drive failure is not the only means by which a system can be brought to a halt.)

You don't want to become complacent or foster a lackadaisical attitude among users. Part of your strategy should be to maintain perfect backups without ever needing to resort to them. This means encouraging users to keep multiple copies of their important files in their home directories so that you won't be asked to mount a backup to restore a file that a user corrupted.

Continues...


Excerpted from Red Hat Linux Networking and System Administration by Terry Collings Kurt Wall Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)