Re: bug reporting?

[Kaare Hviid <ukh@id.cbs.dk>]

OK, I just conducted a few non-scientific tests regarding the use of
amd64 as an NIS slave.  This is, as I suspected, not a gcc-3.4/pure64
issue, nor an amd64 issue.  IIRC, rpc.ypxfrd transfers the raw
databases in the host native format - and if I'm not mistaken that's
the way it works in the original Sun ONC implementation as well.  (The
Linux NIS/YP stuff is reverse engineered, since Sun wants $$$ and NDAs
for code and/or proper protocol documentation.)  Indeed, the problem
arises when trying to use an alpha as a slave server as well, and I
wouldn't be surprised if it will happen on, say, PPC too because of the
endianess.  The Linux NIS/YP implementation does, however, have a
fallback mechanism for these cases.  If, after doing the ypinit, you
actually check your /var/yp/${nisdomainname} catalog, you should find
all the databases there anyway, and you should also find that the slave
server actually works.  In other words, ypinit complains, but it still
should work and function.

To make a long story short:

1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave
with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain.
2) Avoid mixing architecture, OS, distro, implementation and version of
NIS servers in a production environment unless you actually find
pleasure in voodoo and the black magic of NIS/YP.  (I obviously do :-))

-ukh