mkd@cs.brown.edu wrote:
I'm not sure if this is a bug or we are doing something wrong. For quite some time now, we have been using ldap to provide group information for our linux/unix desktop machines. I believer there are multiple methods of providing group access, this is the format we are using:
# foobar, group, cs.brown.edu dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu objectClass: posixGroup objectClass: top cn: ugrad gidNumber: 1200 memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 . . .
Up until recently, this had been working great. We are now experiencing hangs whenever we try to update the records with one particular group. I think the hangs are occur when we try to feed too much data to ldapmodify at a time. For instance, if I have the above group and try to apply the following ldif file:
dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2477 memberUid: t2478 memberUid: t2479
Does the offending value of memberUid correspond to something specially related to the modify operation? E.g. to the identity that is performing the modification, or is any other operation 'round when the hang occurs? Is your GSSAPI somehow related to LDAP? Are credentials actually stored in the same slapd you're modifying?
p.