|
Question : Using Netware Server to host home directories on other OS's.
|
|
Our organization is heavily Novell Netware based. Currently, Windows machines login using the Novell Client, and their Home directory is mapped out (ie. H drive).
That is the typical setup. Here is where it gets tricky:
We have about 50 SunRay thin clients, and a Solaris Server running them. Each user has their own unix home directory, and we have created a mass-writeable share called (ie. Files) on the Novell server and mounted it in Solaris via NFS and Novell's Native File Access Pack. In each user's home directory there is a symbolic link to the 'Files Drive'
We have about 25 Mac workstations, ranging from G3s to G5s ... We took a similar approach as we did with Solaris, and we used the Native File Access Pack to map a single mass-writeable share called Files (same share as Solaris)
We are moving more in the direction of Thin Clients and will be setting up a Windows Server 2003 box with Terminal Services. This will allow our Macs and SunRays to utilize rDesktop to access Windows Apps. We are in the process of trying to iron out the kinks now in a test environment (hence why I am writing now) and were curious how we could more tightly integrate everything.
Ideally we would want all Home directories to be stored on the Novell Server, each owned by one user. That Home directory would be the same no matter which of the systems they signed into.
We are toying with eDirectory for Solaris, eDirectory for NT - and although I have not even began investigating it yet - I would imagine we would have to get the MacOSX boxes to use the Novell NDS instead of the native Mac OS OpenDirectory (maybe we will have to purchase OS X Server for this - as I said we have not looked down that road as of yet).
The biggest concern I have right now is how I can make the home directories on Solaris map to the Novell Server, with all the user permissions intact.
ie. /export/home/someuser would contain the same files as //server/volume/users/someuser on the Novell Directory.
I am assuming that NFS would be out of the question for a per-user type setup because (a) Would NDS on Solaris work with the subdirectories and permissions on an NFS mount? (b) Native File Access is a nightmarish security risk from what I have seen so far. If you create a read only file using a windows box - Novell puts the owner as 'root'. Suppose that file was SUID'd then copied back - we'd end up with a SUID root program.
Any suggestions on how this would be done - I imagine there are lots of other companies out there doing exactly what we are proposing, and have it operating smoothly.
|
Answer : Using Netware Server to host home directories on other OS's.
|
|
That's NetWare 6 and NetWare 6.5, not Novell 6 or 6.5 - please do try to remember... I'll refrain from referring to your "sun 9" and "sun 10" servers for now ;)
I don't know about doing the massive PersonalDataVolume mount, though, but I suppose that would cut down on the number of NFS mounts. I was thinking along the lines of an NFS mount done automatically at login through the home directory Unix attributes of the user object. Don't know how that works in practice, but it sounds good to me in theory...
Anyway, if the user "bob" logs into eDirectory to get access to Solaris (via NIS or PAM or LDAP or whatever - but it must be authenticating to eDirectory) then the user bob's UID/GID would be used for his NFS activity as you say. If "bob" later logs into eDirectory as "bob" from a Windows station and writes a file through CIFS to his home directory, when "bob" later logs into eDirectory on Solaris and looks at his home directory through the NFS mount, his UID should be on it, IMHO. We're talking about accessing the same NetWare NSS volume data space through different namespaces, remember. The eDirectory pieces that relate to NFAP should determine how the different namespaces behave.
Same thing should apply if the user "bob" accesses those files from a Mac using NFAP/AFP. His ownership attributes shouldn't have changed at all, but the Mac will see the data and resource fork namespace to acccess the files. In theory.
Since the actual ownership of the data is in the NSS filesystem, and that trustee relationship is defined by the user object, any namespace-specific attributes that that user object has should also be applied to those namespaces as a factor of being an eDirectory user-object attribute. In theory.
Since you've got the test bed already going, maybe you can tell us if the theory translates into practice.
|
|
|
|