I seem to have this very odd issue with CentOS 6 WRT NIS. I have taken the package selection that I used with CentOS 5 and basically plopped it into my C6 kickstart file (see below). On C5 this works just fine and I'm able to log in with NIS credentials just fine. However, it looks like on C6 if you use a package selection like this, you also need to specify the yp-tools package as part of the kickstart *even though* you specify an authentication method of NIS in the kickstart. Seems like a bug to me?!?
auth --useshadow --enablemd5 --enablenis --nisdomain test --nisserver yp.example.com
%packages @core augeas autofs dstat nfs-utils ntp openssh openssh-clients openssh-server portreserve puppet redhat-lsb rsh-server sendmail sendmail-cf sudo sysstat tcp_wrappers wget xinetd yum-utils %end
On Tue, Sep 27, 2011 at 1:55 PM, James A. Peltier jpeltier@sfu.ca wrote:
I seem to have this very odd issue with CentOS 6 WRT NIS. I have taken the package selection that I used with CentOS 5 and basically plopped it into my C6 kickstart file (see below). On C5 this works just fine and I'm able to log in with NIS credentials just fine. However, it looks like on C6 if you use a package selection like this, you also need to specify the yp-tools package as part of the kickstart *even though* you specify an authentication method of NIS in the kickstart. Seems like a bug to me?!?
Current versions of fedora do this as well, in addition to f15 having a buggy startup script for yp*. I agree with you that if you specify auth, the tools for it should be there. That said, NIS needs to die. Quickly.
In article CALSzgHHTWLD-rW1tQ+Z+EUGK+wRRC47ygg31+FC2TrPYp-yZWQ@mail.gmail.com, Jim Perrin centos@centos.org wrote:
... Current versions of fedora do this as well, in addition to f15 having a buggy startup script for yp*. I agree with you that if you specify auth, the tools for it should be there.
That said, NIS needs to die. Quickly.
Why? I'll grant NIS is insecure at best for login auth, and should not be used for that purpose (at least not outside the lab).
But for other purposes e.g. automount maps, NIS is simple and easy and still functional.
I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem?
Cheers, sr.
On Wed, 5 Oct 2011, Steve Rikli wrote:
Why? I'll grant NIS is insecure at best for login auth, and should not be used for that purpose (at least not outside the lab).
But for other purposes e.g. automount maps, NIS is simple and easy and still functional.
I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem?
The problem you get is when you compare it with LDAP.
jh
----- Original Message ----- | On Wed, 5 Oct 2011, Steve Rikli wrote: | | > Why? I'll grant NIS is insecure at best for login auth, and should | > not | > be used for that purpose (at least not outside the lab). | > | > But for other purposes e.g. automount maps, NIS is simple and easy | > and | > still functional. | > | > I'll also readily agree I wouldn't want NIS on internet-facing | > systems, | > but for things like automount maps on the internal corporate LAN, is | > it really a catastropic problem? | | The problem you get is when you compare it with LDAP. | | jh
There is no comparison. NIS is *much* faster than LDAP for these purposes.
On Thu, 6 Oct 2011, James A. Peltier wrote:
| The problem you get is when you compare it with LDAP. | | jh
There is no comparison. NIS is *much* faster than LDAP for these purposes.
And slow (and let's put it into context here, not *that* slow) performance of automount map resolution bites your setup how?
jh
In article alpine.LRH.2.00.1110060937180.9689@pfcpm187.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
On Wed, 5 Oct 2011, Steve Rikli wrote:
... I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem?
The problem you get is when you compare it with LDAP.
Compare in what way? What characteristics are you contrasting? I'm genuinely trying to understand the problem you're talking about for the case I've presented, and pro-con from someone who has done both would be appreciated.
Thanks, sr.
On Thu, 6 Oct 2011, Steve Rikli wrote:
In article alpine.LRH.2.00.1110060937180.9689@pfcpm187.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
On Wed, 5 Oct 2011, Steve Rikli wrote:
... I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem?
The problem you get is when you compare it with LDAP.
Compare in what way? What characteristics are you contrasting? I'm genuinely trying to understand the problem you're talking about for the case I've presented, and pro-con from someone who has done both would be appreciated.
I'm not saying NIS is catastrophically bad for an internal system that you consider to be 'safe', it just comes from a time when security wasn't high up the list of worries. Other than it being easy as cake to setup in the first place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results.
A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP infrastructure you start to discover just how many tools offer some form of LDAP integration. Extending the schema to suit internal uses is also easy, and querying it from within your own apps/scripts is far from difficult.
jh
In article alpine.LRH.2.02.1110062107400.21755@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
...
A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP infrastructure you start to discover just how many tools offer some form of LDAP integration. Extending the schema to suit internal uses is also easy, and querying it from within your own apps/scripts is far from difficult.
Thanks, good perspective.
[ about to display ignorance of LDAP ... ]
So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password?
That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data.
What's the functional equivalent for LDAP automount maps?
Cheers, sr.
On Thu, 6 Oct 2011, Steve Rikli wrote:
So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password?
That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data.
You need an account that can do lookups. Either you have one 'lookup' account that you share between multiple machines, or you do it AD style and have an account per machine. As I do it, this auth is done with a kerberos keytab credential with GSSAPI.
What's the functional equivalent for LDAP automount maps?
Automount maps work just nicely in LDAP, there's a standard schema and you just populate the records and it works.
jh
In article alpine.LRH.2.02.1110062229170.24568@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
On Thu, 6 Oct 2011, Steve Rikli wrote:
So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password?
That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data.
You need an account that can do lookups. Either you have one 'lookup' account that you share between multiple machines,
That's what I thought. But doesn't that "lookup" account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity?
Granted, we're talking about "public data" in this example (i.e. automount map data) so security isn't a concern for that part; but the "lookup" account could potentially be used for other means, yes?
or you do it AD style and have an account per machine.
OK for user workstations, impractical when you're talking about servers, no? Or do I misunderstand your example?
As I do it, this auth is done with a kerberos keytab credential with GSSAPI.
Sounds like I would need to research that, then. This replaces the need for the "lookup" account, or augments it, or something else entirely?
What's the functional equivalent for LDAP automount maps?
Automount maps work just nicely in LDAP, there's a standard schema and you just populate the records and it works.
I grok'd that part; it was the "NIS binding" sort of equivalent behavior that I was specifically interested in for LDAP.
Cheers, sr.
On Thu, 6 Oct 2011, Steve Rikli wrote:
That's what I thought. But doesn't that "lookup" account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity?
Yes. Either you're talking about a samba tdb file, a password in plain text, or a kerberos keytab file. GSSAPI means you don't need to hardcode anything, as it just fishes around in your keytab.
Granted, we're talking about "public data" in this example (i.e. automount map data) so security isn't a concern for that part; but the "lookup" account could potentially be used for other means, yes?
It can be used to do what you grant it access to do (but it can be constrained). That's not worse than NIS.
or you do it AD style and have an account per machine.
OK for user workstations, impractical when you're talking about servers, no? Or do I misunderstand your example?
Account per machine is fine. As part of your install do a 'net ads join' (in AD speak), and you're done. You'll want kerberos credentials per machine anyway, so it's nothing new. Servers more than clients want kerberos credentials, as lots of services can benefit from kerberos authentication (httpd, cups, nfs, ssh, smtp, imap...).
As I do it, this auth is done with a kerberos keytab credential with GSSAPI.
Sounds like I would need to research that, then. This replaces the need for the "lookup" account, or augments it, or something else entirely?
If you're generating a keytab per machine (which you want for kerberised services), then having a credential within that that's able to do lookups isn't a big extra. Look at FreeIPA as suggested, as this wraps all this up and makes it quite straightforward (in much of the same way as MS AD does).
jh
In article alpine.LRH.2.02.1110062331450.27186@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
On Thu, 6 Oct 2011, Steve Rikli wrote:
That's what I thought. But doesn't that "lookup" account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity?
Yes. Either you're talking about a samba tdb file, a password in plain text, or a kerberos keytab file. GSSAPI means you don't need to hardcode anything, as it just fishes around in your keytab.
Granted, we're talking about "public data" in this example (i.e. automount map data) so security isn't a concern for that part; but the "lookup" account could potentially be used for other means, yes?
It can be used to do what you grant it access to do (but it can be constrained). That's not worse than NIS.
Well, somewhat. E.g. my NIS master doesn't need to publish a "passwd" map in order to provide "auto.home" map or whatever, and I don't need a "lookup" account to get at the required data in the case of NIS.
[ other useful info & ideas for research deleted for brevity ]
Thanks for the discussion & sharing the benefits of your experience, John -- much appreciated.
Cheers, sr.
On Fri, 7 Oct 2011, Steve Rikli wrote:
Well, somewhat. E.g. my NIS master doesn't need to publish a "passwd" map in order to provide "auto.home" map or whatever, and I don't need a "lookup" account to get at the required data in the case of NIS.
You could have LDAP that only contained automounter information and you can allow anonymous binds. I don't think you're losing those options.
Thanks for the discussion & sharing the benefits of your experience, John -- much appreciated.
No problem,
jh
On Thu, Oct 06, 2011 at 09:14:35PM +0100, John Hodrien wrote:
place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results.
Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs).
You've never seen unexpected DoS attacks 'cos of "netstat -a" 'cos of all the temporary ports 'cos nscd doesn't cache serv-by-port values when each request is a new port number.
You've never seen...
Oh, never mind.
LDAP (being TCP connection oriented) is a world of hurt when it comes to stability and performance in any large environment. NIS, being UDP, allows you to just "run". (By large, I'm talking 30,000 client machines on 5 continents).
That said:
A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP
This is true. NIS security is awful. Which is why we use LDAP :-)
On Thu, 6 Oct 2011, Stephen Harris wrote:
On Thu, Oct 06, 2011 at 09:14:35PM +0100, John Hodrien wrote:
place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results.
Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs).
As I said with my nscd/sssd comment, you need a client that's not total crap. nss_ldap isn't up to dealing with large ldap setup, especially with nested groups. sssd 1.6.1, suitably configured *is* up to it. I've tested it with give or take 100k users and 100k groups. nscd with nss_ldap isn't up to it, as the caching is done at the wrong time, and it doesn't understand anything about LDAP. I've seen ssh time out with a nss_ldap setup due to a slow initgroups. Your only option there is:
nss_getgrent_skipmembers true
That gets your performance up to a pretty tasty level, but it *will* break some things.
sssd correctly configured gets you to only a small distance behind that setup, but without the breakage, and it handles failures of LDAP servers *much* better.
You've never seen unexpected DoS attacks 'cos of "netstat -a" 'cos of all the temporary ports 'cos nscd doesn't cache serv-by-port values when each request is a new port number.
nscd is a pile of pants, I fully accept.
You've never seen...
Oh, never mind.
LDAP (being TCP connection oriented) is a world of hurt when it comes to stability and performance in any large environment. NIS, being UDP, allows you to just "run". (By large, I'm talking 30,000 client machines on 5 continents).
So with sssd you're looking at persistent connections, sensible failover between servers, and caching that understands the reality of ldap, not just the NSS level. It really is a different world to be playing in. I'd been longing for a better solution, but wasn't totally sold on the nss_ldapd stuff that was lurking. sssd, and the winning attitude of the developers to addressing problems has been a revolution to me. Caching that happens *before* your cache expires... Seriously, sssd ticks so many boxes. If you've not had a look at sssd, *do*, and by all means drop me a line or on the sssd mailing list if you have problems. It's *not* perfect, but from my perspective it's so far towards right I can forgive all the problems.
This is true. NIS security is awful. Which is why we use LDAP :-)
;)
jh
On Thu, Oct 06, 2011 at 10:28:58PM +0100, John Hodrien wrote:
On Thu, 6 Oct 2011, Stephen Harris wrote:
Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs).
As I said with my nscd/sssd comment, you need a client that's not total crap.
Which, up until a few months ago, was "no client". Solaris is crap (they recently rewrote their caching infrastructure to make it better); AIX is crap (with it's own unique solution and persistent connections). HPUX is crap....
Oh wait... what this really means is that _LDAP_ is crap at performance and each and every client needs to have massive kludges and work-arounds (that aren't necessary with NIS) in order to resume some semblence of usability.
And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a "ypmatch" quicker than an ldapsearch.
about LDAP. I've seen ssh time out with a nss_ldap setup due to a slow initgroups. Your only option there is:
nss_getgrent_skipmembers true
You might as well not use secondary groups at all, then!
Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot!
On Thu, 6 Oct 2011, Stephen Harris wrote:
Which, up until a few months ago, was "no client". Solaris is crap (they recently rewrote their caching infrastructure to make it better); AIX is crap (with it's own unique solution and persistent connections). HPUX is crap....
;)
Oh wait... what this really means is that _LDAP_ is crap at performance and each and every client needs to have massive kludges and work-arounds (that aren't necessary with NIS) in order to resume some semblence of usability.
Only I don't buy into that. Too much of NSS assumes that linear searching through the user information is the quickest route, and that's just plain dumb in complicated setups with more advanced sources of information (like LDAP).
And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a "ypmatch" quicker than an ldapsearch.
Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a given department who have access to a given resource and tell me their display name and phone number. ldapsearch makes that simple. If you want to go a step further (and personally I don't) store their ssh public keys in LDAP.
nss_getgrent_skipmembers true
You might as well not use secondary groups at all, then!
I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works perfectly with secondary groups. Unfortunately chgrp and newgrp don't work without patching, which is a pain. But most things do an initgroup and don't worry about the group actually containing no members.
Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot!
Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers?
jh
On Thu, Oct 06, 2011 at 11:17:42PM +0100, John Hodrien wrote:
On Thu, 6 Oct 2011, Stephen Harris wrote:
And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a "ypmatch" quicker than an ldapsearch.
Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so
ldapsearch requires a new TCP connection; slow.
while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a
Compound queries belong in a database.
given department who have access to a given resource and tell me their display name and phone number. ldapsearch makes that simple. If you want to go a
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. ldapsearch adds massive overhead (2 orders of magnitude) to the return. The right tools for the job; fast lightweight efficient protocols for the OS where we get millions of calls; slower heavier weight calls for applications that make calls once a minute or slower.
I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works
getgrnam("foo") to see who is in a group is nice and efficient for a connection that's already open. initgroups (which _has_ to do a while(getrgrent()) loop) is slow. Logins and su and similar do initgroups.
Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot!
Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers?
ldapsearch doesn't use the connection manager. Unless you're now replacing tonnes of tools (and the perl Net::LDAP module and the python module and the apache LDAP module and...)
On Thu, 6 Oct 2011, Stephen Harris wrote:
On Thu, Oct 06, 2011 at 11:17:42PM +0100, John Hodrien wrote:
On Thu, 6 Oct 2011, Stephen Harris wrote:
And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a "ypmatch" quicker than an ldapsearch.
Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so
ldapsearch requires a new TCP connection; slow.
Right, so how often do you want to do a single query where performance is that critical? SSSD maintains connections, so it's not one connection per query. And slow is a very vague term:
time ldapsearch 'cn=someuser' >& /dev/null real 0m0.017s
So with all the GSSAPI authentication and the TCP connection and finding the right entry it takes how long? I know you were talking about more WAN type connections, but persistent connections with SSSD should deal with that performance hit shouldn't it?
while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a
Compound queries belong in a database.
Probably you're right, but as a user of LDAP is sometimes find need to do them, and I'm not going to store the information twice.
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.
ldapsearch adds massive overhead (2 orders of magnitude) to the return. The right tools for the job; fast lightweight efficient protocols for the OS where we get millions of calls; slower heavier weight calls for applications that make calls once a minute or slower.
If there are millions of calls you can't afford to be asking the network, especially on things like this where odds are you're only talking about the value changing relatively rarely.
I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works
getgrnam("foo") to see who is in a group is nice and efficient for a connection that's already open. initgroups (which _has_ to do a while(getrgrent()) loop) is slow. Logins and su and similar do initgroups.
Yes, but relatively few things do the former. You specify AllowGroups blah in sshd_config, and ssh doesn't check who is a member of that group, it does an initgroups instead.
Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot!
Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers?
ldapsearch doesn't use the connection manager. Unless you're now replacing tonnes of tools (and the perl Net::LDAP module and the python module and the apache LDAP module and...)
No, but for a lot of these things querying through nss is an option.
jh
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.
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
On Fri, 7 Oct 2011, Craig White wrote:
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.
We'd found the tradeoffs with using nscd with a large centralised institutional AD directory to be definitely worthwhile. The caching it does is dumb, and it's traditionally been prone to failure (although current versions are far less bad), but it did throw back in necessary speed to the mix.
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.
SSSD keeps a local LDB cache of retreived information, so does indeed maintain a cache and it sensibly updates that cache while not holding up requests for the cached data in a configurable manner. It also caches the nested structure well, by keeping partial caches of accrued data. So I don't really understand why you don't think it's about caching, when that's one of the things it does.
jh
On Thu, Oct 06, 2011 at 07:16:45PM -0700, Craig White wrote:
On Thu, 2011-10-06 at 19:10 -0400, Stephen Harris wrote:
LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work around that fact.
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
*sigh*
I recently stress tested one of our LDAP servers; it handled 100,000 simultaneous collections and performed over 24,000 group "memberid" searches per second.
The servers are fast.
The protocol is heavy and slow. You can only get that sort of performance with persistent connections; ie client side kludges.
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.
If you want to install software on 30,000 machines... yet another kludge.
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.
It's _essential_ for reasonable LDAP performance. Back in the good ol' days of NIS, "nscd" got the nickname of "Needless Sun Complexity Daemon" because it was optional and caused more problems than it was worth. Everyone disabled it. With LDAP if you don't have nscd then your performance drops massively and you put a much larger load onto your LDAP servers.
SSD really isn't about user/group caching and I'm not sure how that
SSSD is the RedHat 6 replace for nscd; it replaces nscd for LDAP communication and caching.
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.
... and we drop into ad hominem attacks.
FWIW, anyone can do these tests. Write a loop that does 10,000 ypmatch's and a loop that does 10,000 ldapsearches. Time 'em. Oh. (Run "netstat -an" and watch the tcp sockets! Oh!!). This demonstrates the utter essential nature of nscd. Now with nscd with services configured for LDAP in nsswitch and run 20 'netstat -a' commands (without the 'n' option, to force getservbyport() queries). Whee. (Maybe this has been fixed, now; we bitched enough at Sun and RedHat). Create a /home with 10,000 users and do an "ls -l". Awww...
Do the same tests against NIS and watch speeds come up. It's possible for NIS to be _faster_ (even without nscd) than even a local passwd and group file 'cos the NIS maps have a primary index and are built in multiple ways (passwd.byname, passwd.byuid for example). LDAP has indexes (multiple indexes!), but the protocol slows you down.
Note: I'm not saying "don't use LDAP". LDAP is so much more superior than NIS in almost every respect, except speed. Work hard on those kludges (nscd,sssd,ldapcachemgr etc) to bring performance back to a reasonable level. Use LDAP profiles to automatically configure clients to the closest servers, and so on. You'll get a usable LDAP infrastructure. Just it's now more complicated than NIS and has more failure modes as a result.
LDAP is definitely a case of 2 steps forward, 1 step back.
On Fri, Oct 07, 2011 at 07:19:20AM -0400, Stephen Harris wrote:
I recently stress tested one of our LDAP servers; it handled 100,000 simultaneous collections and performed over 24,000 group "memberid" searches per second.
Correction; we had 100,000 simultaneous clients; 55,000 bound simultaneously, the rest were queued. That's a socket limitation on the server. Not one I'd hit practically (we load balance).
On Fri, 7 Oct 2011, Stephen Harris wrote:
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.
In one sense yes, but I don't necessarily see any sense in an 'ls -l' in a lively directory causing *that* many hits to the information provider every time when user information changes rarely.
LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work around that fact.
It all depends on your definition of slow.
$ time ldapsearch 'cn=someuser' >& /dev/null
real 0m0.016s
That's not so bad for a LDAP server with ~100k users is it?
jh
On 09/27/2011 11:55 AM, James A. Peltier wrote:
I seem to have this very odd issue with CentOS 6 WRT NIS. I have taken the package selection that I used with CentOS 5 and basically plopped it into my C6 kickstart file (see below). On C5 this works just fine and I'm able to log in with NIS credentials just fine. However, it looks like on C6 if you use a package selection like this, you also need to specify the yp-tools package as part of the kickstart *even though* you specify an authentication method of NIS in the kickstart. Seems like a bug to me?!?
since you mention nis, i'll guess you use automount as well. so be warned that centos 6 has some issues with automount. if automount requests are made rapidly (like on a mail server delivery to a large alias), it will quickly start failing to mount directories and get stuck that way for minutes. i don't have access to r*dh*t box to determine if this has been fixed with all the 6.1 updates. needless to say i can't roll out centos 6 yet.
i have filed a centos bug (4984), but since i can't compare against upstream, i don't know for sure where the problem lies.
Hi Joe,
Le 29/09/2011 18:18, Joe Pruett a écrit :
since you mention nis, i'll guess you use automount as well. so be warned that centos 6 has some issues with automount. if automount requests are made rapidly (like on a mail server delivery to a large alias), it will quickly start failing to mount directories and get stuck that way for minutes. i don't have access to r*dh*t box to determine if this has been fixed with all the 6.1 updates. needless to say i can't roll out centos 6 yet.
Did you try to install the CentOS 6 CR repo (continuous releaes), which brings to 6.0 the updates from 6.1 ? See : https://www.centos.org/modules/newbb/viewtopic.php?topic_id=33458&forum=...
See if it solves the problem.
Alain
On 09/29/2011 09:23 AM, Alain Péan wrote:
Hi Joe,
Le 29/09/2011 18:18, Joe Pruett a écrit :
since you mention nis, i'll guess you use automount as well. so be warned that centos 6 has some issues with automount. if automount requests are made rapidly (like on a mail server delivery to a large alias), it will quickly start failing to mount directories and get stuck that way for minutes. i don't have access to r*dh*t box to determine if this has been fixed with all the 6.1 updates. needless to say i can't roll out centos 6 yet.
Did you try to install the CentOS 6 CR repo (continuous releaes), which brings to 6.0 the updates from 6.1 ? See : https://www.centos.org/modules/newbb/viewtopic.php?topic_id=33458&forum=...
See if it solves the problem.
sorry, forgot to mention that i have applied the cr updates. but i don't think the cr has everything from 6.1 yet (no new kernel, which i'd guess there will be). since the devs are still having issues with getting 6.1 to fully compile, i expect more packages to show up. there was an autofs update, but that didn't help the situation.
Okay, I'm getting frustrated here. C6 has been a bit of a bear. It looks like I am also having trouble with rsh on C6 with just @core as well. At least with the NIS stuff I was able to determine rather easily why it wasn't working, but with rsh on workstation working and only on my server with @core, I can't seem to figure out what the package is that I am missing to make rsh on C6 work. Hints please...
----- Original Message ----- | Okay, I'm getting frustrated here. C6 has been a bit of a bear. It | looks like I am also having trouble with rsh on C6 with just @core as | well. At least with the NIS stuff I was able to determine rather | easily why it wasn't working, but with rsh on workstation working and | only on my server with @core, I can't seem to figure out what the | package is that I am missing to make rsh on C6 work. Hints please...
BTW: This is all I get
Oct 10 21:24:31 daat xinetd[2203]: bind failed (Address already in use (errno = 98)). service = shell Oct 10 21:24:31 daat xinetd[2203]: Service shell failed to start and is deactivated. Oct 10 21:24:31 daat xinetd[2203]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in. Oct 10 21:24:31 daat xinetd[2203]: Started working: 2 available services Oct 10 21:26:41 daat rsyslogd: Framing Error in received TCP message: delimiter is not SP but has ASCII value 0. Oct 10 21:32:23 daat rsyslogd: Framing Error in received TCP message: delimiter is not SP but has ASCII value 0.
Fresh install using following packages
%packages @core augeas autofs dstat nfs-utils ntp openssh openssh-clients openssh-server portreserve puppet redhat-lsb rsh-server sendmail sendmail-cf sudo sysstat tcp_wrappers wget xinetd yp-tools yum-utils %end
On 10/10/11 9:39 PM, James A. Peltier wrote:
It looks like I am also having trouble with rsh on C6 ...
rsh was deprecated 10+ years ago, along with all the other r things... they aren't even remotely secure and using them is sloppy practice, even on a private network.
----- Original Message ----- | On 10/10/11 9:39 PM, James A. Peltier wrote: | > It looks like I am also having trouble with rsh on C6 ... | | | rsh was deprecated 10+ years ago, along with all the other r things... | they aren't even remotely secure and using them is sloppy practice, | even | on a private network. | | | | -- | john r pierce N 37, W 122 | santa cruz ca mid-left coast | | _______________________________________________ | CentOS mailing list | CentOS@centos.org | http://lists.centos.org/mailman/listinfo/centos
Tell that to the engineering software vendors who require the service in order to properly operate. If I didn't already know that, obviously I wouldn't be posting this as I use SSH keys for most other services.
On Mon, Oct 10, 2011 at 10:12 PM, James A. Peltier jpeltier@sfu.ca wrote:
----- Original Message ----- | On 10/10/11 9:39 PM, James A. Peltier wrote: | > It looks like I am also having trouble with rsh on C6 ...
| rsh was deprecated 10+ years ago, along with all the other r things... | they aren't even remotely secure and using them is sloppy practice, | even | on a private network.
Tell that to the engineering software vendors who require the service in order to properly operate. If I didn't already know that, obviously I wouldn't be posting this as I use SSH keys for most other services.
I am exactly in the same situation. Our IT department allows access to their tape archiver only by way of '/usr/bin/rsh server command'. For well >15 years now.
In my case, what I needed to get it to work was :
(1) install /usr/bin/rsh by 'yum install rsh'
(2) Add the following to iptables :
-A INPUT -p tcp -m state --state NEW -m tcp -s [server IP] --dport 1011:1023 -j ACCEPT
You may want to adjust the port range by examining the ports used for inbound connections from the server.
Hope this helps,
Akemi
----- Original Message ----- | On Mon, Oct 10, 2011 at 10:12 PM, James A. Peltier jpeltier@sfu.ca | wrote: | > ----- Original Message ----- | > | On 10/10/11 9:39 PM, James A. Peltier wrote: | > | > It looks like I am also having trouble with rsh on C6 ... | | > | rsh was deprecated 10+ years ago, along with all the other r | > | things... | > | they aren't even remotely secure and using them is sloppy | > | practice, | > | even | > | on a private network. | | > Tell that to the engineering software vendors who require the | > service | > in order to properly operate. If I didn't already know that, | > obviously | > I wouldn't be posting this as I use SSH keys for most other | > services. | | I am exactly in the same situation. Our IT department allows access to | their tape archiver only by way of '/usr/bin/rsh server command'. For | well >15 years now. | | In my case, what I needed to get it to work was : | | (1) install /usr/bin/rsh by 'yum install rsh' | | (2) Add the following to iptables : | | -A INPUT -p tcp -m state --state NEW -m tcp -s [server IP] --dport | 1011:1023 -j ACCEPT | | You may want to adjust the port range by examining the ports used for | inbound connections from the server. | | Hope this helps, | | Akemi
Did you install just @core? I have done @core as described earlier with rsh and rsh-server and it just hangs so I'm missing something. On the workstation install it works using the exact same setup so I think I'm missing a package somewhere, I'm just not sure which one.
On Tue, Oct 11, 2011 at 9:12 AM, James A. Peltier jpeltier@sfu.ca wrote:
Did you install just @core? I have done @core as described earlier with rsh and rsh-server and it just hangs so I'm missing something. On the workstation install it works using the exact same setup so I think I'm missing a package somewhere, I'm just not sure which one.
Mine is more like a workstation type install.
Akemi
----- Original Message ----- | On Tue, Oct 11, 2011 at 9:12 AM, James A. Peltier jpeltier@sfu.ca | wrote: | | > Did you install just @core? I have done @core as described earlier | > with rsh and rsh-server and it just hangs so I'm missing something. | > On the workstation install it works using the exact same setup so I | > think I'm missing a package somewhere, I'm just not sure which one. | | Mine is more like a workstation type install. | | Akemi
Drat!
Vreme: 10/11/2011 06:59 PM, James A. Peltier piše:
----- Original Message ----- | On Tue, Oct 11, 2011 at 9:12 AM, James A. Peltierjpeltier@sfu.ca | wrote: | |> Did you install just @core? I have done @core as described earlier |> with rsh and rsh-server and it just hangs so I'm missing something. |> On the workstation install it works using the exact same setup so I |> think I'm missing a package somewhere, I'm just not sure which one. | | Mine is more like a workstation type install. | | Akemi
Drat!
Maybe attempt to build rsh*.src.rpm would reveal missing dependencies?
On Tue, Oct 11, 2011 at 12:39 AM, James A. Peltier jpeltier@sfu.ca wrote:
Okay, I'm getting frustrated here. C6 has been a bit of a bear. It looks like I am also having trouble with rsh on C6 with just @core as well. At least with the NIS stuff I was able to determine rather easily why it wasn't working, but with rsh on workstation working and only on my server with @core, I can't seem to figure out what the package is that I am missing to make rsh on C6 work. Hints please...
Use "which rsh" to see what binary each is running. Your workstation install might be using the kerberos version. Here is what Centos 5 has to say:
$ which rsh /usr/kerberos/bin/rsh $ rpm -q --whatprovides /usr/kerberos/bin/rsh krb5-workstation-1.6.1-62.el5 $ rpm -q --whatprovides /usr/bin/rsh rsh-0.17-40.el5
Notice that the kerberos version is first in the path.
----- Original Message ----- | On Tue, Oct 11, 2011 at 12:39 AM, James A. Peltier jpeltier@sfu.ca | wrote: | > Okay, I'm getting frustrated here. C6 has been a bit of a bear. It | > looks like I am also having trouble with rsh on C6 with just @core | > as well. At least with the NIS stuff I was able to determine rather | > easily why it wasn't working, but with rsh on workstation working | > and only on my server with @core, I can't seem to figure out what | > the package is that I am missing to make rsh on C6 work. Hints | > please... | > | | Use "which rsh" to see what binary each is running. Your workstation | install might be using the kerberos version. Here is what Centos 5 | has to say: | | $ which rsh | /usr/kerberos/bin/rsh | $ rpm -q --whatprovides /usr/kerberos/bin/rsh | krb5-workstation-1.6.1-62.el5 | $ rpm -q --whatprovides /usr/bin/rsh | rsh-0.17-40.el5 | | Notice that the kerberos version is first in the path. | | -- | William Hooper
I'm just using /usr/bin/rsh, so the non-kerberized version in both locations
-
Akemi Yagi -
Alain Péan -
Craig White -
James A. Peltier -
Jim Perrin -
Joe Pruett -
John Hodrien -
John R Pierce -
Ljubomir Ljubojevic -
sr＠genyosha.net -
Stephen Harris -
William Hooper