Adding other File Systems or Network Resources to your NSS File System
Novell Cool Solutions: Tip
By J.R. Wessels
Digg This -
Posted: 15 Dec 2005
You would like other file systems (such as CDs, floppies) or network resources (such as windows shares, nfs, apple shares, ftp, sftp) to be part of your Novell NSS directory structure. Plus, the file permissions need to be managed by eDirectory for people accessing them.
With traditional NetWare, you could create DFS junctions from one NSS volume to another. However, NetWare can't create a junction to other types of systems.
In short, you can mount the foreign file system under a directory on an NSS volume under OES Linux. Clients would access the NSS volume. Then when they encounter the mounted file system, the underlying Linux OS does the file access while the NSS system enforces file permissions. Also since the remote systems appear as part of NSS, you can create DFS junctions from NetWare file servers to the OES Linux box that has the other mounted file systems. So not only can other systems appear as part of the NSS volume, but you can now create DFS junctions to systems far different than NetWare. Different systems are joined, creating a network wide unified file system.
First step is to have a working NSS volume running under Linux OES in your tree.
The next step is to setup an empty directory on the NSS volume. This is where you will mount the foreign filesystem. After creating the directory, the default rights need to be setup on it. The foreign filesytems have no idea what eDirectory is, its permissions, or the users. The permissions on this new directory are going to be the default permissions for all files that will suddenly appear when the actual mount is done. After the mounting is done, finer permissions can get setup in subdirectories or files.
Recommended permissions depend on what type of file system you are mounting. For read only file systems such as CDs or read only ftp servers, set the directory to Read and Filescan only. This isn't necessary, but this will have your user's Novell clients give meaningful error messages why they can't write to the directory. Otherwise if they try writing to a readonly mounted filesystem, while NSS says it is writable, your clients will get file system timeout errors. On other file systems at are writeable, use your own discretion on default rights.
After setting the directory permissions, now is the time to setup the remote file system for mount. The quick and dirty way is to simply run the mount command from the OES Linux command line.
For example, if I wanted to mount a windows share:
mount -t smbfs -o username=remoteuseraccount,password=supersecret,fmask=777,dmask=777,ip=192.168.1.1,netbios=SERVERNAME //SERVERNAME/SHARE/SUBDIRECTORY /media/nss/MYVOLUME/ourspecialdirectory
What this does is mount the Windows UNC path "//SERVERNAME/SHARE/SUBDIRECTORY" under the NSS volume "MYVOLUME" at the directory we just created "ourspecialdirectory". On the Windows box, the user we logged in as was "remoteuseraccount" with password "supersecret" which should have rights on its own file system for that user. Since Windows doesn't have Unix file permissions, we tell mount to give the files Unix permissions of 777. Even though we open the permissions on the unix system wide, the NSS permissions will be used later to restrict access. Specifying the IP and Netbios name of the server isn't absolutely necessary, but helps to insure a stable connection.
If you want the foriegn file system to always be available, you will need to setup the mounts to come up automatically at bootup. However, you only want the mounts to come up after NSS is running. This can be done in another startup file after the NSS daemon starts. So for the above, we would enter this line in the /etc/samba/smbfstab file:
//SERVERNAME/SHARE/SUBDIRECTORY /media/nss/MYVOLUME/ourspecialdirectory smbfs username=remoteuseraccount,password=supersecret,fmask=777,dmask=777,ip=192.168.1.1,netbios=SERVERNAME
In the runlevel you are in (I'm in runlevel 3 without X-Windows starting), move the smbfs startup item to run later than the NSS daemon. Novell is configured to start the NSS daemon at S16, so S20 is a good spot to move smbfs too. I do this on my system with:
mv /etc/init.d/rc3.d/S13smbfs /etc/init.d/rc3.d/S20smbfs
For other file systems, just insure they are mounted after NSS starts. Otherwise the NSS directory you are trying to mount to won't exist. NFS mounts can be handled the same way as Samba mounts, just move the init startup script (S10nfs and S10nfsboot).
Linux supports many different file systems, even ones that aren't engineered to be mounted. FUSE and LUFS both offer ways to mount untraditional file systems. Unfortunately LUFS has no longer been in development since 2003.
- FUSE http://fuse.sourceforge.net
- LUFS http://lufs.sourceforge.net
Here are some possiblities that may be possible with the above projects:
- ftp servers
- sftp using the ssh protocol (this seems to be the most used of the above projects)
- Gnutella peer-2-peer. Part of the LUFS project to allow you to download (but not upload files).
- Gmail accounts
Loopback file systems could also be possible, like mounting CD ISO or floppy images.
For sftp I recommend using the Linux FUSE project at http://fuse.sourceforge.net. To mount Gmail accounts it is a module that runs as part of FUSE from http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html.
Once all the file systems are mounted, you can now go into ConsoleOne, iManager, or through Explorer on your Windows box to manage permissions farther down the directories. Remember the default permission we set on the mount directory? That is the default for all stuff under the mount point.
As you modify rights farther down the directories, it puts the trustee rights in an XML file on the OES Linux box. If you unmount the foreign file system, the rights still remain in the XML file. This allows you to down the remote ftp, sftp, etc server without losing your rights. However, if your remote server isn't brought up, all these entries still remain. This can lead to some strange problems in eDirectory if users create directories in that now vacant mount point. Duplicate entries will show up, even though only one of them really exists. The only way I have been able to clean this up is to delete the entries in that mount point, manually delete the entries from the XML rights file, then reboot the OES Linux box.
Since this method of mounting non-NSS file systems on top of NSS directories is not supported, the NSS daemon on the server does not have access to all the features of NSS when it reads or writes into those directories. This leads to many error messages filling it's log files. To insure the log files don´t fill the server, I added an entry into logrotate´s configuration to rotate the /var/log/ncpserv.log and /var/log/ncp2nss.log files if they grow to over 50 megabytes. In the crontab file it calls the logrotate program every hour to check the size. If you have significantly more activity on your server with these mount points, you may want to call logrotate more often or put the /var/log on a different partition.
By mounting these file systems on NSS, remote access possibilities open. NetStorage access through the web interface and Webdav work wonderfully if the NetStorage server is not on the same OES Linux box. I have not tried using NetStorage if it is on the same box as the mount points.
Novell OES Linux running an NSS volume required.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com