IBM AS-400e User Manual

0 (0)

AS/400e

IBM

OS/400 Network File System Support

Version 4

SC41-5714-01

AS/400e

IBM

OS/400 Network File System Support

Version 4

SC41-5714-01

Note

Before using this information and the product it supports, be sure to read the information in ªNoticesº on page 99.

Second Edition (May 1999)

This edition replaces SC41-5714-00.

Note to U.S. Government Users Ð Documentation related to restricted rights Ð Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . .	vii
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . .	ix
About OS/400 Network File System Support (SC41-5714) . . . . . . .	xi
Who should read this book . . . . . . . . . . . . . . . . . . . .	xi
AS/400 Operations Navigator . . . . . . . . . . . . . . . . . . .	xi
Installing Operations Navigator. . . . . . . . . . . . . . . . . .	xii
Prerequisite and related information . . . . . . . . . . . . . . . . .	xii
How to send your comments . . . . . . . . . . . . . . . . . . .	xiii
Summary of Changes . . . . . . . . . . . . . . . . . . . . .	xv

Chapter 1. What is the Network File System? . . . . .

Introduction . . . . . . . . . . . . . . . . . . .

A Brief History . . . . . . . . . . . . . . . . . .

The Network File System as a File System . . . . . . .

Stateless Network Protocol . . . . . . . . . . . . .

Overview of the TULAB Scenario . . . . . . . . . . .

. . . . . . .	1
. . . . . . .	1
. . . . . . .	3
. . . . . . .	3
. . . . . . .	4
. . . . . . .	4

Chapter 2. The Network File System Client/Server Model. . . . . . . .	7
Network File System Client/Server Communication Design . . . . . . . .	7
Network File System Process Layout . . . . . . . . . . . . . . .	8
Network File System Stack Description . . . . . . . . . . . . . .	8
AS/400 as a Network File System Server . . . . . . . . . . . . . . .	9
Network File System Server-Side Daemons . . . . . . . . . . . . .	9
AS/400 as a Network File System Client . . . . . . . . . . . . . . .	11
Network File System Client-Side Daemons . . . . . . . . . . . . .	12
NFS Client-Side Caches . . . . . . . . . . . . . . . . . . . .	12
Chapter 3. NFS and the User-De®ned File System (UDFS) . . . . . . .	15
User File System Management . . . . . . . . . . . . . . . . . .	15
Create a User-De®ned File System. . . . . . . . . . . . . . . .	15
Display a User-De®ned File System. . . . . . . . . . . . . . . .	17
Delete a User-De®ned File System . . . . . . . . . . . . . . . .	18
Mount a User-De®ned File System . . . . . . . . . . . . . . . .	19
Unmount a User-De®ned File System . . . . . . . . . . . . . . .	20
Saving and Restoring a User-De®ned File System . . . . . . . . . .	21
Graphical User Interface . . . . . . . . . . . . . . . . . . . .	21
User-De®ned File System Functions in the Network File System . . . . . . 22
Using User-De®ned File Systems with Auxiliary Storage Pools. . . . . .	23
Chapter 4. Server Exporting of File Systems . . . . . . . . . . . .	25
What is Exporting? . . . . . . . . . . . . . . . . . . . . . . .	25
Why Should I Export? . . . . . . . . . . . . . . . . . . . . . .	26
TULAB Scenario . . . . . . . . . . . . . . . . . . . . . . .	26
What File Systems Can I Export?. . . . . . . . . . . . . . . . . .	27
How Do I Export File Systems? . . . . . . . . . . . . . . . . . .	28
Rules for Exporting File Systems . . . . . . . . . . . . . . . . .	28
CHGNFSEXP (Change Network File System Export) Command . . . . .	30
Exporting from Operations Navigator . . . . . . . . . . . . . . .	33
Finding out what is exported . . . . . . . . . . . . . . . . . .	36
Exporting Considerations . . . . . . . . . . . . . . . . . . . .	38

iii

Chapter 5. Client Mounting of File Systems . . . . . . . . . . . . .	39
What Is Mounting? . . . . . . . . . . . . . . . . . . . . . . .	39
Why Should I Mount File Systems? . . . . . . . . . . . . . . . . .	41
What File Systems Can I Mount? . . . . . . . . . . . . . . . . . .	42
Where Can I Mount File Systems? . . . . . . . . . . . . . . . . .	42
Mount Points . . . . . . . . . . . . . . . . . . . . . . . .	45
How Do I Mount File Systems? . . . . . . . . . . . . . . . . . .	45
ADDMFS (Add Mounted File System) Command . . . . . . . . . . .	45
RMVMFS (Remove Mounted File System) Command . . . . . . . . .	48
DSPMFSINF (Display Mounted File System Information) Command . . . . 50

Chapter 6. Using the Network File System with AS/400 File Systems . . . 55

