Re: Help diagnosing NIS breakage ?

> > > 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_at_windriver.com | Wind River Systems
=============================================================================
      "If stupidity were a handicap, you'd have the best parking spot."
=============================================================================