Help diagnosing NIS breakage ?

Bill Paul wpaul at FreeBSD.ORG
Mon Jul 14 14:53:47 PDT 2003

> > > 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* maps,
but I'm not sure what yet.


-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul at | Wind River Systems
      "If stupidity were a handicap, you'd have the best parking spot."

More information about the freebsd-current mailing list