²Root² File System (/) . . . . . . . . . . . . . . . . . . . . . .	55
Network File System Differences . . . . . . . . . . . . . . . . .	56
Open Systems File System (QOpenSys) . . . . . . . . . . . . . . .	56
Network File System Differences . . . . . . . . . . . . . . . . .	56
Library File System (QSYS.LIB) . . . . . . . . . . . . . . . . . .	57
Network File System Differences . . . . . . . . . . . . . . . . .	57
Document Library Services File System (QDLS) . . . . . . . . . . . .	60
Network File System Differences . . . . . . . . . . . . . . . . .	60
Optical File System (QOPT). . . . . . . . . . . . . . . . . . . .	61
Network File System Differences . . . . . . . . . . . . . . . . .	61
User-De®ned File System (UDFS) . . . . . . . . . . . . . . . . .	62
Network File System Differences . . . . . . . . . . . . . . . . .	63
Administrators of UNIX Clients . . . . . . . . . . . . . . . . . . .	63
Network File System Differences . . . . . . . . . . . . . . . . .	63
Chapter 7. NFS Startup, Shutdown, and Recovery . . . . . . . . . .	65
Con®guring TCP/IP. . . . . . . . . . . . . . . . . . . . . . . 65
Implications of Improper Startup and Shutdown . . . . . . . . . . . .	66
Proper Startup Scenario . . . . . . . . . . . . . . . . . . . . .	66
STRNFSSVR (Start Network File System Server) Command. . . . . . .	67
Proper Shutdown Scenario . . . . . . . . . . . . . . . . . . . .	70
Shutdown Consideration . . . . . . . . . . . . . . . . . . . .	70
ENDNFSSVR (End Network File System Server) Command . . . . . . .	70
Starting or stopping NFS from Operations Navigator . . . . . . . . . . .	72
Locks and Recovery . . . . . . . . . . . . . . . . . . . . . .	74
Why Should I Lock a File? . . . . . . . . . . . . . . . . . . .	74
How Do I Lock A File? . . . . . . . . . . . . . . . . . . . . .	74
Stateless System Versus Stateful Operation . . . . . . . . . . . . .	74
RLSIFSLCK (Release Integrated File System Locks) Command . . . . .	75
Chapter 8. Integrated File System APIs and the Network File System . . . 77
Error Conditions . . . . . . . . . . . . . . . . . . . . . . . .	77
ESTALE Error Condition . . . . . . . . . . . . . . . . . . . .	77
EACCES Error Condition . . . . . . . . . . . . . . . . . . . .	77
API Considerations . . . . . . . . . . . . . . . . . . . . . . .	77
User Datagram Protocol (UDP) Considerations. . . . . . . . . . . .	77
Client Timeout Solution . . . . . . . . . . . . . . . . . . . .	78
Network File System Differences . . . . . . . . . . . . . . . . . .	78
open(), create(), and mkdir() APIs . . . . . . . . . . . . . . . .	79
fcntl() API . . . . . . . . . . . . . . . . . . . . . . . . .	79
Unchanged APIs . . . . . . . . . . . . . . . . . . . . . . . .	79
Chapter 9. Network File System Security Considerations. . . . . . . .	81
The Trusted Community . . . . . . . . . . . . . . . . . . . . .	81

iv OS/400 Network File System Support V4R4

Network Data Encryption . . . . . . . . . . . . . . . . . . . .	82
User Authorities . . . . . . . . . . . . . . . . . . . . . . . .	83
User Identi®cations (UIDs) . . . . . . . . . . . . . . . . . . .	83
Group Identi®cations (GIDs). . . . . . . . . . . . . . . . . . .	83
Mapping User Identi®cations . . . . . . . . . . . . . . . . . .	84
Proper UID Mapping . . . . . . . . . . . . . . . . . . . . .	86
Securely Exporting File Systems . . . . . . . . . . . . . . . . . .	87
Export Options . . . . . . . . . . . . . . . . . . . . . . .	88
Appendix A. Summary of Common Commands . . . . . . . . . . .	91
Appendix B. Understanding the /etc Files . . . . . . . . . . . . . .	93
Editing ®les within the /etc directory. . . . . . . . . . . . . . . . .	93

Editing stream ®les by using the Edit File (EDTF) command. . . . . . . 93

Editing stream ®les by using a PC based editor . . . . . . . . . . .	94
Editing stream ®les by using a UNIX editor via NFS. . . . . . . . . .	94
/etc/exports File . . . . . . . . . . . . . . . . . . . . . . . .	94
Formatting Entries in the /etc/exports File . . . . . . . . . . . . . .	94
Examples of Formatting /etc/exports with HOSTOPT Parameter . . . . .	96

