Bug 64445
| Summary: | "ypwhich -m" map enumeration is broken | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Victor Sudakov <sudakov> |
| Component: | bin | Assignee: | Peter Wemm <peter> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | peter |
| Priority: | Normal | ||
| Version: | 5.2-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Victor Sudakov
2004-03-19 06:00:32 UTC
* Victor Sudakov, 2004-03-19 : > >Description: > "ypwhich -m" should produce a list of maps available on the NIS master server. > Instead, it produces an error: > ypwhich: can't find the master of `ÐÐ`Ð: reason: No such map in server's domain > which breaks "/usr/sbin/ypinit -s" and perhaps something else. Reproduced here, this seems to be related to the coexistence of two incompatible definitions of yp_maplist. According to the following, this could have been introduced with rev. 1.15 of ypwhich.c: http://lists.freebsd.org/pipermail/freebsd-current/2003-December/017066.html Thomas. Responsible Changed From-To: freebsd-bugs->peter Over to peter, who last modified ypwhich(1). It's used by ypinit and therefore we can't even create a proper clone of the master YP server. /running 5.3-RELEASE After looking at the bug and analysis using the URL included in the
report, I looked through the source:
$ find . -type f -exec grep ypml_name {} /dev/null \;
./include/rpcsvc/yp_prot.h: char ypml_name[YPMAXMAP + 1];
./usr.bin/ypwhich/ypwhich.c: r = yp_master(domnam, ypml->ypml_name, &master);
./usr.bin/ypwhich/ypwhich.c: printf("%s %s\n", ypml->ypml_name, master);
./usr.bin/ypwhich/ypwhich.c: ypml->ypml_name, yperr_string(r));
$ find . -type f -exec grep ypmaplist {} /dev/null \;
./include/rpcsvc/yp.x:struct ypmaplist {
./include/rpcsvc/yp.x: ypmaplist *next;
./include/rpcsvc/yp.x: ypmaplist *maps;
./include/rpcsvc/yp_prot.h: * YPPROC_MAPLIST takes (char *), returns (struct ypmaplist *).
./include/rpcsvc/yp_prot.h:struct ypmaplist {
./include/rpcsvc/yp_prot.h: struct ypmaplist *ypml_next;
./include/rpcsvc/yp_prot.h: struct ypmaplist *list;
./include/rpcsvc/ypclnt.h:struct ypmaplist;
./include/rpcsvc/ypclnt.h:int yp_maplist(char *indomain, struct ypmaplist **outmaplist);
./lib/libc/yp/yplib.c:yp_maplist(char *indomain, struct ypmaplist **outmaplist)
./usr.bin/ypwhich/ypwhich.c: struct ypmaplist *ypml, *y;
./usr.sbin/ypserv/yp_server.c:static void yp_maplist_free(struct ypmaplist *yp_maplist)
./usr.sbin/ypserv/yp_server.c: register struct ypmaplist *next;
./usr.sbin/ypserv/yp_server.c:static struct ypmaplist *
./usr.sbin/ypserv/yp_server.c: struct ypmaplist *cur = NULL;
./usr.sbin/ypserv/yp_server.c: struct ypmaplist *yp_maplist = NULL;
./usr.sbin/ypserv/yp_server.c: if ((cur = (struct ypmaplist *)
./usr.sbin/ypserv/yp_server.c: malloc(sizeof(struct ypmaplist))) == NULL) {
On every other OS I have access to, ypml_name is not defined as it is
in the FreeBSD yp_prot.h. The only place in the source that ypml_name
is used is in ypwhich.c. In yp_server.c, the ypmaplist struct is used
from yp.h, as you'd expect.
My proposed bugfix is to patch yp_prot.h and make it consistent with
the definition in yp.x & yp.h and recompile ypwhich.c. The change
to yp_prot.h (whenever it was done) was wrong.
patch referenced from /usr/src (source) or /usr (release). This is
for FreeBSD 5.4-RELEASE.
------------------------------------------------------------------------------
--- include/rpcsvc/yp_prot.h.ORIG Thu May 27 06:34:21 2004
+++ include/rpcsvc/yp_prot.h Sun Jun 5 16:52:52 2005
@@ -148,7 +148,7 @@
};
struct ypmaplist {
- char ypml_name[YPMAXMAP + 1];
+ char *ypml_name;
struct ypmaplist *ypml_next;
};
------------------------------------------------------------------------------
--
Gil Kloepfer - ARL ITS/CSD Network Support
Applied Research Laboratories : The University of Texas at Austin
(512) 835-3771 / gil@arlut.utexas.edu
I edited yp_prot.h as Gil Kloepfer suggested, recompled and reinstalled ypwhich on FreeBSD 5.4, however it did not solve the problem. Have I missed something? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN On Tue, Sep 27, 2005 at 01:55:31PM +0700, sudakovva@sibptus.tomsk.ru wrote: > I edited yp_prot.h as Gil Kloepfer suggested, recompled and > reinstalled ypwhich on FreeBSD 5.4, however it did not solve the > problem. > > Have I missed something? > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN Be sure that you have changed the yp_prot.h in /usr/include/rpcsvc (not just the one in /usr/src/include/rpcsvc). When you recompile ypwhich.c, it will use one of them - but you always want to keep the two consistent. I hope that this helps you. We are successfully using the fix on all of our FreeBSD systems. -- Gil Kloepfer - ARL ITS/CSD Network Support Applied Research Laboratories : The University of Texas at Austin (512) 835-3771 / gil@arlut.utexas.edu NOTE: Please send e-mail in plaintext ONLY. HTML or RTF mail will NOT be read! Gil Kloepfer wrote: > > I edited yp_prot.h as Gil Kloepfer suggested, recompled and > > reinstalled ypwhich on FreeBSD 5.4, however it did not solve the > > problem. > > > > Have I missed something? > > Be sure that you have changed the yp_prot.h in /usr/include/rpcsvc (not > just the one in /usr/src/include/rpcsvc). When you recompile ypwhich.c, > it will use one of them - but you always want to keep the two consistent. > > I hope that this helps you. We are successfully using the fix on all > of our FreeBSD systems. Yes, I forgot to change /usr/include/rpcsvc/yp_prot.h Now everyting works fine, thanks Gil! I wonder why the fix is not in the sources yet. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru People... I tried this and Worked... the original ypwhich -m did a core dump... We need someone to aply this patch ASAP.... -- Paniago -- Carlos F. A. Paniago pan@cnptia.embrapa.br http://www.cnptia.embrapa.br/ Fone: +55 (19) 3789-5815 This problem still exists in current releases. Applying the patch resolved the issue. FreeBSD fileserv2.luminex.com 6.1-RC FreeBSD 6.1-RC #0: Tue Apr 18 11:18:28 PDT 2006 root@fileserv2.luminex.com:/usr/obj/usr/src/sys/GENERIC i386 -- ============================ Calvin Ellison Junior Systems Administrator Luminex Software, Inc. PO Box 5908 Riverside, CA 92517 Voice: 951-781-4100 ext. 151 Fax: 951-781-4105 cellison@luminex.com http://www.luminex.com ============================ State Changed From-To: open->closed brooks@ fixed the issue in HEAD, RELENG_6, RELENG_6_1 and RELENG_5. |
