On Thu, 2011-10-06 at 19:10 -0400, Stephen Harris wrote: > On Thu, Oct 06, 2011 at 11:47:21PM +0100, John Hodrien wrote: > > On Thu, 6 Oct 2011, Stephen Harris wrote: > > > > > I wouldn't do that in NIS. Why would my OS care about it?. But I would > > > do "tell me the path to the latest version of application X" 100s of times > > > per minute. > > > > Which should all be cached at the client side. > > You're missing the point. If the query was sufficiently fast then you > don't _need_ to worry about caching, and thus cache coherency, speed of > propagation of changes, inconsistent results between machines etc etc. > > Caching is a _kludge_ to hide an underlying problem. It adds complexity > and additional failure modes. > > LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work > around that fact. > > And the whole world isn't nss. > > The reality is that we're screwed; LDAP became the God Of Naming Services and > everybody rushed into it (didn't help that Sun's NIS+ was just plain bloody > awful). And so we're paying the price; caching has become essential. > > We (where I work) moved into LDAP a decade ago. And it's only now that the > OS performance is beginning to approach that of a NIS client. ---- OpenLDAP is highly optimized and very fast and can search a large DSA much quicker than you can search a large passwd/group setup. Maybe the LDAP setup at your workplace is really slow but it might be a mistake to characterize all LDAP services as slow. I find Fedora DS (aka 389, formerly the Netscape DS) to be considerably slower than OpenLDAP but not every puts the ultimate premium on LDAP speed. For the record... ldap does have a 'socket' mode that one can use on a local machine where speed is of the essence so that sort of blunts the point you are trying to make about TCP/IP speeds. I would agree with NSCD adding additional mode failures. I try not to use it. I know nothing at all about other cache technologies for LDAP. SSD really isn't about user/group caching and I'm not sure how that worked its way in here. http://fedoraproject.org/wiki/Features/SSSD In reality, you're going to have to use something like libnss or sssd for any alternative authentication system. What I see is that the hardware is sufficiently fast enough to tolerate latency via virtualization in favor of flexibility, mobility, disaster recovery, etc. and speed is clearly not the only thing and often not the most important thing. Personally, I think you are making a fallacious argument and offering no empirical evidence, no comparison testing methodology and no evidence of anything worthwhile to consider. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.