/etc/netgroup File. . . . . . . . . . . . . . . . . . . . . . . . 96 /etc/rpcbtab File . . . . . . . . . . . . . . . . . . . . . . . . 97 /etc/statd File . . . . . . . . . . . . . . . . . . . . . . . . . 97

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Programming Interface Information . . . . . . . . . . . . . . . . . 101 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 103

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Readers' Comments Ð We'd Like to Hear from You. . . . . . . . . . 113

Contents v

vi OS/400 Network File System Support V4R4

Figures

1.	AS/400 Operations Navigator Display . . . . . . . . . . . . . .	xii
2.	The local client and its view of the remote server before exporting data . .	1
3.	The local client and its view of the remote server after exporting data . .	2
4.	The local client mounts data from a remote server . . . . . . . . .	2
5.	Remote ®le systems function on the client. . . . . . . . . . . . .	2
6.	The TULAB network namespace . . . . . . . . . . . . . . . .	5
7.	The NFS Client/Server Model . . . . . . . . . . . . . . . . .	7
8.	A breakdown of the NFS client/server protocol . . . . . . . . . . .	8
9.	The NFS Server . . . . . . . . . . . . . . . . . . . . . .	10
10.	The NFS Client . . . . . . . . . . . . . . . . . . . . . .	12

11.Using the Create User-De®ned FS (CRTUDFS) display. . . . . . . . 16

12.Display User-De®ned FS (DSPUDFS) output (1/2). . . . . . . . . . 17

13.Display User-De®ned FS (DSPUDFS) output (2/2). . . . . . . . . . 18

14.Using the Delete User-De®ned FS (DLTUDFS) display. . . . . . . . 19

15.A Windows 95 view of using the CRTUDFS (Create UDFS) command . . 21

16.A Windows 95 view of using the DSPUDFS (Display UDFS) command . . 22

17.Exporting ®le systems with the /etc/exports ®le. . . . . . . . . . . 25

18.Dynamically exporting ®le systems with the²-I² option . . . . . . . . 26

19.	Before the server has exported information . . . . . . . . . . . .	27
20.	After the server has exported /classes/class2 . . . . . . . . . . .	28
21.	A directory tree before exporting on TULAB2. . . . . . . . . . . .	29
22.	The exported directory branch /classes on TULAB2 . . . . . . . . .	29
23.	The exported directory branch /classes/class1 on TULAB2 . . . . . .	29
24.	Using the Change NFS Export (CHGNFSEXP) display . . . . . . . .	31
25.	The Operations Navigator interface. . . . . . . . . . . . . . . .	34
26.	The NFS Export dialog box. . . . . . . . . . . . . . . . . . .	34
27.	The Add Host/Netgroup dialog box. . . . . . . . . . . . . . . .	35
28.	The Customize NFS Clients Access dialog box.. . . . . . . . . . .	36
29.	The NFS Exports dialog box. . . . . . . . . . . . . . . . . .	37

30.A local client and remote server with exported ®le systems . . . . . . 39

31.A local client mounting ®le systems from a remote server. . . . . . . 40

32.The mounted ®le systems cover local client directories. . . . . . . . 40

33.The local client mounts over a high-level directory. . . . . . . . . . 41

34.The local client mounts over the /2 directory . . . . . . . . . . . . 41

35.	Views of the local client and remote server . . . . . . . . . . . .	43
36.	The client mounts /classes/class1 from TULAB2 . . . . . . . . . .	43
37.	The /classes/class1 directory covers /user/work. . . . . . . . . . .	43
38.	The remote server exports /engdata . . . . . . . . . . . . . . .	44
39.	The local client mounts /engdata over a mount point . . . . . . . . .	44
40.	The /engdata directory covers /user/work . . . . . . . . . . . . .	44
41.	Using the Add Mounted FS (ADDMFS) display . . . . . . . . . . .	46

42.A Windows 95 view of Mounting a user-de®ned ®le system. . . . . . 47

43.Using the Remove Mounted FS (RMVMFS) display . . . . . . . . . 49

44.Using the Display Mounted FS Information (DSPMFSINF) display . . . . 51

45.Display Mounted FS Information (DSPMFSINF) output (1/2) . . . . . . 52

46.Display Mounted FS Information (DSPMFSINF) output (2/2) . . . . . . 52

47.The ²Root² (/) ®le system accessed through the NFS Server. . . . . . 55

48.The QOpenSys ®le system accessed through the NFS Server . . . . . 56

49.The QSYS.LIB ®le system accessed through the NFS Server . . . . . 57

50.The QDLS ®le system accessed through the NFS Server. . . . . . . 60

51.The QOPT ®le system accessed through the NFS Server. . . . . . . 61

52.The UDFS ®le system accessed through the NFS Server. . . . . . . 62

53.Using the Start NFS Server (STRNFSSVR) display . . . . . . . . . 69

vii

