Linux Directory Services? 9
m0rph asks: "My company is building a Linux web cluster solution. We are currently discussing using Open LDAP for user authentication (for ftp http etc). I have been reading recently about the NDS port to Linux. This has raised some questions to me. In reading the NDS-Linux How-To the document states the you can use NDS in conjuction with Open LDAP. Being new to directory services I am wanting to know how does NDS differ in function from Open LDAP or other directory services? Is anyone using this same sort of method for authentication? and if so what are you using? why would you use a directory service like NDS with Open LDAP? also can someone can reccomend good documentation or a book that you have had good results with? "
NDS = LDAP (sort of) (Score:1)
-Aaron
Re:NDS = LDAP (sort of) (Score:1)
NDS LDAP but does *DO* LDAP. (Score:1)
Realize that I know NDS and am just learning LDAP.
Now having said that. In a Novell environment NDS is the *Cloud* (for lack of a better term) in which the network lives. It is a self replicating, distributed, self repairing (to a greater/lesser extent) database. In your Tree you have Containers and Objects that include but are not limited too: Orginizations, Orginizational Units, Users, Groups, Printers, Print Servers, Print Queues, Servers, Volumes, Orginizational Roles (this is about 11 of 30 object types install by default and it is extensible). You do 90% of you administration here (some programs just don't fully integrate into the admin tools). You setup user rights, file system rights, who can see what and do what. You can store programs here for launching with double click. It is X.500 compliant.
In the latest version of NDS, NDS 8 or E-Directory it includes LDAP. You can take an LDAP supporting application and using the catalogs that can be created, use NDS as your Directory for your site.
As was stated E-Directory runs not only on Novell, but can be placed on Windows NT, Linux, Solaris, SCO UnixWare, and I belive AIX and/or HP-UX.
Using it to combine administration of Novell and NT domains allows you to grant rights for any user to any NT server just by assigning rights (no more Trusts) and allows your Novell admins to administrat using NWAdmin or Console One while your NT admins use User Manager.
(Yes I know this sounds like a sales pitch but it's not.)
On the other hand a poorly planed NDS Tree will cause you no end of problems becouse if the Tree is down so is the Network. Fotunantly you can (and *MUST* [ok should but really]) but replicas on multiple servers, partition the network for both performance and redundancy, and raise or lower any of the replicas to master or back to read/write or read-only replicas almost anytime.
Like anything else usefull it has much to be learned about it, but if it is a possibility or a need for you take the time to look into it or talk to someone who knows about it.
shdo
(just a plain old mcne)
Directories for Linux (Score:1)
Linux and NDS and LDAP, oh my! (Score:1)
I've played with NDS for Solaris before, and it's pretty slick. Here at Miami U, we've got one or two replicas of a test NDS tree, and we just made our Solaris machine another replica of that tree. All user attributes like shell and home directory are stored as NDS attributes (part of the installation involved extending the NDS schema to allow for Unix attributes). We're pretty excited about this, because any given client of ours has at least five or six different passwords to remember; consolidating directories is a must at this point.
Novell also has a product in Golden Master right now called NetWare NFS Services 3.0. This is another gateway-type thingy that provides NIS and NFS services. I haven't played with this one yet, but it sounds promising.
The problem I'm running into is that Linux doesn't support 32-bit UID's. Miami has on the order of 30,000 clients to support, so we decided to start numbering UID's at the next highest order of magnitude, 100,000. Well, Linux can't see UID's bigger than 65,535, so we must either re-do all our UID's (big, big, big pain in the tochus, as thousands of these UID's are currently in use), abandon universal UID's and the ability to NFS share data across platforms, or wait until Linux gets big UID support. I've read that the recent 2.3 kernels actually support large UID's but we've still got to wait for glibc 2.2. There have been hacks, but I really don't want an enterprise depending on Joe's hack.
Re:Linux and NDS and LDAP, oh my! (Score:1)
Yes, NDS is a DATABASE and LDAP is a DATABASE ACCESS METHOD. Fundamentally different animals, joined at the genitalia (a colorful image for you bestiaphiles out there).
In current releases of Netware, the base protocol is IP, the directory is NDS, and the directory access protocol is LDAP. NDAP is on the way out (IPX has already been shown the door).
There are a (very) few problems with Netware's LDAP standards compliance that were caused by the the original NDAP design. Novell has been refreshingly open about these bugs, in fact there were tutorials at Brainshare showing ways to deal with these conflicts; basically, though, if you don't have to be backwards compatible with an existing NDS installation you can easily modify currently shipping versions of NDS to be 100% LDAP read/writable. If you are already sitting on a large NDS-based Novell net things are a little trickier.
--Charlie
PS- NDS is not particularly stable, but it has redundant linking that allows it to be rebuilt using the DSrepair software. The more third-party NDS-interactive software you have (particularly IBM software like IWSAA) the more often you will have to run DSrepair.
--C
Re:NDS LDAP but does *DO* LDAP. (Score:1)
Pretty image. NDS is a database. It is a variant of the LDS Church's (the "Mormons") genealogy database and inherits some shortcomings from that.
You forgot to mention "self-breaking". Heh. I would have said it is a large database composed of small chunks (less than 108 bytes, usually much less except in the overflow file BLOCK.NDS) which can be configured to automatically update replicas stored on physically diseparate servers. One replica is always the master, and in early versions (prior to "transitive updating") it was easy to set up large WAN-linked NDS trees that spent all their time trying unsuccessfully to sync.
NDS is lame. Having said that, it is easily the most mature, dependable, and useful directory service on the market. Microsoft's AD will probably never catch up with the lead Novell has established, and there are no comparable Open Source directory services that I am aware of (if I'm just iggernant, somebody PLEASE enlighten me!).
Incidentally - in general, you should avoid extending your schema. Novell used to do it quite casually, and now the base schema is incredibly unwieldy and difficult to fathom. The ZenWorks extensions are a particularly egregious example.
Oh, and the management tools suck unbelievably. You are not allowed to type fully qualified object names into many fields, you MUST click on a list, even if you have a list that is comprised of millions of objects and you need to make a couple hundred changes. Large shops often have to give people a few days off after a major NDS change because their wrists have been fragged from too much mousing in too short a time period. There are third-party tools that address this problem, but in general Novell has gone down a very bad path for the management interface. GUIs are not the solution to every problem.
--Charlie
Re:NDS LDAP but does *DO* LDAP. (Score:1)
I would like to think my interest in products such as this have very little to do with how well they perform on a day-to-day basis. I've often mentioned how boring directory services are (we've beta tested several versions--we install it, create a user, sit back and admire his red shirt). What interests me is what happens when they break.
I'd be willing to bet that Miami University must rank fairly highly on the list of dial-in sites for repair by Novell Technicians because of our use of, ahem, early release software in sometimes nonrecommend manners. For instance, we installed NetWare 5.0 (NDS 7) into our tree without performing a step listed in the readme. We promptly began turning Organizational Units into unknown objects until we disabled DS on the initial box. Oops. Took Novell dial-in technicians (hi, Byron!) about 4 days to fix our problems. Effect? Four divisions which had configured printing in bindery emulation could not print. No other effect--users did not notice. Administrators scrambled and converted printing to NDS mode, but users logged in and did not suffer in performance.
Several years ago, the only replica of [Root] was deleted and Novell dialin had to convert an ancilliary partition to include [Root]. We've caused severe problems in tree communication through incompatible releases and have corrupted our schema more times than I want to think.
In fact, the other day, I accidently chose to merge a partition back into [Root] instead of simply checking synchronization. I aborted about 5 minutes after it started. This happened right in the middle of the afternoon. The abort worked smoothly and within 10 minutes, everything was back the way it had been. No user or service was affected.
Sounds bad, no? It has been and continues to be in many ways, but I look at any large, distributed product administered by 12 individuals who can modify DS versions and probably 60 individuals with "write" access to portions of the directory as having potentially vast and horrible problems. Novell could have done more in the past to prevent us from damaging ourselves. My point is that we are still running our original, begun with NW 4.01, tree without scrapping and staring over (though we've redesigned several times) upgraded to NetWare 5.1 with the newest DS, and we have not experienced severe downtime. Sure, on occaision logins took 10+ minutes for the application launcher to complete because of a misconfiguration, but it was up. Current versions of DS allow us to perform repairs during the daytime without taking down service for most repairs.
This is why I like Novell Directory Services. It works well when it works. It works okay when it's broken. I like this second point. Active Directory requires the server to be rebooted to perform a directory repair (it's a special boot option). I'm not very familiar with other directory technologies, but I believe there are similar limitations.
Novell is also beginning to get the meta-directory picture. They are currently shipping tools that allow ldif import and export (haven't tested the export utility yet--just found out about it) as well as forthcoming synchronization support for Notes, Netscape and Active Directory (the beta for this product, DirXML is available from Novell's public beta site, but I haven't been able to get it working).
A significant problem of Novell is client-platform support. For instance, you can put an NDS replica on AIX, but you cannot access it from AIX. You can put a replica on OS/390, but you cannot access it from there. You can put a replica on Linux and Solaris and have PAMs authenticate from the NDS, but applications cannot use it. (Actually, they will be shipping a product soon, derived from work at a university, that does export NDS APIs and allow logins from the above platforms and many others.) NetWare access from Macs seems a much greater priority than NDS access (they are quite different) from Macs. In fact, sp1 ships with something called NDSDAV--similar to WebDAV to access and modify NDS properties and permissions through the Web. I began to think I had a solution for my Mac/Linux/Refridgerator users. Unfortunately, it prompty required an ActiveX control and would not work on any platform but my Windows box running IE. Hopefully they'll get in gear.
To underscore their desire to go the path of LDAP, however, their APIs for their "supported" platforms (Win32 and NetWare) are going out of their way to support LDAP-style access and current rumor is that when LDAP supports everything that NDAP does (printing and other fun things), Novell will dwindle their reliance on NDAP for native communication. One story I heard from an NDS engineer is that LDAP access in NDS 8 is actually faster than NDAP access, but I haven't tested it.
In general, directory services seem a way to relate many servers and services together. Problems arise when you have technologies that can vary by 4-5 years communicating with each other (our tree includes a 4.10 server) on sometimes questionable hardware (that server is a 486 PS/2).
Also, I wanted to pose the question whether Open Source directories can really crack the enterprise. I believe a lot can be done in open source, but directories, to me, are the large, disparate databases that only break when they get large. It seems that a company would be reluctant to bet big on an untested technology and performance on a smale scale does not necessarily mean any sort of performance on a large scale. When I see companies take a chance on a new product like this, it's after the vendor has flown out and promised much assistance and support (when we were an Alive w/ 5.1 site, we had 3 people fly out, one with connections to all sorts of engineers back in Utah-home, and a special contact if we had problems after they left). I don't see how open source products can create that feeling of confidence.
NDS vs other LDAP servers (Score:1)
A. NDS was only in Beta on Linux at the time.
B. LDAP compatibility. In our test pilot, we did run into some LDAP compatibility issues. They seem to occur in the way in which NDS classes and attributes are mapped to/from LDAP.
C. The Netscape LDAP Server has a simpler and more open design that better fits our work philosphy. NDS relies on a multi-master approach for replication. This has many advantages, but it raises the complexity of the directory network. By staying with a simple Master/Client model for replication and controlling the directory writes (we are fortunate that we are able to do this), we will have a directory service which will be extremely stable and have nearly zero administrative costs. Our design philosophy is basically to keep everything stateless and easily replaceable.
Where the multi-master replication model has the strong advantage is when data in the directory needs to be changed often and at several different locations. In short if you have to change your data often and at several different locations then you are not looking at an optimal directory service.