Replacing NIS [was:NIS - "Could not read ypservers map" during "make"]

[pll at lanminds.com]

>>>>> On Wed, 18 Jun 2003, "Derek" == Derek Martin wrote:

  Derek> Another way is to set up an NIS-like master-slave
  Derek> relationship with the master and one host on each subnet
  Derek> where systems which need the files live.  The "master" pushes
  Derek> the files out to the "slaves" which in turn push the files
  Derek> out to each of the systems on their subnet.  This keeps the
  Derek> vast majority of traffic on local subnets and obviously
  Derek> serializes much of the transfers.
[...snip...]
  Derek> Also, since all of this will be scripted, it's easy to
  Derek> determine which hosts did not receive updates, and notify the
  Derek> sysadmin team of problems so they can (hopefully) react and
  Derek> fix it before anyone notices.

Also, this could be configured to be a 'pull' system where, when the 
clients boot, they contact the "ypserver" and pull the files over.
I'm thinking of a 2-way file transmission scenario here where the 
servers provide both push and pull capability using both rdist and 
rsync.

2 types of servers:  Master - the primary system where all changes
                              are centralized and pushed out from

                     Slaves - one or more per subnet which get changes
                              propagated to them by the master and push
                              the new files out to the clients

In addition, both masters and slaves would run an rsync:: server.
At boot time, the slaves would attempt to contact the server to pull 
the latest files over, and only the deltas at that, not the entirety 
of every file.

A normal client works exactly the same as a slave server, with the 
caveat that if the client fails to contact a local slave, you could 
opt for it to attempt to contact the master as well.


>>>>> On Wed, 18 Jun 2003, "mike" == mike ledoux wrote:

  mike> how do you handle password changes?  I can't think of any
  mike> reasonable way to deal with that short of requiring people to
  mike> log in to the 'master' server to make changes, and that seems
  mike> like a very fragile solution to me (I can easily imagine my
  mike> users 'forgetting' and changing their password on the local
  mike> copy of the file, and not being able to log in tomorrow).
  mike> Maybe I'm just missing something obvious.

Well, I think this could be handled pretty easily in a couple of 
different ways.  The first, and rather simplistic method is via a Web 
interface where the user changes their password, shell, whatever.  
Upon submission and validation of the form, an rdist is kicked off to 
the slaves and clients.

 The intersting thing about this idea is that with a combination of
good planning, a good client replication/auto-build system such as
FAI, System Imager, or maybe even KickStart, you could actually have a
web server running on each client system.  This would first make
changes to the local files, then rsync the changes back up to the
local subnet slave.  The slave could then both immediately update it's
subnet and contact the master, which would kick off an rdist/rsync to
all slaves except the one from which it received the latest updates.

There are some obvious concerns with this method, namely, do you want 
to trust propagating changes to an entire network which were received 
from a possibly compromised host.  However, in certain environments, 
I can see where this risk is really no worse than running NIS in the 
first place, since an NIS server is rather easy to compromise even 
without physical access to it.

Another more interesting idea would be a network based revision
control system with post-commit hooks to distribute the changes..  For
instance, assume you have a master server which keeps all these files
under revision control.  The clients at boot time could simply attempt
to update their working copy of these files, and failing that, check
out the repository.

When any of the files is changed, the client would first check in the 
working copy, which on the server would trigger a post-commit hook 
which would turn around and kick off some command issued to all 
clients to update their working copies.

I don't have this idea completely fleshed out yet, and there are some
obvious flaws and/or requirements for making this all transparent to
the end user to which I have not given a lot of thought to yet.
However, using Subversion as a revision control system makes this
scenario incredibly plausible IMO.

In short, while all the ideas presented above have very obvious flaws 
or hurdles to over come, I think it's entirely possible to come up 
with a viable and more secure/stable system file distribution 
mechanism than NIS.  The most obvious place which needs work IMO, is 
user training.  Which I don't think would be all that bad.  Users 
have been taught that they change their password using yppasswd 
(or passwd in non-NIS environment) so, for one of these methods, we 
just need to teach them "the new way".  IME, tell them what to do and 
why their doing it, and they'll gladly do it.  The big caveats being:

  a) it makes sense to them
  b) it works
  c) it's not any more effort than what they're used to
  d) it's ideally a great deal simpler than what they're used to

In otherwords, as with everything, make it easier to do the right 
thing[1], and they're less likely to put up a fight :)

[1] The "right thing" being defined as "Whatever it is that you 
    *want* them to do :)
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!