Bug 85262
Summary: | Incorrect answer to MATCH when map does not exist | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Boris Vinarsky <borisv> | ||||
Component: | ypserv | Assignee: | Steve Dickson <steved> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Jay Turner <jturner> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 8.0 | CC: | borisv, srevivo, tao | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i586 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-02-21 18:52:00 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Boris Vinarsky
2003-02-27 00:44:37 UTC
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. |