From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 14:53:47 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 8493D37B401; Mon, 14 Jul 2003 14:53:47 -0700 (PDT) In-Reply-To: from "Robin P. Blanchard" at "Jul 14, 2003 03:46:55 pm" To: Robin.Blanchard@gactr.uga.edu (Robin P. Blanchard) Date: Mon, 14 Jul 2003 14:53:47 -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: <20030714215347.8493D37B401@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 21:53:47 -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 > > Thanks for getting back to me on this. First off, apologies if I'd failed to > mention the server before...Now, on a -CURRENT NIS client (with rev 1.81 > getpwent.c): > $ ypwhich -m > shadow dc3 > passwd.byuid dc3 [...] Ok, so it does support the YPPROC_MASTER procedure. Let's try something a little different. This time, do: % ypwhich -m master.passwd.byname And show the results. Might as well try ypwhich -m master.passwd.byuid too, though the result will probably be the same. > And to elaborate... [...] > > Shall I patch getpwent.c (rev 1.82) with your diff and see what happens ? If you could, please. Though I'm curious to know just what was causing the failure in the first place. Clearly YPPROC_MASTER on maps that exist seems to work (otherwise ypwhich would have complained like gangbusters), so maybe it's generating some sort of non-standard error on maps that don't exist. The fact that it fails for root means it must have something to do with probing for the master.passwd.by* maps, but I'm not sure what yet. -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." =============================================================================