54.	Using the End NFS Server (ENDNFSSVR) display . . . . . . . . .	71
55.	Starting or stopping NFS server daemons. . . . . . . . . . . . .	73
56.	NFS Properties dialog box. . . . . . . . . . . . . . . . . . .	73

57.Using the Release File System Locks (RLSIFSLCK) display . . . . . . 76

58.Client outside the trusted community causing a security breaches . . . . 82

viii OS/400 Network File System Support V4R4

Tables

1. CL Commands Used in Network File System Applications . . . . . . . 91

x OS/400 Network File System Support V4R4

About OS/400 Network File System Support (SC41-5714)

The purpose of this book is to explain what the Network File System is, what it does, and how it works on AS/400. The book shows real-world examples of how you can use NFS to create a secure, useful integrated ®le system network. The intended audiences for this book are:

vSystem administrators developing a distributed network using the Network File System.

vUsers or programmers working with the Network File System

Chapters one and two introduce NFS by giving background and conceptual information on its protocol, components, and architecture. This is background information for users who understand how AS/400 works, but do not understand NFS.

The rest of the book (chapters three through nine) shows detailed examples of what NFS can do and how you can best use it. The overall discussion topic of this book is how to construct a secure, user-friendly distributed namespace. Included are in-depth examples and information regarding mounting, exporting, and the following topics:

vHow NFS functions in the client/server relationship

vNFS exceptions for AS/400 ®le systems

vNFS startup, shutdown, and recovery

vFile locking

vNew integrated ®le system error conditions and how NFS affects them

vTroubleshooting procedures for NFS security considerations

It is assumed that the reader has experience with AS/400 client/server model, though not necessarily with the Network File System.

Who should read this book

This book is for AS/400 users, programmers, and administrators who want to know about the Network File System on AS/400. This book contains:

vBackground theory and concepts regarding NFS and how it functions

vExamples of commands, AS/400 displays, and other operations you can use with NFS

vTechniques on how to construct a secure, efficient namespace with NFS

AS/400 Operations Navigator

AS/400 Operations Navigator is a powerful graphical interface for Windows clients. With AS/400 Operations Navigator, you can manage and administer your AS/400 systems from your Windows desktop.

You can use Operations Navigator to manage communications, printing, database, security, and other system operations. Operations Navigator includes Management Central for managing multiple AS/400 systems centrally.

Figure 1 on page xii shows an example of the Operations Navigator display:

Figure 1. AS/400 Operations Navigator Display

This new interface has been designed to make you more productive and is the only user interface to new, advanced features of OS/400. Therefore, IBM recommends that you use AS/400 Operations Navigator, which has online help to guide you. While this interface is being developed, you may still need to use a traditional emulator such as PC5250 to do some of your tasks.

Installing Operations Navigator

To use AS/400 Operations Navigator, you must have Client Access installed on your Windows PC. For help in connecting your Windows PC to your AS/400 system, consult Client Access Express for Windows - Setup, SC41-5507-00.

AS/400 Operations Navigator is a separately installable component of Client Access that contains many subcomponents. If you are installing for the ®rst time and you use the Typical installation option, the following options are installed by default:

vOperations Navigator base support

vBasic operations (messages, printer output, and printers)

To select the subcomponents that you want to install, select the Custom installation option. (After Operations Navigator has been installed, you can add subcomponents by using Client Access Selective Setup.)

1.Display the list of currently installed subcomponents in the Component Selection window of Custom installation or Selective Setup.

2.Select AS/400 Operations Navigator.

3.Select any additional subcomponents that you want to install and continue with Custom installation or Selective Setup.

After you install Client Access, double-click the AS400 Operations Navigator icon on your desktop to access Operations Navigator and create an AS/400 connection.

Prerequisite and related information

Use the AS/400 Information Center as your starting point for looking up AS/400 technical information. You can access the Information Center from the AS/400e Information Center CD-ROM (English version: SK3T-2027) or from one of these Web sites:

xii OS/400 Network File System Support V4R4

http://www.as400.ibm.com/infocenter

http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm

The AS/400 Information Center contains important topics such as logical partitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also contains Internet links to Web sites such as the AS/400 Online Library and the AS/400 Technical Studio. Included in the Information Center is a link that describes at a high level the differences in information between the Information Center and the Online Library.

For a list of related publications, see the ªBibliographyº on page 103.

How to send your comments

Your feedback is important in helping to provide the most accurate and high-quality information. If you have any comments about this book or any other AS/400 documentation, ®ll out the readers' comment form at the back of this book.

vIf you prefer to send comments by mail, use the readers' comment form with the address that is printed on the back. If you are mailing a readers' comment form from a country other than the United States, you can give the form to the local IBM branch office or IBM representative for postage-paid mailing.

vIf you prefer to send comments by FAX, use either of the following numbers:

±United States and Canada: 1-800-937-3430

±Other countries: 1-507-253-5192

