In Phase I of our migration, we installed the UAM/Redirection services on all platforms while keeping the NDS tree itself on the NetWare server. We started our transformation with Windows NT. The beauty of the NT migration process is that the only machines you need to "touch" are domain controllers: the PDC and BDCs. The rest of the client machines need not be changed.

A simple setup wizard helped in the NT installation of the domain controllers. It walked us through installing the NT client for NetWare, then rebooting, installing the redirection modules (replacing the samsrv.dll and a couple of other files), migrating objects into the NDS tree, then rebooting, installing management utilities and, yes, rebooting. For the most part, the process was painless. In the end, all user and machine objects were migrated to the NDS tree, from which they were manageable through Novell's ConsoleOne and NWAdmin. All login requests were redirected to NDS, and all machines that previously were able to log into the NT domain could still do so, but they were now (unknowingly) being rerouted to NDS. Pretty suave.

The Solaris install was deceptively simple: It consisted of installing several Solaris packages and some NDS install and uninstall shell scripts. This opened an editor to input relevant NDS data, then finished without a hitch. Upon completion, a Unix workstation object was added to the NDS tree container we had specified. All that remained was to replace the /etc/nsswitch.conf and /etc/pam.conf files with the sample files provided by the install, assign users access in the NDS tree and log in.

We did, however, run into a few hitches after the installation. First, home directories can't be added through the NDS management utilities. While this is not such a big deal, you still need to log onto the Solaris workstations, create the directories and assign proper rights. Second, Unix UIDs (user IDs) and GIDs (group IDs) must be tracked manually--Novell doesn't provide any sanity checking on this front. For example, Novell doesn't have any mechanism--like the Unix useradd command--to automatically assign UIDs in sequential order. This is not a deal-breaker, but most Unix administrators we know have grown accustomed to relying on automated sequential UID assignment.

Finally, when we attempted to assign a UID to the NetWare admin user, ConsoleOne blew up in our faces. This was, unfortunately, the beginning of a long battle with ConsoleOne's self-destructive nature. We finally resorted to using NWAdmin to assign the admin UID--ConsoleOne was never able to pull it off. When we informed Novell of this issue, people at the company told us the problem must be due to a bug. To date the company has not contacted us with a resolution.

The Linux install was clean but could have been more complete. The install involved several Red Hat Package Manager (RPM) files and a pair of install and uninstall shell scripts. While we were excited to see Novell embrace the RPM format, we soon realized this supposed embrace was weak. One of RPM's primary roles is to check package dependencies. That is, if package X depends on package Y to work, the RPM command will fail the installation of package X when it finds that package Y is absent. Novell, it appears, hasn't grasped this concept. For example, our initial installation on a Red Hat Linux 6.1 machine appeared to go flawlessly--until we tried to use it. We eventually discovered that we needed a newer version of the glibc library suite, as well as the ncsd package.

Had Novell done its homework on Linux RPM, the installation would have failed the dependency check right from the get go, and we wouldn't have wasted days troubleshooting. Novell needs some people who understand the Linux scene. To Novell's credit, however, the requirements were in the documentation--just buried where we failed to see them.

After our initial oversight and an upgrade to Red Hat Linux 6.2, all was well. Other than the installation differences, the Linux and the Solaris UAM installations are almost identical in features and feel. Phase I of our project seemed to be a success: NT clients were able to log into NT, Linux clients were able to log into Linux, NetWare clients were able to log into NetWare and Solaris clients were able to log into Solaris. All the systems were using user accounts found in the NDS tree and were centralized. So far, so good. Off to Phase II: moving the NDS database onto the various platforms.

Into the Heart of NDS Darkness

To begin Phase II, we continued testing on Linux. The NDS install process was simple. We had to execute the NDS-Install script and choose the option to install both UAM and NDS. We then had to answer a couple of questions regarding where we wanted objects placed in the tree, as well as where the NICI (Novell International Cryptographic Infrastructure) key was. (It comes with NDS Corporate Edition.) Incidentally, NICI allows secure keys to be created from a particular server. Once completed, the Linux server object could be found in the context we specified, and it included a read/write copy of its own NDS partition. We performed some light authentication tests and then moved onto Solaris.

The Solaris process was not as simple as we had expected. As with the Linux installation, we began on a second Solaris box to avoid tainting our previous installation. During the UAM part of the procedure, we received a message indicating that the NDS schema had been updated and that the install process couldn't continue the UAM support. This is where our problems started. We troubleshot the UAM issue for some time before breaking down and calling Novell tech support. As far as we can tell, Novell employs only one person capable of handling support for the Solaris/Linux platform, and he was on vacation when we called. Digging deeper we eventually wound up on the phone with a real live product developer. We hope the public is afforded this same luxury, as support for these products within Novell is seemingly scarce.

