Bug 85262 - Incorrect answer to MATCH when map does not exist
Incorrect answer to MATCH when map does not exist
Status: CLOSED DUPLICATE of bug 124557
Product: Red Hat Linux
Classification: Retired
Component: ypserv (Show other bugs)
8.0
i586 Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-26 19:44 EST by Boris Vinarsky
Modified: 2015-01-07 19:03 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixes correct return value when a map does not exist (655 bytes, patch)
2003-03-10 16:21 EST, Steve Dickson
no flags Details | Diff

  None (edit)
Description Boris Vinarsky 2003-02-26 19:44:37 EST
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.
Comment 1 Boris Vinarsky 2003-03-06 21:11:56 EST
I reported this bug to Thorsten Kukuk [kukuk@thkukuk.de].Below is our exchange
on the subject.
=========================================
From: Thorsten Kukuk [kukuk@thkukuk.de]
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
Comment 2 Boris Vinarsky 2003-03-06 21:31:24 EST
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.
Comment 3 Steve Dickson 2003-03-10 16:21:48 EST
Created attachment 90545 [details]
Fixes correct return value when a map does not exist
Comment 4 Steve Dickson 2003-03-10 16:22:56 EST
This fix will be include in an upcoming errata or release.
Comment 5 Seth Vidal 2003-03-10 23:14:52 EST
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?

Comment 6 Steve Dickson 2003-03-11 10:09:53 EST
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...
Comment 7 Boris Vinarsky 2003-03-11 21:34:26 EST
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.
Comment 8 Steve Dickson 2004-09-10 11:10:42 EDT

*** This bug has been marked as a duplicate of 124557 ***
Comment 9 Red Hat Bugzilla 2006-02-21 13:52:00 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.