vIf you prefer to send comments electronically, use one of these e-mail addresses:

±Comments on books:

RCHCLERK@us.ibm.com

IBMMAIL, to IBMMAIL(USIB56RZ)

± Comments on the AS/400 Information Center:

RCHINFOC@us.ibm.com

Be sure to include the following:

vThe name of the book.

vThe publication number of the book.

vThe page number or topic to which your comment applies.

About OS/400 Network File System Support (SC41-5714) xiii

xiv OS/400 Network File System Support V4R4

Summary of Changes

This manual includes changes made since Version 4 Release 1 of the OS/400 licensed program on the AS/400 system. This edition includes information that has been added to the system to support Version 4 Release 4.

Changes made to this book include the following items:

vUpdated graphic ®les.

vUpdated examples.

vUpdated NFS to FSS/400 comparisons.

vAdded information about short and long names.

vAdded a new section about editing ®les within the /etc directory.

xvi OS/400 Network File System Support V4R4

Chapter 1. What is the Network File System?

Introduction

OS/400 Network File System Support introduces a system function for AS/400 that aids users and administrators who work with network applications and ®le systems. You can use the Network File System (NFS**) to construct a distributed network system where all users can access the data they need. Furthermore, the Network File System provides a method of transmitting data in a client/server relationship.

The Network File System makes remote objects stored in ®le systems appear to be local, as if they reside in the local host. With NFS, all the systems in a network can share a single set of ®les. This eliminates the need for duplicate ®le copies on every network system. Using NFS aids in the overall administration and management of users, systems, and data.

NFS gives users and administrators the ability to distribute data across a network by:

vExporting local ®le systems from a local server for access by remote clients. This allows centralized administration of ®le system information. Instead of duplicating common directories on every system, NFS shares a single copy of a directory with all the proper clients from a single server.

vMounting remote server ®le systems over local client directories. This allows AS/400 client systems to work with ®le systems that have been exported from a remote server. The mounted ®le systems will act and perform as if they exist on the local system.

The following ®gures show the process of a remote NFS server exporting directories to a local client. Once the client is aware of the exported directories, the client then mounts the directories over local directories. The remote server directories will now function locally on the client.

Figure 2. The local client and its view of the remote server before exporting data

Before the server exports information, the client does not know about the existence of ®le systems on the server. Furthermore, the client does not know about any of the ®le systems or objects on the server.

Figure 3. The local client and its view of the remote server after exporting data

After the server exports information, the proper client (the client with the proper authorities) can be aware of the existence of ®le systems on the server. Furthermore, the client can mount the exported ®le systems or directories or objects from the server.

Figure 4. The local client mounts data from a remote server

The mount command makes a certain ®le system, directory, or objectaccessible on the client. Mounting does not copy or move objects from the server to the client. Rather, it makes remote objects available for use locally.

Figure 5. Remote ®le systems function on the client

When remote objects are mounted locally, they cover up any local objects that they are placed over. Mounted objects also cover any objects that are downstream of the mount point, the place on the client where the mount to the server begins. The mounted objects will function locally on the client just as they do remotely on the server.

For more information on these aspects of NFS, see the following sections:

vªChapter 4. Server Exporting of File Systemsº on page 25

vªChapter 5. Client Mounting of File Systemsº on page 39

2 OS/400 Network File System Support V4R4

\|	OS/400 Network File System Support is the replacement for the TCP/IP File Server
\|	Support/400 (FSS/400) system application. Users who are accustomed to working
\|	with FSS/400 will notice many similarities between FSS/400 and NFS. It is
\|	important to note, however, that FSS/400 and NFS are not compatible with each
\|	other. The FSS/400 system application can exist on the same AS/400 with OS/400
\|	Network File System Support, but they cannot operate together. On any given
\|	system, do not start or use FSS/400 and NFS at the same time.

A Brief History

	Sun Microsystems, Inc.** released NFS in 1984. Sun introduced NFS Version 2 in
	1985. In 1989, the Request For Comments (RFC) standard 1094, describing NFS
	Version 2, was published. X/Open published a compatible version that is a standard
	for NFS in 1992. Sun published the NFS Version 3 protocol in 1993.
	Sun developed NFS in a UNIX** environment, and therefore many UNIX concepts
	(for example, the UNIX authentication) were integrated into the ®nal protocol. Yet
	the NFS protocol remains platform independent. Today, almost all UNIX platforms
	use NFS, as do many PCs, mainframes, and workstations.
\|	Most implementations of NFS are Version 2, although a number of vendors are
\|	offering products that combine Version 2 and Version 3. The AS/400 implementation
\|	of the Network File System supports both Version 2 and Version 3 of the protocol.

	The Network File System as a File System

AS/400 ®le systems provide the support that allows users and applications to access speci®c segments of storage. These logical units of¢ storage are the following:

vlibraries

vdirectories

vfolders

