Document Actions
10.2. Accessing Novell Netware File Servers
Novell Netware servers can serve files in several different ways. This document will focus on NCP (Netware Core Protocol) and NFS access. It is possible that information about SMB/CIFS will be added in future versions.
Using the ncpfs package and kernel module, it's possible to mount file resources from Netware servers using the Netware Core Protocol, which is the same protocol that is used by for example Windows computers accessing Netware file servers.
Note
There are currently two ways to access Novell File Servers via NCPFS - either via the ncpfs package and kernel module, or via Novell's Client for Linux. The latter is described in Section 10.2.3, “ Using the Native Novell Client to Access Novell File Servers ”.
Since a NCP mount is per user, not per host as with NFS, every user must mount their own resources at login, most often using their password. The procedure used is much like the one used when accessing Windows file servers, described in Section 10.1, “ Accessing Windows File Servers ”.
The package ncpfs must be installed on the ThinLinc server. The programs ncpmount and ncpumount must be setuid root. This is accomplised by executing the following command:
# chmod u+s,a+x /usr/bin/ncpmount /usr/bin/ncpumount
On SuSE, the permissions of ncpmount and ncpumount are reset each time SuSEconfig is run. To avoid this, add the following to /etc/permissions.local and run SuSEconfig:
/usr/bin/ncpmount root.root 4755 /usr/bin/ncpumount root.root 4755
The ThinLinc server must be configured to use LDAP for authentication as described in Section 9.4.5, “ Using Novell eDirectory with ThinLinc ”. The commands used for mounting resources from Netware servers, described below, use the values in /etc/ldap.conf to find what LDAP server to ask for needed information.
We assume that the Netware servers we will mount resources from operate in an IP environment, and that DNS names exist for all Netware servers. If the latter is not true, aliases for the Netware servers need to be added to /etc/hosts.
When using NCP to access the Netware file servers, the permissions are decided by the Netware server. However, the permissions that are showed on the Linux side are not mapped to the effective permission. Therefore, even though a file may look readable/writable when listing it from the Linux side, it may very well not be readable/writable when trying, because the Netware file server denies it.
tl-mount-ncp is a small wrapper for ncpmount which adds:
Automatic submission of password using the ThinLinc Single Sign-On mechanism.
Automatic creation of mountpoint directory if it does not exist.
Automatic translation of the username into a NDS distinguished name
Ability to automatically lookup where (on what server and path) a users home directory resides using LDAP lookups in eDirectory.
The tl-mount-ncp has two main syntaxes:
tl-mount-ncp --homedir <mountpoint> will mount the Novell home directory of the current user (as specified in the USER environment variable) after looking up the location of the home directory from the ndsHomeDirectory attribute in eDirectory.
For example, if a user named john is logged in via ThinLinc and executes
tl-mount-ncp --homedir /home/john/novell/home
his Netware homedirectory will be mounted on /home/john/novell/home.
tl-mount-ncp <server>/<path> <mountpoint> will mount the Netware resource at <server>/path on <mountpoint>
For example, the command
tl-mount-ncp ALABAMA/DATA/common /home/john/novell/common
will mount the directory /DATA/common on the Netware file server ALABAMA on /home/john/novell/common, using the current user's username and password.
If extra parameters need to be added to the ncpmount command line used by tl-mount-ncp, they can either be added on the tl-mount-ncp commandline using the --ncpmount_args parameter, or in Hiveconf, as the parameter /utils/tl-mount-ncp/ncpmount_args . The latter is the preferred way, since it provides a systemwide way to specify the parameters. By default, the parameter has a value that makes filenames with swedish characters work as expected. The Hiveconf parameter is found in /opt/thinlinc/etc/conf.d/tl-mount-ncp.hconf. You can see the ncpmount command line used by using the --verbose flag to ncpmount when testing functionality.
The tl-umount-all-ncp command is a utility that unmounts the current user's mounted NCP shares (all NCP mounts below the user's home directory). It requires no arguments. The optional argument -a will unmount all CIFS (smbfs) filesystems on the host.
Often, it's convenient to automatically mount NCP resources for all users upon login. This can be accomplished by creating a script in /opt/thinlinc/etc/xstartup.d. It can be named anything. The script should contain something like:
#!/bin/sh /opt/thinlinc/bin/tl-mount-ncp --homedir ~/novell/home /opt/thinlinc/bin/tl-mount-ncp ALABAMA/DATA/common ~/novell/common
You should also make sure that tl-umount-all-ncp runs at logout. This can be done with the following command:
# ln -s /opt/thinlinc/bin/tl-umount-all-ncp /opt/thinlinc/etc/xlogout.d
Given the example above, the user's Netware home directory will be mounted on the directory novell/home under the user's Linux home directory. Also, another Netware directory will be mounted at novell/common. Upon logout, all Netware shares will be unmounted.
Novell has released a Linux version of their Novell Client. ThinLinc provides support scripts to help integrate the Novell Client in a ThinLinc installation by automatically adding information on username, eDirectory tree, user's context and user's password, the latter by using the ThinLinc Single Sign-On feature.
Note
There are currently two ways to access Novell File Servers via NCPFS - either via the ncpfs package and kernel module, or via Novell's Client for Linux. The former is described in Section 10.2.2, “ Using NCPFS to Access Novell File Servers ”.
The Native Novell Client for Linux can mount file resources from Novell file servers. This can be done manually after login by using the map command, or by running the user's login script. The latter is done by passing the -r parameter to nwlogin.
The Native Novell Client for Linux must be installed on the ThinLinc server. The integration scripts in ThinLinc has been tested using Novell Client v1.2 on Suse Linux Enterprise Desktop 10.
The ThinLinc server must be configured to use LDAP for authentication as described in Section 9.4.5, “ Using Novell eDirectory with ThinLinc ”. The commands used for mounting resources from Netware servers, described below, use the values in /etc/ldap.conf to find what LDAP server to ask for needed information.
With ThinLinc, a command named tl-nwlogin is shipped. This is a wrapper around the nwlogin command shipped as part of the Native Novell Client for Linux. The tl-nwlogin command takes the same commandline parameters as nwlogin, with the difference that if required parameters such as username, tree, context and password are missing on the commandline, tl-nwlogin will add them before running nwlogin.
If a parameter for one of several of username, tree, context or password is passed on the tl-nwlogin commandline, it will be passed untouched to nwlogin. This allows for flexibility. For example, if the user should be logged in using the same username, context and password but to a different tree, just add -t <treename> to the tl-nwlogin commandline. This will cause tl-nwlogin to automatically add username, context and password, but will pass the tree parameter unchanged to nwlogin.
After login, shares can be mounted by using the map command, part of the Novell Linux Client. They can also be mounted as part of the login procedure by adding the -r parameter to tl-nwlogin. This will cause the Novell Client to run the user's login script.
After session termination, the user should be logged out to free system resources and unmount shares. For this purpose, ThinLinc ships a wrapper script named tl-nwlogout. This script automatically adds the -t parameter to tell nwlogout which tree to log out from.
Simply run tl-nwlogout by linking it into /opt/thinlinc/etc/xlogout.d.
If the user was logged into any additional trees, make sure you add a script for logging out of all trees in /opt/thinlinc/etc/xlogout.d.
The NFS serving capabilities in Novell Netware differ between different versions of Netware. Here's an attempt to summarize what features exist in the different variants.
Table 10.1. NFS serving capabilities in different Novell Netware versions
| Netware version | Serving Traditional volumes | Serving NSS volumes |
|---|---|---|
| Netware 5.1 with Novell NFS 3.0 | Support only over NFS v2. Hard links supported. File locking supported. File Access modes: NFS mode, Independent mode, Netware mode, Netware-NFS mode and NFS-Netware mode. | Supported over NFS v2 and v3. Hard links supported. File locking not supported. Available File Access modes: Independent mode. |
| Netware 6.0sp2+ with Native File Access for Unix | Supported only over NFS v2. Hard links supported. File locking supported. File Access modes: Independent mode. | Supported over NFS v2 and v3. File locking not supported. Hard links not supported. File Access modes: Independent mode. |
| Netware 6.5 with Native File Access for Unix | Not supported. | Supported over NFS v2 and v3. File locking supported. Hard links not supported. File Access modes: Netware mode and Independent mode. |
If the filesystems exported from the Netware server is to be used as home directories for Linux users, both file locking and hardlink support is required for proper operation. Given the table above, home directories can only be exported and used from a Novell Netware server if they reside on traditional volumes on a Netware 6.0sp2 (or higher) server with Netware File Access for Unix installed.
On the other hand, using Netware mode (if your fileserver runs Netware 6.5 or later) means you don't have to assign uid and gid values to all home directories from the Linux side, since Netware will do this translation on the server side. However, since a NFS export from Netware 6.5 doesn't support hard links, the export can't be used as a home directory without special care. Also, be aware of the fact that trustees won't work, so a shared directory where several people have read/write permissions can't be used in a decent way.
First you need to make sure that you have the Novell Native File Access for UNIX installed. This contains the NFS server components and NDS schema extensions. You should install the available service packs for your Netware system. Then Native File Access for UNIX is initially installed, it runs the command schinst, which extends the NDS schemas.
If NDS is reinstalled, if you for example installs a Netware service pack, you may have to run it manually afterwards. After schinst you should run nisinst which extends the schemas with NIS info, which is needed. You should run nfsstop before and nfsstart after these commands.
Before you can export a Netware traditional file system you need to run the command:
$ add namespace nfs <filesystem>
Before this you won't see the file system in the list of file systems possible to export in ConsoleOne and the NFS server won't be able to export it even if you add the filesystem to SYS:\ETC\NFSEXPRT manually
When you have added the NFS namespace you need to export some volumes from the Netware server. In Netware 6.0 this is done using ConsoleOne. First connect to the NDS tree, and then to the NFS server. When you add the exports you can tell from which machines the root user will have root access to the files (similar to no_root_squash on UNIX systems). In Netware 6.5, this configuration is instead done via iManager - using ConsoleOne won't work.
If you read users and groups from NDS (by using nss_ldap as described in Section 9.4, “ Authentication against LDAP servers ”) you should add a group, for instance unixusers . In the group settings you should set the GID in the UNIX -tab. Then you add your users to the group. You should also make sure that the Admin user has UID 0 set in the UNIX -tab.
To get file locking you need to run the lock file daemon. You can start it with the command:
$ load lockd
You probably want to add this to your startup files to make sure that it's running from start. Also note that if you are running ZENworks for Desktops, you want to change the load order in AUTOEXEC.NCF so that NFSSTART.NCF comes before ZFDSTART.NCF. Failing to do this may result in a server with 100% load and malfunctioning NFS.
NFS can be used with several different authentication mechanisms. The most common one is called AUTH_SYS. This is the only mechanism supported by Netware. AUTH_SYS only provides a legitimate authentication if the network can be secured externally, and privileged TCP/UDP ports are used. Unfortunately, the Netware NFS server does not require that NFS requests are originating from privileged ports. This means that any user on any host (which has been granted NFS access) can impersonate any other user (including root). To work around this problem, the Netware filtering support can be used:
Type FILTCFG at the console prompt.
Select Configure TCP/IP Filters->Packet forwarding Filters.
Change status to Enabled.
Make sure "Deny packets in filter list" is selected.
Select (List of denied packets).
Press Insert to define a new filter.
Highlight the "Packet type" entry, and press Enter.
Press Insert to define a new packet type. It should have the following properties:
Name: nfs-unsecure Protocol: UDP Source ports: 1024-65535 Destination ports: 2049 Stateful filtering: Disabled
Press Escape, and then Enter to return to the Define Filter screen.
Press Escape and Enter to save the filter.
Repeat step 6 to 10 to add a TCP filter. In step 8, the Name should be "nfs-unsecuretcp", and the Protocol TCP.
Exit FILTCFG.
When exporting filesystems from a Novell Netware fileserver using NFS in the Independent mode (see Table 10.1 for the available file access mapping modes on different Netware versions), no mapping is done from the Netware permissions to the Unix permissions. Therefore, permissions on the exported filesystems must be set from a Linux client by running chmod as root. This can be done either manually or automatically using tl-nds-posixuser, described in Section 9.4.5.4, “ Using eDirectory User and Group Objects with ThinLinc ”.
Depending on how the NFS-exports of filesystems on the Netware servers are organized, it's more or less easy to mount the homedirectories on the ThinLinc server(s).
If all homedirectories are found under one export, just add a line to /etc/fstab that mounts that path as /home. This situation is however rare. Remember to put nfsvers=2 if the server only exports using NFS v2. Another option is let autofs mount the home directories using a wildcard entry in the automounter map.
If the homedirectories are spread among several different servers and/or on several different exports, it's less easy to mount the correct path. For this purpose, ThinLinc provides the program tl-nds-mountpath that searches LDAP and deducts the correct mountpath from the ndsHomeDirectory value.
The tl-nds-mountpath is added on a line in /etc/auto.master. An example line looks like this:
/home program:/opt/thinlinc/libexec/tl-nds-mountpath nfsvers=2,hard,intr
This will cause tl-nds-mountpath to search LDAP for the correct mountpath for a specific user. The program reads its parameters from /etc/ldap.conf or /etc/pam_ldap.conf, that is, it's using the same DN and password as pam_ldap and nss_ldap . Make sure the DN have the permissions to read the ndsHomeDirectory attribute or tl-nds-mountpath will not work as expected. Use the ThinLinc Novell Configurator as documented in Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ” to create and configure the special DN used to search LDAP for the needed information.
Note
In some Linux distributions, the /etc/auto.master syntax above will not work. Instead, the line should look like this:
/home program /opt/thinlinc/libexec/tl-nds-mountpath nfsvers=2,hard,intr
SUSE Linux Enterprise Server is one example where this syntax is required.
Since many eDirectory installations has one or several entries where the ndsHomeDirectory has an invalid value, tl-nds-mountpath normal behaviour is to check the result of the LDAP query to make sure the key is also in the result. For example, when asked for the mountpath for the home directory of the user alice, it checks that the result contains the string alice, in a case-insensitive string search. This means that if the environment is setup so that the username is not in the home directory path, tl-nds-mountpath will not work. If this is not the desired behaviour, it can be turned off by setting /utils/tl-nds-mountpath/key_in_result_verify to 0.
The filter used by tl-nds-mountpath to find the user object and hence the ndsHomeDirectory attribute can be configured in the parameter /utils/tl-nds-mountpath/ldapfilter. The default filter removes alias objects from the result.
The reason for this behaviour is that when tl-nds-mountpath is used in combination with tl-nds-posixuser, assigning uid/gid values, a whole directory with many home directories can be assigned incorrect uid/gid values, if the ndsHomeDirectory attribute of one user has a bad value.
Netware file systems are case insensitive when using NCP and CIFS, but case sensitive when using NFS. Often, the path specified in NDS has a different case than the actual directory. If you try to mount the path as specified in NDS, you will get an error message. The best way of solving this is to enter the correct home directory path in NDS. However, correcting this for many users can be time consuming. Therefore, tl-nds-mountpath contains support for testing different combinations of uppercase and lowercase characters. When it finds a combination that works, the result is returned to the automounter. Since the number of possible combinations is typically very large, not all combinations can be tested. The combinations to test is specified by the parameter /utils/tl-nds-mountpath/directory_cases . It is a list of strings. Each string can contain the letters l, u or n, for lowercase, uppercase and NDS, respectively. These strings specify the different case combinations for the beginning of the name of directories. The default value is "n l u ul". This means that tl-nds-mountpath tries all combinations of directories that are named like:
Just like it is specified in NDS
With all letters in lowercase
With all letters in uppercase
With the first letter in uppercase, and the rest in lowercase
Other variants can be added as well, but please note that if you have a deep directory structure and many case strings, the number of different combinations will be very large, which means that the execution of tl-nds-mountpath might take a long time. The number of different combinations k is s **( d -1 ), where s is the number of case strings, and d is the number of directories in the home directory path. The average search time t is k *0.005/2 seconds (assuming one mount requests takes 5 ms). The table below lists the search time for some sample values of s and d .
Table 10.2. Combinations and average search time for tl-nds-mountpath
| Directories in home directory path: | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| 1 case string | 1 (5 ms) | 1 (5 ms) | 1 (5 ms) | 1 (5 ms) |
| 2 case strings | 1 (5 ms) | 2 (5 ms) | 4 (10 ms) | 8 (20 ms) |
| 3 case strings | 1 (5 ms) | 3 (7.5 ms) | 9 (22.5 ms) | 27 (67.5 ms) |
| 4 case strings | 1 (5 ms) | 4 (10 ms) | 16 (40 ms) | 64 (160 ms) |
| 5 case strings | 1 (5 ms) | 5 (12.5 ms) | 25 (62.5 ms) | 125 (312.5 ms) |
| 6 case strings | 1 (5 ms) | 6 (15 ms) | 36 (90 ms) | 216 (540 ms) |
Since exports from Netware 6.5 don't support hard links, they cannot be used as home directories in Linux without special care. Both the X Window System, Gnome and KDE use hard links when locking files. One workaround for this is to perform the following steps.
Create a directory either on the local filesystem or, in the case of a ThinLinc cluster, on the machine running the VSM server. Regardless of which, we will call it /localhome in this example. Make /localhome sticky by executing chmod o+ws /localhome. This will enable all users to create files and directories in /localhome, but no user will be able to erase another user's files/directories.
Each time the user logs in, check if the directory /localhome/<username> exists. If not, create it using mkdir.
Set the following environment variables for each user:
ICEAUTHORITY=/localhome/${USER}/.ICEAuthority GCONF_LOCAL_LOCKS=1
Note
It is only necessarity to set GCONF_LOCAL_LOCKS for GConf 2.3.0 or older. In newer versions, you must instead make sure that the variable GCONF_GLOBAL_LOCKS is not set to 1.
Another problem is that in Netware, most home directories are not owned by the user it is associated with, but instead some superuser owns it (since the superuser created it). Try using FLAG.EXE from Windows to correct this.