Are we hitting a NIS limit?

Are we hitting a NIS limit?

Post by Chin Fa » Sat, 20 May 2000 04:00:00



My colleague and I were trying to figure out how many password entries
the NIS package in Solaris 8 could support.  So, we wrote a script that
automatically created password entries, and periodically cd /var/yp, make
passwd.

Once the number of entries were in the 30 thousands, we kept getting
errors like the following:

problem storing 31515 ncetxlgf:*LK*:31515:3000:gdmmxmtquptoruse:/users/home/teacup2/ncetxlgf:/bin/false
*** Error code 1 (ignored)
Broken Pipe
NIS make terminated: passwd.time

*** passwd.time removed.

We checked:

1. nawk is not the culprit (we used gawk, same error)
2. make is not the culprit (gmake got the same error)
3. the line itself is not the culprit (removing it,
   got a similar error somewhere else)

So we were led to believe that there is a NIS limit that is playing
tricks on us. Unfortunately, searching through sunsolve didn't uncover
anything, so we are turning this list and see if anyone has seen it,
and whether there is a get around.

We would be appreciative for any info that might help us in resolving
this issue.

Sincerely,

Chin Fang

 
 
 

Are we hitting a NIS limit?

Post by Kjetil Torgrim Homm » Sun, 21 May 2000 04:00:00


[Chin Fang]

Quote:>   Once the number of entries were in the 30 thousands, we kept getting
>   errors like the following:

>   problem storing 31515 ncetxlgf:*LK*:31515:3000:gdmmxmtquptoruse:/users/home/teacup2/ncetxlgf:/bin/false
>   *** Error code 1 (ignored)
>   Broken Pipe
>   NIS make terminated: passwd.time

>   *** passwd.time removed.

>   We checked:

>   1. nawk is not the culprit (we used gawk, same error)
>   2. make is not the culprit (gmake got the same error)
>   3. the line itself is not the culprit (removing it,
>      got a similar error somewhere else)

You have probably run into a limit in the dbm hashing function.  Our
University uses the Linux NIS implementation (which is based on gdbm)
on all NIS servers to circumvent this limitation.

Kjetil T.

 
 
 

Are we hitting a NIS limit?

Post by Rob McMaho » Wed, 31 May 2000 04:00:00



Quote:> The message comes from makedbm(1m).  The limitation, as described in
> dbm_clearerr(3c), is

>      The sum of the sizes of a key/content pair must not exceed the internal
>      block size (currently 1024 bytes). Moreover all key/content pairs that
>      hash together must fit on a single block.  dbm_store() will return an
>      error in the event that a disk block fills with inseparable data.

> Just when the second of those two limitations might apply is not readily
> predictable (hashing, remember?).  The workaround is to use some other
> naming service, like NIS+.

A trick (sorry, I've forgotten who said this), is to change the NIS Makefile
for the passwd.byuid map (the one that usually overflows).  Not all the fields
are used significantly, and if you drop the useless ones you can get a lot
further.  We were having this trouble, and changing the line in our Makefile
to look like this (without the wrapping) has fixed the problem.

(nawk 'BEGIN { FS=":"; OFS=":" } /^[a-zA-Z0-9_]/ { printf "%-10d\t", $$3;
print $$1 ":x:" $$3 ":" $$4 "::" $$6 ":" }' $(PWDIR)/passwd $(CHKPIPE)) |
$(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byuid;

Adjust to taste.  We're running at 31,000 users at the moment without any
problems.

Rob
--
INET:   Rob.McMahon near warwick.ac.uk          PHONE:  +44 24 7652 3037
Rob McMahon, IT Services, Warwick University, Coventry, CV4 7AL, England

 
 
 

1. Bizarre NIS+ problem - nisdefaults thinks I am NIS+ master principal

Maybe I shouldn't have experimented.... :(

I was looking at NIS+ security issues, and wanted to check some things
out.  I am a member of the admin NIS+ group, and I used nistbladm to
change my uid in the passwd table to 0 - which worked.  Nisdefaults
says my principal name is the same as the root master server
(master.domain.com rather than user.domain.com).  But permissions
loopholes aside, after I finished my experiment, I changed my uid back
to what it was, and did a nisping -Cf to propagate the change.  Now
the fun starts.

I login again, and notice that nisdefaults says I am still the same
principal as master.domain.com.  Hmmmm, this is not right.  So I
rebooted the master.  Login afer reboot, nisdefaults says the same
thing.  So I logged in as root, removed myself from the admin group,
and used nistbladm and nisaddcred to completely remove myself from the
passwd and cred table, and also remove the entry in the group table
that makes me a member of group 0.  Nisping -Cf to force the update.
Now I created my account all over again, with nistbladm on the passwd
table, then nisaddcred for DES and LOCAL credentials, and finally
nispasswd to add my password.  Nisping -Cf to propagate the changes,
and login as myself.  Nisdefaults STILL says my principal name is the
same as the master.domain.com!

SO - lets see if I screwed something up.  I removed my account again
with nistbladm/nisaddcred, and then created a new account with an
extra letter - instead of "mikebat" I created "mikebatt" (two "t's").
I also created it with a different uid than before, changed the
ownership on my home directory, and logged in.  Same problem - I am
the same principal as the master.domain.com.

OK, well perhaps nistbladm/nisaddcred are doing something funky here.
Let's try nisaddent.  I dumped the shadow, passwd, netid and publickey
tables, edited them to leave only my own account in them, removed my
account from the active tables, and then used nisaddent to add them
back from the files I just dumped and edited.  Same problem.

So I created a completely new account with the name "testuser",
different uid, different home directory.  Used nisaddcred and
nispasswd to finish the setup, and logged in as "testuser".
Nisdefaults says I am testuser.domain.com, just as it should.  Hmmmm,
well that's what's supposed to happen.

So now I delete the "mikebatt" account again, and then use nistbladm
to rename the testuser account to mikebat, and also to change the uid,
gcos, home, etc to correspond to me.  I also make the same changes in
the cred table using nistbladm.  Nisping -Cf to propagate, login as
myself, and - you guessed it - nisdefaults says I am the same
principal name as the master.domain.com.

WTF, over?

--
Mike Batchelor, Staff Engineer
NAI Technologies, Inc., Columbia, Maryland
My opinions are my own, I do not speak for NAI.

2. PK Electronics: BlackoutBuster Standby UPS

3. Why am I getting hits on port 119?

4. Desperate for help with failure in running lpsched!!

5. NIS question (2): limit access from NIS-client pc

6. Star Office Questions...

7. Hitting Telnet connection limit???

8. detecting death of socket

9. SPICE3 simulation hits 2Gb file limit

10. Hitting the 2Gig file limit in 2.5.1 ...

11. limiting hits to virtual

12. HELP: Hitting the 32767 inode limit in a directory

13. tc and bandwidth limiting: What am I doing wrong?