Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

nsdb-parameters(7) [centos man page]

NSDB-PARAMETERS(7)					 Miscellaneous Information Manual					NSDB-PARAMETERS(7)

NAME
nsdb-parameters - NSDB connection parameters INTRODUCTION
RFC 5716 introduces the Federated File System (FedFS, for short). FedFS is an extensible standardized mechanism by which system adminis- trators construct a coherent namespace across multiple file servers using file system referrals. For further details, see fedfs(7). The bulk of FedFS metadata is stored on one or more LDAP servers. These servers are known as namespace databases, or NSDBs, for short. An NSDB client is any system that communicates with an NSDB. This can be either a fileserver or an NSDB administrative client. On NSDB clients, a small local database stores information about how to connect to each NSDB node. These NSDB connection parameters are used when a fileserver contacts an NSDB node to resolve junctions, or when executing NSDB administrative commands. The settings in this database effect only the behavior of NSDB clients on the local system. They have no effect on the operation of NSDB nodes or other NSDB clients. DESCRIPTION
Before an NSDB client may communicate with an NSDB node, that client must know how to contact the NSDB. The client's local NSDB connnec- tion parameter database contains the DNS hostname, IP port number, and connection security type of each NSDB node that can be contacted. Administrators must provide this information in advance. NSDB name equality The local NSDB connection parameter database is indexed by each NSDB node's DNS hostname and IP port number. Two NSDB node names are equivalent if their respective DNS hostnames and port numbers are an exact match. Before matching, the special port value "0" is always mapped to the standard LDAP port "389." Likewise, if no port is specified, "389" is assumed. Upper and lower case are considered equivalent. The IP addresses to which hostnames are bound are not considered when matching. For example, the NSDB "nsdb.example.net:389 would share a database entry with "nsdb.EXAMPLE.NET:0", but not with "nsdb.example.net:636". If "nsdb.example.com:389" maps to 10.0.0.1 and "nsdb.example.net:389" also maps to that address, the database maintains separate entries for each, although the same connection parameters may be set for both entries. Connection security One of two connection security types may be specified in an NSDB connection parameter entry: NONE The local system communicates with the NSDB node in plain-text. The local system performs no authentication of the NSDB node. TLS The local system always uses Transport Layer Security when communicating with the NSDB node. The local system authenticates the NSDB node before making requests. Integrity or encryption is used during communication. Requests to the NSDB node fail if a TLS session cannot be established. NONE is a low-overhead mode for use when the network and the NSDB are trusted by all NSDB clients. TLS is a high-security mode for use when NSDBs operate on untrusted public networks, but it requires the additional burden of creating and distributing x.509 certificates for each NSDB. An NSDB node can operate in one of three security modes: Basic NSDB clients connect to this NSDB node using only FEDFS_SEC_NONE security. Transitional NSDB clients connect to this NSDB node using either FEDFS_SEC_NONE or FEDFS_SEC_TLS security. Secure NSDB clients connect to this NSDB node using only FEDFS_SEC_TLS security. An NSDB client always uses the security type specified in its local NSDB connection parameter database for that NSDB node. For greatest security, it is recommended that NSDB nodes be configured as secure NSDBs (see table above). x.509 certificates Administrators provide the certificate material used to authenticate an NSDB node in a PEM format file that contains an x.509v3 certificate chain. This file may contain just the public certificate of the Certificate Authority (CA) which signed the NSDB's certificate. Or it may contain a chain of certificates that represents the full chain of trust for the NSDB node. A self-signed CA certificate may be used to reduce the burden of setting up NSDBs for your FedFS domain. Either the fedfs-set-nsdb-params(8) command is used to transfer this material to a remote fileserver running a FedFS ADMIN service, or the nsdbparams(8) command is used to install this material in the NSDB connection parameter database on the local system. For both commands, the file containing certificates for one NSDB is specified on the command line with the --certfile option. The certificate material provisioned via these commands is used for no other purpose on the local system than NSDB authentication. SEE ALSO
fedfs(7), nsdbparams(8), rpc.fedfsd(8), fedfs-set-nsdb-params(8) RFC 5661 for a description of NFS version 4 referrals RFC 5716 for FedFS requirements and overview COLOPHON
This page is part of the fedfs-utils package. A description of the project and information about reporting bugs can be found at http://wiki.linux-nfs.org/wiki/index.php/FedFsUtilsProject. AUTHOR
Chuck Lever <chuck.lever@oracle.com> 3 February 2014 NSDB-PARAMETERS(7)
Man Page

Featured Tech Videos