[OpenAFS] AFS client over NIS

Paul Blackburn mpb@est.ibm.com
Tue, 19 Feb 2002 14:25:21 +0000


Neulinger, Nathan wrote:

>>I have used a system where we maintained a single master
>>/afs/@cell/common/etc/passwd and used a crontab job to
>>merge this with local /etc/passwd on selected client machines.
>>The merge only took place if the "master" file was newer than
>>/usr/local/etc/passwd (local replica).
>>
>>This worked well and had the performance benefit of being
>>able to lookup /etc/passwd from a local file. It is also robust
>>because the local file read access is not impacted by network
>>problems etc.
>>
>
>I have only seen a performance benefit from local password files in the
>rare cases:
>
>1. Crappy netgroup handling on linux (it doesn't used the
>netgroup.byuser map, and indexes through all the component netgrops), if
>you have lots of netgroups on a machine (or huge netgroups), this can be
>slow, but it's similar in speed to file access. 
>2. Tiny password files for servers (only 5-10 userids)
>
>For everything else, NIS will scream past a local password file.
>
>Perhaps systems using nscd or similar will perform better, but I didn't
>think that got used for local pw files. 
>

In our case, using AIX, the process for re-generating the local /etc/passwd
used mkpasswd which (as stated in the man page):
"Organizes the basic user database for efficient searches."

This provided very efficient local password lookups (via indexing).
It would be interesting to do some real benchmarking
to determine if NIS is faster than a local indexed passwd file lookup.
For us, the ability to drop NIS altogether was the main bonus.

>>A question  to ask is: how many login ids do I need on each client?
>>
>>Generally, it is much easier to place "master" files in /afs
>>rather than serve them via NIS.
>>
>
>True, but if you have 300+ unix machines, all with different membership
>lists, you're creating a nightmare if you try to maintain all the
>password files in AFS, and every time you have a new user, 300 files
>likely need updated and pushed out to machines. Yuck.
>
>-- Nathan
>
>------------------------------------------------------------
>Nathan Neulinger                       EMail:  nneul@umr.edu
>University of Missouri - Rolla         Phone: (573) 341-4841
>Computing Services                       Fax: (573) 341-4216
>

That sounds like a nightmare you imagined for yourself.

In our configuration, it was very simple and effective.
Updates on clients only happened if the "master" file was changed
and the clients did not subset passwd data.

During the merge process, local UIDS below 201 were preserved.
The master passwd file had UIDS from 201 up.

The other benefit is that the passwd lookups are distributed
out to the clients instead of centralised on an NIS server.

However, I think the real point here is that you don't need NIS for AFS.
If NIS is an overhead, then get rid of it.
--
cheers
paul                                            http://acm.org/~mpb

"Do not panic, do not panic! We are trained professionals!
 Now, stay calm. We are going around the leaf."
 --Mr Soil, "A Bug's Life"  http://uk.imdb.com/Quotes?0120623