The logical storage units can contain different types of data:

vobjects

v®les

vdocuments

Each ®le system has a set of logical structures and rules for interacting with information in storage. These structures and rules may be different from one ®le system to another, depending on the type of ®le system. The OS/400 support for accessing database ®les and various other object types through libraries can be thought of as a ®le system. Similarly, the OS/400 support for accessing documents through folders can be thought of as a separate ®le system. For more information on AS/400 ®le systems, please see theIntegrated File System Introduction,

SC41-4711.

The Network File System provides seemingly ªtransparentº access to remote ®les. This means that local client ®les and ®les that are accessed from a remote server operate and function similarly and are indistinguishable. This takes away many complex steps from users, who need a set of ®les and directories that act in a consistent manner across many network clients. A long-term goal of system administrators is to design such a transparent network that solidi®es the belief of

Chapter 1. What is the Network File System? 3

users that all data exists and is processed on their local workstations. An efficient NFS network also gives the right people access to the right amount of data at the right times.

Files and directories can be made available to clients by exporting from the server and mounting on clients through a pervasive NFS client/server relationship. An NFS client can also, at the same time, function as an NFS server, just as an NFS server can function as a client.

Stateless Network Protocol

NFS incorporates the Remote Procedure Call (RPC) for client/server communication. RPC is a high-end network protocol that encompasses many simpler protocols, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

NFS is a stateless protocol, maintaining absolutely no saved or archived information from client/server communications. State is the information regarding a request that describes exactly what the request does. A stateful protocol saves information about users and requests for use with many procedures. Statelessness is a condition where no information is retained about users and their requests. This condition demands that the information surrounding a request be sent with every single request. Due to NFS statelessness, each RPC request contains all the required information for the client and server to process user requests.

By using NFS, AS/400 users can bypass the details of the network interface. NFS isolates applications from the physical and logical elements of data communications and allows applications to use a variety of different transports.

In short, the NFS protocol is useful for applications that need to transfer information over a client/server network. For more information about RPC and NFS, see ªNetwork File System Stack Descriptionº on page 8.

Overview of the TULAB Scenario

This book uses the ®ctional namespaceTULAB to describe detailed applications of NFS concepts. A namespace is a distributed network space where one or more servers look up, manage, and share ordered, deliberate object names.

TULAB exists only in a hypothetical computer-networked environment at a ®ctitious Technological University. It is run by a network administrator, a person who de®nes the network con®guration and other network-related information. This person controls how an enterprise or system uses its network resources. The TULAB administrator, Chris Admin, is trying to construct an efficient, transparent, and otherwise seamless distributed namespace for the diverse people who use the TULAB:

vEngineering undergraduate students

vHumanities undergraduate students

vEngineering graduate students

vTULAB consultants

4 OS/400 Network File System Support V4R4

Each group of users works on sets of clients that need different ®le systems from the TULAB server. Each group of users has different permissions and authorities and will pose a challenge to establishing a safe, secure NFS namespace.

Chris Admin will encounter common problems that administrators of NFS namespaces face every day. Chris Admin will also work through some uncommon and unique NFS situations. As this book describes each command and parameter, Chris Admin will give a corresponding example from TULAB. As this book explains applications of NFS, Chris Admin will show exactly how he con®gures NFS for TULAB.

The network namespace of TULAB is complex and involves two NFS server systems:

1.TULAB1 Ð A UNIX server system

2.TULAB2 Ð An AS/400 server system

The following ®gure describes the layout of the TULAB namespace.

Figure 6. The TULAB network namespace

Chapter 1. What is the Network File System? 5

6 OS/400 Network File System Support V4R4

Chapter 2. The Network File System Client/Server Model

To understand how the Network File System works on AS/400, you must ®rst understand the communication relationship between a server and various clients. The client/server model involves a local host (the client) that makes a procedure call that is usually processed on a different, remote network system (the server). To the client, the procedure appears to be a local one, even though another system processes the request. In some cases, however, a single computer can act as both an NFS client and an NFS server.

Figure 7. The NFS Client/Server Model

There are various resources on the server which are not available on the client, hence the need for such a communication relationship. The host owning the needed resource acts as a server that communicates to the host which initiates the original call for the resource, the client. In the case of NFS, this resource is usually a shared ®le system, a directory, or an object.

RPC is the mechanism for establishing such a client/server relationship within NFS. RPC bundles up the arguments intended for a procedure call into a packet of data called a network datagram. The NFS client creates an RPC session with an NFS server by connecting to the proper server for the job and transmitting the datagram to that server. The arguments are then unpacked and decoded on the server. The operation is processed by the server and a return message (should one exist) is sent back to the client. On the client, this reply is transformed into a return value for NFS. The user's application is re-entered as if the process had taken place on a local level.

Network File System Client/Server Communication Design

