If you have an established eDirectory infrastructure, most people who support Macs as well are interested in reusing that infrastructure. If you follow Cool Solutions, you will see several postings on how to do this on your own, using the posix (RFC2037) schema 'stuff'. Once you have such a system and in place and automated it works just fine.
Of course, the problem is that in order to use a network drive as a home directory, and ultimately to share it with your Windows users' home directories, you need to maintain the reference to the home directory location in two places:
- The eDirectory attribute on the user, HOME_DIRECTORY that is referenceable in the login script
- In the posix extensions, for AFP users or SMB users
These two locations are in no way linked or connected. So if you need to move a user's home directory to a different location, then you need to change it in two places. Again, if you have this automated, it's not really an issue. But automating this step is a bit more tricky ...
If you use a product like Novell's File System Factory, which is a wonderful tool for home directory management, (look for a review of this product coming soon), then moving a user's home directory needs extra work.
Condrey Consulting (http://www.condreyconsulting.com) makes a number of products for use in Novell environments, and for Macintosh users with eDirectory trees, they have a product called Kanaka.
Kanaka consists of two parts. First, there is a single NLM running on one server per tree (although you probably want to pick two servers at least, for redundancy). The second component is an Open Directory plugin that you install on each target Macintosh computer.
Configuration is two-fold; once per tree on the server side, and once per client.
On the client side,
1. Install the provided DMG file. You can do this from a direct mount of the sys:\kanaka\ volume, from a copy provided otherwise, or by downloading from the Kanaka web interface at: https://server.ip.address:8009/KANAKA/HTTPGetClientFile
2. Open Directory Access from Macintosh HD: Applications: Utilities, and you'll see an option for Kanaka.
3. Click to configure, and then provide a URL to the Kanaka interface, usually in the form of https://server.ip.address:8009/KANAKA/. If you decide on two or more servers for redundancy and fault tolerance, then enter the second one on the next line, and so on.
Figure 1 - Kanaka interface
You should not have to reboot, but of course, if it only takes a moment or two, go ahead and do that.
Server-side takes a little more thought. You need to deploy the KanakSC.NLM file and some associated file structure to a server that can be AFP- or SMB-mounted by your clients. There is an unforeseen consequence here: AFP/SMB from Novell, as part of the Native File Access Pack, basically needs a replica (master or read/write) on the local server to allow authentication. The server hosting KanakaSC.NLM, according to the manual, requires the ability to mount the SYS (or potentially you could move it elsewhere) volume to be mountable over AFP/SMB for proxy directories. There is a cute trick that can work around this, under some circumstances. That trick in a moment ...
1. Install the server-side component by running the Win32 installer executable which is how Kanaka is distributed.
The authors comment that in order to administer a Netware server at this moment in time, you require a Windows workstation. (iManager does not count, because several snap-ins require Internet Explorer, which is only on Windows.) Therefore, they might as well distribute the package in this manner. This is hard to argue with, even if a slightly different format choice would be helpful.
2. Once KanakaSC.NLM is running on your server, connect to it via the Novell Remote Manager (NoRM) interface at https://server.ip.address:8009/ and authenticate as appropriate to your config.
3. At the bottom, click the Kanaka option, which takes you to the Kanaka main interface.
4. Run the Config Wizard, which asks you to do a couple of simple tasks: extend the schema, install a license file, (you can request a 30 day demo file at this point), create a proxy user, set the login search contexts, and assign AFP names to NSS volumes.
The last step is the trickiest and most important, and in some ways, where Kanaka performs its most sublime tasks. The problem is that the name format for an AFP volume under OS X is of the type, afp://server.ip.address/volumeName. But eDirectory stores volumes as .SERVER_VOL.context.ou.o, and there is no link in eDirectory between the volume name and the AFP volume name. Worse still, imagine a cluster volume, whose name has changed to .CLUSTERRESOURCE_VOL.context.ou.o - or far worse, where the admin has renamed the AFP volume. NFAP allows an admin to edit the sys:etc\afpvol.cfg file and rename the 'ugly' default volume name in AFP of SERVER.VOL to something 'prettier' like PrettyVolumeNameForStudents. This decision is basically completely arbitrary, and it is stored on each server in a file in the file system - not in eDirectory.
Figure 2 - Volume list
Kanaka's magic, which solves the "home directory stored in two places" problem, is to translate one name to the other. When you extended the schema you added an attribute called cccKanakaAFPVolumeName, which is an attribute of the Volume class. When you use the Kanaka web interface to assign a value, Kanaka walks the tree, searches for all Volume objects and presents them in a list. You then select each volume you care about and give it a valid AFP name, IP name of the server, and whatever the volume name is set to for AFP.
Users with widely distributed trees have complained that this task is a pain, if you have hundreds of volumes, but that is a fairly rare case,. Usually it is only a small handful of volumes to be mapped, and it only has to be done once. For those with large numbers, choose your tool (LDAP/LDIF, JRB Tools, third party attribute manipulator), export the volume list yourself, load it into an editor, make all the changes, then push them out to the cccKanakaAFPVolumeName attrib. The syntax is easy to get (set one, retrieve it with your toolset, and then look at it).
Once the volumes names are properly mapped, when a user logs in, the Open Directory plugin on the Mac asks the KanakaSC NLM on the server for your info. The NLM then does the following things:
- Reads the users' home directory attribute.
- Pulls the eDirectory volume name out of it.
- Finds the referenced volume.
- Reads its cccKanakaAFPVolumeName attrib.
- Uses the attrib to construct a valid AFP volume reference to send back to the Open Directory plugin for login.
Thus if you move the users home directory from one volume to another, or anywhere really, no extra work is required, unless you need to assign an AFP name to it in KanakSC's web interface.
Kanaka and UID/GIDs
Another useful thing Kanaka can do for you is use existing UID's and GID's, or generate random ones, in the high range for your users. OS X is sufficiently related to the Unix-like operating systems that it still maintains a UID (user ID number) and GID (group ID number) for users and groups to assign file system rights in NetInfo or via the Open Directory interface.
Certain accounts always have certain UID numbers (root); the same goes for groups (world). KanakaSC in the web interface allows you to use existing UIDs and GIDs found in eDirectory (these are included in the posix/RFC2302 schema extensions) if you populate them, or generate useful random ones if you do not have them.
Now for the Trick ...
Remember that problem we alluded to earlier - needing replicas on the KanakaSC server, to allow an AFP mount of its SYS volume? There is a very cute workaround for this.
The SYS volume gets a Kanaka directory that includes the NLM, and some of the web interfaces HTML bits. But most usefully, it contains some proxy directories. The SYS:\KANAKA\PROXY directory gets RF filesystem access by [Root] so everyone can read them. When a user logs in whose Home directory property is empty, since the Open Directory interface requires a home directory to mount, the login will fail. Kanaka allows you to choose to allow it to fail, or continue, using a proxy directory. There are three cases: no home dir property, no home dir found where the property points, and error reading the HD property. In each case the Proxy directory contains a file (TXT or HTML, you can edit it and add more) that is all the user sees in their home directory on the Mac when they log in. The file recommends they contact the sys admin, because either their home directory is gone, or the mapping is broken.
However, to mount one of these proxy directories as a temporary (read-only) home directory, the user needs to be able to do an AFP mount. Thus, you need replicas to AFP mount the proxy directory. To resolve this, as long as no users need to mount the KanakaSC servers SYS volume for real reasons,
1. In the volume mapping of eDirectory volume object to AFP name, point the SYS volume towards another volume that is mountable.
2. Copy the SYS:KANAKA directory there.
3. Grant the RF right for [Root] to it.
That should be it. After all, the link that Kanaka maintains is basically just an alias between NSS and AFP name spaces.
The end result is that with a small plug-in on the local Mac, an NLM on one server in the tree, and little other work, you get Macintosh OS X computers nicely integrated into your existing eDirectory infrastructure.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.