With ncpfs, connections to NetWare can be classified in three kinds:
Temporary connections are established within a process by a call to NWCCOpenConn* API calls or their derivatives (ncp_open_*). These connections cannot be shared between several processes and should be closed when the process terminates with calls to NWCCCloseConn() or ncp_close_conn().
Permanent connections are created by mounting a NetWare resource on the local system. Once created by a process, they can be re-opened by other processes by a call to ncp_open_mount(&conn, mount_point). Closing these connections by a process does not actually cut the Netware connection but simply releases memory allocated when reopening it. To actually close these connections and detach from NetWare resources, process must umount the associated mount point. The file /etc/mtab keeps track of these connections in standard Unix format; internally reopening a permanent connection creates a new connection handle and fill its internal data with information read back from this file. This client uses extensively permanent connections.
Shared connections are similar to permanent connections, but are usually opened at startup of a Unix client and use as a mount point a system-wide accessible directory. All users logged in can use this connection to access NetWare resources such as file systems or printing queues. With regular user, this client do not use nor create shared connections. All mounting are done using default mount points within current user 's Unix home directory and receive 700 file permissions. With superuser, some of the created permanent connections may behave as shared connections if the mount point is a publicly accessible directory and specific file permissions are provided as command line parameters.
Historically ncpfs utilities that require login/password against a server will search for any command line missing information in a ~/.nwclient file with the following format:
This NDS client will try to make use of information stored in ~/.nwclient file if not default values has been found in environment variables, nor in ~./nwinfos file. Of course, for the login/password values to be used in authentication, the corresponding server must belongs to the tree to which current user is trying to authenticate to. Furthermore, the server must resides in the same context as the user, since no name context information are stored in nwclient files.
Again, this file must be flagged 600 to be considered; and it may be autocreated by the PAM authentication module.
Starting with ncpfs-2-2-0-18 distribution, a PAM ncp authentication module allows validation (and eventual automatic creation) of local user accounts against NDS login/password database. Among various features, this module may create in current user's home directory a .nwinfos file filled with data retrieved from NDS at authentication time. Albeit it contains only publicly available data of NDS, and never any password information, this file is flagged 600 when created or overwritten.
The following listing shows an example of .nwinfos file; most of the entries are self-explanatory:
NDS_USER=alexis
NDS_GECOS="Alexis Pollet,fistonnet"
NDS_SHELL=/bin/bash
NDS_HOME=/home/alexis
NDS_UID=10006
NDS_GID=100
NDS_QFLAG=8033
NDS_HOME_SERVER=EURINSA
NDS_HOME_VOLUME=APPS
NDS_HOME_PATH=HOME/EXT/ALEXIS
NDS_HOME_MNT_PNT=/mnt/ncp/alexis/nwhome
NDS_EMAIL=Alexis.Pollet@cipcinsa.insa-lyon.fr
NDS_PREFERRED_SERVER=CIPCINSA
NDS_PREFERRED_TREE=INSA_ROOT
NDS_PREFERRED_NAME_CTX=PC
NDS_ZEN_FLAG=0x840c7101
NDS_BCAST=0
It this client does not found in environment the missing options, it will try to fetch them from this file.
|
Looking for |
Replace with |
|
NWCLIENT_PREFERRED_TREE |
NDS_PREFERRED_TREE |
|
NWCLIENT_DEFAULT_NAME_CONTEXT |
NDS_PREFERRED_NAME_CTX |
|
NWCLIENT_PREFERRED_SERVER |
NDS_PREFERRED_SERVER |
|
NWCLIENT_DEFAULT_USERNAME |
NDS_USER |
Vous êtes notre eme visiteur