NFS Server Functionality
Network File System (NFS) enables UNIX users to access a NetWare file system as if it were a local directory on the UNIX workstation. Any client that supports the NFS protocol can also access NetWare files using the NFS Server.
This section uses the UNIX operating system as the example when referring to the remote NFS client. The following figure shows an example of the NFS Server file sharing process.
Figure 1
NFS Server Functionality
Before UNIX users can access the NetWare file system, it must be made available to the UNIX workstations. This process is called exporting the file system. When exporting, you can define who should access the information and how it is accessed by specifying the trusted systems and export options. For example, you can restrict the access to specific UNIX workstations, export the directory as Read-only, etc.
After exporting the NetWare file system from a NetWare server, you must mount the exported file system on the UNIX workstation for normal access. This process is called mounting the file system. Mounting a NetWare file system from a UNIX workstation consists of the following:
A mount point is an empty directory you create. This directory becomes the access point for the NetWare file system. If you choose an existing directory as a mount point, the contents of the existing directory become unavailable until you unmount the remote file system.
Most UNIX systems use the MOUNT command to mount a remote file system.
After these steps are complete, UNIX users can access the NetWare file system by accessing the local mount point. Different UNIX systems can use slightly different commands or user interfaces to mount a remote file system.
The Web-NFS component of the NFS software enables direct Web access to data on NFS servers. It defines a new NFS URL that complements HTTP. The format is as follows:
NFS://Hostname or IP Address
Using this URL, browsers with Web-NFS support can access data from any server.
Web-NFS extends NFS to support operations over a WAN. With Web-NFS, clients can obtain file handles more easily without going through the portmapper or the mount protocols. This makes it firewall-friendly and enables NFS operations across WANs and the Internet. It also improves performance over a WAN by reducing the number of turnarounds.
For each NFS server, only one of the exported paths can be enabled for Web-NFS access.
NetWare and UNIX use different methods for controlling access to files. Although both have similar directory and file security, NetWare security is more elaborate. At a basic level, both systems assign access controls to similar user types.
The access control mode is known as Independent Mode wherein there are no rights/permissions mappings. NFS Client rights apply to NFS client access and NetWare rights apply to NetWare client access.
For information about NFS Server configuration and management, see NFS Server.
Network Information Service (NIS) software lets you administer both UNIX and NetWare from a single point, namely eDirectory.
NIS is a yellow pages service widely implemented in UNIX environments. NIS contains common information about users, groups, and hosts and other information that any client might require. This information could include a list of network hosts, protocol information, and even non-standard information that is likely to benefit from a centralized administration like phone lists.
NIS maintains its information in eDirectory and also integrates the user/group information so that the eDirectory User/Group object also represents the NIS user/group. In the eDirectory-enabled NIS, all NIS-related information is stored as eDirectory objects. The NetWare NIS can also be set up to work in the various NIS configurations available.
NetWare Implementation of NIS: In the NetWare implementation of NIS, individual NIS Records, NIS Maps, NIS Domains, and NIS Servers are eDirectory objects with additional custom attributes defined to accommodate the NIS-specific information.
NetWare NIS is installed as part of the Native File Access for UNIX installation, and the NIS Server eDirectory object is created with the name NISSERV_ServerName in the default bindery context of the server or in the Server's eDirectory Context.
This NISSERV_ServerName is the main NIS Server eDirectory object. It maintains a list of all the NIS Domains it is serving. To view and edit the list, do the following:
Right-click NISSERV_Servername object.
Click Properties.
Click the Memberships Tab to display the list of NIS Domains served by this NIS Server object.
Click the Others Tab to view the IP Address of the NetWare server where NIS server is installed.
The NIS system organizes nodes into administrative segments called domains. The NIS domain exists only in the local environment and usually covers a single network. An NIS domain is a hierarchical structure; hence it is stored as a container in eDirectory. NIS does not impose any strict rules on domain naming; however, each domain must have a unique name.
An administrative NIS domain could be a company or a division of a company. Many administrators using DNS choose to relate their NIS domain name to their DNS domain name, but this is not necessary.
NIS stores all the common information pertaining to a domain as a set of NIS Maps. Users can access the information in these NIS maps. In the eDirectory-enabled NIS, these maps are stored as containers under the NIS domain container. A migration utility is available to create the NIS maps under a specified domain. The NIS Server supports both standard and custom maps.
Standard NIS Maps: Standard maps are created from the standard NIS text files.
The following standard maps are supported. They are classified according to the type of records they contain.
Ethers Map---A source of information about the Ethernet addresses (48-bit) of hosts on the Internet. The Ether objects (ieee802Device) store information about the Ethernet address and hostname.
Bootparams Map---A source of information for various boot parameters. The Boot objects store information about the boot parameters of the various devices that are running. If the Bootparams text filename is to be migrated from the ConsoleOne, it should be named bootp.
Hosts Map---Contains one entry for each IP address of each host. If a host has more than one IP address, it will have one entry for each. The Hosts objects store the IP address and hostname as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Netgroup Map---A source of information about Net Group parameters. It provides the abstraction of net groups.
Networks Map---Contains a single object for each network. The Network objects store network names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Protocols Map---Contains one object for each protocol. The Protocols objects store protocol names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
RPC Map---Contains one object for each Remote Procedure Call (RPC) program name. The RPC objects store RPC program names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Services Map---Contains an object for each service. The Services objects store service names, ports, and protocols as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Passwd Map---Maintains the details of the users such as UID, Username, home directory etc.
Group Map---Maintains the details of the groups present such as GID, Group name, and Group members.
Ypservers Map---Maintains a list of NIS slave servers which can also serve the NIS domain.
Custom NIS Maps: You can use NIS to store any common configuration information that is valuable to NIS clients. Maps you create in addition to the standard NIS maps are called custom maps. For example, you can create an NIS map that provides an employee phone list.
You can create custom maps by creating a text file that contains the relevant configuration information. After creating the text file, you convert it into an NIS map through migration.
To create a phone list map, you would begin by creating a text file containing each employee's name and phone number. An NIS map text file must conform to the following rules:
The following is an example of the phone list text file:
# This is the text file for the phone list map.
Janice_SmithMS 881-1456
Bob_SpillerMS 235-6777
Jim_Miller MS 769-8909
NIS can be configured in the following ways:
The master server is the true single owner of map data. It is responsible for all map maintenance and distribution to slave servers. Once an NIS map is built on the master, the new map file is distributed to all slave servers for that domain, through the client-server relationship. You must, therefore, make all the modifications only on the master. The master maintains a list of slave servers within its domain in the form of a map named Ypservers.
You can set up read-only copies of the NIS database on secondary servers. The secondary servers are referred to as slaves. When the server is set up as an NIS slave, it contacts the master NIS server and requests a complete copy of the NIS maps on that server.
Once the slave server is set up, you don't need to manage the update process manually. The slave servers periodically query the master and request an update when the slave detects a more recent time stamp on the master. A slave server can be added to the Ypservers map in the master.
We recommend that you set up at least one slave server for each NIS domain. The slave server can then function as a standby if the master server goes down, although it might not be necessary in all networks. Slave servers can also be used for load distribution in the network. A master NIS server for one domain can also function as a slave NIS server for another domain.
NIS client enables users to query NIS map information from NIS servers.
For more information on setting up and managing NIS, see NIS Server.
With the implementation of NIS over eDirectory, there exists only one user/group in the network which contains both eDirectory information and UNIX information. This brings up the user management to single point, namely eDirectory.
For this purpose, the eDirectory schema has been extended and the relevant user information is placed in the eDirectory Library. The User object now stores UNIX information such as UID, GID, password, home directory, and shell on eDirectory.
By default, UNIX users /groups are looked for within the containers specified by the parameter SEARCH_ROOT in the configuration file NFS.CFG. The search is recursive within the containers specified by this parameter. In case the parameter does not contain any value, then the search is done under the default bindery or servers context.
When a set of users/groups are migrated to eDirectory from a UNIX server, corresponding User/Group objects are created /updated in eDirectory. During migration, if the UNIX user or group is not present, a new eDirectory User or Group object is created with default NetWare rights. If the User or Group object exists, the user or group's UNIX-related information is updated by default during the migration.
NetWare and UNIX both use the same User and Group objects to get the information they need.
When a user/group makes a request to access one of the services, it searches for the User object on eDirectory by default. The services can also be configured to look for users and groups from a remote NIS database.
The user information includes the following:
The Group Information includes the following:
A typical UNIX system stores user account information in the /ETC/PASSWD file and stores group information in the /ETC/GROUP file. You can migrate this data directly into eDirectory using the migration utility.
Each user uses a username to log in to the system. The UID identifies file and directory ownership information. The user's UID can be a number between 0 and 65,535, with the numbers 0 through 99 usually reserved. (0 is usually assigned to the Superuser.)
NFS group names also have identification numbers. The range of numbers is between 0 and 65,535, with the numbers 0 through 99 reserved. The GID identifies the user as a member of the primary group identified by that GID.
The home directory is the absolute pathname of the user's home directory on UNIX machines.
The shell information identifies the path of the shell program that runs when the UNIX user logs in to the system. You can set the login account to run any program when a user logs in to the system, but the program typically creates an operating system working environment.
The current implementation does not migrate the existing UNIX password field in the password map.
Before migrating the users and groups, remove the password field ("*", "x", or "!") from the corresponding text file and then migrate. After doing this, you can set the UNIX password from the UNIX machine. This is done by making the UNIX machine an NIS client to the NetWare machine, logging in as that NIS user and running an NIS client utility named YPPASWD to set the UNIX password.
For information about UNIX user management, see Migration.
You can use ConsoleOne to perform the following Native File Access for UNIX tasks:
For more information, see ConsoleOne-Based Configuration.
In a non-cluster environment, if the server running Native File Access for UNIX fails, then UNIX users will not be able to use this service until the NetWare server is up. To achieve high availability, you can run Native File Access for UNIX on Novell Cluster ServicesTM.
The product is installed on all the required nodes in the cluster. Cluster enabling is achieved by storing the required configuration files on the shared disk in the cluster. Native File Access for UNIX then accesses these files through an always or highly available virtual IP address. NFS/NIS clients must, therefore, use the virtual IP Address for NFS mounts and issuing NIS client calls. In case the server where the services are currently running fails, the shared disk volume with configuration files automatically remounts along with the virtual IP on a designated node in the cluster.
Native File Access for UNIX supports only active-passive mode on the cluster. This means that only one node in the cluster will be running NFS Services.
Running Novell Native File Access for UNIX on Novell Cluster Services provides the following benefits:
For information on configuring Native File Access for UNIX on Novell Cluster Services see Setting Up Novell Native File Access for UNIX with Novell Cluster Services.
The following administration utilities are provided with Novell® Native File Access for UNIX:
This utility is run automatically during the installation of Native File Access for UNIX. This utility extends the schema necessary for storing the UNIX information of objects. If the directory services are reinstalled or if the NISUserDef/NISUser object is deleted, run this utility manually. The syntax is as follows:
schinst [ -f filename]
The -f filename is an optional parameter. It is the name of the file that contains the list of schema files that need to be extended. If a filename is not specified, the default file, SYS:\ETC\UNIXSCH, is used.SCHINST takes the administrator's FDN and password as input for extending the schema.SCHINST extends the UAM schema only if N4S schema is not already extended in the tree. If N4S is present, SCHINST will not extend the UAM.
It creates NISUserDef object if N4S schema is available or else creates NISUser object if UAM schema is extended. It also adds the UNIX Profile of the root user as UID=0, GID=1, Home Directory=/home to this object. It updates the parameter NIS_ADMIN_OBJECT_CONTEXT in the configuration file NFS.CFG with the context where the object is present.
To extend UAM schema deliberately when N4S schema is already present in the tree, execute the following command after stopping the NFS services running (use nfsstop):
schinst -n
NOTE: You also have to run nisinst after this.
All log messages generated by SCHINST are written to the SYS:\ETC\SCHINST.LOG file. All information regarding schema extension can be found in SYS:\SYSTEM\DSMISC.LOG.
This utility creates an eDirectory object with the name NISSERV_Servername by default or whatever name was specified with the -s option. NIS Server uses this object to store the domains served by the NIS Server. NIS Server validates every request against the list of domains specified in this object. It serves the request only when the domain in the request is present in the above list. The syntax is as follows:
nisinst [-s name] [-x context]
The parameter -s is optional. It specifies the name to be given to the nisserver object. The parameter -x is also optional. It specifies the context where the object should be created in eDirectory.
Run the NISINST manually, if the nisserver object is deleted.
IMPORTANT: If directory services are removed, you need to comment the SEARCH ROOT parameter in NFS.CFG and do the following:
nfsstop
schinst
nisinst
nfsstart
The upgrade utility (NFAUUPGR.NLM) is automatically invoked to upgrade the default configuration of NetWare NFS Services 2.x or 3.0 when you choose Native File Access for UNIX while upgrading the operating system from NetWare 4.x or NetWare 5.x to NetWare 6. When invoked during installation, the upgrade utility retains the existing configuration into the new configuration files, NFS.CFG, NIS.CFG, and NFSSERV.CFG located in SYS:\ETC. The existing configuration files NFSTHOST, and NFSEXPRT are retained.
During installation, if N4S schema is detected, then some of the features available for the UAM schema will not be available. Some such features are, multiple domain support, RFC2307 compliance for NIS, starting and stopping NIS services from ConsoleOne. To enable these features, you need to extend the new schema by executing schinst -n.