Managing NFS and NIS

( 4 )


A modern computer system that's not part of a network is even more of an anomaly today than it was when we published the first edition of this book in 1991. But however widespread networks have become, managing a network and getting it to perform well can still be a problem.Managing NFS and NIS, in a new edition based on Solaris 8, is a guide to two tools that are absolutely essential to distributed computing environments: the Network Filesystem (NFS) and the Network Information System (formerly called the ...

See more details below
Paperback (Second Edition)
$40.40 price
(Save 26%)$54.99 List Price
Other sellers (Paperback)
  • All (22) from $1.99   
  • New (9) from $30.47   
  • Used (13) from $1.99   
Managing NFS and NIS

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$22.99 price
(Save 42%)$39.99 List Price


A modern computer system that's not part of a network is even more of an anomaly today than it was when we published the first edition of this book in 1991. But however widespread networks have become, managing a network and getting it to perform well can still be a problem.Managing NFS and NIS, in a new edition based on Solaris 8, is a guide to two tools that are absolutely essential to distributed computing environments: the Network Filesystem (NFS) and the Network Information System (formerly called the "yellow pages" or YP).The Network Filesystem, developed by Sun Microsystems, is fundamental to most Unix networks. It lets systems ranging from PCs and Unix workstations to large mainframes access each other's files transparently, and is the standard method for sharing files between different computer systems.As popular as NFS is, it's a "black box" for most users and administrators. Updated for NFS Version 3, Managing NFS and NIS offers detailed access to what's inside, including:

  • How to plan, set up, and debug an NFS network
  • Using the NFS automounter
  • Diskless workstations
  • PC/NFS
  • A new transport protocol for NFS (TCP/IP)
  • New security options (IPSec and Kerberos V5)
  • Diagnostic tools and utilities
  • NFS client and server tuning
NFS isn't really complete without its companion, NIS, a distributed database service for managing the most important administrative files, such as the passwd file and the hosts file. NIS centralizes administration of commonly replicated files, allowing a single change to the database rather than requiring changes on every system on the network.If you are managing a network of Unix systems, or are thinking of setting up a Unix network, you can't afford to overlook this book.

Unlike Santifaller's book, Stern is writing for those who are already working with NFS and need to know as much as possible about it. Its primary audience will be system administrators, as it features lengthy chapters on security, performance tuning, diagnostic and administrative tools (including the Automounter), debugging network problems, and more. Users can get something out of the introductory chapters, including one on building applications.

Read More Show Less

Product Details

  • ISBN-13: 9781565925106
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 7/18/2001
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 512
  • Product dimensions: 7.10 (w) x 9.14 (h) x 1.03 (d)

Meet the Author

Mike Eisler graduated from the University of Central Florida with a master's degree in computer science in 1985. His first exposure to NFS and NIS came while working for Lachman Associates, Inc., where he was responsible for porting NFS and NIS to System V platforms. He later joined Sun Microsystems, Inc., responsible for projects such as NFS server performance, NFS/TCP, WebNFS, NFS secured with Kerberos V5, NFS Version 4, and JavaCard security. Mike has authored or coauthored several Request For Comments documents for the Internet Engineering Task Force, relating to NFS and security. He is currently a Technical Director at Network Appliance, Inc.

Ricardo Labiaga is a staff engineer at Sun Microsystems, Inc., where he concentrates on networking and wireless technologies. Ricardo spent 8 years in the Solaris NFS group at Sun, where he worked on a variety of development projects with a primary focus on automounting and the NFS server. Ricardo is responsible for implementing significant functionality and performance enhancements to the automounter, as well as leading the NFS Server Logging design team. He holds a master of science degree in computer engineering from The University of Texas at El Paso.

Hal Stern is a technical consultant with Sun Microsystems, where he specializes in networking, performance tuning, and kernel hacking. Hal earned a Bachelor of Science degree from Princeton University in 1984. Before joining Sun, Hal was a member of the technical staff at Polygen Corporation, developing UNIX-based molecular modelling and chemical information system products. Hal also worked on the Massive Memory Machine project as a member of the Research Staff in Princeton University's Department of Computer Science. His interests include large installation system administration, virtual memory management systems, performance, local and wide-area networking, interactive graphics, applications in financial services, cosmology, and the history of science. Hal is active in the Sun User's Group and has served on the advisory trustee board of the Princeton Broadcasting Service for seven years. Hal and his wife Toby live in Burlington, Massachusetts. At home, Hal enjoys carpentry, jazz music, cooking, and watching the stock market.

Read More Show Less

Read an Excerpt

Chapter 8: Network Security

NFS Security

Filesystem security has two aspects: controlling access to and operations on files, and limiting exposure of the contents of the files. Controlling access to remote files involves mapping UNIX file operation semantics into the NFS system, so that certain operations are disallowed if the remote user fails to provide the proper credentials. To avoid giving superuser permissions across the network, additional constraints are put in place for access to files by root. Even more stringent NFS security requires proving that the UNIX-style credentials contained in each NFS request are valid; that is, the server must know that the NFS client's request was made by a valid user and not an imposter on the network.

Limiting disclosure of data in a file is more difficult, as it usually involves encrypting the contents of the file. The client application may choose to enforce its own data encryption and store the file on the server in encrypted form. In this case, the client's NFS requests going over the network contain blocks of encrypted data. However, if the file is stored and used in clear text form, NFS requests to read or write the file will contain clear text as well. Sending parts of files over a network is subject to some data exposure concerns. In general, if security would be comprised by any part of a file being disclosed, then the file should not be placed on an NFS-mounted filesystem. You can prevent damage to files by restricting write permissions and enforcing user authentication, but there are few safeguards against someone eavesdropping on your network. NFS has some simple security mechanisms in place today, and the Secure RPC mechanisms described in this chapter ensure that user authentication is made secure as well. "Ibis section presents ways of restricing access based on the user credentials presented in NFS requests, and then looks at validating the credentials themselves using Secure RPC.

NFS RPC Authentication

Every NFS request, including mount requests, contains a set of user credentials with a UID and a list of group IDs (GIDs) to which the UID belongs. NFS credentials are the same as those used for accessing local files, that is, if you belong to five groups, your NFS credentials contain your UID and five GIDs. On the NFS server, these credentials are used to perform the permission checks that are part of UNIX file accesses-verifying write permission to remove a file, or execute permission to search directories. There are three areas in which NFS credentials may not match the user's local credential structure: the user is the superuser, the user is in too many groups, or no credentials were supplied (an "anonymous" request). Mapping of root and anonymous users is covered in the next section.

Problems with "too many" groups depend upon the implementation of NFS used by the client and the server, and may be an issue only if they are different (including different revisions of the same operating system). Every NFS implementation has a limit on the number of groups that ran be passed in a credentials structure for an NFS RPC. Ibis number usually agrees with the maximum number of groups to which a user may belong, but it may be smaller. Typically, the limit on the number of groups is either 8 or 16. If the client's group limit is larger than the server's, and a user is in more groups than the server allows, then the server's attempt to parse and verify the credential structure will fail, yielding error messages like:

RPC: Authentication error

Authentication errors may occur when trying to mount a filesystem, in which case the superuser is in too many groups. Errors may also occur when a particular user tries to access files on the NFS server; these errors result from any NFS RPC operation. Pay particular attention to the group file in a heterogeneous environment, where the Nis-managed group map may be appended to a local file with several entries for common users like root and bin. The only solution is to restrict the number of groups to the smallest value allowed by all systems that are running NFS.

Superuser Mapping

The superuser is not given normal file access permissions to NFS-mounted files. The motivation behind this restriction is that root access should be granted on a per-machine basis. A user who is capable of becoming root on one machine should not necessarily have permission to modify files on a file server. Similarly, a setuid program that assumes root privileges may not function properly or as expected if it is allowed to operate on remote files.