The logical layout of the Network File System on the client and server involves numerous daemons, caches, and the NFS protocol breakdown. An overview of each type of process follows.

A daemon is a process that performs continuous or system-wide functions, such as network control. NFS uses many different types of daemons to complete user requests.

A cache is a type of high-speed buffer storage that contains frequently accessed instructions and data. Caches are used to reduce the access time for this information. Caching is the act of writing data to a cache.

For information about NFS server daemons, see ªNetwork File System Server-Side Daemonsº on page 9. For information about NFS client daemons, see ªNetwork File System Client-Side Daemonsº on page 12. For information about client-side caches, see ªNFS Client-Side Cachesº on page 12 Detailed information about the NFS protocol can be found in ªNetwork File System Stack Descriptionº.

Network File System Process Layout

Figure 8. A breakdown of the NFS client/server protocol

Local processes that are known as daemons are required on both the client and the server. These daemons process both local and remote requests and handle client/server communication. Both the NFS client and server have a set of daemons that carry out user tasks. In addition, the NFS client also has data caches that store speci®c types of data locally on the on the client. For more information about the NFS client data caches, see ªNFS Client-Side Cachesº on page 12.

Network File System Stack Description

Simple low-end protocols make up a high-end complex protocol like NFS. For an NFS client command to connect with the server, it must ®rst use the Remote Procedure Call (RPC) protocol. The request is encoded into External Data

8 OS/400 Network File System Support V4R4

Representation (XDR) and then sent to the server using a socket. The simple User Datagram Packet (UDP) protocol actually communicates between client and server. Some aspects of NFS use the Transmission Control Protocol (TCP) as the base communication protocol.

The operation of NFS can be seen as a logical client-to-server communications system that speci®cally supports network applications. The typical NFS ¯ow includes the following steps:

1.The server waits for requests from one or more clients.

2.The client sends a request to the server and blocks (waits for a response).

3.When a request arrives, the server calls a dispatch routine.

4.The dispatch routine performs the requested service and returns with the results of the request. The dispatch routine can also call a sub-routine to handle the speci®c request. Sometimes the sub-routine will return results to the client by itself, and other times it will report back to the dispatch routine.

5.The server sends those results back to the client.

6.The client then de-blocks.

The overhead of running more than one request at the same time is too heavy for an NFS server, so it is designed to be single-threaded. This means that an NFS server can only process one request per session. The requests from the multiple clients that use the NFS server are put into a queue and processed in the order in which they were received. To improve throughput, multiple NFS servers can process requests from the same queue.

AS/400 as a Network File System Server

The NFS server is composed of many separate entities that work together to process remote calls and local requests. These are:

vNFS server daemons. These daemons handle access requests for local ®les from remote clients. Multiple instances of particular daemons can operate simultaneously.

vExport command. This command allows a user to make local directories accessible to remote clients.

v/etc/exports ®le. This ®le contains the local directory names that the NFS server exports automatically when starting up. The administrator creates and maintains this ®le, which is read by the export command. For more discussion about this ®le, see ª/etc/exports Fileº on page 94 and ªChapter 4. Server Exporting of File Systemsº on page 25.

vExport table. This table contains all the ®le systems that are currently exported from the server. The export command builds the /etc/exports ®le into the export table. Users can dynamically update the export table with the export command.

For discussion regarding the CHGNFSEXP (Change Network File System

Export) and EXPORTFS (Export File System) commands and how they work with both the /etc/exports ®le, see ªChapter 4. Server Exporting of File Systemsº on page 25.

Network File System Server-Side Daemons

Chapter 2. The Network File System Client/Server Model 9







	Figure 9. The NFS Server
	NFS is similar to other RPC-based services in its use of server-side daemons to
	process incoming requests. NFS may also use multiple copies of some daemons to
	improve overall performance and efficiency.
	RPC Binder Daemon (RPCD)
\|	This daemon is analogous to the port mapper daemon, which many
\|	implementations of NFS use in UNIX. Clients determine the port of a speci®ed RPC
\|	service by using the RPC Binder Daemon. Local services register themselves with
\|	the local RPC binder daemon (port mapper) when initializing. On AS/400, you can
\|	register your own RPC programs with the RPC binder daemon.
	NFS Server Daemons (NFSD)
	The most pressing need for NFS server daemons centers around the need for
	multi-threading NFS RPC requests. Running daemons in user-level processes
	allows the server to have multiple, independent threads of processes. In this way,
	the server can handle several NFS requests at once. As a daemon completes the
	processing of a request, the daemon returns to the end of a line of daemons that
	wait for new requests. Using this schedule design, a server always has the ability to
	accept new requests if at least one server daemon is waiting in the queue. Multiple
	instances of this daemon can perform tasks simultaneously.
	Mount Daemon (MNTD)
	Each NFS server system runs a mount daemon which listens to requests from
	client systems. This daemon acts on mount and unmount requests from clients. If
	the mount daemon receives a client mount request, then the daemon checks the
	export table. The mount daemon compares it with the mount request to see if the
	client is allowed to perform the mount. If the mount is allowed, the mount daemon
	will send to the requesting client an opaque data structure, the ®le handle. This
	structure uniquely describes the mounting point that is requested by the client. This
	will enable the client to represent the root of the mounted ®le system when making
	future requests.

