Hi,
We have a a NIS/YP problem that somebody may have a possible suggestion
on what we do (other than ignore it, which I'm afraid is probably the
answer).
We're trying to use a Linux box as our NIS master, this replacing a Sun
Solaris server for the same purpose. After much hacking we took the
Makefile and got things working, however when we go to do a "yppush"
(from ypserv-1.3.9 RPM) to any Sun slave NIS servers we get:
YPPUSH: Cannot call YPPROC_XFR: RPC: Can't decode result
(Note however the map does transfer anyway).
After much digging and packet tracing we came to the following
conclusion, Solaris instead of sending the enum and an unsigned int back
in the RPC reply sends a "void" return. Even Sun's "snoop" was confused
by this. For example a healthy response from a Linux slave server:
NIS: ----- Network Information Service -----
NIS:
NIS: Proc = 6 (Request map update) <---- NOTE DECODED INFO
NIS: Transid = 4090
NIS: Transfer status = 1 (Success)
NIS:
0: 0090 27e7 97cc 00c0 4f35 6f7e 0800 4500
..'.....O5o~..E.
16: 003c eb6b 0000 4011 43ff a499 0112 a499
.<.k..@.C.......
32: 0102 0374 0368 0028 2b6f 2329 4ee7 0000
...t.h.(+o#)N...
48: 0001 0000 0000 0000 0000 0000 0000 0000
................
64: 0000 0000 0ffa 0000 0001 ..........
And a less than healthy reply from a Sun slave server:
NIS: Proc = 6 (Request map update)
<---- NO DECODED INFO!!!
0: 0090 27e7 97cc 0800 2074 c18a 0800 4500 ..'.....
t....E.
16: 0034 3f6e 4000 ff11 f109 a499 010c a499
.4?n@...........
32: 0102 02d9 0387 0020 7ada 01e1 3151 0000 .......
z...1Q..
48: 0001 0000 0000 0000 0000 0000 0000 0000
................
64: 0000 ..
As you see the "snoop" collected on the Sun could not parse the Sun RPC
reply (duh). Even the Sun header file "/usr/include/rpcsvc/yp_prot.h"
does in fact define the response as being a enum and an unsigned int, so
why does the working implimentation return void?
I then went to the SunSolve online bug database and found this little
gem from 1993:
> I added NIS decoding to tcpdump and noticed that I was seeing transfer
> requests replied with void data. In particular, and with file names
> relative the top of the ONC 4.2 source tree, usr.etc/yp/ypserv.c calls
> usr.etc/yp/ypserv_proc.c's ypxfr() which forks off a /var/yp/ypxfr
> process and doesn't wait for its results. ypxfr() returns a RPC reply
> via:
>
> if (!svc_sendreply(transp, xdr_void, 0)) {
> RESPOND_ERR;
> }
>
> yppush expects null back:
>
> s = (enum clnt_stat) clnt_call(ps->domb.dom_client, YPPROC_XFR,
> xdr_ypreq_xfr, &req, xdr_void, 0, udp_timeout);
>
> However, over in sys/rpcsvc/yp.x, the XFR procedure is defined as:
>
> enum ypxfrstat {
> ...
> };
>
> struct ypresp_xfr {
> unsigned int transid;
> ypxfrstat xfrstat;
> };
>
> program YPPROG {
> version YPVERS {
> ...
>
> ypresp_xfr
> YPPROC_XFR(ypreq_xfr) = 6;
>
> ...
> } = 2;
> } = 100004;
>
> I am not terribly concerned about this problem. Indeed, I don't understand
> most of YP, especially the functions that happen behind my back. Which of
> these should I include in tcpdump?
> History:
> Submitter: martha Date: 09/01/93
> Dispatch Operator: bugtraq Date: 10/12/93
> Evaluator: sxn Date: 10/14/93
> Closeout Operator: sxn Date: 10/14/93
As you see essentially saying the same thing and obviously never fixed
(but closed nevertheless).
The reason the Sun's don't care when they're NIS masters is because
their "yppush" uses an undocument RPC ypserv procedure 12 instead of
procedure 6 which Linux "yppush" uses. Again, duh.
So, to cut to the chase, Sun developed NIS/YP (along with RPC and NFS)
so in a sense their implimentation is the reference implimentation. Even
though the open and official NIS spec says return enum and unsigned
since all Sun implimentations I find return void, should Linux do the
same?
I can (and will) bug this with Sun but since all of their slaves and
masters through all versions are wrong their more likely to try to
change the reference implimentation than fix the bug.
What do you think? Am I just going to have to pipe my "yppush" through
"grep -v 'CANNOT ENCODE'"?
- Matt
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
http://listman.redhat.com/mailman/listinfo/redhat-devel-list
