Hi all, Is it a necessity to use the winbind nss module? I have run a few tests and having it enabled creates a massive bottleneck. It's not nss_winbind itself that is the bottleneck but something in the background (I'm guessing uid/rid->username code). If I disable winbind in nsswitch.conf what impact will it have? Will the system continue to work? eg: #nss_winbind enabled on group and passwd time samba-tool ntacl sysvolreset real 3m58.240s user 2m54.760s sys 0m27.030s #nss_winbind disabled time samba-tool ntacl sysvolreset real 0m46.940s user 0m35.057s sys 0m6.350s #nss_winbind enabled on only group time samba-tool ntacl sysvolreset real 0m46.668s user 0m34.790s sys 0m6.263s #nss_winbind enabled on only passwd time samba-tool ntacl sysvolreset real 4m7.639s user 2m56.987s sys 0m26.923s #nss_winbind enabled on group and passwd with enum groups and users disabled time samba-tool ntacl sysvolreset real 4m1.464s user 2m55.350s sys 0m26.660s #nss_winbind disabled and *nss-pam-ldap* enabled on passwd, shadow and group time samba-tool ntacl sysvolreset real 3m57.029s user 3m0.913s sys 0m30.570s Please note this last test shows that it is not the nss_winbind module that it slow it is something 'behind the scenes'. Also note that this is not just applicable to the sysvolreset (it was just a convenient method of testing). Copying a directory consisting of many small files (eg a windows roaming profile) can be excruciatingly slow! 50s+ for a 50mb folder! I am sure that it is not a network or drive limitation, copying the folder locally and via NFS happen very quickly and copying the same folder from a standalone S3 install on the same hardware is 'fast' also. Thanks, Alex
On Wed, 2013-05-08 at 15:23 +0100, Alex Matthews wrote:> Hi all, > > Is it a necessity to use the winbind nss module? > I have run a few tests and having it enabled creates a massive > bottleneck. It's not nss_winbind itself that is the bottleneck but > something in the background (I'm guessing uid/rid->username code). > If I disable winbind in nsswitch.conf what impact will it have? Will the > system continue to work?> Please note this last test shows that it is not the nss_winbind module > that it slow it is something 'behind the scenes'. > Also note that this is not just applicable to the sysvolreset (it was > just a convenient method of testing). Copying a directory consisting of > many small files (eg a windows roaming profile) can be excruciatingly > slow! 50s+ for a 50mb folder! > I am sure that it is not a network or drive limitation, copying the > folder locally and via NFS happen very quickly and copying the same > folder from a standalone S3 install on the same hardware is 'fast' also.The issue is that the winbind in the Samba 4.0 AD DC is incredibly inefficient. It is required for the [homes] share to work, but we try to avoid needing it for other things. I understand this is incredibly frustrating, but what this highlights is that we really, really need to start on the project to replace it with running the winbindd code from source3. The challenge is that this is a lot of work, which will cause disruption in other parts of the system as we generalise stuff and add the plugins we need to hook into the AD DC. I'm increasingly of the view that this will need to be a priority soon, but it's still hard to get stuck into this stuff. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org
Apparently Analagous Threads
- nss_winbind does not recognize group membership
- RE: solaris 8/samba3.0alpha15: ld.so.1: ls: fatal: relocation err or: file /lib/nss_winbind.so.1: symbol socket: referenced symbol not fou nd
- Samba from Sunfreeware and nss_winbind.so
- [SAMBA-SECURITY] CVE-2007-0453: Buffer overrun in nss_winbind.so.1 on Solaris
- [SAMBA-SECURITY] CVE-2007-0453: Buffer overrun in nss_winbind.so.1 on Solaris