DCE/DFS Release Overview and Administration Guide RO-5225 1.1 Cray Research, Inc. Notices ======= Copyright © 1995, 1996 Cray Research, Inc. All Rights Reserved. This manual or parts thereof may not be reproduced in any form unless permitted by contract or by written permission of Cray Research, Inc. Portions of this product may still be in development. The existence of those portions still in development is not a commitment of actual release or support by Cray Research, Inc. Cray Research, Inc. assumes no liability for any damages resulting from attempts to use any functionality or documentation not officially released and supported. If it is released, the final form and the time of official release and start of support is at the discretion of Cray Research, Inc. Autotasking, CF77, CRAY, Cray Ada, CraySoft, CRAY Y-MP, CRAY-1, CRInform, CRI/Turbo Kiva, HSX, LibSci, MPP Apprentice, SSD, SUPERCLUSTER, SUPERSERVER, UNICOS, and X-MP EA are federally registered trademarks and Because no workstation is an island, CCI, CCMT, CF90, CFT, CFT2, CFT77, ConCurrent Maintenance Tools, COS, Cray Animation Theater, CRAY APP, CRAY C90, CRAY C90D, Cray C++ Compiling System, CrayDoc, CRAY EL, CRAY J90, Cray NQS, Cray/REELlibrarian, CRAY S-MP, CRAY SSD-T90, CRAY SUPERSERVER 6400, CRAY T90, CRAY T3D, CRAY T3E, CrayTutor, CRAY X-MP, CRAY XMS, CRAY-2, CS6400, CSIM, CVT, Delivering the power . . ., DGauss, Docview, EMDS, GigaRing, HEXAR, IOS, ND Series Network Disk Array, Network Queuing Environment, Network Queuing Tools, OLNET, RQS, SEGLDR, SMARTE, SUPERLINK, System Maintenance and Remote Testing Environment, Trusted UNICOS, UNICOS MAX, and UNICOS/mk are trademarks of Cray Research, Inc. EXABYTE is a trademark of EXABYTE Corporation. FLEXlm is a trademark of Globetrotter Software, Inc. IBM and RISC System/6000 are trademarks of International Business Machines Corporation. Kerberos is a trademark of Massachusetts Institute of Technology. Open Software Foundation, OSF, and OSF/1 are registered trademarks of the Open Software Foundation, Inc. PostScript is a trademark of Abode Systems, Inc. Sun and Solaris are trademarks of Sun Microsystems, Inc. UNIX is a trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. The UNICOS operating system is derived from UNIX® System V. The UNICOS operating system is also based in part on the Fourth Berkeley Software Distribution (BSD) under license from The Regents of the University of California. Chapter 1. Introduction *********************** This document describes two products: the Cray Distributed Computing Environment (DCE) Client Services 1.1 and the Cray DCE Distributed File Service (DFS) Server 1.1. The Cray DCE implementation is derived from the Open Software Foundation (OSF) DCE 1.1 release. This release provides support for the following DCE client core services: o Remote Procedure Call o Cell Directory services o Threads o Security Cray Research does not provide support for the DCE servers; therefore, at least one Security server and Cell Directory server must be accessible on a non-Cray Research platform in the DCE cell. Also, if you are running DFS, the File Location Server (FLS) must also reside on a platform other than a Cray Research system. The DFS component of DCE/DFS is derived from code that will be part of the OSF DCE 1.2 release. The Cray DCE DFS Server 1.1 package consists of all of the DCE Client Services components, plus DFS server support. The Cray DCE Client Services 1.1 and Cray DCE DFS Server 1.1 releases are supported on CRAY T90, CRAY J90, CRAY EL, CRAY C90, and CRAY Y-MP systems running UNICOS release level 9.02 or higher, and on CRAY T90 IEEE systems, running UNICOS release level 9.1 or higher. These products are not supported on CRAY-2 systems, CRAY X-MP systems CRAY SUPERSERVER 6400 (CS6400) systems, or Cray MPP systems. This release overview briefly describes Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 and includes the following chapters: o New features o Software overview o Compatibilities and differences o Installation and configuration o Administration o Customer services o Release package 1.1 Distribution of this release overview ========================================= A copy of this release overview is included with the DCE/DFS 1.1 release package; you can also order it separately through the Cray Research Distribution Center. In addition, you can access this release overview electronically through one of the following systems: o Both ASCII and PostScript files of this release overview are available on the Cray Research CRInform system, which is an online information and problem-reporting system for Cray Research customers. If you do not have access to CRInform but you would like a copy of the files, contact your Cray Research representative. For more information on CRInform, see Section 7.4. o Both ASCII and PostScript files of this release overview are available on the Cray Research hydra system, using the path name /home/hydra/release_docs. If you would like a copy of the files, contact your Cray Research representative. o A copy of this release overview is available on the Cray Research Software Web page at the following URL: http://www.cray.com/PUBLIC/product-info/sw/ 1.2 Reader comments =================== If you have comments about the technical accuracy, content, or organization of this document, please tell us. You can contact us in any of the following ways: o Send us electronic mail from a UNICOS or UNIX system, using the following UUCP address: uunet!cray!publications o Send us electronic mail from any system connected to the Internet, using the following Internet address: publications@timbuk.cray.com o Call our Software Publications Group in Eagan, Minnesota, through the Customer Service Call Center, using either of the following numbers: o 1-800-950-2729 (toll free from the United States and Canada) o +1-612-683-5600 o Send a facsimile of your comments to the attention of "Software Publications Group" in Eagan, Minnesota, at fax number +1-612-683-5599. o Use the postage-paid Reader's Comment form at the back of this document. We value your comments and will respond to them promptly. Chapter 2. New Features *********************** This chapter describes new OSF features and new Cray Research proprietary enhancements to OSF features. 2.1 New OSF features ==================== This section describes the following new OSF features: o Features to improve and simplify DCE administration o Security enhancements o Generic Security Service Application Program Interface (GSS-API) o DFS/NFS Secure Gateway o Internationalized interfaces 2.1.1 Improved and simplified DCE administration ++++++++++++++++++++++++++++++++++++++++++++++++ Release 1.1 improves and simplifies DCE administration with the following features: o Single administrative DCE control program (dcecp) o DCE daemon program (dced) o Enhanced diagnostic messaging o Cell aliasing o Hierarchical cell support o Host unconfiguration This section describes each of these features. 2.1.1.1 Single administrative DCE control program ------------------------------------------------- The dcecp program provides a common interface for DCE administrative functions. This utility combines the most common tasks performed by rpccp, cdscp, rgy_edit, acl_edit, dtscp (dtscp is not supported in the Cray Research implementation), and sec_admin. 2.1.1.2 DCE daemon program -------------------------- Functionality added to the endpoint mapper (dced) allows administrators to specify during configuration which services should be running on a host, to start and stop them, and to perform status queries of DCE services. 2.1.1.3 Enhanced diagnostic messaging ------------------------------------- Enhancements were made to DCE diagnostic messaging in the following areas: o Consistent debugging, tracing, and diagnostic message output and control o Documentation of error messages in the OSF Message Manual and the Problem Determination Manual, both available from OSF 2.1.1.4 Cell aliasing --------------------- Cell aliasing enables cell names to be changed and allows cells to have multiple names. For more information, see section 11.4.3, in the OSF DCE Administration Guide - Core Components. 2.1.1.5 Hierarchical cell support --------------------------------- Cell alias and polymorphous naming functionality of hierarchical cells are supported. Transitive trust is not included in DCE 1.1. For more information, see section 11.4.2, in the OSF DCE Administration Guide - Core Components. 2.1.1.6 Unconfiguring a host ---------------------------- This feature enables the unconfiguring of a host from the cell. It deletes all entries for a given host from the security registry, the directory service, and the DFS file location database (fldb). 2.1.2 Security enhancements +++++++++++++++++++++++++++ Security enhancements for the OSF DCE 1.1 release include security delegation and security auditing. 2.1.2.1 Security delegation --------------------------- Security delegation allows intermediary servers to operate on behalf of the initiating client while preserving both the client's and the servers' identities, and preserving access control attributes across chained RPC operations. 2.1.2.2 Security auditing ------------------------- The security auditing feature allows administrators to track security events within DCE's trusted computing base. It also provides the means to configure the filtering and notification of these events, and a facility for extracting and printing audit records. Note: DCE security auditing is separate from Cray Research MLS security auditing, which is not supported for DCE and DFS in this release. 2.1.3 Generic Security Service Application Program Interface (GSS-API) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This feature provides access to the DCE authentication and authorization services for non-RPC applications that operate within the DCE environment. 2.1.4 DFS/NFS Secure Gateway ++++++++++++++++++++++++++++ The DFS/NFS Secure Gateway provides a mechanism for granting authenticated access to the DFS file space from an NFS client. This feature allows NFS clients full access to the DFS file system without the need to install DFS locally. 2.1.5 Internationalized interfaces ++++++++++++++++++++++++++++++++++ Internationalized interfaces allow the use of message catalogs for all messages that are visible to the user. DCE structures (prompts and messages) have been standardized to support international formats. Note: This OSF release provides only the US English message catalogs. 2.2 Cray Research enhancements ============================== This section describes the following new Cray Research proprietary enhancements to OSF features: o DFS ID mapping o Multilevel security (MLS) o Integrated DCE login and enhanced authentication configuration o Single sign-on 2.2.1 DFS ID mapping ++++++++++++++++++++ ID mapping is a feature of UNICOS that masks different account-to-user ID mappings between hosts. This feature is currently an extension to NFS, which allows an NFS server to map between user IDs and group IDs supplied by clients to those in the local user database (UDB). This same mapping technique can be applied to DFS. In addition, when MLS is used, maps are needed if restricted network access lists (NALs) are used. DFS ID mapping provides the following features: o DFS authenticated intercell access (see Section 3.3.4.1) o MLS support for restricted NALs (see Section 2.2.2.4 and Section 3.3.4.4) o Restricting client/user access to a DFS exported file system (see Section 3.3.4.3) o Mapping from the DCE registry to the UDB (see Section 3.3.4.2) 2.2.2 Multilevel security (MLS) +++++++++++++++++++++++++++++++ The DCE/DFS 1.1 release includes the following MLS features: o Configuration for PRIV_SU and non-PRIV_SU security o Mandatory access control (MAC) labels o Privilege assignment lists (PALs) o ID mapping o Network access lists (NALs) 2.2.2.1 Configurations for PRIV_SU ---------------------------------- The MLS DCE/DFS software runs with the kernel configured for PRIV_SU with PALs and non-PRIV_SU with PALs. Note: The DCE/DFS software was not included in the Trusted Computing Base (TCB) evaluation. This software should be installed only if approved by the local site security officer. The DCE/DFS software does not support PRIV_TFM security at this release level. 2.2.2.2 Mandatory access control (MAC) labels --------------------------------------------- Files can exist at a MAC label. A user's MAC label on the client machine is propagated to the server at which it is used to control file access. File MAC labels are visible on the DFS client. However, clients cannot change MAC labels by using DFS. DFS enforces the NAL by using the label range from the NAL on communication to and from a DFS server and client. 2.2.2.3 Privilege assignment lists (PALs) ----------------------------------------- Privilege assignment lists (PALs) were created for DCE/DFS executable files, including the following: o auditd o cdsadv o cdscp o cm o cray_dce_login o dcecmd o dcecp o dced o dcestat o dfsbind o dfsd o dfsexport o dfstrace o ftserver o fxd o fts o klogin o klogind o krcp o krsh o kshd o telnet o telnetd PALs give these executable files sufficient permission to execute system calls on a non-PRIV_SU configuration. Permissions are created for system, secadm, sysadm, and sysops roles as needed for the executable files. 2.2.2.4 ID mapping ------------------ If your site plans to run a DFS server and restrict access to the server by using a restricted NAL, you must run ID mapping. The ID maps provide MAC label ranges for users who are attempting to access the DFS server. The server maps must contain an entry for the machine context of every DFS client machine that will access the server through a restricted NAL. 2.2.2.5 Network access lists (NALs) ----------------------------------- Follow these guidelines when using NALs: o Communication to DCE naming and security services must not have NAL restrictions. o DFS servers return data with the same label as that of the client request received. NAL ranges should be the same for both client and server ranges. 2.2.2.6 MLS features not supported ---------------------------------- The following UNICOS MLS features are not supported in this release: o Additional MLS security auditing. o Access control lists (ACLs); MLS ACLs are enforced by the DFS server, but are not visible to the DFS client. o DFS over SFS on an MLS PAL-only system. 2.2.3 Integrated DCE login and enhanced authentication configuration ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The common UNICOS identification and authorization mechanism ia_user(3C); has been modified to allow a site to select either the UDB or the DCE registry to be used for user identification and password checking. Integration of DCE authentication and UNICOS login utilities provides users with DCE credentials without requiring that they explicitly perform the DCE login (that is, execute the dce_login(8) command). 2.2.4 Single sign-on ++++++++++++++++++++ The single sign-on feature provides integration of kerberized network login utilities with DCE security. Kerberos version 5 beta 5 network utilities such as telnet, rlogin, rcp, and rsh are provided for UNICOS systems. These kerberized network utilities provide ticket forwarding as well as conversion of the Kerberos 5 tickets to a DCE context for transparent single sign-on access to DFS files in the networked environment. Chapter 3. Software Overview **************************** The Cray Distributed Computing Environment (DCE), as developed by the Open Software Foundation (OSF), is a set of services and tools that provide for distributed computing in a heterogeneous computing environment. The Cray DCE Client Services implementation is a full client implementation; it provides all client services that are part of DCE. Other vendors' security and directory servers must be accessible in the cell. If you are implementing DFS, the File Location Server (FLS) must also be accessible. The Cray DCE Distributed File System (DFS) Server product provides facilities for the UNICOS operating system to act as a DFS file server. The reader of this release overview and of the online man pages included as part of the Cray Research package is assumed to be familiar with DCE. If you are not familiar with DCE, reviewing the guides published by OSF and Prentice-Hall is recommended. For a list of OSF documentation, see Section 7.1.3. The Cray Research DCE security service supports the use of the Data Encryption Standard (DES) as a data encryption mechanism for secure Remote Procedure Calls (RPCs). DES enables secure communication between DCE facilities and services. One of the DES services is packet privacy, a protection level that encrypts data in RPCs sent between DCE applications. United States export restrictions prevent Cray Research from offering packet privacy in its international version of DCE. Therefore, the option to encrypt RPC data has been removed from the international version of the product. The kerberized login utilities also provide entire session encryption as a user-selectable option. United States export restrictions prevent Cray Research from offering login session encryption in its international versions of DCE. The option to encrypt login sessions has been removed from the kerberized login utilities for the international versions of the product. 3.1 Cray DCE/DFS product structure ================================== All DCE/DFS user space files are installed in the /opt/dcelocal directory. Under this directory, the following major subdirectories are created: Subdirectory Description bin The DCE/DFS binaries. Users wanting to access DCE/DFS must access executable files from this directory. etc Configuration and start-up utilities. etc/logs Daemon logs. This directory contains logs for daemons started on the system. These may offer help in diagnosing any DCE/DFS problems you might experience. krb5 Kerberos support directory. lib Programming libraries. This directory contains the application programming libraries. Links are also made from /usr/lib to this directory. nls Message catalog files. This directory is a repository for files used to generate DCE/DFS error messages. Links are made from /usr/lib/nls/En to the files in this directory. include Header files for application programming. To build DCE applications, programmers must include header files from this directory. man Manual pages. var General log, core, and data files. tcl Tcl support files. dcecp dcecp support files. For a description of setting up your environment to most easily access the files needed during DCE/DFS operation, see Section 5.8. This DFS product requires specific kernel modules to be built into the UNICOS kernel. For UNICOS releases 9.2 and later, these modules come released with UNICOS. For UNICOS 9.0.2 and any version of UNICOS 9.1, these modules are shipped and loaded from the Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 media and are placed in the following default directories (the directories can be modified during the loading process): Directory Description /usr/src/uts/rlib DFS kernel modules /usr/src/uts/cmd/crash/rlib DFS crash(8) modules These modules will be used on subsequent builds of the kernel and crash(8) command. 3.2 OSF features supported by Cray Research =========================================== The following list identifies the OSF components that are supported by Cray Research: o Libraries in the libdce header files. For a list of libraries not supported, see Section 4.2. o DCE services: o DCE command program (dcecp(8)) o DCE daemon (dced(8)) o RPC services: o Interface Definition Language (IDL) compiler (idl(1)) o RPC control program (rpccp(8)) o UUID generator (uuidgen(1)) o Administrative interface (dcecp(8)) o Cell directory services: o Combined advertiser and child code (cdsadv(8)) o Control program (cdscp(8)) o Administrative interface (dcecp(8)) o Security services: o Security utilities (dce_login(8), kinit(1), klist(1), kdestroy (1), kpurge(1), chpass(8)) o Access control list (ACL) editor (acl_edit(8)) o Registry editor (rgy_edit(8)) o Generic Security Service Application Program Interface ( gssapi_intro(3)) o Administrative interface (dcecp(8)) o Audit server (auditd(8)) o Cell configuration: o Configuration script (dce_config(8)) o Cell name utility (getcellname(8)) o Administrative interface (dcecp(8)) o Unconfigure host o DFS client: o Cache manager (kernel-resident) o Kernel RPC (kernel-resident) o DFS daemon (dfsd(8)) o DFS trace utility (dfstrace(8)) o DFS update client (upclient(8)) o Cache manager command interface (cm(8)) o Kernel diagnostic program (crash(8)) o DFS/NFS Gateway (dfsgw(8)) o Kernel helper utility (dfsbind(8)) o DFS server: o Token manager (kernel-resident) o Protocol exporter (kernel- resident) o Kernel RPC (kernel-resident) o Initialization daemon (fxd(8)) o File set server (ftserver(8)) o File set command interface (fts(8)) o File set exporter command (dfsexport(8)) o DFS trace utility (dfstrace(8)) o DFS update client (upclient(8)) o Kernel diagnostic program (crash(8)) o Kernel helper utility (dfsbind(8)) o File system export scripts (dfsmkfs(8) and dfsrmfs(8)) 3.3 Cray Research enhancements ============================== Enhancements that Cray Research has made to the OSF components are as follows: o Multilevel Security (MLS) (for a description of this enhancement, see Section 2.2.2) o Cray shared file system (SFS) o FLEXlm licensing o Integrated DCE login and enhanced authentication configuration o DFS ID mapping o Single sign-on 3.3.1 Cray shared file system +++++++++++++++++++++++++++++ Cray Research supports using the Cray shared file system (SFS) as the underlying file system for DFS. SFS is an optional software package from Cray Research that allows a cluster of Cray Research systems to simultaneously mount a file system that is resident on shared media, such as HIPPI disks. Placing DFS over SFS has the following advantages over direct SFS: o The shared media device is made accessible to platforms other than Cray Research platforms. o DFS caching technology allows for much greater throughput for small block I/O. When DFS is run over SFS, each of the systems on which the SFS is mounted reads and writes data directly from the file system. Data is not transferred from the DFS server. All other operations, including file and directory manipulation, use the DFS server. All hosts with direct access to the SFS disk must run a DFS client and server. One of the hosts is designated as the primary server and is responsible for administering DFS tokens. For configuration information, see Section 5.5. 3.3.2 FLEXlm licensing ++++++++++++++++++++++ The DCE/DFS product uses FLEXlm licensing to control access to the software. A separate license key is required for the client and server portions of the release. You will receive FLEXlm license keys from the Cray Research Distribution Center with instructions on how to install them. If you do not receive the license keys, contact the Cray Research Distribution Center. 3.3.3 Integrated DCE login and enhanced authentication configuration ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The common UNICOS identification and authorization mechanism, ia_user(3C), has been modified to allow a site to select either the UDB or the DCE registry to be used for user identification and password checking. Integrated DCE login allows a user to log in to a Cray Research system and have a DCE identity (credentials) set up transparently, without the user having to explicitly perform the DCE login (executing the dce_login command). With this feature, is it possible for users to have their home directory on a DFS exported file system. A configuration file controls how the password is validated (from the DCE registry, from the UDB, or from both). The chpass(8) command allows users to easily change their DCE cell passwords on the Cray Research system. The chpass program can be installed as a /bin/passwd replacement to update both registry and UDB passwords at once. If the DCE registry was used for authentication, the DCE credentials are saved and associated with the user's session. The same technique works for telnet(1), rlogin(1) with a password, ftp(1), and nqe(1) batch jobs. The fta(8) command is supported in a limited fashion. The file transfer service (FTS) must be ftp, and the transfer must be done synchronously. If the file transfer is queued by fta, DCE credentials will not be available when the actual transfer is performed. The UDB is used to set up all of the remaining parameters of the user's session. The UDB is still required, because it contains many extensions to the account information that are not available from a DCE registry. Figure 1, shows the integrated login procedure. Figure 1. Integrated login ******************************************** See hardcopy for Figure 1. ******************************************** The integrated DCE login feature cannot authenticate a user in the DCE registry if a password is not provided. To use the ticket forwarding feature, you must install and configure the Kerberos 5.5 login utilities. For more information on the Kerberos login utilities, see Section 3.3.5. Because of the password restriction, no integrated DCE login support can be provided for .rhosts or host.equiv functionality for rlogin. Additionally, requests that use the rcmd command are not supported. In the case of an rlogin request in which the remote user has a .rhosts file set up, the DCE authentication is not performed. The user is allowed on the system but without any DCE credentials. The user must then perform a separate DCE login (using the dce_login command) to use DCE/DFS services as an authenticated user. Table 4, provides a detailed description of the authentication method and the results that are obtained for all of the possible configuration options. You can install and configure the integrated DCE login feature by using the dce_config script that has been provided. For installation and configuration information, see Chapter 5. 3.3.4 DFS ID mapping ++++++++++++++++++++ This section assumes that the reader is familiar with the terms and concepts of the NFS ID mapping facility. For more information on the NFS ID mapping facility consult the UNICOS Networking Facilities Administrator's Guide, publication SG-2304. ID mapping is a feature of UNICOS that provides mapping of user and group IDs between a Cray Research machine and another host. DFS uses this extension to NFS to provide DFS ID mapping. The maps used by DFS are wholly contained in the DFS server so that clients from any DCE vendor can be supported. NFS must be built into the kernel to use any of the DFS ID mapping features, which include the following: o DFS authenticated intercell access o Mapping from the DCE registry to the UDB o Restriction of client/user access to a DFS exported file system o MLS MAC label support 3.3.4.1 DFS authenticated intercell access ------------------------------------------ Cray DFS servers provide authenticated intercell access by using DFS ID mapping without having to implement the LFS type file system. Before file system access is made, the principal's identity from the foreign cell is obtained from the request and mapped into a local cell principal. DFS ID mapping provides the remote-cell-to-local-cell mapping. See Figure 2, for an example of this mapping. Figure 2. ID mapping (DCE registry ->local UID) ********************************************** See hardcopy for Figure 2. ********************************************** Without DFS ID mapping or an LFS file system, files created by any principal from a foreign cell would be owned by the DCE registry principal nobody (uid = -2). DFS ID mapping allows the foreign cell principal to be mapped to a local cell principal, thereby allowing authenticated intercell access to files exported through DFS on a Cray Research machine. A user must have a principal in both the foreign and the local cell. DFS ID mapping allows files on the Cray Research DFS server to be uniquely identified as belonging to a principal in a foreign cell. DFS maintains status information about a principal's identity so that mapping is performed infrequently and efficiently. Additional administrative tasks and considerations arise when you administer a multicell environment in which principals from foreign cells are allowed to access objects in local cells. There might be interactions of principals across different cells. For more information, see Chapter 33 in the OSF DCE Administration Guide - Core components. 3.3.4.2 Mapping from the DCE registry to the UDB ------------------------------------------------ You can use DFS ID mapping to map DCE registry principals to users with accounts in the UDB on the Cray Research system. This type of mapping is useful if you have users in the UDB and you cannot create DCE registry principals for these users with the same name as assigned in the UDB. For example, a user, brian, has an account on a Cray Research system. However, when a DCE registry account is created for brian, the principal brian has already been assigned to another user. The DCE cell administrator creates a principal with the name gaffey. A DFS ID map is created with an exceptions file mapping DCE principal gaffey to UDB user brian. When the DCE principal gaffey creates files through DFS on the Cray Research server, the ID maps translate to user brian. File attributes listed through DFS will show files and directories as belonging to DCE principal gaffey. However, if the user brian logs in to the Cray Research system and lists the attributes of a file or directory through NC1, the file will appear as being owned by user brian instead of user gaffey. 3.3.4.3 Restriction of client/user access to a DFS exported file system ----------------------------------------------------------------------- DFS ID mapping can be used to control access to the local Cray Research system through DFS by allowing requests only from certain Internet addresses, or by restricting access for certain users at these addresses. Because NFS ID mapping domains are created per client IP address, it is possible to create maps that restrict access per DFS client machine and user ID. 3.3.4.4 MLS MAC label support ----------------------------- DFS ID mapping can be used with UNICOS multilevel security (MLS) to provide MAC label ranges for DCE principals. The mapping is performed on inbound DFS server requests. The maps translate the principal to a user ID on the server machine. The server machine looks up the user's label ranges in the UDB. This type of mapping requires a one-to-one mapping of DCE principals to user IDs in the UDB. It also requires a UDB entry for every DFS client that attempts to contact the DFS server through a restricted NAL. 3.3.4.5 Feature limitations --------------------------- The DFS ID mapping feature uses NFS ID mapping code to create and store maps. Therefore, if you want to use DFS ID mapping, NFS must be built into the kernel, and NFS ID mapping must be turned on in the configuration. The DFS server performs all ID mapping to and from the DFS file system. DFS clients do not perform any mapping. If you want to run NFS and DFS and share ID maps between the NFS server and the DFS server, there is a restriction on how these maps can be structured. Caution: If the NFS client's /etc/passwd file is not flat (that is, if login names, user IDs, and group IDs do not exactly match those in the DCE registry), you can run NFS ID mapping or DFS ID mapping, but not both. The DFS server performs the ID map translation from the DCE credentials to a local user ID and group ID set the first time an RPC call is made on behalf of the user from a specific client. The resulting user ID and group IDs are cached on the DFS server and are not translated with every file system access, as is the case with NFS. Therefore, changes to the ID mappings will not be reflected in existing active contexts. Flushing the DFS ID cached map domains or executing the nfsclear(8) command will not cause active contexts to be remapped. However, flushing the DFS ID cached map domains will cause any subsequent context creations to be translated according to the current ID maps. It is not possible to change the ID maps and have the changes reflected immediately in all previously active contexts without a reboot of the DFS file server machine. Eventually, active contexts will either expire or need to be refreshed. It is at this point that these contexts will be remapped with the current ID mapping translations. 3.3.5 Single sign-on ++++++++++++++++++++ Integrated login always requires a password to function. Single sign-on adds the ability to take a set of previously obtained DCE credentials and use them to gain access to remote services or systems and have DCE credentials for use on the remote systems. The single sign-on feature makes use of Kerberos 5, Beta 5 versions of the telnet, rlogin, rcp, and rsh utilities to ship tickets from the DCE credentials cache to remote systems. These kerberized network utilities also provide conversion of the Kerberos 5 tickets to a DCE context for transparent single sign-on access to DFS files in the networked environment. Figure 3, shows the client side of the sign-on facility. Figure 4, shows the server side of the sign-on facility. The entire process is as follows: 1. A kerberized utility such as telnet obtains tickets from the DCE credentials cache. 2. Kerberos protocol is used to obtain, from the DCE security server, a ticket for the requested destination and a ticket granting ticket for the user at the destination host. 3. The ticket is forwarded over the telnet protocol to a telnetd daemon that is aware of Kerberos. 4. The telnetd daemon creates a Kerberos 5 ticket file for the user and then runs /bin/login. 5. The login binary file executes a new DCE binary file named cray_k52dce, which converts the Kerberos 5 ticket file into a DCE credentials file. 6. The UDB is used to set up the session information before a shell process is started. Figure 3. Single sign-on leaving a host ******************************************** See hardcopy for Figure 3. ******************************************** Figure 4. Single sign-on authentication to remote service (telnet) ******************************************** See hardcopy for Figure 4. ******************************************** 3.3.5.1 Supported commands -------------------------- The following commonly used network service application clients and servers have been kerberized: Kerberized client applications: Application Description telnet telnet protocol klogin Kerberized rlogin krsh Kerberized rsh kcp Kerberized rcp Kerberized server applications: Application Description telnetd telnet protocol klogind Kerberized rlogind kshd Kerberized kshd All of the kerberized commands are installed in /opt/dcelocal/bin. 3.3.5.2 Multihomed hosts ------------------------ Kerberos performs authentication based in part on an IP address encrypted within the ticket. The KDC (or DCE security service) ensures that the ticket-granting ticket (TGT) contains a IP address that matches the IP address of the interface on which the request was made. This can create difficulty for machines that have multiple IP addresses (multi-homed hosts). The Domain Name Service (DNS) can store multiple interface IP addresses for a multi-homed host. Therefore, if you run named (8) on your Cray Research system, you can accommodate multi-homed hosts. Kerberos 5 can store multiple IP addresses for a host within the TGT. If you do not run named, you must ensure that the IP address provided by a gethostbyname (3C) call will return the same address on every machine that is to act as a login utility client (for example, the host on which you want to run klogin). This IP address must also be the interface that the destination host (the host running klogind) will use to make requests to the KDC (DCE security service). 3.3.5.3 Third-party software ---------------------------- Your network probably consists of various types of hardware, running many different versions of software. You should check with the vendors of your other hardware and software to determine whether they have implementations of Kerberos version 5 available on their platforms. If they do not, and if you want to use Kerberos on the unsupported platform, you must port the Massachusetts Institute of Technology (MIT) Kerberos version 5 to that platform yourself. The Kerberos authentication system is a set of software that performs distributed authentication in an open network environment. This software was designed and developed at MIT as part of Project Athena. All Kerberos software included in DCE 1.1 except for telnet and telnetd is copyrighted by MIT. For further information, you can use anonymous ftp to access descriptions of Kerberos directly from MIT. To access these, connect to athena-dist.mit.edu through ftp. Use anonymous as your user name, and use your Internet email address as your password. List the available files by using the following command: ls pub/kerberos/doc Files that end with a .PS suffix are in PostScript format; files that end with a .TXT suffix are in ASCII format. A set of patches to Kerberos Version 5 beta 5 are provided by ESnet and can be obtained through anonymous ftp from achilles.ctd.anl.gov. These patches allow using a DCE registry as the KDC. Obtain the README file through anonymous ftp from the following location: ftp:///achilles.ctd.anl.gov/pub/kerberos.v5/README The README file explains the steps required to download, install, and configure the ESnet Kerberos distribution. You can also read OSF RFC 92.0, which covers Kerberos 5 and DCE integration issues. 3.3.5.4 Kerberos version 4 and Kerberos version 5 compatibility --------------------------------------------------------------- Both versions of Kerberos share common Internet service entries. Therefore, the Kerberos version 4 network utilities that are bundled with UNICOS are not compatible with the Kerberos version 5 network utilities. You can run one or the other, but you cannot run both Kerberos versions of network utilities on the same Cray Research system at the same time. Chapter 4. Compatibilities and Differences ****************************************** This chapter describes differences and incompatibilities between the Cray Research implementation of DCE and the OSF description of DCE version 1.1, and between the Cray Research implementation and other implementations. In a few cases, certain commands and routines are not implemented; in other cases, there are differences in functionality. In the online man pages distributed with the Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 releases, differences are described in a special section labeled Cray Notes. In this chapter, differences are divided into the following areas: o Cray DCE/DFS programming environment use o Commands, routines, and other facilities not supported o Threads o Remote procedure calls (RPCs) o Time o Directory services o Security o DFS/NFS Secure Gateway o Online man page names o UNICOS file system features o DCE on a PAL-only system 4.1 Cray DCE/DFS programming environment use ============================================ The programming environment consists of support libraries, C programming language header files, and a few DCE utilities. The support libraries are installed in the /opt/dcelocal/lib directory with links made from /usr/lib. The DCE/DFS headers are installed in the /opt/dcelocal/include directory and must be referenced by anyone who wants to build a DCE application. To properly include these header files, the -I /opt/dcelocal/include option must be added to the cc(1) command line. The programming utilities (uuidgen(1), sams(1) and idl(1)) are located in the /opt/dcelocal/bin directory. 4.2 Commands, routines, and other facilities not supported ========================================================== The following sections describe commands, routines, and other facilities that are not implemented in the Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 versions of these products. Note: Due to the size and complexity of the UNICOS software, the following might not be an exhaustive list. 4.2.1 Distributed File System (DFS) service +++++++++++++++++++++++++++++++++++++++++++ The following DFS special files are not supported: o admin.bak(4dfs) o admin.bos(4dgs) o admin.fl(4dfs) o admin.up(4dfs) o BakLog(4dfs) o BosConfig(4dfs) o BosLog(4dfs) o DFSLog(4dfs) o FMSLog(4dfs) o RepLog(4dfs) o SalvageLog(4dfs) o TapeConfig(4dfs) o TE(4dfs) o TL(4dfs) o UpLog(4dfs) 4.2.2 Cell directory service (CDS) ++++++++++++++++++++++++++++++++++ The following CDS administrator commands are not supported: o cdsbrowser(8cds) o cdsclerk(8cds) o cdsd(8cds) o dump_clerk_cache(8cds) o gdad(8cds) 4.2.3 Global directory service (GDS) ++++++++++++++++++++++++++++++++++++ The GDS administrator commands are not supported. 4.2.4 Diskless support service ++++++++++++++++++++++++++++++ The following diskless support service routines are not implemented: o bootpd(8dskl) o bootptab(8dskl) o client(8dskl) o dlcd(8dskl) o dlctab(8dskl) o dsw_adm(8dskl) o dswd(8dskl) o tftpd(8dskl) 4.2.5 Distributed time service (DTS) ++++++++++++++++++++++++++++++++++++ The following DTS administrator commands are not implemented: o advertise(8dts) o change(8dts) o create(8dts) o delete(8dts) o disable(8dts) o dtscp(8dts) o dtsd(8dts) o enable(8dts) o exit(8dts) o help(8dts) o quit(8dts) o set(8dts) o show(8dts) o synchronize(8dts) o unadvertise(8dts) o update(8dts) 4.2.6 Security commands +++++++++++++++++++++++ The following security administrator commands are not implemented. For more information, see Section 4.7. o passwd_export(8sec) o passwd_import(8sec) o sec_create_db(8sec) 4.2.7 Fileset server commands +++++++++++++++++++++++++++++ The following commands are not supported when applied to a Cray Research DFS server and, if used, might cause serious problems. However, from a Cray Research DFS client, you can send them to a server other than a Cray Research system by using the -server option. o fts_dump(8) o fts_restore(8) 4.3 Threads =========== Threads-related differences occur in the following areas. See the following sections for specific information on each: o Wrappers o pthread_create(3) o fork(2) and exec(2) o Output from ps(1) o Scheduling threads o Canceling threads o getpid(2) o sleep(3) o Signals o pthread_yield(3) o Thread stack size 4.3.1 Wrappers ++++++++++++++ As in most DCE implementations, the Cray Research implementation uses library and system call wrappers to protect routines in a multithreaded environment. Wrappers are needed because some libraries are not thread-safe. However, wrappers are not provided for all libraries supported by Cray Research. For example, the X11 libraries are not thread-safe. Care must be taken to ensure that such libraries are not used simultaneously by two or more threads. Some DCE implementations come with wrappers for I/O-related system calls. The calls are wrapped to prevent one thread from blocking the entire process, even if other threads can be run. These are not provided by Cray Research because the threads implementation uses multiple kernel threads to support the user-level threads. User-level threads can be blocked on any system call without the entire process being blocked. Wrappers are provided for libc routines that are not thread-safe, including, for example, printf(3) and fopen(3). For a complete list of these routines, see the cma_stdio.h include file; this file is included if pthread.h is included. Users must include pthread.h in all code within a DCE process. This requirement will be eliminated in future versions of the UNICOS system, as thread-safe libraries are provided. 4.3.2 pthread_create(3) routine +++++++++++++++++++++++++++++++ The Cray Research DCE threads implementation uses multitasking routines in libu. Because of this, certain limitations apply. Most users of RPC, directory, and security services do not call the DCE threads interface directly. DCE threads are handled transparently by these services. If a user is using the DCE threads interface directly, the pthread_create routine is used to create new threads (see the pthread_create(3) man page or other DCE documentation for more information). Separate threads in a user process execute independently and concurrently. These threads are called user threads. The pthread_create call can also create a separate kernel thread of execution. Kernel threads are visible when you use the ps(1) command, and they appear as separate processes even though they are within the same process. These kernel threads are called members of the multitasking group. In the UNICOS operating system, a user process with multiple threads can sit on top of one or more kernel threads; that is, if a process has N kernel threads, N of its user space threads can be in system calls simultaneously. Cray Research's DCE implementation is limited to 4159 threads active at one time in one UNICOS process. Initially, a process has two threads: the main thread and the null thread (used internally to manage timers). After the 4159th thread is created, additional calls can be issued only after other threads terminate, either because the start routine defined by the thread completes or because the thread exits or is canceled. No more than 4159 threads can execute simultaneously. If you try to create more than 4159 threads, the program receives an Error Exit (signal 7). The global integer variable Max_cray_threads is defined within DCE and allows a user to control the number of kernel threads relative to the number of user threads. The Cray Research DCE threads implementation has an M-to-N relationship between user threads and kernel threads, where M represents user threads and N represents kernel threads. M cannot be larger than 4159; N cannot be larger than 4159 and must be at least 2 (one for the null thread and one for the initial thread). By default, Max_cray_threads is set to 4159. If a user wants fewer kernel threads than user threads, you can set Max_cray_threads to the value of kernel threads desired. Whenever pthread_create is called, the number of kernel threads is compared to Max_cray_threads. If the number of kernel threads is less than Max_cray_threads, another kernel thread is created. If not, the new user thread shares the existing kernel threads with all of the other user threads (including the initial thread and the null thread). You can block user threads without blocking the entire process by using UNICOS system calls such as select(2) and read(2). However, if N user threads are blocked in UNICOS system calls, the entire process could be blocked, even if some user threads can be run. This can occur only if Max_cray_threads is set to a value smaller than M (that is, the number of calls to pthread_create plus 2, representing one for the initial thread and one for the null thread). Because the null thread is almost always blocked on a select system call, when you tune Max_cray_threads, 1 should be added to the number of threads that the user expects to block in UNICOS system calls. On Cray Research systems, wrappers are not used for I/O blocking routines. A read on a pipe or a select could block a kernel thread. The safest thing is to leave Max_cray_threads set to the default value. However, users can optimize their resource usage by setting Max_cray_threads to the maximum number of threads that can be blocked on a UNICOS system call, plus 1 for the null thread. Remember to count the initial thread also if it can be blocked on a system call. 4.3.3 fork(2) and exec(2) system calls ++++++++++++++++++++++++++++++++++++++ If a UNICOS user executes a fork, fork(2) creates a new process with one user and one kernel thread. This is independent of the number of threads in the forking process. The new process contains a copy of the DCE library with the same state as the forking process. This is also true of the underlying support library for the DCE threads, the Cray Research multitasking library. The multitasking library does not work across the fork in the subprocess. The only functionality that is supported in the subprocess after the fork is a call to one of the exec(2) system calls. There must not be a call to any DCE routine between the start of the subprocess and the call to exec. The daemonizing function (usually done by forking, exiting in the parent, and continuing in the child) does not work. Cray Research modified dced(8), cdsadv (8), and cdsclerk(8) to remove the fork. To daemonize, a DCE process should use setsid(2) and be manually placed in the background. 4.3.4 Output from the ps(1) command +++++++++++++++++++++++++++++++++++ On Cray Research systems, the ps(1) command shows several entries for a DCE program. Each kernel thread appears as a different process. 4.3.5 Scheduling threads ++++++++++++++++++++++++ All threads have the same scheduler, scheduling policy, and priority. The pthread_attr_getinheritsched(3) routine returns the value set in the attributes structure by the pthread_attr_setinheritsched(3) routine. The scheduler will always be the same; more information on schedulers follows. The pthread_attr_getprio(3) routine always returns the midpoint between PRI_OTHER_MIN and PRI_OTHER_MAX. If the pthread_attr_setprio(3) routine is called with any other value, it fails with an ENOSYS message or an unimplemented exception, because no other priorities are implemented. The pthread_attr_getsched(3) routine always returns SCHED_OTHER. If the pthread_attr_setsched(3) routine is called with any other value, it fails with an ENOSYS message or an unimplemented exception, because no other schedulers are implemented. The scheduler is truly preemptive; all threads will get a chance to run if they can run. 4.3.6 Canceling threads +++++++++++++++++++++++ On Cray Research systems, the pthread_cancel(3) routine works only in a synchronous manner. The scheduler does not check to see if a thread is canceled. To receive a cancel request, the target thread must either be blocked on some event (for example, a condition variable or signal wait) or call the test cancel routine. If a thread is looping while doing some work, it cannot be canceled by using pthread_cancel unless the loop calls or is blocked in one of the following pthread routines: o pthread_testcancel(3) o pthread_cond_wait(3) o pthread_cond_timedwait(3) o sigwait(3) (that is, cma_sigwait(3) with wrappers) If a thread is blocked in any UNICOS system call (for example, the select(2) system call), it cannot be canceled by using the pthread_cancel routine. A user can prevent the reception of a cancel during the condition wait, sigwait(3), and pthread_testcancel(3) calls by using the pthread_setcancel(3) routine. The pthread_setasynccancel(3) routine has no impact on canceling a thread; asynchronous cancels are not implemented on Cray Research systems. 4.3.7 getpid(2) system call +++++++++++++++++++++++++++ The getpid(2) system call returns different values, even in the same user threads. The scheduler multiplexes user threads on top of kernel threads. Each kernel thread has a unique process identifier. The user thread can be preempted and moved to another kernel thread between two calls to getpid. 4.3.8 sleep(3) routine ++++++++++++++++++++++ The sleep(3) routine should not be used in a Distributed Computing Environment. Use pthread_delay_np(3) instead. See the discussion in the following section for an explanation of why sleep could fail. The sleep routine uses the SIGALRM signal to wake up. 4.3.9 Signals +++++++++++++ Users should avoid using signals whenever possible when writing DCE applications. DCE, POSIX threads, and different versions of the UNICOS system all have different signal models. For more information, refer to the Application Development Guide - Core Components. In DCE applications, signal handlers (called when a signal arrives) exist per thread, and signal masks (used to disable and enable signals) exist per process. In the latest version of POSIX, signal handlers exist per process, and signal masks exist per thread. In UNICOS 8.0, the signal masks were changed to be per user thread instead of per kernel thread. Signal handlers are being changed to be per process. A single user thread can run on several different kernel threads during its lifetime. This causes the signal handlers and mask of an executing thread to change as the thread is moved between different kernel threads. In the Cray Research DCE implementation, exceptions that are not caught with TRY and CATCH macros cause an abort. Other DCE implementations simply terminate the thread that has generated the exception. Without the abort, program debugging can be very difficult. Signals also have impacts on running system calls. A signal can interrupt a system call. In some cases, a system call waits for an asynchronous signal. For example, the sleep(3) routine issues the pause(2) system call after registering to receive a signal at a later time. The signal interrupts the system call so that the thread and process can continue executing after the time has expired. Depending on the signal model, the signal may not wake up the system call if the signal arrives at the wrong kernel thread. For example, in the case of the sleep routine, if a thread registers to receive the wake-up signal and gets moved to another kernel thread before calling pause, the signal will not wake up the pause. Many system calls sleep in the kernel, waiting for some event. If a signal arrives, the system call might fail and return an error (EINTR) indicating that the system call was interrupted. This might occur if the signal arrives at the wrong kernel thread. With UNICOS 8.0 and later versions, signal handlers apply to each kernel thread. In DCE threads, a wrapper is used to map sigaction(2) to cma_sigaction. The cma_sigaction routine implements signal handlers per thread by catching most signals within DCE and calling the appropriate signal handlers. The functionality of sigwait(3) is also implemented. Wrappers are not provided for the signal(2) system call, which changes the DCE internal signal handlers. These handlers implement sigwait(3), generate exceptions, and implement DCE signal semantics. 4.3.10 pthread_yield(3) routine +++++++++++++++++++++++++++++++ The Cray Research threads scheduler is truly preemptive. All threads run at the same priority. Therefore, there is no need to explicitly yield so that another thread can run. If there are several threads that can run, they will all compete at the same priority to run on the available kernel threads. The pthread_yield(3) routine is not supported on Cray Research systems. 4.3.11 Thread stack size ++++++++++++++++++++++++ Cray Research supports variable-length stacks for all threads, independent of the use of the pthread_attr_getstacksize(3) and pthread_attr_setstacksize(3) routines. If more space is needed for a stack, the space is allocated transparently. The pthread_attr_getstacksize routine returns the octal number 04000 if no stack size has been previously set. In other words, the default stack size in an attribute structure is 04000. Users are allowed to change and retrieve the stack size for an attribute structure. However, this has no impact on the stack of a given thread created with that structure. 4.4 Remote Procedure Calls (RPCs) ================================= The Cray DCE Client Services 1.1 release might require the creation of a network_ifs(5) file to support broadcast RPCs. Broadcast RPC is required for correct functioning of the DCE directory service. For more information, see the network_ifs(5) man page. 4.5 Time ======== The distributed time service daemon (dtsd) is not provided on Cray Research systems. You must either update the time manually or run the network time protocol (NTP) on all machines, including Cray Research systems. The time application programming interface (API) is provided and supported. The API call to the system time maps to gettimeofday(2), rather than calling the time server. 4.6 Directory services ====================== The following subsections describe differences between the Cray Research implementation and the Open Software Foundation (OSF) definition in the area of directory services. 4.6.1 X.500 not supported +++++++++++++++++++++++++ All X.500 functionality has been removed from the Cray Research DCE implementation, including administration tools, daemons, and X.500-specific APIs. Calls into XDS or XOM libraries using X.500 naming conventions will always return a service error. 4.6.2 Cell directory service daemon not supported +++++++++++++++++++++++++++++++++++++++++++++++++ The cell directory service (CDS) daemon (cdsd) is not supported in the Cray Research DCE implementation. The CDS daemon for the local cell is assumed to reside on another platform. 4.6.3 cdsbrowser utility not supported ++++++++++++++++++++++++++++++++++++++ The cdsbrowser utility is not supported on Cray Research systems. Use cdscp(8) or dcecp(8) instead. 4.6.4 Shared cache ++++++++++++++++++ Because shared memory is not supported on most Cray Research systems, the clerk and the advertiser have been combined into one process. When a request for a clerk is received from the CDS library, the advertiser performs a pthread_create(3) process (instead of a fork(2) and exec(2), as in the OSF code). The cache is allocated by the use of the malloc(3) routine and made accessible to all instances of clerks and the advertiser as if it were in shared memory. The name of the combined clerk-advertiser is cdsadv(8). It was given the same daemon name as the original advertiser so that the configuration, start-up, and shut-down scripts would work under both the new and the old clerk and advertiser configurations. 4.6.5 dump clerk cache(8) command +++++++++++++++++++++++++++++++++ The dump clerk cache(8) command in the cdscp utility assumes shared memory is in place. It attempts to connect directly to the shared cache rather than sending the request to the cdsclerk to get the cache information. Because the Cray Research CDS implementation does not use shared memory, the dump clerk cache command always returns a cache version error. 4.6.6 disable clerk(8) command ++++++++++++++++++++++++++++++ Because the clerk and advertiser are combined into one process, the disable clerk(8) command in the cdscp utility shuts down the clerk and the advertiser. 4.7 Security ============ Cray Research security implementation is very close to that described in the OSF documentation. Cray Research supports only the client side of security. The server must reside on a machine other than a Cray Research system. Commands that modify the registry, such as rgy_edit(8), can be used on Cray Research systems, but the registry and the secd utility cannot reside on the Cray Research system. For this reason, the sec_create_db(8) and sec_salvage_db(8) commands are not supported on Cray Research systems. The passwd_import(8) and passwd_export(8) commands are not supported. The Kerberos version 5 commands are supported. Their names are the same as the names of the commands in Kerberos version 4: kinit(1), kdestroy(1), and klist(1). The DCE installation script installs these commands in /opt/dcelocal/bin. If users want to use the version 5 commands, they must place the /opt/dcelocal/bin directory in their path before /usr/bin. 4.8 DFS/NFS Secure Gateway ========================== Cray Research does not support remote authentication to DCE from NFS clients. This means that users must perform local authentication either by logging in directly to the gateway server machine or by using telnet(1) or rlogin(1) remotely to establish their DCE identity. The dfsgwd(8), dfs_login(1), and dfs_logout(1) commands are not supported. 4.9 Online man page names ========================= Because of the way the Cray Research man(1) command functions, the 4-character and 5-character section references to the DCE man page names (such as (3thr)) are not supported in the online version of the man pages. Except where collisions with other man page names would occur, the suffixes are reduced to a single number. For example, pthread_create(3thr) is named pthread_create(3) in the online man page. The following command line displays the pthread_create man page: man pthread_create Some of the introductory man pages would collide if the alphabetic characters were dropped from the suffix. For example, intro(3rpc) and intro(3sec) would both be intro(3). To avoid such collisions, the alphabetic characters in the suffix have been moved out of the suffix and into the man page name itself. Thus, intro(3rpc) becomes rpc_intro(3), and intro(3sec) becomes sec_intro(3). You must include the sec_ characters in the man command operand to see the man page that introduces the DCE security service routines, as follows: man sec_intro 4.10 UNICOS file system features ================================ The UNICOS NC1 file system supports a number of special features, including quotas, data migration, access control lists, and checkpoint restart. These features are supported by DCE DFS. Future releases of DCE DFS will provide further integration with these UNICOS features. o Quotas DCE DFS enforces quotas on a file system. If a user exceeds quota on a file system, the error is passed back to the program running on the client. The error may occur later in the user's process (for example, upon closing a file rather than on return from a write call). If you want DFS to export a file system that enforces quotas, you must ensure that the quota file is on a different file system that is not exported through DFS. To do this, use the 'quota+' option and refer to the mount(8) and fstab(5) man pages. Placing the quota file within the exported file system may prevent the file system from unmounting. o Data migration You can export a file system running data migration by using DCE DFS. Attempting to access migrated files blocks the accessing process until the files are unmigrated; it is impossible for the client to break out of the system call. It is possible for all client threads on a machine to be blocked while waiting for data migration. Therefore, it is not recommended that DCE DFS be used in combination with a migrated file system with a long turnaround time. The following variables specified in the /etc/config/dmf_config file should not be placed on a DFS exported file system: HOME_DIR JOURNAL_DIR MOVE_FS SPOOL_DIR TMP_DIR o UNICOS access control lists UNICOS access control lists on an exported file system will be honored, but you cannot view or manipulate them by using DCE DFS. o Interworking with NFS It is possible to have a file system accessed by both DCE DFS and the network file system (NFS) at the same time. In this case, NFS accesses the file system as if it were a local access. Tokens are still used to control contention on file access. o Symbolic links DFS treats a symbolic link with no execute bits as a mount point. If you turn off execute modes from a symbolic link to a file (UNICOS allows you to do this), and you try to follow that link (for example, by using a cat sym.link.file command), you might receive the following message: No such file or directory You will also get the following message on the system console: dfs: dce errors (code 676372487) from the fileset location server 4.11 DCE on a PAL-only system ============================= One of the requirements of running an application on a PAL-only system is that you assign the correct set of privileges to your DCE executable files, especially if you run with active mandatory access control (MAC) labels. To assign privileges, you can use the setpal(8) and setprivs(8) commands, or you can create a file to run with the privcmd(8) command. This section describes the following aspects of programming on a PAL-only system: o RPC calls o Using cell directory services o Accessing credentials for multiple users 4.11.1 RPC calls ++++++++++++++++ A DCE cell can contain hosts other than Cray Research hosts that cannot run Common IP Security Option (CIPSO), which means that packets arriving at a Cray Research system from these hosts will not contain a CIPSO label. As long as outbound communication from the other system is not restricted by the network access list (NAL) on the Cray Research system, the packet arrives with a security level of 0 and null compartments. If a user has restricted label range, as the user's packets leave the machine are labeled according to the NAL restrictions. If these packets are leaving the machine destined for a machine without NAL, the packet arrives at the destination machine with security level 0 and null compartments. Reply packets are returned as level 0, null compartments range. Because of the label difference, these packets are not given to the socket associated with the user's process. The RPC runtime library relabels sockets that it creates so that their minimum label is the lowest configured on the system. This relabeling requires PRIV_MAC_DOWNGRADE and PRIV_MAC_UPGRADE privileges. The active label on the socket and its maximum label are not changed. An example of this use involves the klist command, which makes RPC calls to the DCE security server. This server is not on a Cray Research system and would not have a restricted NAL. A user with a restricted label range cannot use klist without these privileges. The klist process sends messages to the security server that is running on a machine other than the Cray Research system. These messages are sent out without a label. The RPC code adds the PRIV_MAC_DOWNGRADE and PRIV_MAC_UPGRADE privileges to the process, relabels the socket, and then removes the privileges after setting the socket options. An example of the required privileges in a privdb file is as follows: file = { name = /application; allowed = [PRIV_NULL]; forced = [PRIV_MAC_UPGRADE, PRIV_MAC_DOWNGRADE]; set_effective = [PRIV_NULL]; PAL = [ other: PRIV_MAC_UPGRADE, PRIV_MAC_DOWNGRADE : TEXT_NULL; ]; }; 4.11.2 Using cell directory services ++++++++++++++++++++++++++++++++++++ Communication between DCE applications and cell directory services is through named pipes. This code is hidden at the bottom of the cell directory service (CDS) runtime library, which is part of the libdce library. When first contacting CDS, the application opens and writes to a pipe that belongs to the CDS daemon. The daemon then creates a special pipe for that user (owned by the user) and writes the name of this pipe back to the application. The application then opens this second pipe and uses it for its CDS queries. Because there is only one pipe for making initial contact with CDS, users with any active label range must be able to use it. In addition, the CDS interface does not pass the user's label range to the CDS daemon, so the user-specific pipes are not labeled. The CDS library code overcomes this labeling problem by obtaining PRIV_MAC_READ and PRIV_MAC_WRITE privileges around communication with CDS. Therefore, any CDS application that is accessible to users with an active label requires these privileges. An example extract from the required privdb file is as follows: file = { name = /application; allowed = [PRIV_NULL]; forced = [PRIV_MAC_READ, PRIV_MAC_WRITE]; set_effective = [PRIV_NULL]; PAL = [ other: PRIV_MAC_READ, PRIV_MAC_WRITE : TEXT_NULL; ]; }; 4.11.3 Accessing credentials for multiple users +++++++++++++++++++++++++++++++++++++++++++++++ DCE credentials are stored in an MLS multilevel directory. A set of credentials is associated with a specific label and is not visible from any other label. Thus, if a user logs in, runs dce_login, and then does a setulvl(1) or setucmp(1) operation, the credentials are not visible to the DCE security library code. However, the library code is coded so that it can find credentials at differing security labels, given the correct set of privileges. This is typically only required for DCE daemon processes such as dfsbind. PRIV_MAC_READ and PRIV_MAC_WRITE privileges are required to find credentials with different labels. Daemons such as dfsbind also require PRIV_DAC_OVERRIDE privilege to be able to read multiple users' credentials. In this case, the set_effective part of the privdb entry must also have the required privileges. Chapter 5. Installation and Configuration ***************************************** This chapter provides installation and configuration procedures for the Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 release. 5.1 Overview ============ The following sections outline the DCE/DFS release and make note of preinstallation requirements. 5.1.1 Media files +++++++++++++++++ The Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 installation media contains the binary distribution of this release for your specific Cray Research platform. The media contains the following items: o Load script o Header files, libraries, and binary files o Man pages The POSIX shell load script, SCRIPT, assumes that you have loaded the DCE cpio files into a single directory, either manually or by using the UNICOS Installation/Configuration Menu System (the menu system). SCRIPT asks you where to place the loaded files and then performs the DCE installation. More information on DCE installation and the installation script is provided in Section 5.2. 5.1.2 Preinstallation notes +++++++++++++++++++++++++++ This section presents information of which you should be aware before you install Cray DCE Client Services 1.1: o If you are upgrading from a previous release of DCE/DFS, or reinstalling the software on a system, you must first stop the current DCE core services before installing the new product. Do this by becoming a super user and issuing the following command: /opt/dcelocal/etc/dce.clean Executing this command stops the core services and makes the DFS client and DFS server inoperable on your system. You do not need to specifically stop DFS (by rebooting) at this time, stopping the DCE core services will, in effect, stop all DFS operations. o You are required to have super-user permission to install Cray DCE Client Services 1.1 or Cray DCE DFS Server 1.1, either manually or through the menu system. o Previously installed DCE files are overwritten. o Cray DCE Client Services 1.1 is installed relative to directory /. Most of the components are then located in the following directory: /opt/dcelocal If you want to save space in your root file system and you do not have a /opt file system, you can link /opt to an alternative file system. o Ensure that FLEXlm licensing is set up according to the Cray Distribution Center instructions, which were sent with the DCE DFS package. If you have valid keys from a previous release, those keys are still valid for this product. o Installation from the menu system automatically releases all temporary files. If you are running the installation script manually, you will need to delete the cpio file by hand when the installation is complete. 5.1.3 File space requirements +++++++++++++++++++++++++++++ The following file space is necessary to complete the installation of the Cray DCE Client Services 1.1. Table 1. File space | File | Description | Space in Mbytes | ========================================================================== | /tmp | Temporary space used by | 55 | | | the menu system | | +------------------------------------------------------------------------+ | /usr/src/net/dce | Load location | 160 | +------------------------------------------------------------------------+ | /opt/dcelocal | config/run/install loc | 160 | | | ation | | +------------------------------------------------------------------------+ An additional 20 to 40 Mbytes (depending upon DFS usage) is used in /opt as the product runs. The number of inodes required for Cray DCE Client Services/Cray DCE DFS Server is as follows: Server Required inodes /tmp 10 /usr/src/net/dce 3000 /opt/dcelocal 1700 5.2 Loading the software from media =================================== You can install the Cray DCE Client Services 1.1 release as an asynchronous product by using the menu system. This section describes the procedure for starting the menu system and selecting and loading the tape devices. You must be a super user to start the menu system, which is accomplished by entering the following commands: cd /etc/install ./install 5.2.1 Selecting the load device +++++++++++++++++++++++++++++++ This section describes the procedure for selecting the device from which Cray DCE Client Services 1.1 will be loaded. Position the menu prompt at the Release media management menu selection on the UNICOS Installation/Configuration Menu System menu ( the main menu), as shown in the following screen, and press RETURN. UNICOS Installation/Configuration Menu System M-> Release media management ==> Configure system ==> Build/Install system ==> Utilities ==> Preferences ==> The UNICOS Release Media Management menu appears, as shown in the following screen. To specify the load device appropriate for the medium on which the software was delivered, position the menu prompt at the Define load device menu selection and press RETURN. UNICOS Release Media Management M-> Define load device ==> . . . Load asynchronous product ... The Define Load Device menu appears, as in the following example: Define Load Device Customize load device parameters ==> S-> Media type J90_EL Physical load device Tape Device Remote or local? local Remote host name Package images directory name Optional package image name CD-ROM mount point Verbose load (cpio -v option) NO Location of archive directory /usr/src/.ARCHIVE Continue load upon error (ldproto -I) NO Reload only damaged/missing files (-R) NO Verify/list only, do not load package (-n ) NO Miscellaneous load options -A Position the menu prompt at the Media type selection and select the value appropriate for your site. Your choice sets the Physical load device selection to an appropriate default value and affects the selections that appear on the rest of the Define Load Device menu. Additionally, depending on your choices for the required selections, you may also be required to set values for the following option selections: o Media type o Remote host name o Package images directory name o Optional package image name Not all options have a set value; that is, the field may be blank, depending on the choices you made for Media type, Physical load device, and Remote or local selections. If an option is not valid at your site, the N/A (not available) notation is displayed next to that option when it is selected. Table 2 summarizes valid combinations of values for Media type and Physical load device selections. In this table, Online tape refers to a tape loaded with the tpmnt(1) command and the Cray Research tape daemon. Tape device refers to any other tape device activated by having the dd(1) command access a node entry in the /dev directory. Table 2. Valid Media type and Physical load device combinations ****************************************** See hardcopy for Table 2. ****************************************** 5.2.2 Specifying media type for CRAY J90 and CRAY Y-MP EL systems +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you are loading software on a CRAY J90 or CRAY Y-MP EL system while running the tape daemon, device names are mapped to media types as shown in the following list: Device name Media type /dev/tape/rpq01 QIC-150 rectangular cartridge tapes (CRAY Y-MP EL systems only) /dev/tape/rpd03 Digital tape device DAT (CRAY J90 and CRAY Y-MP EL systems) If loading software on a CRAY J90 or CRAY Y-MP EL system without running the tape daemon, you must select J90_EL for the Media type. After you select J90_EL as the Media type, verify that the J90_EL device name in the Customize load device parameters menu is set to the appropriate device for your system. 5.2.3 Specifying a remote host name +++++++++++++++++++++++++++++++++++ If the specified Physical load device is on a remote host, you must set the Remote or local? selection to remote and then set the Remote host name selection to the name of the remote host. If you specify remote for the Remote or local? option, the user specified in the Remote login ID entry of the Customize Load Device Parameters menu must have suitable authentication (for example, a correct .rhosts entry) on the remote host specified in the Remote host name menu item. 5.2.4 Loading the software ++++++++++++++++++++++++++ After selecting and, if necessary, customizing the load device parameters, insert the CD-ROM or mount the release tape on the selected drive. Return to the UNICOS Release Media Management menu by pressing e twice. In the UNICOS Release Media Management menu, position the menu prompt next to the Load asynchronous product selection, as shown in the following screen, and press RETURN. Release Media Management Define load device ==> . . . A-> Load asynchronous product ... Depending on the selected method of loading or load medium, a message such as the following appears on the screen: Load Manager: Loading Async from Tape Device (Root - / ) Mount ASYNC0 tape on the local J90_EL style tape drive, then press return: Verify that the release medium is mounted on the chosen device and press RETURN. 5.2.5 Selecting packages to load ++++++++++++++++++++++++++++++++ If the package you loaded contains multiple products, the following screen appears: Distribution Package M-> Distribution Package Contents ==> Load selected products... To view a list of individual products in a package, position the M-> menu prompt at the Distribution Package Contents menu item and press RETURN. A form menu describing the package contents is displayed as shown in the following example: Distribution Package Contents Load ? [Description] [Vol] [Pos] [Directory] ------ -------------- ----- ----- ----------- E-> YES Package 1 0 0 pkgdir0 YES Package 2 0 1 pkgdir1 YES Package 3 0 2 pkgdir2 . . . YES Package N 0 n pkgdir(n) Keys: ^? Commands H Help Q Quit V ViewDoc W WhereAmI The default is to load all packages when the Load selected products action item of the Distribution Package menu is invoked. Note: If your screen is not wide enough to display the full form menu, an > or < symbol appears in the direction of the undisplayed information. Use the > and the < keys to scroll the screen from side to side. 5.2.6 Deferring loading +++++++++++++++++++++++ To defer loading of a package, position the menu prompt next to the package you do not want to load, as shown in the following example, and press RETURN. Distribution Package Contents Load ? [Description] [Vol] [Pos] [Directory] ------ -------------- ----- ----- ----------- E-> YES Package 1 0 0 pkgdir0 A menu describing the contents of the selected package appears. Position the menu prompt next to the Load Subpackage? menu item and select the value NO, as shown in the following example: Distribution Package Contents S-> Load Subpackage ? NO Description [read only] Package 1 Volume [read only] 0 Position [read only] 0 Directory [read only] pkgdir0 Press E to return to the previous menu. Repeat this step for any package you do not want to load. After you have selected those packages that will not be loaded, pressE to update the form file. To complete the update to the form file, answer y at the prompt, as shown in the following example: Distribution Package Contents . . Do you want to update form file? (y/n): y The form file will now be updated, and you will be returned to the Distribution Package menu. 5.2.7 Initiating loading ++++++++++++++++++++++++ To start loading of the selected products, position the menu prompt next to the Load selected products action item and press RETURN, as shown in the following screen: Distribution Package Distribution Package Contents ==> A-> Load selected products... Selected products are loaded in the order of their position on the medium (from first to last). As each product is loaded, the installation script for that product is invoked. 5.2.8 Finishing the load ++++++++++++++++++++++++ At this point, the data has been read from tape into a temporary location. The final step in loading is to copy the data into its permanent load tree location on the system by invoking the SCRIPT script. If you are doing this installation from the menu system, this script is run for you automatically following the load from tape. If not, you can invoke the script by entering the following command: sh ./SCRIPT The script prompts for information required to load the product into its permanent load location, as follows: This script must update kernel files for systems running UNICOS 9.0.2 or any version of UNICOS 9.1 (9.1, 9.1.0.1, 9.1.1 ...). Is your UNICOS release level either 9.0.2 or 9.1*? [y] ? y This question is asked to verify the level of UNICOS that is running on your system. Based on the operating system level given by the uname -r command, the installation script attempts to determine if kernel files should be loaded. If the operating system level is 9.0.2 or any version of 9.1, the default answer is [y] (as shown in the example). Otherwise, the answer is displayed as [n]. By answering y to this question, you will be installing new DFS kernel modules into your kernel build area for the operating system and for the crash(8) command. A prompt is issued for this location later in this script. If you are running UNICOS 9.0.2 or any version of UNICOS 9.1, enter y. If you are not running either of these levels of UNICOS, enter n. In this example, y was entered. The script next prompts for several directory locations, as follows: Enter the permanent binary load tree for the user components [default /usr/src/net/dce] > This prompt is asking where to place the data in the permanent binary load tree. This is the location from which the final product installation is done. So that you can accept mods later or perform a quick reinstallation in case of data corruption in the installation, you should retain this load tree even after installation has completed. At this prompt, either enter the location at which you wish to load the files or press RETURN to accept the default value shown in brackets (/usr/src/net/dce). For this example, RETURN was pressed. If you answered y to indicate that you are running UNICOS 9.0.2 or any version of 9.1, the script issues the following prompt: Enter the permanent binary load tree for the kernel components [default /usr/src/uts] > This prompt is asking for the location of your kernel build area. Either enter the location at which you wish to load the files or press RETURN to accept the default value shown in brackets (/usr/src/uts). If files will be overwritten by this load process, you will receive the following prompt: Files currently exist in one or more of the load directories. If you wish to save a pre-load copy of these directories, enter the directory name of a location to save the files. To not save these files enter [RETURN]. > /tmp/pre-dce-install In the preceding example, the directory name, /tmp/pre-dce-install, was entered at the user prompt to save a version of these files before they were overwritten with the load of the DCE/DFS product. If it is not necessary to save the files, press RETURN to continue the load without saving the files. You will then see a prompt similar to the following: The Installation process is now ready to start. The permanent binary load tree for the user components will be placed in /usr/src/net/dce The permanent binary load tree for the kernel components will be placed in /usr/src/uts A backup of the binary load tree will be placed in /tmp/pre-dce-install Do you wish to proceed with loading DCE 1.1 [y] ? y If you are certain of the choices made for locations for the load, you can enter y for yes and press RETURN. The load will then complete. To abort the loading of files, enter n for no. After all files have been loaded, the installation tool displays the following message: Done loading Async To return to the main menu, press RETURN. 5.3 Installing DCE DFS client software ====================================== After you have successfully loaded the files, you must install them on the system. If you have just completed loading the tape, press e once to return to the main menu. From the main menu, position the menu prompt at the Build/Install system menu selection, as shown on the following screen, and press RETURN: UNICOS Installation/Configuration Menu System Release media management ==> Configure system ==> M-> Build/Install system ==> Utilities ==> Preferences ==> The Build/Install System menu is displayed, as follows: Build/Install System Build Options ==> /usr/src reconfiguration ==> Build action to take install Build object all objects Components to build specific component Major components selection ==> Specific component to build net/dce A-> Do the build ... Restart the build ==> Review last build error summary Escape to a chroot shell ... To set up the menu, perform the following steps: Procedure 1: +++++++++++++ 1. Position the menu prompt at Build action to take and select install. This selection builds and installs the entire product. 2. Position the menu prompt at Build object and select all objects. This specifies that all DCE objects are to be linked. Do not select any other options at this time, or the linking process will not be complete. 3. Position the menu prompt at Components to build and select specific component. This selection enables the install command to build the DCE product. 4. Position the menu prompt at Specific component to build and select net/dce. This selects the DCE product as the specific component to build. 5. Position the menu prompt at Do the build and press RETURN. The menu system links DCE according to the selections set in the rest of this menu. The product is linked and the output is displayed as each component is processed. The linking process has to touch several files and may take some time to complete, depending on how busy your machine is. After the linking is complete, the files are installed into /opt/dcelocal on your system. 5.4 Configuring, building, and installing the kernel ==================================================== The following steps must be taken to include Cray DCE DFS in the UNICOS operating system. They are necessary for both the DFS client and server, and must be executed prior to running the Cray DCE DFS server configuration or the Cray DCE DFS client configuration. If you are not running UNICOS 9.0.2 or any version of UNICOS 9.1, and if DFS has already been configured into the kernel, skip to Section 5.5. Similarly, if you do not want to run the DFS client or server, skip to Section 5.5. You must be the super user to start the menu system, which is accomplished by entering the following commands: cd /etc/install ./install 5.4.1 Configuring the DFS kernel ++++++++++++++++++++++++++++++++ To configure the kernel for DFS, you must perform the following steps: 1. Turn on DFS in the kernel build 2. Alter the kernel definitions for DFS The following sections describe how to perform these steps. 5.4.1.1 Turning on DFS in the kernel build ------------------------------------------ You must turn on the DFS component in the build by navigating in the menu system and finding the DFS switch. To do this, go to the UNICOS Installation/Configuration Menu System menu, and select Configure system -> Major software configuration . A large menu is displayed, a subset of which appears in the following example. Major Software Configuration Source or binary system? source Cray machine system name sn9999 Cray machine node name morgan . . . DCE Distributed File Service (DFS) on . . . A-> Activate the major configuration... Set the DCE Distributed File Service (DFS) parameter on by entering on, as shown. Activate the configuration by moving the menu prompt to Activate the major configuration, as shown, and pressing RETURN. 5.4.1.2 Altering kernel definitions for DFS ------------------------------------------- You might need to modify certain kernel parameters for the DFS kernel components. This section describes the kernel parameters and how they might need to be changed to run DFS. You can change the parameters in one of two ways: by using the menu system or by maintaining the files by hand. Because the parameter files must be maintained in a consistent manner, you must determine which method is used on your system before you modify the parameters. You can find detailed information on how to modify the kernel parameters in the UNICOS Networking Facilities Administrator's Guide, publication SG-2304. If your site uses the menu system, you can find the parameters in the following menus: Configure system -> Kernel configuration -> Table size parameters Configure system -> Kernel configuration -> Network parameters Because the parameter file on the IOS or operator workstation (OWS) overrides values built into the kernel, after you activate your changes from the menu system, you must transfer the parameter file to the IOS or the OWS. If you are modifying the configuration files by hand (not using the menu system), and the parameter file has been modified, you must still transfer it to the IOS or OWS. The following table describes the parameters that you can modify to support DFS: Table 3. Menu system parameters ***************************************** See hardcopy for Table 3. ***************************************** 5.4.2 Building the DFS kernel +++++++++++++++++++++++++++++ Start the build of the kernel by positioning the menu prompt at the Build/Install system option on the UNICOS Installation/Configuration Menu System menu and pressing RETURN: UNICOS Installation/Configuration Menu System Release media management ==> Configure system ==> M-> Build/Install system ==> Utilities ==> Preferences ==> The Build/Install System menu is then displayed, as follows: Build/Install System /usr/src reconfiguration files ==> Build action to take install Build object all objects S-> Components to build specific components Major components selection ==> Specific component to build uts Do the build in batch NO NQS submission options ==> Do the build... Restart the build ==> Review last build summary... Escape to a chroot shell... Start the build of the kernel by moving the prompt to the Do the Build selection, as shown in the next example, and pressing RETURN. Build/Install System /usr/src reconfiguration files ==> Build action to tak install Build object all objects Components to build specific components Major components selection ==> Specific component to build uts Do the build in batch NO NQS submission options ==> A-> Do the build... Restart the build ==> Review last build summary... Escape to a chroot shell... The kernel is then built. The new DFS-activated kernel is in the /usr/src/uts/cf.xxxx file, where xxxx is the serial number of your system. The new kernel is installed by using the exdf(8) command or the menu system. Refer to the UNICOS Networking Facilities Administrator's Guide, publication SG-2304, for details on this procedure. 5.5 Initial configuration and start-up of DCE client components =============================================================== This section describes the initial configuration and start-up of Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1. Follow the instructions in this section after you have performed the following tasks: o Completed loading the product from media o Installed the product In addition, if you intend to run a DFS client or server you must perform the following tasks: o Configure and build a kernel with DFS. Note: If you are running UNICOS 9.0.2 or any version of 9.1, be sure to build the kernel after installing the Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1 product, to ensure that you have the correct modules. o Install and boot the kernel on the local system. The instructions for performing these tasks are provided in the preceding sections. 5.5.1 Upgrading from a previous DCE/DFS release +++++++++++++++++++++++++++++++++++++++++++++++ A reconfiguration is not necessary if you have a working DCE/DFS configuration from a previous release and are upgrading to Cray DCE Client Services 1.1/Cray DCE DFS Server 1.1. The working configuration you did when you configured the previous release will continue to work with the newly installed software. Complete the tasks outlined at the beginning of this section (load and install the product, and build, install, and boot a kernel), and then restart the product. 5.5.2 Preparing for configuration +++++++++++++++++++++++++++++++++ You will be prompted for several pieces of information to complete the configuration. The following is a list of the information you will need: o The name of the DCE cell you want to join o The password for the cell_admin account (or equivalent administrator account) of the cell you are joining o The name of the main security server host of the cell o The name of the main cell directory service (CDS) server host of the cell Note: The main security server and the CDS server must be running on their respective hosts. 5.5.3 Invoking dce_config for configuration and start-up ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Once your kernel is booted, start the dce_config script. (You must be a super user to start the dce_config script.) Start the configuration process by entering the following command: /opt/dcelocal/etc/dce_config 5.5.4 Navigating the DCE menu +++++++++++++++++++++++++++++ This section shows a sample configuration of the DCE product and demonstrates dce_config menu navigation. The menus of the dce_config script guide you through the configuration and start-up of DCE/DFS. Selections you make determine how the product is configured. The types of selections are action and parameter. Action selections indicate which action you want the dce_config script to take or which menu you wish to view. The description of the action tells you what each action will do when selected. If you select an action that requires that specific parameters be set, the script prompts you for those required parameters. Parameter selections allow you to enter or change parameters before the configuration is run. The menu selection identifies the parameter and its current value. When you invoke a parameter selection, the script displays a description of the parameter, a default value, and the current value. After you have entered the new value, the original menu is displayed again. When you invoke the dce_config script, the following main menu is displayed: DCE Main Menu 1. CONFIGURE -configure and start DCE/DFS daemons 2. START -re-start DCE/DFS daemons 3. STOP -stop DCE/DFS daemons 4 UNCONFIGURE -remove a host from CDS and SEC databases 5. REMOVE -stop DCE/DFS daemons and remove data files created by daemons 99. EXIT selection: 1 The CONFIGURE selection configures the product. It starts itself, contacts DCE servers on other hosts, and leaves DCE running after completion of the configuration. The START selection starts DCE running after the product is configured. The product must be properly configured to start. The STOP selection stops DCE. The UNCONFIGURE selection unconfigures this or another host from the cell. The REMOVE selection removes data files created by DCE daemons. It is used to clean up an old configuration. The EXIT selection exits from the configuration script. 5.5.5 DCE core services configuration +++++++++++++++++++++++++++++++++++++ From the DCE Main Menu, select CONFIGURE by entering 1. The script then displays the DCE/DFS Configuration Menu, as follows: DCE/DFS Configuration Menu 1. DCE Client-Core Services 2. DFS Client 3. DFS Server 4. UNICOS/DCE Login Configuration 5. Audit Server 98. Return to previous menu 99. Exit Selection: 1 The DCE Client-Core Services selection configures the DCE client. This configuration must be done before any other options are selected. The DFS Client selection configures the DFS client on the local machine. The DFS Server selection configures the DFS server on the local machine. The UNICOS/DCE Login Configuration selection configures the integrated login and single sign-on features. The Audit Server selection configures the local audit server. The Cray daemons do not use this feature, but it might be of use for those writing their own DCE servers. If the system is not licensed for the client or server, this menu notes that fact next to the menu selection. Start the DCE client configuration by entering 1. The script then displays the following message: Prompting for all main configuration parameters... The script next displays all of the main configuration parameters, asking you to enter values for each. If a default value is available, it is listed. Any value that is displayed in the current value field or enclosed in brackets ([ ]) is the current value. To accept this value unaltered, simply press RETURN. You will have the opportunity to alter these values before running the configuration, so you do not need to worry about mistyping any of the values. The following list provides examples of the parameters the configuration will encounter and includes additional notes for clarity. o The Cell name parameter defines the cell name. Cell name This parameter defines the name of the DCE Cell that this host is joining/has joined. Enter this value without '/...'. Reconfiguration required after changing this parameter. Default value: -none- Current value: -not set- Enter new value: morgan.abc.com 'Cell name' set to 'morgan.abc.com' In this example, the value morgan.abc.com has been entered. If you do not know the cell name or if the cell is not yet established, this configuration will fail. o The Security server host parameter defines the main security server of the cell. Security server host This parameter defines the name of the host that runs the main Security server.The host must be up and running the security server (secd) for the configuration to complete successfully. Default value: -none- Current value: -not set- Enter new value: morgan 'Security server host' set to 'morgan' In this example, the value morgan has been entered, indicating that a host named morgan is the main security server (secd) for the cell morgan.abc.com. o The CDS server host parameter defines the CDS server for the cell. CDS server host This parameter defines the name of the host that runs the main CDS server. The host must be up and running the CDS server (cdsd) for the configuration to complete successfully. Configuration required after changing this parameter. Default value: -none- Current value: morgan Enter new value: 'CDS server host' set to 'morgan' In this example, the script set the CDS server host value to morgan to match the security server host value (as is usually the case). In this example, that value is accepted; that is, RETURN is pressed, and the value morgan is retained. o The Network interface list parameter defines the network interface list. Network interface list This parameter defines the network interface(s) DCE will use in communicating with other hosts. Enter all values on one line separated by a space. The following is the list of active network interfaces for this host as displayed by the netstat(1) command: Name Mtu Network Address Ipkts Ier en0 1496 128.162.101 sn9999 902 0 lo0 65535 127 localhost 8 0 Reconfiguration required after changing this parameter. Default value: en0 lo0 Current value: en0 lo0 Enter new value: Not changing value The script is almost always able to define the value properly on its own. If you want to alter the value in anticipation of adding a new network interface, enter the desired value at the Enter new value prompt. At a minimum, the values must indicate the network interfaces used to get to the CDS server host and the security server host selected in response to earlier parameter questions. In this example, RETURN is pressed to accept the value selected by the script. o The script sets up the remainder of the CDS configuration and displays the CDS server network_if parameter. CDS server network_if This parameter defines the single network interface used to reach the CDS Server host (morgan). The value MUST be a value taken from the list of network interfaces. The following is the list of active network interfaces for this host as displayed by the netstat(1) command: Name Mtu Network Address Ipkts Ie en0 1496 alphanet/24 sn9999 15372 0 lo0 6553 128.162.101 localhost 8 0 The choices of interfaces are: en0 lo0 Restart of product required after changing this parameter. Default value: en0 Current value: en0 Enter new value : Not changing value This parameter indicates the best network interface to use in accessing the CDS server host. The script selects the most active interface as the default for this value. If the host you have defined as the CDS server host cannot be reached through this network interface, you must change this value. In this example, RETURN is pressed to retain the current value. o The MLS Multilevel directories parameter tells DCE whether MLS multilevel directories are in use on the system. MLS Multilevel directories This parameter determines if DCE/DFS should create the security/creds directory using an MLS multilevel directory. If your site is going to run with MLS level and compartments, this variable should be enabled. Default value: off Current value: off Enter new value: Not changing value If you are using MLS multilevel directories, on must be specified as a new value. In this example, RETURN is pressed to select off (the default). o The Cell administrator password parameter indicates that the cell administrator password should be entered. Cell administrator password This parameter is the login password for the cell administrator account for this Cell. This value is used for interaction with the Cell servers. It does not redefine the value of the password. Default value: -none- Current value: -not set- Enter new value: For security reasons, the cell administrator password is not echoed to the screen or placed in the log file as it is typed (see the example). The value is not retained between invocations of dce_config. After displaying all of the DCE client parameters, the script displays the following message, along with a menu of the defined values and options to select for configuration: Completed prompting for all main configuration parameters. DCE Configuration Parameters Menu (on sn9999) 1. Cell name morgan.abc.com 2. Security server host morgan 3. CDS server host morgan 4. Network interface list en0 lo0 5. CDS server network_if en0 6. MLS Multilevel directories off 7. Cell administrator account cell_admin/ -password defined- 90. Run DCE client configuration 98. Return to previous menu 99. Exit selection: 90 At this point, you can select the number of a parameter (1 through 7) to display a description of that parameter or to alter any of the values that you previously entered. When you are sure that the parameters have been properly defined, enter 90 to select the Run DCE client configuration action. This selection checks that all necessary parameters are defined, prompts you for any missing values, and runs the DCE client configuration. The following screen shows an example of a configuration completion. CONFIGURING DCE CLIENTS... Checking parameter definitions ... Completed check of parameter definitions. Saving configuration parameter variables... Initializing dced... Checking for active sec_client service... Starting sec_client service... This node is now a security client. Starting cdsadv... The CDS client daemon has started correctly. Creating client entries for this host... This node is now a CDS Client. DCE Client configuration complete. Press to continue, CTRL-C to exit: To get back to the DCE/DFS Configuration Menu, press RETURN. 5.5.6 DFS client configuration ++++++++++++++++++++++++++++++ Initiate the DFS client configuration by entering the DCE/DFS Configuration Menu. This menu will already be displayed if you just completed the previous DCE client configuration (you can also enter this menu by specifying 1 for the CONFIGURE option on the DCE Main Menu). To select the DFS client configuration, enter 2, as shown in the following example: DCE/DFS Configuration Menu 1. DCE Client-Core Services 2. DFS Client 3. DFS Server 4. UNICOS/DCE Login Configuration 5. Audit Server 98. Return to previous menu 99. Exit Selection: 2 The script displays the DFS Client Parameters Menu, as follows: DFS Client Parameters Menu 1. Cache size (in 1024 byte incr.) 64000 2. Cache file directory /opt/dcelocal/var/adm/dfs/cache 3. Cache files (chunk) -default- 4. Cache chunk size (in 1024 incr.) 18 5. In-memory data cache entries -default- 6. In-memory status cache entries -default- 7. Cache manager main daemons 6 8. Cache manager token daemons 4 9. Verbose daemon output off 10. Dfstrace output off 11. Lock daemons in memory no 12. Cell administrator account cell_admin/-password defined- 90. Run DFS client configuration 91. View UNICOS resource info 98. Return to previous menu 99. Exit selection: 90 The first 12 selections are parameter options that display DFS client configuration information. Each entry contains a short description followed by the current value of the parameter. The value is determined by defaults in the system, taken from a previous configuration, or listed as -not defined-. The values listed as -default- are not defined; the DFS client daemon processes will properly default to reasonable values. You can select a parameter value from 1 through 12 to display a description of the associated parameter or to alter the value of the parameter. However, you are not required to enter any of the parameter values at this time. Selection 91 offers some information on tuning UNICOS for running the DFS client. This information is placed here to be easily viewed as needed, but is also provided in Section 5.4.1. Refer to Section 6.10.2, for further information about tuning considerations for these parameters. Enter 90 to select the Run DFS client configuration action. This selection ensures that all necessary parameters are defined, prompts you for any missing values, and runs the DFS client configuration. After entering any values requested by dce_config, the script establishes the configuration with the necessary servers within the cell. The configuration takes approximately 5 minutes. Output is displayed, indicating where in the configuration the script is at any given moment. The following shows the configuration completion: CONFIGURING DFS CLIENT... Checking parameter definitions ... Completed check of parameter definitions. Modifying rc.dfs... Creating DFS mount point... Starting dfsbind... Creating CacheInfo file... Creating Data Cache directory... Starting dfsd... DFS Client configuration complete. Press to continue, CTRL-C to exit: To get back to the DCE/DFS Configuration Menu, press RETURN. 5.5.7 DFS server configuration ++++++++++++++++++++++++++++++ Initiate the DFS server configuration by entering the DCE/DFS Configuration Menu. You will already be within this menu if you just completed the previous DFS client configuration (you can also enter this menu by specifying 1 for the CONFIGURE option on the DCE Main Menu). To select the DFS server configuration, enter 3, as shown in the following example: DCE/DFS Configuration Menu 1. DCE Client-Core Services 2. DFS Client 3. DFS Server 4. UNICOS/DCE Login Configuration 5. Audit Server 98. Return to previous menu 99. Exit Selection: 3 The script displays the DFS Server Parameters Menu, as follows: DFS Server Parameters Menu 1. Network address sn9999 2. File exporter main daemons 6 3. File exporter token daemons 4 4. Token state recovery on 5. Verbose daemon output off 6. Dfstrace output off 7. DFS ID mapping off 8. Lock daemons in memory no 9. Cell administrator account cell_admin/-password defined- 90. Run DFS server configuration 91. View UNICOS resource info 98. Return to previous menu 99. Exit selection: 90 The first 9 selections are parameter options that display the DFS server configuration information. Each entry contains a short description followed by the current value of the parameter. Each value is determined by defaults in the system, taken from a previous configuration, or listed as -not defined-. You can select a parameter value from 1 through 9 to display a description of the associated parameter or to alter the value of the parameter. However, you are not required to enter any of the parameter values at this time. Selection 91 offers some information on tuning UNICOS for running the DFS client. This information is placed here to be easily viewed as needed, but it is also provided in Section 5.4.1. Enter 90 to select the Run DFS server configuration action. After entering the values requested by dce_config, the script establishes the configuration with the necessary servers within the cell. The configuration takes approximately 15 minutes. Output is displayed, indicating where in the configuration the script is at any given moment. The following shows the configuration completion: CONFIGURING DFS SERVER... Checking parameter definitions ... Completed check of parameter definitions. Checking login requirements... Checking the registry database ... Modifying the registry database for DFS server operation... Creating entry for 'sn9999' in FLDB... Creating a template dfstab file... Starting dfsbind... Starting fxd... Modifying rc.dfs... The DFS server configuration has completed. To export DFS partitions, use the instructions from the "OSF Administration Guide" or use the CRAY dfsmkfs(8) command. Press to continue, CTRL-C to exit: DFS server configuration complete. Press to continue, CTRL-C to exit: To get back to the DCE/DFS Configuration Menu, press RETURN. 5.5.8 UNICOS/DCE login configuration ++++++++++++++++++++++++++++++++++++ You can configure the system login(1) command to prompt for the dce_login password automatically and for single sign-on capabilities. Configure this feature from the UNICOS/DCE Login Configuration Menu. You will already be within this menu if you just completed the DFS server configuration described in Section 5.5.7 (you can also enter this menu by specifying 1 for the CONFIGURE option on the DCE Main Menu). To select the login configuration feature, enter 4, as shown in the following example. DCE/DFS Configuration Menu 1. DCE Client-Core Services 2. DFS Client 3. DFS Server 4. UNICOS/DCE Login Configuration 5. Audit Server 98. Return to previous menu 99. Exit Selection: 4 The script then displays the following message: Prompting for all main configuration parameters... The script runs through all of the login configuration parameters, asking you to enter values for each. If a default value is available, it is listed. Any value that is displayed in the current value field or enclosed in brackets ([ ]) is the current value. To accept this value unaltered, simply press RETURN. You will have the opportunity to alter these values before running the configuration, so you do not need to worry about mistyping any of the values. The following list provides examples of the parameters the configuration will encounter and includes additional notes for clarity. o The Integrated login parameter specifies whether a DCE login and a UNICOS login are performed together. If the value is set to on, users will be authenticated to DCE and UNICOS simultaneously. If the value is set to off, only the standard UNICOS user database (UDB) authentication is performed. In the following example, the value is set to on to enable integrated login. Integrated login This parameter determines whether a DCE login is performed at the same time as the UNICOS login. If 'on', users that have both a UNICOS account and a DCE registry account will be logged into both simultaneously. If the passwords are identical for both accounts, the password is only prompted for once. WARNING: Setting this value to 'on' will install a modified passwd(1) command. Possible values: 'on' 'off' Default value: off Current value: off Enter new value: on o The Primary authentication parameter enables you to specify the primary authentication service as either the normal UNICOS udb(5) process or the DCE registry. This parameter is displayed only if you turned on integrated login by setting the integrated login value to on. In the following example, the value is set to DCE. Primary authentication This parameter determines the perferred password authentication method. If set to 'UDB', the UNICOS udb(5) account and password are used. If set to 'DCE', the user is authentication to the DCE Cell only. 'DCE' primary authentication can only be set when the 'Integrated login' parameter is set to 'on'. Possible values: 'UDB' 'DCE' Default value: UDB Current value: UDB Enter new value : DCE o The Fallback to UDB authentication parameter enables users on your system who do not have a DCE registry account to log on to the system even though the primary authentication is set to DCE. This parameter is displayed only if you set your primary authentication parameter value to DCE. Setting the value to yes enables any user with a udb(5) account to authenticate. Setting the value to no allows only those users who have valid DCE accounts to access the system. In the following example, the value is set to yes. Fallback to UDB authentication This parameter determines if the system will fall back to UDB authentication when DCE is the primary authentication and users do not have a DCE account. This parameter has no significance when UDB is the primary authentication method. Possible values: 'yes' 'no' Default value: yes Current value: no Enter new value : yes o The Local internet domain parameter sets a domain name to be used in the /krb5/krb.realms file. The domain name is typically the Internet domain name of the local system with the specific host component removed. For example, the Internet domain of machine sn9999 might be sn9999.CRAY.COM. In this case, the domain name is .cray.com. This value must be entered for single sign-on to work. In the following example, .CRAY.COM is entered. Local internet domain This parameter sets a domain name to be used within the /krb5/krb.realms file. This parameter only insures that the initial domain is set, other domains will need to be added by hand. Restart of product required after changing this parameter. Default value: -none- Current value: -none- Enter new value: .CRAY.COM o The Kerberos 5.5 telnet parameter specifies whether standard telnet(1) or Kerberos 5.5 telnet sessions will be used. Setting the value to on specifies that the Kerberos 5.5 version will be used. Setting the value to off specifies that the standard version will be used. In the following example, the value is set to on. Kerberos 5.5 telnet This parameter switches between using standard telnet(1) or Kerberos 5.5 telnet. If 'on' a modification to the inetd.conf(5) file will be done to make all telnet sessions use the Kerberized version. If 'off', the standard UNICOS telnet daemon (/etc/telnetd) will be used. Possible values: 'on' 'off' Default value: off Current value: off Enter new value: on o The Kerberos 5.5 krsh & krcp parameter specifies whether remote shell and copy commands can be used. Setting the value to on indicates that these commands can be used. In the following example, the value is set to on. Kerberos 5.5 krsh & kcp This parameter determines if Kerberos 5.5 remote shell and copy commands will be accepted on the system. If 'on', it will result in modifications to the services(5) and inetd.conf(5) files so that Kerberos shell and copy will be accepted. See the 'DCE/DFS Release Overview', krsh(1), or krcp(1) manual page for a description on use of this feature. Turning this parameter 'on' does not effect the use of other already existing network commands. Possible values: 'on' 'off' Default value: off Current value: off Enter new value: on o The Kerberos 5.5 klogin parameter specifies whether Kerberos 5.5 remote login can be used. Setting the value to on indicates that this remote login method can be used. Setting the value to off or pressing RETURN prohibits the use of this method. In the following example, RETURN was pressed to indicate that klogin cannot be used on the system. Kerberos 5.5 klogin This parameter determines if Kerberos 5.5 remote logins will be accepted on the system. If 'on', modifications will be done to the services(5) and inetd.conf(5) files so that Kerberos logins will be accepted. See the 'DCE/DFS Release Overview' or klogind(8) manual page for a description on use of encrypted login. Turning this parameter 'on' does not effect the use of other already existing network commands. Possible values: 'on' 'off' Default value: off Current value: off Enter new value : o The Kerberos 5.5 eklogin parameter specifies whether DES encrypted Kerberos 5.5 remote logins can be used. Setting the value to on indicates that encrypted logins can be used. Setting the value to off indicates that encrypted logins cannot be used. This feature might not be available on your system because of U.S. export restrictions. If that is the case, encrypted remote logins will not be supported. In the following example, the Kerberos 5.5 eklogin value is set to on. Kerberos 5.5 eklogin This parameter determines if DES encrypted Kerberos 5.5 remote logins will be accepted on the system. If 'on', modifications will be done to the services(5) and inetd.conf(5) files so encrypted logins will be accepted. See the 'DCE/DFS Release Overview' or klogind(8) manual page for a description on use of encrypted login. Turning this parameter 'on' does not effect the use of other, already existing, network commands. Possible values: 'on' 'off' Default value: off Current value: off Enter new value: on The script next prompts for the cell adminstrator password if it has not already been acquired in this dce_config session. After displaying all of the login parameters, the script displays the following menu: Local Login Variables 1. Integrated login on 2. Primary authentication DCE 3. Fallback to UDB authentication yes Single Sign-On Variables 4. Local internet domain .cray.com 5. Kerberos 5.5 telnet on 6. Kerberos 5.5 krsh & krcp on 7. Kerberos 5.5 klogin off 8. Kerberos 5.5 eklogin on 9. Cell administrator account cell_admin/ -password defined- 90. Run Login Configuration 98. Return to previous menu 99. Exit selection: 90 At this point, you can select the number of a parameter (1 through 9) to display a description of the parameter or alter any of the values that you previously entered. Enter 90 to select the Run Login Configuration action. This selection determines if all necessary parameters are defined, prompts you for any missing values, and runs the login configuration. The values you have set up will not become valid until this selection has completed. This configuration modifies some critical system files. The script describes what it is doing and give warnings where necessary. The following screen is an example of a configuration completion. CONFIGURING LOGIN... Checking parameter definitions ... Completed check of parameter definitions. Configuring Integrated login... Creating the iauser configuration... Completed UNICOS/DCE integrated login configuration. Configuring Single Sign-on... Creating the realms file... Checking the /etc/services configuration... Checking the /etc/inetd.conf configuration... Checking KRB5 keytab entries for this host... KRB5 keytab entries are up to date without change. WARNING Modifying /etc/services... The following /etc/services entry/entries are being added: >klogin 543/tcp >kshell 544/tcp >eklogin 2105/tcp WARNING Modifying /etc/inetd.conf... The following /etc/inetd.conf entry/entries are being added: >klogin stream tcp nowait root /opt/dcelocal/bin/klogind klogind >kshell stream tcp nowait root /opt/dcelocal/bin/kshd kshd >eklogin stream tcp nowait root /opt/dcelocal/bin/klogind klogind -x Restarting inetd... WARNING The /etc/inet.conf or /etc/services file(s) have been modified as described above. Updates to these files are also done from the install menu system (install(8)). Any changes made via install(8) will overwrite the changes made here unless you take proper action. We recommend that after completing this configuration, you 'import' the DCE changes into install(8) by selecting the following install-menu operation: Configure System ==> Network Configuration ==> General Network Configuration ==> Import general network configuration Completed single sign-on configuration. Completed login configuration. Press to continue, CTRL-C to exit: In this example, some system files were modified. The warning messages indicate what has been done to the system and how the changes might conflict with use of the menu system. If you use the menu system for updating the services file and the inetd.conf file, you will need to do the action indicated in the final warning shown in the example. If you modify these files by hand, no action is necessary. 5.6 Audit server configuration ============================== One feature of DCE security is the ability to maintain an audit trail of events for DCE servers. Cray Research does not currently have any servers that use the audit service. However, if you write your own server, you might have need for the audit service. You can configure the audit service on the local host from the DCE/DFS Configuration Menu. You will already be within this menu if you just completed the DFS server configuration described in Section 5.5.7, or you can enter this menu by specifying 1 for the CONFIGURE option on the DCE Main Menu. To select the Audit Server feature, enter 5, as shown in the following example. DCE/DFS Configuration Menu 1. DCE Client Core Services 2. DFS Client 3. DFS Server 4. UNICOS/DCE Login Configuration 5. Audit Server 98. Return to previous menu 99. Exit selection: 5 The script then displays the following menu: DCE Audit Configuration Menu 1. Configure Audit Daemon 2. Unconfigure Audit Daemon 98. Return to previous menu 99. Exit selection: A selection of 1 configures the audit daemon on; a selection of 2 unconfigures the daemon. 5.7 DFS/NFS Secure Gateway configuration ======================================== The DFS/NFS Secure Gateway provides a mechanism for granting authenticated access to the DFS file space from an NFS client. The Gateway server machine is configured as a DFS client and an NFS server. This machine uses NFS to export the DFS file system (/...), which enables NFS clients to mount and use the DFS file system based on credentials they establish on the Gateway server host. Cray Research supports only unauthenticated and locally authenticated access through the Gateway (remote authentication is not supported). This functionality is supported by users issuing the dfsgw add command on the Gateway server. This command establishes cell credentials and adds them to the list of users accessing DFS from a specific NFS client. There may be any number of DFS/NFS Secure Gateways in the cell. This section describes the following aspects of the DFS/NFS Secure Gateway: o Configuring the DFS/NFS Gateway server host o Configuring NFS clients to use the Gateway o Accessing DFS from an NFS client o Gateway user information 5.7.1 Configuring the DFS/NFS Gateway server host +++++++++++++++++++++++++++++++++++++++++++++++++ The following prerequisites must be met before you create a DFS/NFS Gateway Server: o The DCE cell must be created. o The gateway machine's system time must not differ from that of the DFS server machines and NFS client machines by more than 60 seconds. o The Gateway machine must be configured as a DCE client and a DFS client. o The Gateway server machine must be configured as an NFS server machine. See the UNICOS Networking Facilities Administrator's Guide, publication SG-2304, for instructions on configuring an NFS server and setting the system time. To complete configuration you must be the super user on the machine you have selected to b