The new 9.2 manual addresses the very question I was about to pose to the list - whether to use LDAP or NIS. It just seems to me to make sense to implement NFS, and use PAM/LDAP for user authentication & directory service. If that doesn't make sense, I'd love to hear why not. Put another way, is there a good argument to use NIS in favor of LDAP? Any other issues I should be aware of here? Thanks, Don -- Web Developer Matheteuo Christian Fellowship webdev@matheteuo.org http://matheteuo.org/ Free software is like God's love - you can share it with anyone anywhere anytime!
Web wrote regarding '[SLE] LDAP vs. NIS Question' on Fri, Oct 29 at 18:49:
The new 9.2 manual addresses the very question I was about to pose to the list - whether to use LDAP or NIS. It just seems to me to make sense to implement NFS, and use PAM/LDAP for user authentication & directory service. If that doesn't make sense, I'd love to hear why not. Put another way, is there a good argument to use NIS in favor of LDAP? Any other issues I should be aware of here?
If you plan to work with some antique software (on other operating systems) or stuff that's not PAM/NSS aware, NIS may work better. Then again, NIS sucks in about every way, so LDAP's a much better choice in almost every situation. :) --Danny, who dislikes LDAP just because it seems non-intuitive and/or excessively verbose, but likes that it works well
måndag 01 november 2004 19:32 skrev Danny Sauer:
If you plan to work with some antique software (on other operating systems) or stuff that's not PAM/NSS aware, NIS may work better. Then again, NIS sucks in about every way, so LDAP's a much better choice in almost every situation. :)
Well, not always ... LDAP with the built in database (ldb I think it's called), is so slow that it can really make lookups suck ... big time. However, with bdb it's quite fast, but bdb has a lot of drawbacks. A word of caution is not to upgrade a bdb layout from a i386 to a x86_64, that didn't happen quite happily on my end. Export/Import ldiff's for that. I never really got SQL working, so I don't know how good that is. But I think NIS has some advantages in specific situations, as I never felt the kind of performance drop with nis as I did with ldap,with the ldb database.
Örn wrote regarding 'Re: [SLE] LDAP vs. NIS Question' on Tue, Nov 02 at 07:09:
måndag 01 november 2004 19:32 skrev Danny Sauer:
If you plan to work with some antique software (on other operating systems) or stuff that's not PAM/NSS aware, NIS may work better. Then again, NIS sucks in about every way, so LDAP's a much better choice in almost every situation. :)
Well, not always ... LDAP with the built in database (ldb I think it's called), is so slow that it can really make lookups suck ... big time. However, with bdb it's quite fast, but bdb has a lot of drawbacks.
As the other poster said - use indecies. If you've got so many users that stuff gets slowed down, consider using multiple servers (note that heavy usage will also slow down NIS). I'm partial to setting up a few slave servers in a round-robin using the "ldap.your.domain" hostname, and including the read-write master in that list as well as listing it under its own hostname, perhaps ldapmaster.your.domain. It's a bit difficult to scale NIS that way, IIRC (haven't used NIS for a long time).
A word of caution is not to upgrade a bdb layout from a i386 to a x86_64, that didn't happen quite happily on my end. Export/Import ldiff's for that.
You probably oughtta be dumping out ldifs periodically for backup purposes anyway - it's a bad thing to directly copy the files for a live database as the only backup. :) Anyway, I'd imagine lots of stuff doesn't move from x86 to IA64 very well. When you go changing the size of index counters, etc, you tend to break stuff...
I never really got SQL working, so I don't know how good that is. But I think NIS has some advantages in specific situations, as I never felt the kind of performance drop with nis as I did with ldap,with the ldb database.
The SQL auth works ok, but the nss libraries just don't seem to work quite completely - and it's tough to determine *which* of the available libraries should be used, given that there are at elast 2 of each, and that both of those usually appear to be dead. I've played with nss_mysql and pam_mysql, never any of the other SQL variants. It's a shame that it's not quite there, because I'm a bit more comfortable dealing with the RDBMS than I am with the LDAP stuff. The LDAP has a bit more "smoke and mirrors" feel to it, for some reason. Maybe that's just me. Regardless, you definately need to use indecies, and you should probably run nscd if you're using any network auth service. That'd probably take care of any slowdown. --Danny
tisdag 02 november 2004 16:28 skrev Danny Sauer:
The SQL auth works ok, but the nss libraries just don't seem to work quite completely - and it's tough to determine *which* of the available libraries should be used, given that there are at elast 2 of each, and that both of those usually appear to be dead. I've played with nss_mysql and pam_mysql, never any of the other SQL variants. It's a shame that it's not quite there, because I'm a bit more comfortable dealing with the RDBMS than I am with the LDAP stuff. The LDAP has a bit more "smoke and mirrors" feel to it, for some reason. Maybe that's just me. Regardless, you definately need to use indecies, and you should probably run nscd if you're using any network auth service. That'd probably take care of any slowdown.
Did you try using ldap with an sql backend? After I setup bdb as an ldap backend, the speed was good ... it's the default ldap database that was slow. I noticed the slowness, because I did setup ldap on my own desktop, while testing and stuff, but when I went into 3D games, there was a "momentary" pause during network play all the time. The reason, was the ldap ... momentary wasn't some huge time, only an instant, but during armyops ... that's enough to get your character killed during combat :-) I did notice however, when I revisited my settings that I had indexed all major attributes, including default as sub, but had failed to specifically index the uid attribute, merely the uidNumber attribute. It may have played a role, but bdb is definately faster but more volatile.
Örn wrote regarding 'Re: [SLE] LDAP vs. NIS Question' on Tue, Nov 02 at 18:53:
tisdag 02 november 2004 16:28 skrev Danny Sauer:
The SQL auth works ok, but the nss libraries just don't seem to work quite completely - and it's tough to determine *which* of the available libraries should be used, given that there are at elast 2 of each, and that both of those usually appear to be dead. I've played with nss_mysql and pam_mysql, never any of the other SQL variants. It's a shame that it's not quite there, because I'm a bit more comfortable dealing with the RDBMS than I am with the LDAP stuff. The LDAP has a bit more "smoke and mirrors" feel to it, for some reason. Maybe that's just me. Regardless, you definately need to use indecies, and you should probably run nscd if you're using any network auth service. That'd probably take care of any slowdown.
Did you try using ldap with an sql backend?
Not for auth. I am, however, using ldap with a perl backend that filters requests to an SQL server. That just exists to allow email clients access to a set of mailing lists stored in a user database. The perfomance on that is good, but it's not heavily used by any means. My users can only send out so much email. :)
After I setup bdb as an ldap backend, the speed was good ... it's the default ldap database that was slow. I noticed the slowness, because I did setup ldap on my own desktop, while testing and stuff, but when I went into 3D games, there was a "momentary" pause during network play all the time. The reason, was the ldap ... momentary wasn't some huge time, only an instant, but during armyops ... that's enough to get your character killed during combat :-)
I did notice however, when I revisited my settings that I had indexed all major attributes, including default as sub, but had failed to specifically index the uid attribute, merely the uidNumber attribute. It may have played a role, but bdb is definately faster but more volatile.
Actually, given that the default config file uses bdb, and that all the docs suggest using bdb, I'd suggest that bdb might be the default... I fail to see why you'd have momentary lags in network play unless something else was running, though. Were you also loking up hosts in LDAP before DNS or something like that? Were you running nscd? Before I got married, I had a roommate that enjoyed FPS-type games, and we'd occasionally have another couple of machines on our in-house network, all running Quake 2/3 (this was a few years ago). I would play on either the LDAP server or a client that used LDAP for auth, and never noticed any kind of delay like what you're mentioning. This was with 6-7 *nix variants all using that LDAP server actively, including a web server authenticating page requests off of it. Granted, this wasn't a super-busy network, but I'd guess there was more traffic (LDAP and otherwise) than a single desktop would generate... :) Anyway, I'm somewhat inclined to believe that there was an error in your test setup. I've run a very active 10K student webmail system with auth and aliases all looked up in a bdb-backed openLDAP server running on the same dual P2-800 machine that was also running postfix, apache, and Imp, and had no noticable authentication delay either on that machine or on the 30-node *nix student lab that also auth'd off that one server. The school later replaced that machine with a more expensive, less stable, generally worse in every way windows solution, but then, that's a rant for another time (and they did it after I left, so it's their problem anyway). My point is that I didn't do anything weird on that - just indexed commonly looked up attrs and ran nscd. I wrote some replacements for the useradd/usermod/etc tools in perl, and it all just worked. 'Course, now the default tools that come with distros work fine, but back then... Oh, I wasn't running TLS or any kind of encryption on the system (used stunnel on the remote machines, though), so maybe that was accounting for some of your delay? --Danny
On 02/11/04 11:47 AM, Örn Hansen
måndag 01 november 2004 19:32 skrev Danny Sauer:
If you plan to work with some antique software (on other operating systems) or stuff that's not PAM/NSS aware, NIS may work better. Then again, NIS sucks in about every way, so LDAP's a much better choice in almost every situation. :)
Well, not always ... LDAP with the built in database (ldb I think it's called), is so slow that it can really make lookups suck ... big time. However, with bdb it's quite fast, but bdb has a lot of drawbacks. A word of caution is not to upgrade a bdb layout from a i386 to a x86_64, that didn't happen quite happily on my end. Export/Import ldiff's for that. I never really got SQL working, so I don't know how good that is. But I think NIS has some advantages in specific situations, as I never felt the kind of performance drop with nis as I did with ldap,with the ldb database.
You can dramatically increase the performance of an ldap database by caching and indexing it. Caching can be done by placing cachesize and dbcachesize into your slapd.conf and giving them a value equal to the largest index file. Index however really increased the performance, at the expense of increasing the time taken to modify attributes, so once your database is setup and filled, add "index default" to the slapd.conf. This will generate an index of all the attributes in your system, to exclude particular ones you can use "index <attribute> none" prior to the index default to remove them from indexing. So long as you dont have a vast database the performance increase is phenominal. Our ldap implimentation, with a userbase of over 3000, had logons of ~15 seconds prior to indexing; now its certainly under a second. Regards, Ben
participants (4)
-
Ben Higginbottom -
Danny Sauer -
Web Developer -
Örn Hansen