I am seeing a problem with retrieving group information from an LDAP backend where the number of members of the groups can be large. The data I have contains duplicate gidNumbers which may be causing other problems. But I think this is a buffer size problem in the interface between the glibc library and the nss_ldap backend. The behaviour is as follows. I am using getent to enuerate the group map e.g. getent group I get all of the entries from the local group files back, and then the first entry from the LDAP store is returned, the next entry is retrieved from the LDAP backend by NSS_LDAP but this layer returns NSS_TRYAGAIN/ERANGE and getent just terminates. Does anybody know if this is a correct diagnosis of the problem I am seeing, i.e. getent calls into getgrent in the library and it calls the nss layer which gives up on the LDAP service as soon as the buffer overflows. Note I am testing this on a rehat RHEL 5.3 box running glibc-2.5-34 with nss_ldap-265 plus my patches (which do not touch this area of the code yet). Thoughts or suggestions as to where I can go to check this out further solicited. Regards, Howard. Coherent Technology Limited, 23 Northampton Square, Finsbury, London EC1V 0HL, United Kingdom Telephone: +44 20 7690 7075 Mobile: +44 7980 639379 Company Email: coherent@xxxxxxxxxxx Website: http://www.cohtech.com <http://www.cohtech.com/> -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
