Subject: Re: pwd_mkdb - 29,000 users in 7 Seconds.
To: NetBSD-current Discussion List <email@example.com>
From: John Nemeth <firstname.lastname@example.org>
Date: 08/10/2001 18:34:52
On Nov 25, 10:06pm, Greg A. Woods wrote:
} [ On Thursday, August 9, 2001 at 20:23:56 (+0200), Wojciech Puchar wrote: ]
} > it's still 6.58s too much
} > the right solution is to use database files directly and only change data
} > that were changed without rebuilding. "real" files should be generated
} > only in case of vipw.
} The real world doesn't work that way. For the general purpose system
The real world most certainly does work that way.
} both /etc/passwd and /etc/master.passwd must also be kept up-to-date for
} non-DB-capable programs which access their contents (awk, cut, sed, etc.).
Anybody that does this (except for special case software where the
environment is completely controlled) should be taken out and shot.
And, their programs/scripts deserve to die an immediate and most
Ever since Sun invented Yellow Pages 15+ years ago, there has been
no guarantee that /etc/passwd would have useful data. Add to that,
Hesiod, NIS+, and LDAP. Not to mention that godawful C2 implementation
by SecureWare that SCO and HP use. It's been a very long time since
one could assume that /etc/passwd has useful data. The only way to
access that data is by using getpwnam() et al. Anything else is
Yes, I know that getpwnam() is only available in C or advanced
scripting languages like Perl, but it doesn't take much to write a
small helper program in C that you can use from your scripts. Which is
exactly what I did five years ago when I started working with NIS+. I
most certainly did not want to be constantly doing a linear search on a
20,000 line password file.
}-- End of excerpt from Greg A. Woods