10 OS/400 Network File System Support V4R4

Network Status Monitor Daemon (NSMD)

The Network Status Monitor (NSM) is a stateful NFS service that provides applications with information about the status of network hosts. The Network Lock Manager (NLM) daemon heavily uses the NSM to track hosts that have established locks as well as hosts that maintain such locks.

There is a single NSM server per host. It keeps track of the state of clients and noti®es any interested party when this state changes (usually after recovery from a crash).

The NSM daemon keeps a notify list that contains information on hosts to be informed after a state change. After a local change of state, the NSM noti®es each host in the notify list of the new state of the local NSM. When the NSM receives a state change noti®cation from another host, it will notify the local network lock manager daemon of the state change.

Network Lock Manager Daemon (NLMD)

The Network Lock Manager (NLM) daemon is a stateful service that provides advisory byte-range locking for NFS ®les. The NLM maintains state across requests, and makes use of the Network Status Monitor daemon (NSM) which maintains state across crashes (using stable storage).

The NLM supports two types of byte-range locks:

1.Monitored locks. These are reliable and helpful in the event of system failure. When an NLM server crashes and recovers, all the locks it had maintained will be reinstated without client intervention. Likewise, NLM servers will release all old locks when a client crashes and recovers. A Network Status Manager (NSM) must be functioning on both the client and the server to create monitored locks.

2.Unmonitored locks. These locks require explicit action to be released after a crash and re-established after startup. This is an alternative to monitoring locks, which requires the NSM on both the client and the server systems.

	AS/400 as a Network File System Client
	Several entities work together to communicate with the server and local jobs on the
	NFS client. These processes are the following:
\|	v RPC Binder Daemon. This daemon communicates with the local and remote
\|	daemons by using the RPC protocol. Clients look for NFS services through this
\|	daemon.
	v Network Status Monitor and Network Lock Manager. These two daemons are
	not mandatory on the client. Many client applications, however, establish
	byte-range locks on parts of remote ®les on behalf of the client without notifying
	the user. For this reason, it is recommended that the NSM and NLM daemons
	exist on both the NFS client and server.
\|	v Block I/O daemon. This daemon manages the data caches and is therefore
\|	stateful in operation. It performs caching, and assists in routing client-side NFS
\|	requests to the remote NFS server. Multiple instances of this daemon can
\|	perform tasks simultaneously.
	v Data and attribute caches. These two caches enhance NFS performance by
	storing information on the client-side to prevent a client/server interaction. The
	attribute cache stores ®le and directory attribute information locally on the client,
	while the data cache stores frequently used data on the client.

Chapter 2. The Network File System Client/Server Model 11

vMount and Unmount commands. Users can mount and unmount a ®le system in the client namespace with these commands. These are general tools, used not only in NFS, but also to dynamically mount and unmount other local ®le systems. For more information about the ADDMFS (Add Mounted File System) and RMVMFS (Remove Mounted File System) commands, see ªChapter 5. Client Mounting of File Systemsº on page 39.

Network File System Client-Side Daemons

	Figure 10. The NFS Client
	Besides the RPC Daemon, the NFS client has only one daemon to process
	requests and to transfer data from and to the remote server, the block I/O daemon.
	NFS differs from typical client/server models in that processes on NFS clients make
	some RPC calls themselves, independently of the client block I/O daemon. An NFS
	client can optionally use both a Network Lock Manager (NLM) and a Network
	Status Monitor (NSM) locally, but these daemons are not required for standard
	operation. It is recommended that you use both the NLM and NSM on your client
	because user applications often establish byte-range locks without the knowledge of
	the user.
	Block I/O Daemon (BIOD)
\|	The block I/O daemon handles requests from the client for remote ®les or
\|	operations on the server. The block I/O daemon may handle data requests from the
\|	client to remote ®les on the server. Running only on NFS clients or servers that are
\|	also clients, this daemon manages the data caches for the user. The block I/O
\|	daemon is stateful and routes client application requests either to the caches or on
\|	to the NFS server. The user can specify the regular intervals for updating all data
\|	that is cached by the block I/O daemon. Users can start multiple daemons to
\|	perform different operations simultaneously.
	NFS Client-Side Caches
	Caching ®le data or attributes gives administrators a way of tuning NFS
	performance. The caching of information allows you to delay writes or to read
	ahead.

12 OS/400 Network File System Support V4R4

+ 105 hidden pages