From owner-freebsd-hackers Sun Apr 20 16:36:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA27271 for hackers-outgoing; Sun, 20 Apr 1997 16:36:59 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA27251; Sun, 20 Apr 1997 16:36:52 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id QAA08144; Sun, 20 Apr 1997 16:38:40 -0700 Date: Sun, 20 Apr 1997 16:38:39 -0700 (PDT) From: Alex Belits To: Terry Lambert cc: vinay@agni.nuko.com, freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Need a common passwd file among machines In-Reply-To: <199704201926.MAA08355@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Apr 1997, Terry Lambert wrote: > > P.S. Is there any existing thing or at least an idea of making one that > > does this thing nicer? NIS is based on rather dumb idea that to > > authenticate local user one will want to go to some server and ask him > > instead of IMHO more sane approach of distributing authentication > > information from that server to always perform authentication locally and > > never depend on some host being accessible at the time of user's login. > > This is the design error of the X.500, NDS, and NT models for > having credentials apply to the net instead of individual machines: You mean, all machines on the network use the same set of users? That will be bad, but such system can be designed to support individual setup for machines, groups of them and/or supporting additional authentication information stored locally that will be added after receiving files. Secondary servers that may also handle some local for their clients lists can be useful, too. Model with ftp/scp+scripts that I've mentioned is too primirive to do that, but this is why I've asked about "pushing" model implemented better, so it can unclude that functionality. > 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. > 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). -- Alex