Creating user accounts....

Donald Becker becker at
Fri Feb 14 10:09:59 PST 2003

On Fri, 14 Feb 2003, Srihari Angaluri wrote:

> So, is BeoNSS a replacement to NIS, or is it on top of NIS?

It can be used in place of NIS, or can use NIS as a back-up.

> How are you
> able to solve the problem of saturating the network or overloading a
> single server (as in the case of NIS) exactly?

When we issue a job to a compute node we send the user information with
it.  A good mental model is that we send a line from the master's

> Do you have replicated
> services over the network? Or, is there a hierarchical scheme of naming
> users in the network, so that the authentications are handled as name
> resolutions like in the case of DNS?

Sending out the user info with the job neatly avoids all of these.
Since we are already sending out the job, it's just a few more bytes
down an already established network connection.

> How is it different from NIS? In case of NIS, as I understand it,
> whenever a compute node needs to authenticate a particular user, it will
> contact the NIS server, correct? So, where is the point of (or advantage
> of) maintaining a "partial user list"? 

It's a major difference.

As usual, the devil is in the details.

You might imagine your cluster application isn't doing a name lookup at
all.  But there are a whole bunch of things going on in libc that you don't
think about before the application main() is called.  Run 'strace' on
your applications sometime to get an idea of how much the library
initializers are doing.  Add that to the libc operations and explicit
lookups of the process that accepts the job, and you end up with a bunch
of nameserver work.

And each time the library does a name lookup, it's not a simple map
operation.  Look at how getpwent() and libc work with NIS.  It must scan
the user list linearly.  In the typical case you end up transferring
most of the user map for each name look-up.

In a small group with a handful of personal workstation, this is no big
deal.  In a large cluster at a site with many users, all of this work is
happening at the same time that the other nodes are requesting the user
map (and perhaps the host map as well).

Donald Becker				becker at
Scyld Computing Corporation
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993

More information about the Beowulf mailing list