Bug 85262 - Incorrect answer to MATCH when map does not exist
Summary: Incorrect answer to MATCH when map does not exist
Status: CLOSED DUPLICATE of bug 124557
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypserv
Version: 8.0
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-02-27 00:44 UTC by Boris Vinarsky
Modified: 2015-01-08 00:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:52:00 UTC

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

Description Boris Vinarsky 2003-02-27 00:44:37 UTC
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:

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 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-07 02:11:56 UTC
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
+++ lib/access.c        3 Mar 2003 10:55:18 -0000
@@ -189,8 +189,6 @@
                  status = -1;
              ypdb_close (dbp);
-         else
-           status = -2;



Comment 2 Boris Vinarsky 2003-03-07 02:31:24 UTC
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

Comment 3 Steve Dickson 2003-03-10 21:21:48 UTC
Created attachment 90545 [details]
Fixes correct return value when a map does not exist

Comment 4 Steve Dickson 2003-03-10 21:22:56 UTC
This fix will be include in an upcoming errata or release.

Comment 5 Seth Vidal 2003-03-11 04:14:52 UTC
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 to procedure

shouldn't this have changed if I applied the patch in the attachment Steve included?

Comment 6 Steve Dickson 2003-03-11 15:09:53 UTC
server ypserv[17381]: refused connect from to procedure

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-12 02:34:26 UTC
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 15:10:42 UTC

*** This bug has been marked as a duplicate of 124557 ***

Comment 9 Red Hat Bugzilla 2006-02-21 18:52:00 UTC
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.