Why does initgroups() do yp_all() instead of yp_match()?
Gary Mills
reads the entire NIS group.byname map, instead of looking up the
information for the one specific user? I'm using NIS as an example
here, but the same thing would apply to other network databases, such
as NIS+ or LDAP. initgroups() appears to enumerate the entire
group.byname with yp_all(). Surely, there are other NIS maps that
can return the group list for a specific user with a single yp_match()
call. Is there a reason why initgroups() doesn't do this?
I noticed this problem because we have a cron command that runs every
five minutes on all of our workstations. They are synchronized with
NTP, so the cron commands all start at exactly the same instant.
cron does an initgroups() before it runs each command, so we have a
sudden large number of TCP RPC requests to the NIS server, all
to read the group.byname map. There are so many that ypserv
momentarily runs out of file descriptors. Staggering the times of
the cron commands will fix the problem, but overall performance would
certainly be better if initgroups() didn't behave that way.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Casper H.S. Dik - Network Security Engineer
mi...@cc.umanitoba.ca (Gary Mills) writes:
>Does anyone know why, on Solaris, the initgroups() library function
>reads the entire NIS group.byname map, instead of looking up the
>information for the one specific user? I'm using NIS as an example
>here, but the same thing would apply to other network databases, such
>as NIS+ or LDAP. initgroups() appears to enumerate the entire
>group.byname with yp_all(). Surely, there are other NIS maps that
>can return the group list for a specific user with a single yp_match()
>call. Is there a reason why initgroups() doesn't do this?
WHich map would that be? By default, there isn't on except the
netid nismap which often isn't kept or not kept uptodate.
>I noticed this problem because we have a cron command that runs every
>five minutes on all of our workstations. They are synchronized with
>NTP, so the cron commands all start at exactly the same instant.
>cron does an initgroups() before it runs each command, so we have a
>sudden large number of TCP RPC requests to the NIS server, all
>to read the group.byname map. There are so many that ypserv
>momentarily runs out of file descriptors. Staggering the times of
>the cron commands will fix the problem, but overall performance would
>certainly be better if initgroups() didn't behave that way.
I think there is or will be a method to enable netid searches, but
it isn't available everywhere (ther eare point patches for older
releases)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Chris Thompson
Casper H.S. Dik - Network Security Engineer <Caspe...@Holland.Sun.Com> wrote:
>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
>
>mi...@cc.umanitoba.ca (Gary Mills) writes:
>
>>Does anyone know why, on Solaris, the initgroups() library function
>>reads the entire NIS group.byname map, instead of looking up the
>>information for the one specific user? I'm using NIS as an example
>>here, but the same thing would apply to other network databases, such
>>as NIS+ or LDAP. initgroups() appears to enumerate the entire
>>group.byname with yp_all(). Surely, there are other NIS maps that
>>can return the group list for a specific user with a single yp_match()
>>call. Is there a reason why initgroups() doesn't do this?
>
>WHich map would that be? By default, there isn't on except the
>netid nismap which often isn't kept or not kept uptodate.
The Sun-supplied /var/yp/Makefile would keep it "uptodate".
>>I noticed this problem because we have a cron command that runs every
>>five minutes on all of our workstations. They are synchronized with
>>NTP, so the cron commands all start at exactly the same instant.
>>cron does an initgroups() before it runs each command, so we have a
>>sudden large number of TCP RPC requests to the NIS server, all
>>to read the group.byname map. There are so many that ypserv
>>momentarily runs out of file descriptors. Staggering the times of
>>the cron commands will fix the problem, but overall performance would
>>certainly be better if initgroups() didn't behave that way.
>
>I think there is or will be a method to enable netid searches, but
>it isn't available everywhere (ther eare point patches for older
>releases)
That's good news, if true: please tell us more!
This is notoriously one of the things we lost by moving from SunOS4
to Solaris2. The former used the netid map to implement initgroups().
[Well, except for root logins, which thereby became abominably slow,
until that was fixed in 100891-08, bugid 1041054 ... ah, happy days:-)]
Chris Thompson
Email: cet1 [at] cam.ac.uk
Casper H.S. Dik - Network Security Engineer
cet1-...@cam.ac.uk.invalid (Chris Thompson) writes:
>That's good news, if true: please tell us more!
Might not be until the next OS release, but it could make an
update. There will be an /etc/default file to control the behaviour.
>This is notoriously one of the things we lost by moving from SunOS4
>to Solaris2. The former used the netid map to implement initgroups().
>[Well, except for root logins, which thereby became abominably slow,
>until that was fixed in 100891-08, bugid 1041054 ... ah, happy days:-)]
NIS does update netid, as long as you type "make" and not "make group".
However, NIS+ doesn't automatically update the cred table, and that's
why the use of netid was removed.