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

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