Jakub Hrozek wrote:
On Mon, Sep 08, 2014 at 10:03:10PM +0000, Nordgren, Bryce L -FS
wrote:
> ls -l is very slow, as is "getfacl".
>
> Is there any reason that a call to getpwuid(10008) should produce an ldap query
filter like this?:
>
>
(&(uidNumber=10008)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))
>
> Clearly, if uidNumber=10008, it is both present and not zero so the last two terms
are moot. At best, a smart ldap server will optimize this out and only waste the time it
takes to parse the filter. At worst, it goes and performs all three checks independently.
>
> Also, my ldap setup is proxying "uid" defined in two remote ADs and
FreeIPA, optionally overriding the uid value locally to resolve conflicts. Adding (uid=*)
essentially translates to "send me information on every account in your system, so I
can then combine your remote result with the rest of the query", which is causing
size limit errors and/or timeouts. (objectClass=posixAccount) would cause the same issues,
except none of the entries in AD are posixAccounts. FreeIPA will probably observe exactly
the same phenomenon when they implement views.
>
> Is there any way for me to control this ldap query, hopefully knocking it down to
(&(uidNumber=10008)(objectClass=posixAccount)), requesting attribute uid?
Are you sure it would help in your environment? Did you check that
searching with:
(&(uidNumber=10008)(objectClass=posixAccount))
is faster than:
(&(uidNumber=10008)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))
We had this discussion before:
https://lists.fedorahosted.org/pipermail/sssd-users/2014-May/001630.html
With lots of fine-grained ACLs in the LDAP server (like in my setup) each
additional assertion attribute type is a performance penalty (without
additional benefit in my setup).
Ciao, Michael.