To enforce restrictions on superuser access, the roof s UID is mapped to the anonymous user nobody in the NFS RPC credential structure. The superuser frequently has fewer permissions than a non-privileged user for NFS-mounted filesystems, since nobody's group usually includes no other users. in the password file, nobody has a UID of -2, and the group nogroup also has a GID of -2. On systems that require non-negative user and group ID values, nobody and nogroup use a 16-bit unsigned representation of -2. When an executable that 65534, which is is setuid runs, its effective user ID is root, which gets mapped to nobody. The executable still has permissions on the local system, but it cannot get to remote files unless they have been explicitly exported with root access enabled.

Some implementations of NFS allow the root UID mapping to be defeated by changing the UID used for nobody in the server's kernel. Changing the UID for nobody from -2 to 0 allows the superuser to access all files exported from the server, which may be less restrictive than desired. The mapping may be changed by simply modifying the UD and GID of the nobody user in the server's password file:

nobody:*:0:0:Anonymous user::

Changing nobody's UID affects every filesystem exported from the server, and should be considered as much an invitation for trouble as providing the root password to users that mount filesystems from the server.

Most NFS servers grant root permission on an exported filesystem on a per-host basis using the root=export option. The server exporting a filesystem grants root access to a host or list of hosts by including them in the /etc/exports file:

/home/work -root=bitatron:corvette

superuser on hosts bitatron and corvette is given normal root filesystem privileges on the server's /home/work directory. The name of a netgroup may be substituted for a hostname; all of the hosts in the netgroup are granted root access.

Root permissions on a remote filesystem should be extended only when absolutely necessary. While privileged users may find it annoying to have to log into the server owning a filesystem in order to modify something owned by root, this restriction also eliminates many common mistakes. If a system administrator wants to purge /usr/local on one host (to rebuild it, for example), executing rm -rf * will have disastrous consequences if there is an NFS-mounted filesystem with root permission under /usr/local. If /usr/local/bin is NFS mounted, then it is possible to wipe out the server's copy of this directory from a client when root permissions are extended over the network.

The only clear-cut case where root permissions should be extended on an NFS filesystem is for the root and swap partitions of a diskless client, where they are mandatory. One other possible scenario in which root permissions are useful is...

Read More Show Less

Table of Contents

