Description of problem: ypcat fakemap returns a map of zero entries rather than "No such map". In our environment, this causes great problems. For example, programs such as automounter try to determine the correct NIS map name for the auto-master file. (Various distros try auto-master, auto.master, auto_master). Most automounters then select the first of these maps they find. Since ypserv is saying that such a map exists, but no entries are present instead of returning YP_NOMAP, automounter and other programs do not operate properly. Version-Release number of selected component (if applicable): ypserv-2.8-1 How reproducible: ALWAYS Steps to Reproduce: 1. On RHEL3, setup ypserv in master or slave mode 2. Ensure 'fakemap' does not exist in the maps 3. Do 'ypcat fakemap' Actual results: No Error message, Empty result set Expected results: No such map fakemap. Reason: No such map in server's domain Additional info: Running 'ypserv -d' does infact show the 'gdbm error 3' but it does not correctly propagate it back to the client. (verified with ethereal) This bug is present in both ypproc_all_2_svc() & ypproc_first_2_svc() (in ypserv/server.c) The ypserv-2.6-nomap.patch does seem to help (enough?) Maybe this patch should be discarded and rewritten. Newer version of ypserv from kernel.org have this problem fixed. I built ypserv-2.13 using RedHat's SPEC file and it works great. They address the problem by almost alrays returning YP_NOMAP instead of other error messages in ypserv/server.c Feel free to contact me. I would be glad to provide additional tests and debugging.
My proposed fix is to remove the defective ypserv-2.6-nomap.patch that was introduced earlier and replace it with the attached patch. The broken account doesn't take into account the handling the return code -4 by each of the callers to is_valid(). The new patch is much simpler, handles each use case properly, and is identical to how it was fixed in later versions of ypserv on kernel.org. Please see attached patch... -Aaron Spangler
Created attachment 100636 [details] replacement 'nomap' patch
The attached patch works on ypserv-2.8-1 or ypserv-2.8-6
In the latest release 2.8-6, is issue is addressed by setting the status to -4 which means fakemaps are silently ignored.
ypserv-2.8-6 has the same problem. (Verified)
In fact I first tried 2.8-6 before I even posted the bugzilla report. Maybe you are saying that the 'Actual Results' is the desired behavior rathar than the 'Expected Results' (as described above)? Please elaborate.
Fixed in yp-tools-2.8-6
Steve, Umm - do you *ypserv* 2.8-6? That was a defective patch. In fact, I did additional testing was against ypserv 2.8-6. It does not properly address the symptoms on Solaris automounters that are NIS clients of Redhat ypserv 2.8-6. Please recall the NOMAP patch in 2.8-6 and replace it with the patch one suggested in Bug 124557. Please let me know if you want more information. I would even be willing to setup lots of additional tests. Provide network traces, etc to show that 2.8-6 was defective. -Aaron
Created attachment 103344 [details] new nomap patch Please try this new nomap patch to see if takes care of the Solaris issue
No I did mean yp-tools-2.8-6 since does fix bug in ypcat.
*** Bug 85262 has been marked as a duplicate of this bug. ***
The fix for this bug is in the ypserv-2.8-9 rpm for RHEL3 and in ypserv-2.8-7.21 rpm for AS2.1
Tried ypserv-2.8-10. It does not fix it either. Can we please use my patch now?
It did at this end.... could you please post a new ethereal trace and the output of 'ypcat nomap' Aaron, your patch does not address the entire problem and I'm never been a fan of applying half fixes....
Created attachment 107982 [details] Ethereal captures of ypserv-2.10 Attached tar.gz file containing: ypserv2.8-10.tcpdump ypserv2.8-10.tcpdump.pdf ypserv2.8-6nwie3.tcpdump ypserv2.8-6nwie3.tcpdump.pdf The *.pdf files contain the printout of the relavent packets. But the entire dumps (*.tcpdump) can be read with ethereal. The 6nwie3 is our internally patched version with the same patch I am promoting. The 2.8-10 is the most recent rev you asked me to test. Nis Client: 172.25.135.33 (Solairs 8) Nis Server: 172.25.94.191 (RHEL4U1 w/ corresponding ypserv) Please let me know if I can provide more information. -Aaron
Just to be sure.... 'rpm -q --changelog ypserv' has an entry that says: * Fri Oct 08 2004 Steve Dickson <SteveD> - Found a hole in the yp_first/yp_next code where YP_NOMAP was not being set
Yup. Same RPM.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-578.html
Closing out based on comment 26.
Comment 26 is not public! I see comment #20 and comment #27, but thats it.
Please let me know the status of this bugzilla.
This bug has been fixed, another similiar bug #136509 has been opened which should detail the other problems that you're having. Let me know if this isn't the case, and I'll re-open the bug.
Chris, This has NOT been fixed. I disagree considering I am the person who opened up this bug (see above) and also did all the network traces AND even submitted the actual patch. Until this patch (or similar) is applied or until the network traces of the new package demonstrate that the problem is fixed, then how can it be fixed?
A *test* version of the ypserv with the fixes is available at http://people.redhat.com/cfeist/ypserv/