Description of problem: I was attempting to test a new NIS server and while using ypcat on Fedora 18 I am getting errors like, "No such map group.byname. Reason: RPC failure on NIS operation". The same occurs if I try again group.bygid. Version-Release number of selected component (if applicable): Fedora 18 yp-tools-2.12-11.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Use ypcat to look at groups Actual results: Some groups are returned but the list is cut short with the error message above Expected results: All groups are returned. Additional info: I used ypcat on RHEL6 and did not have this issue.
A little additional information: I went back to look at this again and using ypcat on Fedora 18 against a server running ypserv and I don't see the issue. I am only seeing it when testing using ypcat on Fedora 18 running against a couple new servers running the slapi-nis plugin with RHDS 9.1 on RHEL 6.3. I tried ypcat on a RHEL 6.3 system and using a Fedora 17 Live CD and did not see the problem using either of those against the RHDS/slapi-nis server. Unfortunately, I don't think this narrows down whether yp-tools or slapi-nis might be at fault, just that it seems something between Fedora 18 and slapi-nis.
This is broken now due to the limit imposed to resolve https://bugzilla.redhat.com/show_bug.cgi?id=848748 Bumping the number from 1024 to 9999 in these and rebuilding/reinstalling glibc gets things working again since slapi-nis does not split groups (our largest group is currently 9853 characters). glibc-2.16-75f0d304/nis/rpcsvc/yp.x:const YPMAXRECORD = 1024; glibc-2.16-75f0d304/nis/rpcsvc/yp.h:#define YPMAXRECORD 1024 glibc-2.16-75f0d304/nis/rpcsvc/yp_prot.h:#define YPMAXRECORD 1024 On our servers using the ypserv we split large groups into multiple groups with the same gid which is why we did not see this issue there.
Hi Jason, thanks for the analysis. For information about consequences of increasing YPMAXRECORD see the topic [1]. It states, that unlimited or higher value than 1024 is not recommended, because it can cause problems when communicating with non-linux machines. However, no limit has been used for years in glibc and there have been no issues with that. So I think we can increase the limit to some reasonable value. [1] http://www.linux-nis.org/nis-howto/HOWTO/maps.html#AEN548 Re-assigning to glibc.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Steps to reproduce: 1. add a very long group record into /etc/group (longer than 1024B), e.g.: foo:x:10000:bar1,bar2,bar3, ... ,bar999 2. add --no-limit-check option to makedbm command in /var/yp/Makefile, since otherwise lines longer than 1024B are ignored, but we need to add them to map file: -DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname` +DBLOAD = $(YPBINDIR)/makedbm --no-limit-check -c -m `$(YPBINDIR)/yphelper --hostname` 3. rebuild maps: # cd /var/yp # make 4. # systemctl restart ypserv ypbind (while ypbind is configured to use ypserv running on localhost) 5. # ypcat group.byname You should see a failure like this: ... yp_all: clnt_call: RPC: Can't decode result No such map group.byname. Reason: RPC failure on NIS operation
glibc-2.16-31.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/glibc-2.16-31.fc18
Package glibc-2.16-31.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.16-31.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7223/glibc-2.16-31.fc18 then log in and leave karma (feedback).
glibc-2.16-31.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
glibc-2.17-11.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/glibc-2.17-11.fc19
glibc-2.17-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.