[comp.sys.sequent] passwd hashing

jef@surf.ee.lbl.gov (Jef Poskanzer) (04/23/89)

I just finished helping the WELL switch from a VAX 750 to a Sequent
Balance 8.  There were practically no glitches, and overall I'm very
happy with the new system.  However, there is one annoying problem I
haven't figured out yet.  See, the WELL's /etc/passwd has almost 3000
entries, so the usual method of accessing it is insufficient.  The simple
linear scan normally used can take up to 10 seconds on a lightly loaded
system.  (I haven't tried it on a heavily loaded system yet because I
haven't managed to get the load average above 1.6...)

Anyway, Sequent assured us that we could simply install yellow pages,
with its dbm-ized files, and all programs that ask for passwd entries
would automatically use it.  Well, I configured the kernel with "options
NFS", I did the ypinit, I enabled ypserv and ypbind in rc.local and
rebooted, I tried editting /etc/passwd and then doing a "cd /etc/yp;
make passwd", and everything looked hunky dory.

However, when I tested it out by fingering the last person in /etc/passwd,
it still took 10 seconds.  Same for logging in as him.  It's as if nothing
changed.

I have no idea what could be wrong.  Any clues?
---
Jef

            Jef Poskanzer   jef@helios.ee.lbl.gov   ...well!pokey
                     "Would you buy that for a quarter?"

yuf@mentor.cc.purdue.edu (Kyle Grieser) (04/26/89)

In article <2470@helios.ee.lbl.gov> Jef Poskanzer <jef@helios.ee.lbl.gov> writes:
>I have no idea what could be wrong.  Any clues?

	I am not sure that I can be of any help, but I recently did alot of
work with our accounting system.  We made everything use the 4.3 ndbm routines,
but we don't use yp.  The only thing that I can think might stop finger (along
with other programs) from using the dbm-ized data is that the getpwnam() and
getpwuid() routines in libc aren't smart enough to use it.  Are you sure you
compiled these with the knowledge of dbm?  Or, does the use of yellow-pages
take care of this for you?  Since I haven't worked with yp I am not sure of what
might or might not be affected by it.

-----
Kyle Grieser,  Purdue University Computing Center
mentor.cc.purdue.edu!yuf, yuf@mentor.cc.purdue.edu

csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/26/89)

In article <2470@helios.ee.lbl.gov> Jef Poskanzer <jef@helios.ee.lbl.gov> writes:
>(I haven't tried it on a heavily loaded system yet because I
>haven't managed to get the load average above 1.6...)

There's a reason for that. Dynix divides the load average by the number of
CPUs you have. If uptime(1) displays 1.6, and you have four CPUs, then the
load average is really 6.4.

<csg>

hoyt@polyslo.CalPoly.EDU (Sir Hoyt) (04/26/89)

In article <67727@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>There's a reason for that. Dynix divides the load average by the number of
>CPUs you have. If uptime(1) displays 1.6, and you have four CPUs, then the
>load average is really 6.4.

	I think they do something else too.  I have done a

		while( 1 ) fork();

	on a Sequent, and the load never went above 3.4. Yet
	vmstat should a run queue of 99.  So one wounders what else
	they do to the load average.....

	Oh yes, the Sequent had 10 CPUs.

><csg>

-- 
John H. Pochmara				 A career is great, 
UUCP: {csun,voder,trwind}!polyslo!hoyt		 But you can't run your 
Internet: hoyt@polyslo.CalPoly.EDU		 fingers through its hair
							-Graffiti 4/13/83

edb@fai.UUCP (Edward Bunch) (04/27/89)

In article <2470@helios.ee.lbl.gov> Jef Poskanzer <jef@helios.ee.lbl.gov> writes:
>I just finished helping the WELL switch from a VAX 750 to a Sequent
>Balance 8.  See, the WELL's /etc/passwd has almost 3000
>entries, so the usual method of accessing it is insufficient.  The simple
>linear scan normally used can take up to 10 seconds on a lightly loaded
>system.
>Anyway, Sequent assured us that we could simply install yellow pages,
>with its dbm-ized files, and all programs that ask for passwd entries
>would automatically use it. 
>However, when I tested it out by fingering the last person in /etc/passwd,
>it still took 10 seconds.  Same for logging in as him.  It's as if nothing
>changed.
>I have no idea what could be wrong.  Any clues?

Your problem is that login checks /etc/passwd first, before checking with
YP. What you need to do is create a file /etc/yppasswd for all the accounts,
except root and other admin stuff. Edit /etc/yp/Makefile so that it uses
/etc/yppasswd instead. Oh, and you'll probably have to put a magic cookie at
the tail of /etc/passwd to enable YP lookups. I could not find reference to
this in the Sequent doc's I checked but it's probably the same as Sun's.
+::0:0:::
Sorry, I have not done this myself and can't provide a patch. Our system
has only 100 or so users and login is quite fast.


Edward A. Bunch                         UUCP: {uunet,amdahl,sun}!fai!edb
??Fujitsu America, Inc.??               DOMAIN: edb@fai.com
??Computer Support and Administration.??Can't you hear it comming.

jef@ace.ee.lbl.gov (Jef Poskanzer) (05/01/89)

My thanks to all who replied.  The correct solution was to put the
"+::0:0:::" line near the beginning of /etc/passwd, instead of its
usual place at the end.

What apparently happens is: a yp-linked program reads /etc/passwd as
far as the + line, then asks ypbind for the info; ypbind asks ypserv,
which happens to be running on the same machine; ypserv looks it up
in the dbm database; and the program that built the dbm database ignored
the + line.

Interestingly, Sequent's version of finger seems to have a bug that
prevents "finger -m user" from taking advantage of the speedup.  I got
mail from phils@sequent saying that finger loops through every passwd
entry, so yp wouldn't help much; I replied to him that finger -m does
no such thing, but he insisted that it does.  Well, I believe him now.
After getting yp working (as verified by huge speedups in login, ls -l,
etc.), finger -m was still slug-like.  But when I brought over the latest
BSD version and compiled it up (no errors), it was nice and fast.
---
Jef

            Jef Poskanzer   jef@helios.ee.lbl.gov   ...well!pokey
                            "Mistakes were made."