Authors : Shreyas Rao
Suresh Kumar GP
With the introduction of Novell Domain Services for Windows (DSfW), it is now possible for users to log in and authenticate to both eDirectory and Active directory from a Windows workstation without requiring multiple logins or having the Novell Client, and access the NSS volumes without the client.
This AppNote provides a step by step procedure to configure and access the clustered NSS Volume on a DSfW server and access the volumes from Windows without using the Novell client.
NCS: Novell Cluster Services is a server clustering system that ensures high availability and manageability of critical network resources including data, applications, and services. It is a multinode clustering product for Linux that is enabled for Novell eDirectory and supports failover, fail back, and migration of individually managed cluster resources.
DSfW: Novell Domain Services for Windows (DSfW), a component of Open Enterprise Server (OES) 2 SP1, creates seamless cross-authentication capabilities between Windows/Active Directory and Novell OES 2 Linux/eDirectory servers. This suite of technologies allows Novell customers with Windows networking environments to set up one or more "virtual" Active Directory domains in an eDirectory tree. Users can then log in and authenticate to both eDirectory and Active Directory from a Windows workstation without requiring multiple logins or having the Novell Client for Windows installed With Domain Services for Windows. eDirectory users can use familiar Windows desktop operations to access file services regardless of the platform/operating system where the service resides. Users can access Novell Storage Services (NSS) volumes on Linux servers by using Samba shares or NTFS files on Windows servers that use CIFS shares. eDirectory users can also access shares in trusted Active Directory forests.
More information on these is available at: http://www.novell.com/documentation/oes2/
Let us consider an example of a DSfW server set up where there is a Master eDirectory replica - which is a eDirectory server running on a OES 2 SP1 server.
This Tree has an OES 2 SP1 server attached as a FRD server in the domain 'frd.com'.
There is also an ADC server attached at this level to the server.
We will refer these servers are Master server, FRD server and ADC server henceforth in this document.
A Windows client is added to the FRD domain.
Forest Root Domain (FRD): The domain that provides the base (foundation) directory forest. It is usually the first domain that you create in your directory forest and is known as the default forest root domain.
Additional Domain Controller (ADC): It is an added server used to improve the availability and reliability of network services. If you have an additional domain controller, it helps in fault tolerance and balances the load of existing domain controllers. It also provides additional infrastructure support to the sites. An ADC will have all the parameters same its peer in that domain.
The Tree view is as shown below.
In the above shown screen shot,
The server 'systst-ts-124' is the Master server.
The server 'systst-ts-123' is the FRD server.
The server 'systst-ts-126' is the ADC server.
The installation of the FRD server and ADC server is elaborately mentioned in the novell documentation:
Once the above mentioned DSfW setup is configured, the following operations are done to set up a Clustered NSS Volume in a DSfW Environment:
The configuration of the iSCSI is explained:
We can skip the above mentioned if your using a Shared SAN box between FRD server and ADC server.
We now have a Clustered NSS Volume on a DSfW server set up.
User creation, Rights assignments and Share the cluster volume using samba.
cp /etc/smb.conf /media/nss/CLUSTVOL1/samba/etc/
bind interfaces only = yes
interfaces = 126.96.36.199
pid directory = /media/nss/CLUSTVOL1/samba/locks
path = /media/nss/CLUSTVOL1
read only = No
browseable = yes
inherit acls = yes
Add the following lines in the NSS resource load scripts SAMBA_ROOT=/media/nss/CLUSTVOL1/samba
exit_on_error /usr/sbin/nmbd -l $SAMBA_ROOT/log -s $SAMBA_ROOT/etc/smb.conf
exit_on_error /usr/sbin/smbd -l $SAMBA_ROOT/log -s $SAMBA_ROOT/etc/smb.conf
Add the following lines in the NSS resource unload scripts SAMBA_ROOT=/media/nss/CLUSTVOL1/samba
ignore_error killproc -p $SAMBA_ROOT/locks/nmbd-smb.conf.pid /usr/sbin/nmbd
ignore_error killproc -p $SAMBA_ROOT/locks/smbd-smb.conf.pid /usr/sbin/smbd
bind interfaces only = yes
interfaces = 188.8.131.52 <- local server IP address or the cluster node IP address.
Now different instances of smbd and nmbd process will be run for local and cluster configuration scripts.
Thus the user on the Client will be able to access the files seamlessly even if the Volume will have migrated.
*There are others ways to map to the cluster volumes as well like Mapping Network drives using NSS Pool resource IP or by netbios name.