Date: Mon, 21 Apr 1997 09:20:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: abelits@phobos.illtel.denver.co.us (Alex Belits) Cc: terry@lambert.org, vinay@agni.nuko.com, freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Need a common passwd file among machines Message-ID: <199704211620.JAA13617@phaeton.artisoft.com> In-Reply-To: <Pine.LNX.3.95.970420161047.4103C-100000@phobos.illtel.denver.co.us> from "Alex Belits" at Apr 20, 97 04:38:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > How do I force synchronization with someone's desktop box if they > > turn it off and go home? > > When box is turned off it definitely doesn't need any authentication > information at all -- no one can login there anyway. When such box boots > it can ask server, and server will update authentication information if it > was changed (similar to what happens when secondary nameserver is started) > before any user will have chance to log in -- still less overhead than to > ask server every time. For pure clients, you are correct. Unless the box is a server. Then it depends on who wins the election whether it will update or not. And perhaps the other server who would have won the election is now down. Either way, it's possible for the newly reenabled server to serve stale data to other clients. > > This is the same for all push-model authentication distribution > > services: it has a hard time working in the real world, and depends > > on silly ideas like "skulking" processes to push the data when they > > can. > > > > Meanwhile, between "skulks", the replicating tree has invalid > > information, and may win the "master election" for a client, and > > authenticate client credentials which are, in fact, "stale", and > > there;'s no way to stop it from happening. > > The idea is that server updates authentication data on clients whenever > it's changed, not client asks server about that (except when booting). So > the delay between data being changed on the server and being received on > some client will be almost as short as it takes to do remote > authentication procedure from that client (depends on network bandwidth, > server resources, etc). And this relies on everything being up. No matter how you slice it, there's a race window. At the very least, there is a race window on transient network failure that causes a net split to occur: the very case where you would want replication in the first place. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704211620.JAA13617>