I'm found problem in version 3.4.4 , 3.4.5 and in 3.4.6 Our organization is big (more then 10000 users) and we using samba as PDC. After updating from 3.0.28a to 3.4.5 PDC working was broken - clients can't authorize - they exiting by timeout. I'm fount that older samba versions search sambaGroupMapping with base dn defined by lb_ldap_group_suffix(), but 3.4.4 , 3.4.5 and 3.4.6 (may be other too) search sambaGroupMapping with base dn defined by lb_ldap_suffix() - there is so many ldap entryes (we using ldap to store some stuff such us mail books, ftp asterisk radius vpn accounts and many other) in ldap and search with base dn lb_ldap_suffix() take lot of time, but samba group mappings stored only in lb_ldap_group_suffix() I'm create small patch for 3.4.5: diff -rupN ./samba-3.4.5/source3/passdb/pdb_ldap.c ./samba-3.4.5-Slipeer/source3/passdb/pdb_ldap.c --- ./samba-3.4.5/source3/passdb/pdb_ldap.c 2010-03-02 05:57:26.000000000 +0300 +++ ./samba-3.4.5-Slipeer/source3/passdb/pdb_ldap.c 2010-02-15 14:42:59.000000000 +0300 @@ -3739,8 +3739,8 @@ static NTSTATUS ldapsam_alias_membership if (filter == NULL) { return NT_STATUS_NO_MEMORY; } - rc = smbldap_search(ldap_state->smbldap_state, lp_ldap_suffix(), + rc = smbldap_search(ldap_state->smbldap_state, lp_ldap_group_suffix(), LDAP_SCOPE_SUBTREE, filter, attrs, 0, &result); if (rc != LDAP_SUCCESS) And this is patch for 3.4.6: diff -rupN ./samba-3.4.6/source3/passdb/pdb_ldap.c ./samba-3.4.6-Slipeer/source3/passdb/pdb_ldap.c --- ./samba-3.4.6/source3/passdb/pdb_ldap.c 2010-03-02 06:32:10.000000000 +0300 +++ ./samba-3.4.6-Slipeer/source3/passdb/pdb_ldap.c 2010-03-02 06:20:22.000000000 +0300 @@ -3836,7 +3836,7 @@ static NTSTATUS ldapsam_alias_membership result = ldap_state->search_cache.result; ldap_state->search_cache.result = NULL; } else { - rc = smbldap_search(ldap_state->smbldap_state, lp_ldap_suffix(), + rc = smbldap_search(ldap_state->smbldap_state, lp_ldap_group_suffix(), LDAP_SCOPE_SUBTREE, filter, attrs, 0, &result); if (rc != LDAP_SUCCESS) { return NT_STATUS_UNSUCCESSFUL; Please fix it. Thanks. P.S. Excuse my English, it isn't my primary language...
Closing this bug as WONTFIX, this change is deliberate. We can continue the discussion here certainly or on samba-technical@samba.org. Do you really have those many entries that match our search filter? My guess would be that either our search filter is not tight enough. How many entries do you actually see returned from LDAP? Volker
(In reply to comment #0) > I'm found problem in version 3.4.4 , 3.4.5 and in 3.4.6 > Our organization is big (more then 10000 users) and we using samba as PDC. > After updating from 3.0.28a to 3.4.5 PDC working was broken - clients can't > authorize - they exiting by timeout. > I'm fount that older samba versions search sambaGroupMapping with base dn > defined by lb_ldap_group_suffix(), but 3.4.4 , 3.4.5 and 3.4.6 (may be other > too) search sambaGroupMapping with base dn defined by lb_ldap_suffix() - there > is so many ldap entryes (we using ldap to store some stuff such us mail books, > ftp asterisk radius vpn accounts and many other) in ldap and search with base > dn lb_ldap_suffix() take lot of time, but samba group mappings stored only in > lb_ldap_group_suffix() At first sight I say you are lacking proper indexes so that the ldap server can return objects faster.
(In reply to comment #2) > (In reply to comment #0) > > I'm found problem in version 3.4.4 , 3.4.5 and in 3.4.6 > > Our organization is big (more then 10000 users) and we using samba as PDC and more then 20000 entryes. > > After updating from 3.0.28a to 3.4.5 PDC working was broken - clients can't > > authorize - they exiting by timeout. > > I'm fount that older samba versions search sambaGroupMapping with base dn > > defined by lb_ldap_group_suffix(), but 3.4.4 , 3.4.5 and 3.4.6 (may be other > > too) search sambaGroupMapping with base dn defined by lb_ldap_suffix() - there > > is so many ldap entryes (we using ldap to store some stuff such us mail books, > > ftp asterisk radius vpn accounts and many other) in ldap and search with base > > dn lb_ldap_suffix() take lot of time, but samba group mappings stored only in > > lb_ldap_group_suffix() > > At first sight I say you are lacking proper indexes so that the ldap server can > return objects faster. > part, you're right, but: we use fedora-ds (now in named 389-ds) in can replicate only whole database, and we have more then 70 filials with DC. we don't replicate whole ldap tree, all filials have only needed suffixes. ldap group suffixes placed in own databases and in this databases indexed present. in our main ldap there more then 250 databases and only near 70 contain samba group mapping data creating index for each of 250 - waste of computer time, we indexing attributes only in those database where this attribute used. second aspect is: what is the meaning of attribute ldap group suffix pointed to Groups storage suffix, if you still search Groups in all ldap tree? it' s waste of computer time. We try optimize settings to save every 0.1 of a second because in our scale of these shares are added in minute! or im, mistake and now samba store samba group mapping where she pleases? Then please correct me! Tanks for responding. P.S. Excuse my English, it isn't my primary language...
(In reply to comment #1) > Closing this bug as WONTFIX, this change is deliberate. We can continue the > discussion here certainly or on samba-technical@samba.org. > > Do you really have those many entries that match our search filter? My guess > would be that either our search filter is not tight enough. How many entries do > you actually see returned from LDAP? > > Volker > we have near 236 records in ldap with (&(|(objectClass=sambaGroupMapping)(sambaGroupType=4))) and near 20000 (~20320) records in ldap (objectClass=*)
The suffix is used to point where samba should store group mappings. In any case this need to be discussed on samba-technical@samba.org at this point, bugzilla is not a discussion forum.
(In reply to comment #3) > in our main ldap there more then 250 databases and only near 70 contain samba > group mapping data > creating index for each of 250 - waste of computer time, we indexing attributes > only in those database where this attribute used. Is creating indexes for objects that don't exist really so costly? > second aspect is: > what is the meaning of attribute ldap group suffix pointed to Groups storage > suffix, if you still search Groups in all ldap tree? it' s waste of computer > time. We try optimize settings to save every 0.1 of a second because in our > scale of these shares are added in minute! > > or im, mistake and now samba store samba group mapping where she pleases? > Then please correct me! It is used in places where Samba *creates* the group mapping objects. There were too many problems with objects placed in weird places and then not found by winbind or smbd that we decided to always search in the whole LDAP tree. Volker
*** Bug 7193 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > In any case this need to be discussed on samba-technical@samba.org at this > point, bugzilla is not a discussion forum. > Excuse me but my mails to samba-technical@samba.org rejected with message: "The message's content type was explicitly disallowed" because of this i'm write here. (In reply to comment #6) > (In reply to comment #3) > > in our main ldap there more then 250 databases and only near 70 contain samba > > group mapping data > > creating index for each of 250 - waste of computer time, we indexing attributes > > only in those database where this attribute used. > > Is creating indexes for objects that don't exist really so costly? What database do, when indexing or reindexind database? a. Searching all entry with target attribute b. Store pointer to this attribute in index c. Sorting index (or do other index optimization) stage (a) take order of magnitude more time when we indexind whole database. agree - a small increase in consumption of computational resurses, but this performance! > > > second aspect is: > > what is the meaning of attribute ldap group suffix pointed to Groups storage > > suffix, if you still search Groups in all ldap tree? it' s waste of computer > > time. We try optimize settings to save every 0.1 of a second because in our > > scale of these shares are added in minute! > > > > or im, mistake and now samba store samba group mapping where she pleases? > > Then please correct me! > > It is used in places where Samba *creates* the group mapping objects. There > were too many problems with objects placed in weird places and then not found > by winbind or smbd that we decided to always search in the whole LDAP tree. > > Volker > Nice method. ;) In Rissia it named "crutch". I think that better idea is to find WHY "objects placed in weird places" and fix it. Perhaps it would be better to make this behavior configurable from smb.conf or At least at compile time? In any case, thank you. I think we will use samba with my patch, but you will continue to develop samba P.S. we don't use winbind, and we don't plane to use winbind. P.P.S. Excuse my English, it isn't my primary language...