>>>>> 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!
_______________________________________________
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
