Re: [Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend
Hoogstraten, Ton wrote: Thank you for your reply. I'm testing with 3.0.33 since that's the latest version Redhat is using in RHEL5 (Redhat has the habbit of holding a version and do backport patching). The 3.2.x version was marked for production and what I saw in FAQ was that the 3.4.x was still to experiment with? IIUC 3.0 is in "dead" state and nearly unsupported by Samba team. 3.2 is in "End of life", 3.4 "current" and 4.x "testing". But I'm not an expert and surely someone else is authoritative about it. If you mean the 'winbind enum users/groups' setting that has been turned off as suggested in the man pages. If activated it could crash a certain role AD controller. That's not something I can risk. But would that in normal behaviour not fill somekind of cache? If I increase the caching in theory that would perhaps reduce the numer of queries required for a user at a given time. I don't know if it would be a problem setting this to 3 days so the cache could also pass over the weekend. Does not take away why it takes so long to query the AD. IIUC, the only drawbacks in long lasting caches are related to slowing down updates propagation -- if you add a user to a group, it could take "too much" to actually apply the change to all domain members. Is it always slow to query the AD? Would the 3.0.23d server that I need to upgrade be using more caching then the later versions by default? As I said, I'm not an expert, but I always noticed it's quite slow. Just tested: looking up "for the first time" (with 'id') an user in 12 groups took 49s, immediately rerunning 'id' took 'just' 1s. Running 'id' on other users (that I'm sure weren't in cache) took up to 2s, and seems it's just loosely correlated to the number of groups. So it seems that ust the first query is slow. Since our AD trees are quite large (more than 20K users in one domain and more than 100K in the other... and really a lot more groups, not counting "secondary" domains), I don't think the whole trees can be cached in 49s with the first query (at least not on a 100Mbit link). Actually, if I enable enum users/groups, winbind takes some minutes to start up and needs a couple of GB RAM). -- Diego Zuccato Servizi Informatici Dip. di Astronomia - Università di Bologna Via Ranzani, 1 - 40126 Bologna - Italy tel.: +39 051 20 95786 mail: diego.zucc...@unibo.it -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend
Diego, Thank you for your reply. I'm testing with 3.0.33 since that's the latest version Redhat is using in RHEL5 (Redhat has the habbit of holding a version and do backport patching). The 3.2.x version was marked for production and what I saw in FAQ was that the 3.4.x was still to experiment with? If you mean the 'winbind enum users/groups' setting that has been turned off as suggested in the man pages. If activated it could crash a certain role AD controller. That's not something I can risk. But would that in normal behaviour not fill somekind of cache? If I increase the caching in theory that would perhaps reduce the numer of queries required for a user at a given time. I don't know if it would be a problem setting this to 3 days so the cache could also pass over the weekend. Does not take away why it takes so long to query the AD. What do you mean with: Looking up group names is really slow (up to a couple of minutes when using "id user.name" or "groups user.name"). Is it always slow to query the AD? Would the 3.0.23d server that I need to upgrade be using more caching then the later versions by default? To answer your last question. Yes, the ldap is running on the local system for the idmaps. In production I have one samba server running a master ldap idmap backend and the other samba server configured as slave. Kind regards, Ton -Original Message- From: Diego Zuccato [mailto:diego.zucc...@unibo.it] Sent: maandag 23 november 2009 12:42 To: Hoogstraten, Ton Subject: Re: [Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend Hoogstraten, Ton wrote: > However on the test 3.0.33 system I'm experiencing a problem that I Why are you using such an ancient version? What about 3.4.x ? > I think the explanation for the difference in slowness per user is based > on the group membership of that user. For example an user that is only a > member of Domain Users takes about 10 seconds to display the shares > (still to slow in my opinion). For testing purpose I've reduced the > cache for winbind and idmap so the server needs to keep looking up the > user and SID information. Looking up group names is really slow (up to a couple of minutes when using "id user.name" or "groups user.name"). Have you tried playing with enum users/groups ? If activated on large AD trees, it could impact performances a lot! > idmap alloc config:ldap_url = ldap://127.0.0.1/ Are you using a locally running (on localhost!) ldap server? -- Diego Zuccato Servizi Informatici Dip. di Astronomia - Università di Bologna Via Ranzani, 1 - 40126 Bologna - Italy tel.: +39 051 20 95786 mail: diego.zucc...@unibo.it -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend
I'm hoping someone can help me with the following. I currently have 2 Samba fileservers version 3.0.23d joined to our corporate Active Directory. Clients currently are Windows XP. I'm asked to prepare to migrate XP to Windows 7. From testing it looks like Samba 3.0.23d is not compatible with Windows 7. Therefor I started testing with the latest RHEL5 version 3.0.33-3.1e.el5 on RHEL5. Enabling 'client ntlmv2 auth = yes' seems to be key to make this work for Windows 7. However on the test 3.0.33 system I'm experiencing a problem that I can't solve. The initial connect from either a XP or 7 client is slow when not in the Samba cache (even when changing the config to the same as the production server for XP, removing the ntlmv2 option). It depends on the user connecting how slow. For example my own user account requires an average of 40 seconds before displaying the Samba shares on a fresh connect. The 3.0.23d server remains fast talking to same domain controllers. The following settings I think I got from the Redhat Knowledgebase for performance make no difference in this matter. They have been enabled and disabled with no effect. client schannel = no client use spnego = no server signing = auto large readwrite = no The client spnego setting however does get in your way when trying to join a system to Active Directory when set to 'no'! I think the explanation for the difference in slowness per user is based on the group membership of that user. For example an user that is only a member of Domain Users takes about 10 seconds to display the shares (still to slow in my opinion). For testing purpose I've reduced the cache for winbind and idmap so the server needs to keep looking up the user and SID information. idmap cache time = 120 winbind cache time = 120 The SID to UID/GID mappings are stored in an openldap database so both servers have the same UID/GID mappings. For the test server this is running on the localhost. I have updated the backend config to the following on the test server to use the new idmap_ldap setup. idmap domains = ALLDOMAINS idmap config ALLDOMAINS:default = yes idmap config ALLDOMAINS:backend = ldap idmap config ALLDOMAINS:ldap_base_dn = ou=Idmap,dc=example,dc=com idmap config ALLDOMAINS:ldap_user_dn = cn=Manager,dc=example,dc=com idmap config ALLDOMAINS:ldap_url = ldap://127.0.0.1/ idmap config ALLDOMAINS:range= 1 - 200 #idmap backend where we write new entries: idmap alloc backend = ldap idmap alloc config:ldap_base_dn = ou=Idmap,dc=example,dc=com idmap alloc config:ldap_user_dn = cn=Manager,dc=example,dc=com idmap alloc config:ldap_url = ldap://127.0.0.1/ idmap alloc config:range= 1 - 200 The 'password server' option is set to a local Domain Controller. either by DNS name or IP. This seems to be making no difference. Additional the DNS name is als stored in /etc/hosts. I'm trying to keep the server connecting on the local LAN instead of wandering to the "nearest" server for example in Germany. When I set the winbind logging to level 10 I see the server connecting to the Domain Controller LDAP and retrieve the SID information and store it in the local TDB files. Depending on the user more SIDs needs to be resolved making the process slower. Does anybody know what could be causing this? Has the caching method changed since version 3.0.23d? I can try increasing the caching to cache the information for days to try and reduce the queries for the Domain Controller. But there must be a reason why the default settings are kept low and I don't know if this will bring any other side affects. It is worth to mention that the production server started when we had a NT domain. In order to migrate we had double SID's resolving to single UID/GIDs during the move between domains. When testing this with version 3.0.33 this could crash and make the winbind daemon coredump. I have cleaned out all duplicate entries since the NT domain is gone now. Can it be that I'm missing Indexes/config on my idmap openldap config from version 3.0.23d? Does anybody know how I can optimize that if possible? Currently I have the following in my slapd.conf: index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq Last I can mentioned that upgrading the server to Samba version 3.2.15 to see if that solves anything is also not working. I have 2 test servers now. One being version 3.0.33 and one being 3.2.15 displaying the same problem. When connecting with empty cache the lookups are slow. Kind regards, Ton -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
