We are currently in the process to update an Windows NT driven Network completely to Samba. The main structure is as follows: - one PDC with an Master LDAP Server - Several Samba Member Servers with Slave LDAPs, ACLs and Winbind for nss We wrote some Scripts to Migrate NTs SAM to LDAP and switched over to the Samba PDC, which currently works very well. In the second step we tried to setup Samba member servers to switch off those NT machines. Everything was setup as described in the The Official Samba-3 HOWTO and Reference Guide. During testing we discovered a major problem with Winbind in conjunction with a Samba PDC: If we tried to do a "getent group" on one of the member servers the PDCs load went through the roof and rendered the system nearly unusable. The Problem was the Samba Server which was hard working on "discovering" the users which it found in the groups. The problem seems that Winbind requests a list of Groups, then Samba tries to find EVERY user in that group. Now if you got a broken Group entry with one or more users which are not in the DIT Samba simply loops. Well okay that should normally not happen, but i think this is a Samba bug ;) The second problem, which is by far worse, is that Samba always tries to find every user in every group, which brings LDAP to its knees. We got an av. of 500+ Users and ca. 170 Groups, and some groups have an high amount of users in it. Well now we got to the point where we try to do nss lookups via "getent group" on the members and we were not able to do a reasonable lookup of groupinformation. "wbinfo -g" works by the way. In the meantime the PDCs gets a very hight load by some slapd which are trying to find every user in the DIT multiple times (Timeout problems?) This behavior is reproduceable on different machines :( Since i dont know which information might be usefull for you i will now not attach any files to this Bug, but i may produce any debug log you may wish :)
(In reply to comment #0) > We are currently in the process to update an Windows NT driven Network completely to > Samba. The main structure is as follows: > - one PDC with an Master LDAP Server > - Several Samba Member Servers with Slave LDAPs, ACLs and Winbind for nss > > We wrote some Scripts to Migrate NTs SAM to LDAP and switched over to the Samba PDC, > which currently works very well. > In the second step we tried to setup Samba member servers to switch off those NT machines. > Everything was setup as described in the The Official Samba-3 HOWTO and Reference Guide. > During testing we discovered a major problem with Winbind in conjunction with a Samba PDC: > If we tried to do a "getent group" on one of the member servers the PDCs load went through the > roof and rendered the system nearly unusable. The Problem was the Samba Server which was > hard working on "discovering" the users which it found in the groups. > The problem seems that Winbind requests a list of Groups, then Samba tries to find EVERY > user in that group. Now if you got a broken Group entry with one or more users which are not in > the DIT Samba simply loops. > Well okay that should normally not happen, but i think this is a Samba bug ;) > > The second problem, which is by far worse, is that Samba always tries to find every user in > every group, which brings LDAP to its knees. We got an av. of 500+ Users and ca. 170 > Groups, and some groups have an high amount of users in it. Well now we got to the point > where we try to do nss lookups via "getent group" on the members and we were not able to do > a reasonable lookup of groupinformation. "wbinfo -g" works by the way. > In the meantime the PDCs gets a very hight load by some slapd which are trying to find every > user in the DIT multiple times (Timeout problems?) > This behavior is reproduceable on different machines :( > > Since i dont know which information might be usefull for you i will now not attach any files to > this Bug, but i may produce any debug log you may wish :) ----------------------------- We had the same problem with version 3.0.5, broken groups put's Samba in loop.
Please retest. This should be better in 3.0.6. Thanks. Marking as fixed. Please reopen if that is not the case.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.