From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I have two NIS servers: an old one named basics with ypserv-1.3.9-3.src.rpm which works fine, and a new one (RH 8.0) named advances with ypserv-2.5-1.src.rpm, which works incorrectly. As a result HP-UX 11.0 clients cannot use the new server. If a client bound the old one executes command ypmatch xxx zzz where the map named zzz does not exist the message is: Can't match key xxx in map zzz. Reason: no such map in server's domain. The same command on the same client bound to the new server produces message: Can't match key xxx in map zzz. Reason: args to yp function are bad. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Restart ypbind with -ypset option 2.Execute command ypset advanced (advanced is the NIS server with the latest ypserv) 3. Execute command ypmatch on Solaris-8 client: zebra 52: ypmatch xxx zzz Can't match key xxx in map zzz. Reason: args to yp function are bad. 4. Execute command ypmatch on HP-UX 11.0 client: spirit 69: ypmatch xxx zzz ypmatch: can't match xxx. Reason: bad args to NIS function 5. Execute command ypmatch on RH Linux client [root@advanced yp]# ypmatch xxx zzz Can't match key xxx in map zzz. Reason: Request arguments bad (this is on the new server itself, which is bound to itself) Actual Results: The ypserv transmits to the client the YP_BADARGS (-7) return code. Expected Results: The response to ypmatch xxx zzz command should be Can't match key xxx in map zzz. Reason: no such map in server's domain. The server should transmit to the client return code YP_NOMAP (-1) Additional info: I actually traced this bug by recording the network exchange between various clients with the old server, and with the new server. The significance of this issue is that the HP-UX 11.0 clients cannot use new NIS server. In certain cases HP-UX 11.0 clients try to match certain keys using the map named servi.bynp instead of services.byservicename. The old ypserv responds with YP_NOMAP, and the client repeats the attempt using the correct name. The new ypserv responds with YP_BADARGS, and HP-UX 11.0 clients gives up. Other clients I tested use the correcct map in the first place. An additional annoyance is the message: Feb 24 18:14:01 advanced ypserv[1662]: refused connect from 134.6.22.144:1016 to procedure ypproc_match which ypserv logs in the /var/log/messages. It is not informative. There is a legend circulating on the web that this is a result of server overloading with too many requests. This is the suggestion I got from the RH support. In fact it was the controlled "one server - one client" situation.
I reported this bug to Thorsten Kukuk [kukuk].Below is our exchange on the subject. ========================================= From: Thorsten Kukuk [kukuk] Sent: Monday, March 03, 2003 11:01 AM To: Vinarsky, Boris Subject: Re: Issue with ypserv Follow Up Flag: Follow up Flag Status: Flagged On Sun, Mar 02, Vinarsky, Boris wrote: > Mr. Kukuk, > >... > I upgraded a RH 6.2 NIS server to RH 8.0 and HP-UX NIS clients stopped > working. After investigation I figured out that the problem is that HP > clients issue ypmatch requests with old HP map names like servi.bynp, and if > receive "no such map (YP_NOMAP)" response issue the same query for the > services.byservicename map. It worked fine with old Linux ypserv-1.3.9. It > works also with the ypserv that come with Solaris-8 and HP-UX 11.0. The > Linux ypserv-2.5 responds with the "args to yp function are bad > (YP_BADARGS)", and HP-UX clients give up. Interesting enough that Solaris > and Linux clients are not so sensitive as HP-UX, and do not give up. > > I filed a bug report #85262 at http://bugzilla.redhat.com/ > > I also tried ypserv 2.8 and found the same problem. > Below is the log from running in debug mode. .... Answer from Thorsten Kukuk: The following patch should solve the problem: --- lib/access.c 5 Feb 2003 22:10:21 -0000 1.1.2.4 +++ lib/access.c 3 Mar 2003 10:55:18 -0000 @@ -189,8 +189,6 @@ status = -1; ypdb_close (dbp); } - else - status = -2; } } =================== Boris
I tested the fix. I works fine. This will address some other bug reports about advanced ypserv[xxx]: refused connect from x.x.x.x:x to procedure ypproc_match message.
Created attachment 90545 [details] Fixes correct return value when a map does not exist
This fix will be include in an upcoming errata or release.
I included this patch and rebuilt the ypserv rpm from the errata release for 7.3 The error message is still as useless: server ypserv[17381]: refused connect from 192.168.182.2:37572 to procedure ypproc_match shouldn't this have changed if I applied the patch in the attachment Steve included?
server ypserv[17381]: refused connect from 192.168.182.2:37572 to procedure ypproc_match is message that is sysloged whenever a ypmatch fails (regardless of the reason). True its a bit misleading because the connection is accepted but the request failed...
The record in the log is a problem not only because it is misleading, but mostly because it contaminates log file with useless records making it much harder to fish out really important ones. An attempt to match a key in a map that may, or may not exist for many clients is a part of a normal NIS client routine. There is no need to make a record of the missing map, especially misleading record. For instance, HP client first tries to map servi.bynp, if the result is YP_NOMAP it calls services.byname. I observed it when working on this bug. Sun also looks for the map user_attr during the login, and if not found, continues. In both cases ypserv makes a useless record. I am sure there are other cases as well. These are examples I noticed. I suggest to remove the message Mar 11 18:14:08 basics ypserv[2612]: refused connect from x.x.x.x:58832 to procedure ypproc_match or make it conditional, produced only in a debug mode. I reopen the bug because this message is a real issue that needs a resolution, considering that ypser will be patched anyway.
*** This bug has been marked as a duplicate of 124557 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.