Our newfound friend informed us that the schema updates to NDS introduced by the Linux installation conflicted with the Solaris installation sequence. Huh? Hadn't Novell tested these together? He further pointed us to an updated Solaris product on the Web site and mentioned that the problem is documented in the Linux readme file. Why we were supposed to be looking in the Linux readme for a Solaris problem still escapes us, but we set this aside for later pondering and moved onto the Solaris update.

The update, we soon found, was a treat of its own. After monkeying with the shar file (why it wasn't a tar also is a mystery), we saved the updated file from Novell's Web site and proceeded to execute it. "Choice ^M: is not a valid identifier" is all we could get. Digging into the file revealed a space after each line, which prevented the code from executing properly. Short of our writing a Perl script to remove the space after each line in the 204,867-line file, the only way we could get the thing working was to open the file on the Web site, copy all text and paste it into a file on the Solaris box. Once extracted, the updated files were installed.

After the Solaris fiasco, we finally installed NDS for NT, a quick and painless process. The server object was added to the tree, and a read/write copy of its partition was synchronized before we even had a chance to view it. Again, Novell apparently understands Microsoft platforms well but is behind in the world of Unix.

Pounding on Our New Authentication System

We then launched into Phase III, doing what our Chicago lab does best: attempting to break things. We really wanted to see if we could bring NDS to its knees, so we did all sorts of nasty (yet probable) procedures. We changed the times on several of the systems to see if NDS would be able to handle poor time synchronization. The system had no problems: It simply switched those partitions over to synthetic time and carried on.

We then placed read/write copies of all partitions on all NDS servers and proceeded to shut them down one at a time. As we did so, we tested clients on each individual platform for their ongoing ability to log in. As long as there was a domain controller available (PDC/BDC), all Windows clients still were able to log in. As long as there was a single NDS-enabled server operational, NetWare client authentication was possible. We predicted and experienced reasonable delays, but to Novell's credit, authentication continued without fail. We even changed partition types from read/write to master on all systems one at a time and encountered only one problem: ConsoleOne couldn't perform the operation on Solaris, but NDS Manager completed the task just fine. ConsoleOne appears to be unhappy in general, however, so this didn't surprise us.

We also uninstalled servers one at a time, just to see if all objects could be removed and added without difficulties. We stuck with the best practice of running NDS synchronization tests after each major procedure and still hit it hard on the authentication front. Once we got past the installation nuances, the products appeared to hold up well.

Does Novell Have What It Takes?

Novell's first attempt at spreading NDS to multiple platforms is a good one, but it needs work. NDS has proven itself in the directory-service battlefield--ask anyone who has used it over the years. If Novell wants organizations to take its cross-platform offerings seriously, however, the company needs to overhaul its strategy--and soon. We found Novell's lack of commitment to official support of the Unix-based products a bit terrifying--especially considering this is probably the one road that may save Novell.

Novell's multiplatform vision also needs a sharper focus on pure technology-related issues. If Novell doesn't start transforming its internal culture to start eating, breathing and sleeping Linux and Solaris, its current customer base, and its potential customer base, is going to hang the company. For example, many veteran Solaris administrators aren't going to settle for overseeing their users and machines using Microsoft Windows-based utilities. Not all Linux administrators use, or even install, X Window. If Novell doesn't provide a suite of command-line utilities for at least performing basic tasks, there are going to be problems--especially for ISPs that rarely install X Window on their server farms.

People new to NDS aren't going to tolerate having to figure out when to use NWAdmin and when to use ConsoleOne. And people using ConsoleOne are going to start sending Novell death threats if the company doesn't get the ConsoleOne snap-in fiasco under control. Novell needs to introduce the word "stability" into the vocabulary of ConsoleOne users, and ConsoleOne needs to start working on non-Windows-based platforms. Finally, firing up a DOS shell and running the DOS-based AuditCon utility to look at audit logs continues to drive us crazy--and we grew up with NetWare!

Rumor has it Novell CEO Eric Schmidt used to carry around a packet sniffer to see if campus buildings were in compliance with his "pure IP" vision. His next task should be to get engineers to administer Novell's internal networks from Unix platforms. Teach them how to use LILO (Linux Loader), run command-line utilities that aren't DOS-based and get them to speak the language. Maybe then there will be more than one person at Novell who can support Unix when we call for help. (Click here for more on Schmidt's vision for Novell.)

NDS Corporate Edition starts at $2,600 for 100-user, 128-bit package, Novell, (800) 453-1267, (801) 861-7000. www.novell.com.

Greg Shipley and Kevin Novak are Chicago-based consultants. Send your comments on this article to them at gshipley@neohapsis.com or knovak@neohapsis.com.