Ö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