From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 12:14:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id F25A137B401; Mon, 14 Jul 2003 12:14:00 -0700 (PDT) In-Reply-To: from "Robin P. Blanchard" at "Jul 14, 2003 02:17:58 pm" To: Robin.Blanchard@gactr.uga.edu (Robin P. Blanchard) Date: Mon, 14 Jul 2003 12:14:00 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030714191400.F25A137B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: current@freebsd.org Subject: Re: Help diagnosing NIS breakage ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2003 19:14:01 -0000 > In our implementation, the NIS server is ActiveDirectory with ServicesForUnix > 3.0 :) Ok, first, shame on you for waiting until now to reveal this piece of information. (Although, I'm coming into this thread late, so if you mentioned it in a previous message and I wasn't able to find it, then I apologize. But if you didn't mention it, *THWAP*.) On a client bound to this server, please do: % ypwhich -m and show us the results. The ypwhich(8) utility will obtain a list of all the NIS maps being served by your server host and try to do a YPPROC_MASTER on each one to learn the name of its master server. It's possible that the Services For Unix implementation of NIS does not implement the YPPROC_MASTER procedure because the 'master' server in this case is CaptiveDirectory rather than an actual NIS master server (which means trying to do normal NIS master server things like yppasswd updates wouldn't work). If this is the case, then ypwhich should return an error for each map. I don't remember if ypwhich prints out the whole error status, but the expected underlying RPC error would be RPC_PROCUNAVAIL (procedure not available). This complicates matters a bit. When testing for the master.passwd maps, you can use the following logic: - If you call yp_order() on the master.passwd.byname map and the NIS server says YPERR_MAP (no such map), then you know that the server supports the YPPROC_ORDER procedure, but it doesn't have the master.passwd.byname map. So either it's not a FreeBSD server, or it is a FreeBSD server but the administrator has chosen not to serve the master.passwd maps. In either case, you should roll over to the normal passwd map lookup. - If you call yp_order() and get back YPERR_YPERR, that means there was an underlying RPC error (i.e. RPC_PROCUNAVAIL) which indicates the server doesn't support the YPPROC_ORDER procedure. The Sun NIS+ server in YP compat mode is one example of this. The FreeBSD ypserv does implement YPPROC_ORDER, so this error means you are not talking to a FreeBSD server, and again, you would roll over to the normal passwd map lookup. - When you get to the passwd map lookup, you probably shouldn't be attempting to do either a yp_master() or yp_order() poll on the map. You should just attempt a lookup. The yp_order() trick was something I introduced for the sole purpose of trying to determine if the server on the other end had master.passwd maps on it (i.e. it was a FreeBSD server). The nis_map() function in -current is analagous to the _havemaster() function in -stable, but _havemaster() was only meant to test for the master.passwd maps, whereas nis_map() checks master.passwd maps and then, if that fails, checks for passwd maps too. I don't think this is the correct approach: you should only attempt a yp_order() on the master.passwd.by* maps, and if that doesn't work, you let the nis_lookup() function do the yp_first()/yp_next()/yp_match() and return an error if necessary. I have a diff to do this at: http://www.freebsd.org/~wpaul/getpwent.diff > > I think this is exposing a bug in our NIS implementation, > > but don't know enough about it to be sure. I think backing it out > > just hides the bug again. As a work-around, we could try yp_order > > first, and if that fails, try yp_master. It's not a bug in our implementation, it's implementation weirdness in the server. :) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." =============================================================================