Who this book is for;
Conventions used in this book;
Differences between the first edition and second edition;
Comments and questions;
Hal's acknowledgments from the first edition;
Acknowledgments for the second edition;
Chapter 1: Networking Fundamentals;
1.1 Networking overview;
1.2 Physical and data link layers;
1.3 Network layer;
1.4 Transport layer;
1.5 The session and presentation layers;
Chapter 2: Introduction to Directory Services;
2.1 Purpose of directory services;
2.2 Brief survey of common directory services;
2.3 Name service switch;
2.4 Which directory service to use;
Chapter 3: Network Information Service Operation;
3.1 Masters, slaves, and clients;
3.2 Basics of NIS management;
3.3 Files managed under NIS;
3.4 Trace of a key match;
Chapter 4: System Management Using NIS;
4.1 NIS network design;
4.2 Managing map files;
4.3 Advanced NIS server administration;
4.4 Managing multiple domains;
Chapter 5: Living with Multiple Directory Servers;
5.1 Domain name servers;
5.2 Implementation;
5.3 Fully qualified and unqualified hostnames;
5.4 Centralized versus distributed management;
5.5 Migrating from NIS to DNS for host naming;
5.6 What next?;
Chapter 6: System Administration Using the Network File System;
6.1 Setting up NFS;
6.2 Exporting filesystems;
6.3 Mounting filesystems;
6.4 Symbolic links;
6.5 Replication;
6.6 Naming schemes;
Chapter 7: Network File System Design and Operation;
7.1 Virtual filesystems and virtual nodes;
7.2 NFS protocol and implementation;
7.3 NFS components;
7.4 Caching;
7.5 File locking;
7.6 NFS futures;
Chapter 8: Diskless Clients;
8.1 NFS support for diskless clients;
8.2 Setting up a diskless client;
8.3 Diskless client boot process;
8.4 Managing client swap space;
8.5 Changing a client's name;
8.6 Troubleshooting;
8.7 Configuration options;
8.8 Brief introduction to JumpStart administration;
8.9 Client/server ratios;
Chapter 9: The Automounter;
9.1 Automounter maps;
9.2 Invocation and the master map;
9.3 Integration with NIS;
9.4 Key and variable substitutions;
9.5 Advanced map tricks;
9.6 Side effects;
Chapter 10: PC/NFS Clients;
10.1 PC/NFS today;
10.2 Limitations of PC/NFS;
10.3 Configuring PC/NFS;
10.4 Common PC/NFS usage issues;
10.5 Printer services;
Chapter 11: File Locking;
11.1 What is file locking?;
11.2 NFS and file locking;
11.3 Troubleshooting locking problems;
Chapter 12: Network Security;
12.1 User-oriented network security;
12.2 How secure are NIS and NFS?;
12.3 Password and NIS security;
12.4 NFS security;
12.5 Stronger security for NFS;
12.6 Viruses;
Chapter 13: Network Diagnostic and Administrative Tools;
13.1 Broadcast addresses;
13.2 MAC and IP layer tools;
13.3 Remote procedure call tools;
13.4 NIS tools;
13.5 Network analyzers;
Chapter 14: NFS Diagnostic Tools;
14.1 NFS administration tools;
14.2 NFS statistics;
14.3 snoop;
14.4 Publicly available diagnostics;
14.5 Version 2 and Version 3 differences;
14.6 NFS server logging;
14.7 Time synchronization;
Chapter 15: Debugging Network Problems;
15.1 Duplicate ARP replies;
15.2 Renegade NIS server;
15.3 Boot parameter confusion;
15.4 Incorrect directory content caching;
15.5 Incorrect mount point permissions;
15.6 Asynchronous NFS error messages;
Chapter 16: Server-Side Performance Tuning;
16.1 Characterization of NFS behavior;
16.2 Measuring performance;
16.3 Benchmarking;
16.4 Identifying NFS performance bottlenecks;
16.5 Server tuning;
Chapter 17: Network Performance Analysis;
17.1 Network congestion and network interfaces;
17.2 Network partitioning hardware;
17.3 Network infrastructure;
17.4 Impact of partitioning;
17.5 Protocol filtering;
Chapter 18: Client-Side Performance Tuning;
18.1 Slow server compensation;
18.2 Soft mount issues;
18.3 Adjusting for network reliability problems;
18.4 NFS over wide-area networks;
18.5 NFS async thread tuning;
18.6 Attribute caching;
18.7 Mount point constructions;
18.8 Stale filehandles;
Appendix A: IP Packet Routing;
A.1 Routers and their routing tables;
A.2 Static routing;
Appendix B: NFS Problem Diagnosis;
B.1 NFS server problems;
B.2 NFS client problems;
B.3 NFS errno values;
Appendix C: Tunable Parameters;

Read More Show Less

Customer Reviews

Average Rating 4
( 4 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & 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 & 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 & 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 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


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & 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 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
Sort by: Showing all of 4 Customer Reviews
  • Anonymous

    Posted May 12, 2014

    Nick fury

    Read next rp post 1

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted May 10, 2014



    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted May 9, 2014

    Agents of S.H.E.I.L.D

    Welcome agent to S.H.E.I.L.D. I can not tell you what Sheild stands for but I can tell you what we do. We serve and protect our country when all else fails. We are our county's sheild when superheroes and the army are occupied. We are a secret agency who has protected many things (( even alien )) from the public. We have encountered aliems to mythical beings like Thor. Well...that' s all the time I have left. I have included a map and a list of rules below. I hope you join and I can't wait to see you. <p> Map: Res1- Map / Res2- NewComers Room / Res3- Lounge / Res4- Briefing room / Res5- Jumbo jet / Res7- Weaponry / Res8- The Freezer / the rest of the res vary. <p> RULES: - NO auto killz / NO godmodding / NO moving up ranks unless consulting with the leader of Sheild / No making up missions .

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted December 1, 2012


    She sat and waited.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 4 Customer Reviews

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