----- ...
`
`Brent Callaghan
`
`)>
`0
`0
`Cf)
`
`0 z I
`~ m
`CJ)
`r(cid:173)
`m -< -
`
`-0
`7;:J
`0
`-r,
`m
`V'l
`V'l
`
`0 z
`)>
`r-
`n
`0
`~
`-0
`C
`
`-I -z
`
`C')
`V'l
`m
`7;:J
`m
`V'l
`
`Microsoft Ex. 1007, p. 1
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`Many of the designations used by manufacturers and sellers to distinguish their prod(cid:173)
`ucts are claimed as trademarks. Where those designations appear in this book and
`Addison-Wesley-was aware of a trademark claim, the designations have been printed in
`initial caps or all caps.
`
`The author and publisher have taken care in the preparation of this book but make no
`expressed or implied warranty of any kind and assume no responsibility for errors or
`omissions. No liability is assumed for incidental or consequential damages in connec(cid:173)
`tion with or arising out of the use of the information or programs contained herein.
`
`The publisher offers discounts on this book when ordered in quantity for special sales.
`For more information, please conta~t:
`
`Corporate, Government, and Special Sales
`Addison Wesley Longman, Inc.
`One Jacob Way
`Reading, Massachusetts 01867
`
`Library of Congress Cataloging-in-Publication Data
`
`Callaghan, Brent
`NFS illustrated / Brent Callaghan
`p. cm. -
`(Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-32570-5
`1. Network File System (Computer network protocol)
`
`I. Title.
`
`II. Series
`
`TK5105.574 .C35 2000
`004.6'2--dc21
`
`99-056696
`
`Copyright© 2000 by Addison Wesley Longman, Inc.
`
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval
`system, or transmitted, in any form, or by any means, electronic, mechanical, photo(cid:173)
`copying, recording, or otherwise, without the prior consent of the publisher. Printed in
`the United States of America. Published simultaneously in Canada.
`
`ISBN 0-201-32570-5
`
`Text printed on recycled and acid-free paper.
`
`Microsoft Ex. 1007, p. 2
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`Contents
`
`Preface
`
`1
`
`Introduction
`1.1 File Access and File Transfer
`1.2 Early File Access Protocols
`1.3 ONCRPC
`1.4 Organization of This Book
`
`2 XOR-External Data Representation
`2.1
`Protocols and Transportable Data
`2.2 A Canonical Standard
`2.3 XDR Unit
`2.4
`Primitive XDR Data Types
`2.4.1
`Integer
`2.4.2 Unsigned Integer
`2.4.3 Boolean
`2.4.4 Hyper Integer and Unsigned Hyper Integer
`2.4.5 Fixed-Length Opaque Data
`2.4.6 Variable-Length Opaque Data
`2.4.7 String
`Structured XDR Data Types
`2.5.1 Fixed-Length Array
`2.5.2 Variable-Length Array
`2.5.3 Discriminated Union
`2.5.4 Linked Lists
`2.6 XDR Language
`2.6.1 Notational Conventions
`2.6.2 Lexical Notes
`2.6.3 Syntax Information
`2.6.4 Syntax Notes
`
`2.5
`
`xvii
`
`1
`2
`4
`6
`6
`
`9
`9
`11
`12
`13
`13
`14
`14
`15
`15
`15
`15
`16
`16
`16
`17
`17
`17
`18
`18
`19
`20
`
`vii
`
`Microsoft Ex. 1007, p. 3
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`xiv
`
`Contents
`
`13.2.4 Read-only Replication
`13.2.5 Security
`13.2.6 Summary
`13.3 DCE/DFS
`13.3.1 Cache Consistency with Tokens
`13.3.2 DFS Narnespace
`13.3.3 Episode File System
`13.3.4 Summary
`13.4 SMB File Access
`13.4.1 Namespace
`13.4.2 Session Setup
`13.4.3 PC File Semantics
`13.4.4 Batched Requests
`13.4.5 File Locking
`13.4.6 Opportunistic Locks
`13.4.7 The Samba Server
`13.4.8 Summary
`
`14 PC NFS
`14.1 File Naming
`14.2 File Attributes
`14.3 Text Files
`14.4 Symbolic Links
`14.5 PCNFSD Protocol
`14.5.1 Printing
`14.5.2 Comment Strings
`14.5.3 Transport and Authentication
`14.6 PCNFSD Version 1
`14.6.1 Procedure 1: PCNFSD_AUTH-Perform User
`Authentication
`14.6.2 Procedure 2: PCNFSD_PR_INIT-Prepare
`for Remote Printing
`14.6.3 Procedure 3: PCNFSD_PR_START-Submit
`Print Job
`14.7 PCNFSD Version 2
`14.7.1 Procedure 1: PCNFSD2_INFO-Determine
`Supported Services
`14.7.2 Procedure 2: PCNFSD2_PR_INIT-Prepare
`for Remote Printing
`14.7.3 Procedure 3: PCNFSD2_PR_START- SubmitJob
`f<?r Printing
`14.7.4 Procedure 4: PCNFSD2_PR_LIST-List Printers
`on Server
`14.7.5 Procedure 5: PCNFSD2_PR_QUEUE-List Printer
`Jobs Queued
`14.7.6 Procedure 6: PCNFSD2_PR_STATUS-Determine
`Printer Status
`14.7.7 Procedure 7: PCNFSD2_PR_CANCEL-Cancel
`a Print Job
`
`368
`368
`368
`369
`369
`370
`371
`371
`372
`372
`373
`373
`374
`374
`374
`376
`376
`
`379
`379
`381
`382
`382
`384
`385
`387
`387
`387
`
`388
`
`389
`
`390
`391
`
`391
`
`393
`
`394
`
`395
`
`396
`
`398
`
`399
`
`Microsoft Ex. 1007, p. 4
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`Contents
`
`xv
`
`14.7.9
`
`14.7.8 Procedure 8: PCNFSD2_PR_ADMIN-Printer
`Administration
`Procedure 9: PCNFSD2_PR_REQUEUE-Change
`Print Job Queue Position
`14.7.10 Procedure 10: PCNFSD2_PR_HOLD-Hold a Print
`Job in the Queue
`14.7.11 Procedure 11: PCNFSD2_PR_RELEASE-Release
`Hold on a Print Job
`14.7.12 Procedure 12: PCNFSD2_MAPID- Translate
`Between Username and ID
`14.7.13 Procedure 13: PCNFSD2_AUTH-Perform User
`Authentication
`14.7.14 Procedure 14: PCNFSD2_ALERT-Send Message
`to Server Administrator
`14.8 BWNFSD /HCLNFSD Protocol
`14.9 Summary
`
`15 NFS Benchmarks
`15.1 Factors Affecting Performance
`15.1.1 Memory
`15.1.2 CPU
`15.1.3 Network
`15.1.4 Network Interfaces
`15.1.5 Server Data Bus
`15.1.6 NVRAM
`15.1.7 Disk Controllers
`15.1.8 Disk Spindles
`15.2 Workload
`15.2.1 Operation Mix
`15.2.2 Working Set
`15.2.3 File and Directory Size
`15.3 Nfsstone
`15.4 Nhfsstone
`15.5 SFS 1.0 and 1.1
`15.5.1 Running the SFS Benchmark
`15.5.2 Workload
`15.5.3 Server Configuration
`15.5.4 Cluster Challenge
`15.6 SFS 2.0
`15.7 Summary
`
`16 WebN FS
`16.1
`Internet and NFS over TCP
`16.2
`Internet and NFS Version 3
`16.3 Firewalls
`16.4 Public Filehandle
`16.5 Multicomponent LOOKUP
`
`400
`
`401
`
`403
`
`404
`
`405
`
`407
`
`408
`409
`410
`
`413
`414
`414
`414
`415
`416
`417
`417
`417
`417
`418
`418
`419
`419
`419
`421
`422
`423
`424
`426
`426
`428
`430
`
`431
`431
`432
`433
`433
`434
`
`Microsoft Ex. 1007, p. 5
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`xvi
`
`Contents
`
`16.5.1 Pathname Evaluation and Latency
`16.5.2 Initialization Overhead
`16.5.3 Pathname Evaluation
`16.5.4 Server Evaluation of Pathname
`16.5.5 Symbolic Links
`16.6 NFS URL
`16.6.1 URL Structure
`16.6.2 Absolute vs. Relative Paths
`16.7 WebNFS Client Characteristics
`16.7.1 Mountpoint Crossing
`16.7.2 Fetching a File
`16.7.3 Fetching a Directory
`16.7.4 Fetching a Symbolic Link
`16.7.5 Document Types
`16.8 WebNFS Server Requirements
`16.8.1 Evaluating a Multicomponent LOOKUP
`16.8.2 Canonical vs. Native Path
`16.8.3 Client and Server Port
`16.9 WebNFS Security Negotiation
`16.10 Summary
`
`17 NFS Version 4
`17.1 An IETF Protocol
`17.2 NFS Version 4 Working Group Charter
`17.3
`Improved Access and Good Performance
`on the Internet
`17.3.1 Protocol Integration
`17.3.2 Latency
`17.3.3 Bandwidth
`17.3.4 Efficient Caching
`17.3.S Proxy Caching
`17.3.6 Scalability
`17.3.7 Availability
`17.4 Strong Security with Negotiation Built into the
`Protocol
`17.4.1 Connection-Based Security
`17.4.2 RPC-Based Security
`17.5 Better Cross-Platform Interoperability
`17.5.1 File Attributes
`17.5.2 Representing User and Group IDs
`17.5.3 Access Control Lists
`17.5.4 File Locking
`17.5.S Internationalization
`17.6 Designed for Protocol Extensions
`17.7 Summary
`
`References
`
`Index
`
`434
`435
`435
`436
`436
`438
`438
`438
`439
`441
`441
`442
`442
`442
`442
`442
`444
`444
`445
`447
`
`449
`450
`451
`
`452
`452
`453
`455
`456
`456
`457
`458
`
`459
`459
`459
`460
`460
`461
`462
`462
`463
`465
`466
`
`467
`
`475
`
`Microsoft Ex. 1007, p. 6
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`Chapter 1
`
`Introduction
`
`T he NFS™ protocol (hereafter simply called "NFS") is a network protocol
`
`that makes files stored on a file server accessible to any computer on a
`network. In this book I describe not only the NFS protocol and its implemen(cid:173)
`tation, but other protocols that NFS depends on. The book is intended for peo(cid:173)
`ple who are interested in a better understanding of the NFS protocol:
`developers interested in creating new NFS implementations or system admin(cid:173)
`istrators and users curious about how NFS works. For such a popular proto(cid:173)
`col, it is unusual that there are no books that describe it in detail. NFS is
`accorded a mention in many books that describe TCP /IP-based protocols, but
`there is no reference that provides a complete description of NFS that extends
`to the companion protocols such as MOUNT, Network Lock Manager, and
`PCNFSD. I hope this book provides a valuable reference.
`This book assumes that you are already familiar, at some basic level, with
`the concepts of TCP /IP networking and have a reasonable working knowl(cid:173)
`edge of computer filesystems, programming languages, and operating sys(cid:173)
`tems principles. If you wish to brush up on some of this knowledge, I
`recommend Richard Stevens's book TCP/IP Illustrated, Volume 1 [Stevens94]
`as an excellent introduction to TCP /IP networking. It not only describes the
`protocols on which NFS and ONC RPC are built, but also includes a chapter
`on version 2 of the NFS protocol. For a more complete introduction to distrib(cid:173)
`uted systems and network protocols, I recommend Distributed Systems, Con(cid:173)
`cepts and Design, by George Coulouris, Jean Dollimore, and Tim Kindberg
`[Coulouris+96]. It also includes a chapter that discusses NFS along with other
`distributed filesystem protocols.
`You will notice that the book emphasizes protocol over implementation. In
`most chapters, NFS and the protocols it depends on are discussed at the level
`of a protocol specification: What are the bits that move across the wire and
`what do they mean? There are many implementations of NFS, each with its
`own features and administration requirements. A description of the details of
`these implementations is best left for other books or technical manuals. How-
`
`1
`
`Microsoft Ex. 1007, p. 7
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`4
`
`Chapter 1
`
`Introduction
`
`NFS versions 2 and 3 are designed for these high-speed, local area net(cid:173)
`works. In the final chapter of the book I discuss the challenges facing NFS ver(cid:173)
`sion 4, designed to be competitive with the FTP protocol on the Internet.
`
`1.2 Early File Access Protocols
`
`The high-speed networking that became available in the early 1980s created
`interest in many researchers in building file access protocols. At about this
`time, interest was growing in protocols based on Remote Procedure Calls
`(RPC). NFS was not the first, nor did it support many of the features offered
`by some of its predecessors. Perhaps the feature that most distinguished NFS
`from the others was its publication as a protocol from which many different
`implementations could be built. The other distributed filesystems of the time
`were described as implementations. This feature, a distributed filesystem as a
`protocol, continues to distinguish NFS today.
`AT&T's RFS filesystem (described in chapter 13) was a contemporary of
`NFS but a commercial failure due to its complexity and poor performance.
`The Apollo DOMAIN operating system supported remote file access, though
`it was so tightly integrated with the operating system and Apollo hardware
`that it was impractical to implement it on other operating systems. The
`LOCUS distributed operating system [Popek+83], developed at UCLA in the
`early 1980s, provided many advanced remote file access features, such as con(cid:173)
`sistent, high-performance caching, location independence, file migration and
`replication, and crash recovery. However, like RFS and DOMAIN, its distrib(cid:173)
`uted filesystem was inextricably integrated with the LOCUS operating sys(cid:173)
`tem. Its fate was tied to a complex implementation with limited portability.
`The Newcastle Connection [Brownbridge+82] was another remote file
`access implementation that preceded NFS by several years, and it succeeded
`in building expectations of a distributed filesystem that could be ported to
`other UNIX-like operating systems (Figure 1.2). The Newcastle Cmmection
`achieved its portability by implementing a distributed filesystem outside the
`
`Host B
`
`Host A
`
`Program
`
`C Library
`
`, ' UNIX Kernel
`
`RPC
`
`I
`
`1-
`
`Daemon
`
`' -
`, ' UNIX Kernel
`
`C Library
`
`FIGURE 1.2 Newcastle Connection implementation. A modified C library intercepted UNIX
`1/0 system calls, redirecting them locally or remotely. Remote calls were handled by an
`RPC protocol.
`
`Microsoft Ex. 1007, p. 8
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`Chapter 14
`
`PCNFS
`
`T he implementation of NFS by PC clients is an interesting case study in the
`
`success of NFS as a cross-platform protocol. The PC clients referred to in
`this chapter are assumed to be using DOS-derived operating systems: Win(cid:173)
`dows 95, Windows NT, and OS/2. DOS and UNIX file accesses share many
`common feah1res. Both organize their files and directories into one or more
`hierarchical trees where any file or directory in the tree can be referenced by a
`pathname. Files are generally considered to be uninterpreted byte sequences
`that support byte-range file locking. However, there are some significant dif(cid:173)
`ferences in file naming and attributes that need to be resolved.
`PC clients also make use of the PCNFSD protocol to provide authentica(cid:173)
`tion and file printing services that are not normally available on PC clients.
`Two versions of PCNFSD are described here, as well as an alternative protocol
`called BWNFSD-now called HCLNFSD.
`
`14.1 File Naming
`
`The NFS protocol allows files to be named by a sequence of names that make
`up a path. The protocol is careful not to require that pathnames be supported
`as entities within the protocol itself. A pathname is evaluated with a sequence
`of LOOKUP requests. Component-by-component evaluation makes it unnec(cid:173)
`essary for the protocol to reserve a character to separate the components in a
`pathname. It is fortunate for PC-UNIX interoperability because UNIX uses a
`forward slash separator, a/b/c, whereas PC clients use a backslash, a\b\c.
`UNIX servers are case-sensitive and case-preserving . This means that a
`UNIX server sees ABC123 and abc123 as two different filenames-it is sensi(cid:173)
`tive to differences in case. When a name is assigned to a new file, the UNIX
`server will preserve the cases of the characters in the filename; it will not map
`to uppercase or lowercase. DOS clients are case-insensitive and are not case(cid:173)
`preserving . This means that a DOS client cannot distinguish the name ABC12 3
`
`379
`
`Microsoft Ex. 1007, p. 9
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`380
`
`Chapter 14 PC NFS
`
`from abc123. If the file Abc123 is created, instead of preserving the cases, it
`will map all characters to uppercase-ABC123. A Windows client is case(cid:173)
`insensitive and case-preserving. Like a DOS client, it cannot tell the difference
`between ABC123 and abc123, but it will preserve the cases in a filename-it
`will not map lowercase to uppercase.
`The names within a UNIX or Windows path can be any sequence of up to
`255 characters excluding the separator slash. DOS clients are restricted in their
`choice of names to an "8.3" format: the name is limited to 8 characters plus
`a dot and an extension of up to 3 characters. In addition, the characters
`. , + [] *?: \/; =<> are ruled illegal. These restrictions can create problems for
`DOS clients that access files on a UNIX or Windows server. How can long
`names be represented in 8.3 format and what can be done about the characters
`that are legal for UNIX but illegal for DOS or Windows? The DOS client uses
`an algorithm to map UNIX names to DOS equivalents, as follows:
`
`1. The special names . and .. are not mapped.
`2. Lowercase characters are mapped to uppercase characters and upper(cid:173)
`case to lowercase: Abc123. txt becomes aBC12 3. TXT.
`3. If the name is now a legal DOS name and has no lowercase characters,
`then no further mapping is required.
`4. If the NFS name has a legal DOS extension (up to 3 characters, none ille(cid:173)
`gal), the extension is preserved.
`5. The NFS name is truncated to leave just the first 5 characters, and illegal
`DOS characters are mapped to tilde (~ ). If the name is shorter than 5
`characters, it is extended to a full 5 characters by the addition of tildes.
`6. The 5-character name is extended to 8 characters by adding a tilde and
`two legal DOS characters that are chosen to make the name unique
`within the directory (shown as XX in Table 14.1).
`7. If the NFS name had a valid DOS extension, it is appended following a
`dot.
`
`TABLE 14.1 Mapping Table
`
`NFS name
`
`abc123.txt
`lengthyname
`CORE
`core
`.cshrc
`whitepaper.ps
`index. html
`
`DOS mapped name
`ABC123.TXT
`LENGT~XX
`CORE
`CORE~~XX
`~CSHR~XX
`WHITE~XX. PS
`INDEX~XX
`
`Rules
`
`2, 3
`
`2, 5
`
`2, 3
`2, 5, 6
`
`2, 5, 6
`
`2, 4, 5, 6, 7
`
`2, 5, 6
`
`Microsoft Ex. 1007, p. 10
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`14.2 File Attributes
`
`381
`
`The making of a unique name in step 6 through addition of XX characters
`presents an interesting challenge. The two uniqueness characters must not be
`randomly chosen because the name must persist from one day to the next,
`even if the client is rebooted and the mapping table is lost. The Beame and
`Whiteside (now Hummingbird, Inc.) PCNFS client solved the problem neatly
`by using the READDIR cookie value associated with the directory entry as the
`basis for generating the XX characters.
`The DOS-mapped name and the NFS name are stored in a mapping table.
`If a user types a DOS-mapped name, the client will translate it to the NFS
`name via the mapping table before sending a LOOKUP request to the server.
`DOS clients allow the use of wildcard characters to assist in directory searches.
`For instance, one of the illegal DOS filename characters, the asterisk, can be
`used as a wildcard character to represent any sequence of characters in a DOS
`name. The name 1'
`. TXT will match all names in a directory that have an exten(cid:173)
`sion of . TXT. The NFS protocol does not acknowledge wildcard characters. A
`LOOKUP of a name containing one or more wildcard characters can return
`only a single filehandle-the server will not search the directory for multiple
`matches. A DOS client that needs to wildcard search a directory first copies
`the entire directory from the NFS server and searches it locally on the DOS
`client. UNIX shell programs conduct wildcard searches the same way.
`
`14.2 File Attributes
`
`DOS supports only a small set of file attributes compared with the POSIX set
`of 13 or so file attributes provided in the NFS fattr structure returned by the
`GETATTR request (Table 14.2). Some of the NFS attributes like file size and
`
`TABLE 14.2 DOS File Attributes
`
`DOS file attribute NFS mapping
`
`File size
`Modification time
`Read-only
`
`Hidden
`
`Archive
`
`Directory
`System
`
`size
`mtime
`
`Set if the write bit in the mode attribute is not set. The client needs to determine
`whether the user, group, or other write bit applies, depending on the file's owner and
`group. Server ACLs may make this determination unreliable. Reliable read-only indi(cid:173)
`cation can be returned by the NFS version 3 ACCESS procedure.
`If set, it indicates whether the file will appear in directory listings. The attribute is set
`if the NFS name begins with a dot, e.g., . login.
`Used by DOS utilities to determine whether a file needs to be archived. The attribute
`is cleared (set to 0) when the file is archived and set back to 1 if the file is modified.
`Since there is no l .JNIX equivalent, it is set to 1 for all NFS files.
`Set if the file mode attribute indicates that the file is a directory.
`No NFS equivalent-not set.
`
`Microsoft Ex. 1007, p. 11
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`382
`
`Chapter 14 PC NFS
`
`mtime have DOS equivalents. Others have no mapping or an indirect
`mapping.
`
`14.3 Text Files
`
`The NFS protocol handles file content as an uninterpreted sequence of bytes.
`The insensitivity of NFS to file content is a desirable feature for most file for(cid:173)
`mats. For ASCII text files, however, there are some minor differences in the
`representation of the end-of-line character that can have unexpected effects.
`DOS uses two characters to terminate each line: carriage return followed by
`newline <CR><LF>. UNIX uses only the newline character <LF>, and Mac(cid:173)
`intosh computers use only the carriage return character <CR>.
`A DOS program that displays a UNIX text file on an NFS filesystem
`mounted from a UNIX server may produce an unusual effect if it receives text
`lines that have only a single newline. The text
`
`oneone was a racehorse
`twotwo was one two
`oneone won one race
`twotwo won one too
`
`might appear as:
`
`oneeone was a racehorse
`twotwo was one two
`oneone won one race
`twotwo won one too
`
`In practice, text-handling programs on both DOS/Windows and UNIX
`systems are normally tolerant of variations in end-of-line characters. For
`instance, a UNIX EMACS text editor will recognize a DOS file and provide the
`option of storing the edited file with DOS <CR><LF> or UNIX <LF>.
`
`14.4 Symbolic Links
`
`The NFS protocol supports UNIX style symbolic links. A symbolic link is a
`special file that contains only a pathname. Any process that attempts to access
`the symbolic link as a file or directory will be redirected automatically to the
`target of the pathname in the symbolic link. The pathname in a-symbolic link
`can be any pathname that is valid on the server. A relative pathname will be
`evaluated relative to the directory that holds the symbolic link. For instance,
`the UNIX command
`
`ln -s prog_version_3.2 /usr/bin/prog
`
`Microsoft Ex. 1007, p. 12
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`14.4 Symbolic Links
`
`383
`
`creates a symbolic link.· If a program attempts to open /usr /bi n/prog, it will
`be redirected automatically to the file /usr/bin/prog_version_3.2. When a
`UNIX NFS client encounters a symbolic link, it will combine the link path(cid:173)
`name with the original link path to form a new path, then evaluate the link
`path, as it does for any UNIX pathname, one component at a time with
`LOOKUP requests to the server.
`Since UNIX symbolic links are not supported by PC operating systems
`like Windows, DOS, or OS/2, the PC-NFS client software must itself evaluate
`any symbolic links encountered on the server. To do this, it must follow the
`UNIX pathname convention of using a slash separator and handle the long
`names and case sensitivity. The client's evaluation must also allow for a link
`that crosses from one mounted filesystem to another. For instance, if the client
`has mounted the server's /usr/bin on D: and /usr/sbi non E:, then the sym(cid:173)
`boliclink /usr /bi n/prog -> /usr /sbi n/prog must be followed by the client to
`the file on E : .
`There still could be a difficulty if the destination filesystem for the sym(cid:173)
`bolic link is not yet mounted by the client. The Hummingbird, Inc., NFS Mae(cid:173)
`stro client takes a straightforward approach to symbolic link evaluation. It
`simply sends the link path back to the server via the MOUNT protocol. The
`MOUNT daemon on the server evaluates the path and returns a filehandle
`(Figure 14.1).
`
`PCNFS
`Client
`
`Server
`
`NFS LOOKUP dirfh "mylink"
`
`Time
`
`NFS READLINK 0x1234
`
`MOUNT /export/home/my/file
`
`OK fh=0x1234 filetype=symlink
`
`OK path=/export/home/my/file
`
`OK fh=0x3456
`
`FIGURE 14.1 Evaluation of a symbolic link using the MOUNT protocol.
`
`Microsoft Ex. 1007, p. 13
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`384
`
`Chapter 14 PC NFS
`
`14.5 PCNFSD Protocol
`
`The PCNFSD protocol provides some services for PC clients that are normally
`built into UNIX clients (Figure 14.2). If you walk up to a UNIX system, the
`first thing you do is authenticate yourself by logging in. You give your login
`name and password and the UNIX system obtains a UID and GID for you
`from a local /etc/passwd file or from a name service like NIS or NIS+. A PC
`client has no concept of an initial login step, though if connected to a network,
`it will pop up a network login prompt. With the PCNFSD protocol, a PC client
`can convert the login name and password from this network login prompt
`into a UID, GID, and group list that it can use to construct an AUTH_SYS cre(cid:173)
`dential to access an NFS server. For instance, if I log in as "brent" with pass(cid:173)
`word "zyzzygy" the PCNFSD protocol will return my UID and GID: 3497, 10.
`The PCNFSD protocol provides another valuable service for PCs. The
`UNIX clients will use the l p or l pr commands to spool files to a local network
`printer server. Although products are now available that let PC clients print
`directly to these printers, PCNFSD provides a convenient way to spool files to
`network printers without installation of network printer software on the cli(cid:173)
`ent. Version 1 of PCNFSD provides a couple of simple procedures to allow cli(cid:173)
`ents to submit printer jobs via the NFS server. Version 2 considerably expands
`this printing support by providing procedures to display and manage the
`printer queue.
`
`Network
`Printers
`
`NFS and
`PCNFSD Server
`
`NFS Servers
`
`FIGURE 14.2 A PC client uses the PCNFSD protocol to obtain AUTH_SYS
`credential information from a server. Once the client has the credential set up, it can
`access any NFS server-the PCNFSD service does not have to be run on every NFS
`server. The PCNFSD protocol also provides access to printers through the PCNFSD
`server. The server must export an NFS filesystem writable to the client so that the
`client can create printer spool files on the server.
`
`Microsoft Ex. 1007, p. 14
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`14.5 PCNFSD Protocol
`
`385
`
`The protocol is unusual in that the server is distributed in source form
`ready to be compiled for whatever server it needs to be installed on. While the
`server implementation of the PCNFSD_AUTH procedure is easily managed
`with a call to a standard UNIX function like getpwnam (), the printer interfaces
`are less certain. Some systems may use the Berkeley UNIX l pr command for
`printing while others may use the System V l p command or something
`entirely different. The availability of server source gives a system integrator
`the ability to tailor the server to its environment.
`
`14.5.1 Printing
`PCNFSD provides a printing service that uses a combination of the PCNFSD
`protocol and the NFS protocol (Figure 14.3). The PC client first obtains the
`name of a spool directory on the server that is to be used to create printer out(cid:173)
`put files.
`The PCNFSD server exports this directory to the PC clients with write
`access. Each client establishes its own spool area within this export via the
`
`Server
`
`PCNFSD
`
`NFS
`
`MOUNTD
`
`--
`
`Spool area exported
`with write access to
`PC clients.
`
`/var/spool/pcnfsd/
`
`PC Client
`"happy"
`
`PCNFSD_PR_INIT "happy"
`
`-~
`
`/va r /spool/pcnfsd/happy
`MOUNT /var/ spool /p cnfsd/happy
`-~
`
`(filehandle)
`
`sneezy/
`grumpy/
`sleepy/
`happy/
`report0l
`
`lpr
`Command
`
`--
`
`--
`---
`--
`
`Invokes
`lpr Command
`
`CREATE "report0l"
`
`~
`
`~
`
`-~
`
`WRITE
`
`WRITE
`
`~ -
`
`PCNFSD_PR_START "report0l" "printer4"
`~ -
`
`--
`
`FIGURE 14.3 PCNFSD printing. The client uses the PCNFSD_PR_INIT procedure to
`obtain the name of the server's spool area which it then mounts. After creating a spool file
`on the server with NFS writes, it invokes PCNFSD_PR_START to print the spooled file.
`
`Microsoft Ex. 1007, p. 15
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`386
`
`Chapter 14 PC NFS
`
`PCNFSD_PR_INIT or PCNFSD2_PR_INIT procedure. The server returns the name
`of the client's private spool directory, which it then mounts. Thereafter, PC
`applications create spool files in the client's spool directory. When the client
`has · established that printing is completed for each spool file, it calls the ·
`server's PCNFSD_PR_START procedure so that the server will hand off the
`spool file to the desired printer. When printing is complete, the server
`removes the spool file.
`The PCNFSD printing protocol presents some dangers on an insecure net(cid:173)
`work. The protocol uses no authentication, printing clients are assumed to
`have writable NFS access to the server's printer spool directory, and com(cid:173)
`mands containing client-created filenames are invoked on the server. Evil cli(cid:173)
`ents could create files containing shell metacharacters that could be used to
`invoke unwanted actions on the server as superuser. The PCNFSD server
`checks all client-provided names for possible UNIX shell metacharacters. Any
`of the characters ; I&<>' ' ! ?*()[]A/". are considered to be suspicious and
`names containing them will be rejected.
`In the descriptions for versions 1 and 2 of the protocol in sections 14.6 and
`14.7, the type opti ans is used for passing implementation-specific print con(cid:173)
`trol information. The option string is a set of printable ASCII characters. The
`first character should be ignored by the server; it is reserved for client use. The
`second character specifies the type of data in the print file. The types in Table
`14.3 are defined (an implementation may define additional values).
`If diablo data (type d) is specified, a formatting specification string will be
`appended. This specification has the form
`
`ppnnnbbb
`
`where pp is the pitch (10, 12, or 15), nnn is the normal font, and bbb is the bold
`font to be used-encoded as in Table 14.4. For example, the string ndlOhrbcob
`
`TABLE 14.3 Options Types
`
`Option
`letter
`
`Type of data in print file
`
`P
`
`d
`
`x
`
`r
`
`u
`
`PostScript data. The client will ensure that a valid PostScript header is included.
`Diablo 630 data.
`
`Generic printable ASCII text. The client will have filtered out all nonprintable
`characters other than CR, LF, TAB, BS, and VT.
`
`Raw print data. The client performs no filtering.
`User-defined. Reserved for custom extensions. A vanilla PCNFSD server will
`· treat this as equivf!lent to r .
`
`Microsoft Ex. 1007, p. 16
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`14.6 PCNFSD Version 1
`
`TABLE 14.4 Font Codes
`
`387
`
`Font
`
`Courier
`Courier Bold
`
`Courier Oblique
`Courier Bold Oblique
`
`Code
`crn
`crb
`con
`
`cob
`
`Font
`
`Helvetica
`Helvetica Bold
`Helvetica Oblique
`
`Helvetica Bold Oblique
`
`Code
`hrn
`hrb
`
`hon
`hob
`
`Font
`
`Times Roman
`Times Bold
`Times Italic
`
`Times Bold Italic
`
`Code
`
`t rn
`t rb
`ton
`
`tob
`
`specifies that the print data are in Diablo 630 format (d), it should be printed
`at 10 pitch, normal text should be printed in Helvetica-Bold (hrb), and bold
`text should be printed in Courier Bold Oblique (cob).
`
`14.5.2 Comment Strings
`Version 2 of the protocol includes a comment string with each set of call argu(cid:173)
`ments and reply results. Generally, it is unused, but it may be used to pass an
`uninterpreted text string that may be displayed to a system administrator or
`end user or used for custom extensions to the PCNFSD protocol.
`
`14.5.3 Transport and Authentication
`PCNFSD uses a program number of 150001.The protocol can be used via UDP
`or TCP transports. Since call and reply messages are generally short and infre(cid:173)
`quent, the use of UDP is favored because it means that a server with a large
`number of clients does not have to maintain a large number of TCP connec(cid:173)
`tions.The protocol requires no specific RPC authentication-clients normally
`use AUTH_NONE. The lack of user authentication carries a risk of mischief
`for the printing procedtues of version 2 where any user can manipulate the
`printer queue or cancel any print job.
`
`14.6 PCNFSD Version 1
`
`Version 1 of PCNFSD is notable for its simplicity (Table 14.5). The most com(cid:173)
`monly used procedure is PCNFSD_AUTH to authenticate the PC user and
`provide AUTH_SYS credential information. To use the printing procedures,
`the client uses PCNFSD _PR_INIT to obtain the spool directory to be used, cre(cid:173)
`ates the file to be printed in this directory using the NFS protocol, then calls
`PCNFSD_PR_START to print the file. There is no facility to examine or man(cid:173)
`age the printer queue. These features were added in version 2.
`
`Microsoft Ex. 1007, p. 17
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`388
`
`Chapter 14 PC NFS
`
`TABLE 14.5 Summary of PCNFSD Version 1 Procedures
`
`Number Name
`
`Description
`
`Section
`
`0
`1
`2
`3
`
`PCNFSD_NULL
`PCNFSD_AUTH
`PCNFSD _PR_INIT
`PCNFSD _PR_START
`
`NULL procedure
`Perform user authentication
`Prepare for remote printing
`Submit job for printing
`
`14.6.1, page 388
`14.6.2, page 389
`14.6.3, page 390
`
`14.6.1 Procedure 1: PCNFSD_AUTH-Perform User Authentication
`
`Description
`Perform user authentication-map username and