From owner-freebsd-stable Fri Jun 12 11:01:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03150 for freebsd-stable-outgoing; Fri, 12 Jun 1998 11:01:57 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from mail.atipa.com (altrox.atipa.com [208.128.22.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA03050 for ; Fri, 12 Jun 1998 11:01:20 -0700 (PDT) (envelope-from freebsd@atipa.com) Received: (qmail 17197 invoked by uid 1017); 12 Jun 1998 16:58:24 -0000 Date: Fri, 12 Jun 1998 10:58:24 -0600 (MDT) From: Atipa To: Tom cc: John Kenagy , freebsd-stable@FreeBSD.ORG Subject: Re: NIS client maintenance script In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > It assumes only one NIS server ($nis_host). You'd have to be mad to > > > have only one NIS server in a production environment, especially since > > > clients can automatically kick over to another if one fails. > > > > Correct. This script is not dynamic. I am using it primarily for machines > > w/o NIS servers on their network. Setting up slave servers would eliminate > > several problems. > > Yes, but the new ypbind has no problems handling multiple non-local > servers. I'm hoping to see it committed before 2.2.7. Do you have diffs? I'd be happy to test in on -STABLE. Does it need any of -CURRENT's RPC stuff? > > > Since all the *pwnam fuctions (getpwnam, getpwent, etc) are flawed in > > > that they can not return a temporary failure code, such functions should > > > block until NIS services are back up. This is critical for systems > > > running mail service, because you don't want all your users to disappear > > > when NIS goes down. > > > > But you don't want to have to wait 14 minutes (7 minutes each for user > > login, then su) to remedy problems. > > Yes, but admin users should be listed in the system /etc/master.passwd > so they can always login. The current yplib is bit broken in that it > depends on YP even if all necessary info for login is in /etc. For > example, if you only have a "+" in master.passwd, root should be able to > login without delay, even if YP is down. No, I agree. I do not have any "wheeled" accounts on NIS (for that reason, and security), but if NIS authentication is enabled (any +'s) in /etc/master.passwd, and the domain is not bound, it _still_ takes 14 minutes to su. I thought that was standard behavior; is my setup wrong somehow? > > If no network services are available, your users will go away period, > > unless they are somehow cached (eg slave server). > > For example, it is better that e-mail be delayed until YP is back up, > rather than to bounce all e-mail as "user unknown" while YP is down. How would having +'s in your /etc/master.passwd postpone mail delivery? I think I must be missing a step here. In the case of NIS server being down, I have _no_ user lists at all, but I do have _serious_ delays authenticating users listed locally (wheels, etc.). That is why this script takes out all +'s if the domain is not bound. No, you can't get user info, but you couldn't anyway (w/o caching), and now you can log in w/o delays. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message