SUMMARY: slow password changes

The question was about slow password changes. The original question
wording is at the end. The most common suggest was to use LDAP, which is
the direction we're headed but we aren't ready to jump there right away.

One suggestion was to order older entries to the end to speed up logins,
but even with 30,000 entries our logins are acceptably fast. It's just
the password changes that are slow.

At this time, I don't have an interim solution, although I may fiddle
with the ideas from vogelke@april.dnaco.net. We're going to
live with it for a while.

Thanks for the help.




---------- Individual summaries --------------

>From rlarson@foc.com  Fri May 24 15:51:56 2002
I would recommend something like ldap to store that amount information.
It can also be used to store other information about each student, like
email address, mail address, etc.

>From LParkins@niaid.nih.gov  Fri May 24 16:26:46 2002

Some Unices keep large password files in a hash database (dbm) to speed up
access and updates.  The equivalent in Solaris seems to be NIS+, where
passwords are kept in a database.  NIS+ is a bit of a headache to set up but
then it is a client-server system that permits network-wide logins.  In
NIS+, all network user authentication data is stored in a database rather
than files: the local passwd file contains only system maintenance and
daemon accounts.

I haven't used NIS+ on Solaris in a system with more than a thousand
accounts, but the dbm-style password file management in Tru64 worked fine
for 7000 users at a university.  On the Tru-64 system, we had a separate
home-grown front-end to generate new accounts and passwords and spool them
into the password/security database, so there was no delay, even though the
old-style legacy text passwd file was maintained.  Any kind of database
access has to be faster and more efficient, since the 'files' version needs
to read and write the entire file for each transaction.

>From al@logical-approach.com  Fri May 24 23:07:10 2002

Move to LDAP - now bundled with Sol 9 as the iPlanet Directory Server IIRC.
LDAP is the best long term solution - anything else would be a quick fix
that'll come back to bite you.

>From vogelke@april.dnaco.net  Sat May 25 20:35:33 2002

   Yup.  When password files get that big, linear search/replace starts to
   break down.  You have several choices:

   * For heaven's sake, stay away from NIS/NIS+.  It doesn't scale and it's
     a nightmare to maintain.

   * Put your /etc/{passwd,shadow} files in a database like Postgres, and
     regenerate the flat files periodically.  It's certainly doable, but
     will require someone to learn and install Postgres.  Plus, you'll have
     to change "passwd" to update the database instead of the flat file.

   * Use something like LDAP to handle your authentication.  It's supported
     by Sun, but you may have to deploy something like Iplanet.
     http://www.sun.com/software/solutions/blueprints/1000/ldap-sol8.pdf

   * My personal favorite, (ab)using existing software plus one or two
     small Perl scripts.

   First, create a version of /etc/shadow (called /etc/shadow.db)
   that's much faster to update.  You can use DBM or a fixed-length
   file based on userid number; when the user with userid number 123
   changes his password through the website, seek to (123 * recordsize)
   in shadow.db and write the new shadowfile entry.

   Then have your update script safely open /etc/shadow.new (using
   O_EXCL or something similar) so only one process can do it.
   Read /etc/shadow.db sequentially, write each variable-length entry
   to /etc/shadow.new terminated by a newline, unlink /etc/shadow,
   and rename /etc/shadow.new to /etc/shadow.

   This way, updates are fast because you're seeking and writing a fixed
   number of bytes.  You don't have to lock shadow.db because no two users
   should be updating the password for the same userid at the same time.
   Creating the new /etc/shadow is fast because you're reading the
   fixed-length file sequentially.

   Of course, this breaks down if you're allowing multiple accounts to
   share the same userid numbers.  Also, you have to allow some script
   started by your webserver to write to shadow.db.

>From Dennis_Martens@health.qld.gov.au  Sun May 26 19:28:29 2002

    if, like us, you keep old entries in the passwd file as an audit/histor=
y trail, then put the old unused entries at the end of the file. When loggi=
ng in, the passwd file is read sequentially until a line is found that matc=
hes the login name. If this file has 30,000 entries in it, then that would =
account for the time it is taking some people to log in.

    A simple test is to log in as someone, and time the delay. Then move th=
at person's passwd entry to the top of the file, and try again.


----------- Original Question ---------------

We have an E6000 running Solaris 7 11/99.

There are approximately 30,000 entries in /etc/passwd.
Password entry in nsswitch.conf is:
passwd:     files

It takes about 9 seconds to change a password when answering the prompt
automatically, say with Expect.  In fact, when root tries to change a
password, it takes about 6 seconds for the "New Password:" prompt to
even appear.  This seems quite slow.

At our university, we anticipate that we'll have students registering this
summer who will sit down in a lab and, through a web-based interface,
change their passwords.  We have a way to queue up changes, but if the
last person to send their change request in a room of about 20 people,
who have all started about the same time, has to wait up to 3 minutes
for their password to get set, that seems unacceptable.

Any ideas on how to speed this up (safely).?

***********************************************************************
     Deborah Crocker, Ph.D.                  deborah.crocker@ua.edu
     Unix System Project Leader           http://bama.ua.edu/~crock
     Seebeck Computer Center                           205-348-3758
     University of Alabama                        Fax: 205-348-3993
     Box 870324
     Tuscaloosa, AL 35487
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers