[389-users] Re: Need help to tune 389 DS
On 02/22/2017 09:25 PM, William Brown wrote: Default indexes only apply to new databases (It's a template iirc). You need to edit the index on the cn=userRoot,cn=ldbm database,cn=plugins,cn=config Thanks for clarification, but even when I look in the correct location, it's "eq" as I said originally: dn: cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: objectclass nsSystemIndex: true nsIndexType: eq ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Need help to tune 389 DS
On Wed, 2017-02-22 at 19:35 -0800, Gordon Messmer wrote: > On 02/22/2017 12:56 PM, Noriko Hosoi wrote: > >> > >> Take a look at either the 389 console or > >> /etc/dirsrv/slapd-/dse.ldif (where you will look for > >> default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config). You > >> should see equality indexes (nsIndexType: eq) for both of those > >> attributes by default. Is one of them not currently indexed? > > A tiny correction... > > presence (pres) for objectclass, and > > equality (eq) for uid > > > Has that changed in some recent release? My installation says: > > dn: cn=objectclass,cn=default indexes,cn=config,cn=ldbm > database,cn=plugins,cn > =config > objectClass: top > objectClass: nsIndex > cn: objectclass > nsSystemIndex: true > nsIndexType: eq Default indexes only apply to new databases (It's a template iirc). You need to edit the index on the cn=userRoot,cn=ldbm database,cn=plugins,cn=config Else it won't apply. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Need help to tune 389 DS
On 02/22/2017 12:56 PM, Noriko Hosoi wrote: Take a look at either the 389 console or /etc/dirsrv/slapd-/dse.ldif (where you will look for default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config). You should see equality indexes (nsIndexType: eq) for both of those attributes by default. Is one of them not currently indexed? A tiny correction... presence (pres) for objectclass, and equality (eq) for uid Has that changed in some recent release? My installation says: dn: cn=objectclass,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn =config objectClass: top objectClass: nsIndex cn: objectclass nsSystemIndex: true nsIndexType: eq ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Need help to tune 389 DS
On 02/22/2017 10:30 AM, Gordon Messmer wrote: On 02/22/2017 03:27 AM, wodel youchi wrote: we have many entries like these * Unindexed Search #32105 (notes=A) (&(null=uid=lastname.lastname,ou=people,dc=domain,dc=tld)) - Bind DN: cn=directory manager * You've got two problems here. One is that you appear to be using "cn=directory manager" for one of your LDAP clients, and that is a very serious security risk. Don't do that! The other is that this application appears to be misconfigured. It looks like it's searching for an attribute whose value will be an LDAP DN, but it doesn't have the name of that attribute. It might be looking for a group by "member" but because it doesn't know the name of the attribute, it's searching for an attribute named "null". *Unindexed Component #1 (notes=U) ** - Search Base: ou=people,***dc=domain,dc=tld* - Search Filter: (&(objectclass=*)(uid=pat)) - Bind DN: uid=dovecot,***dc=domain,dc=tld** Take a look at either the 389 console or /etc/dirsrv/slapd-/dse.ldif (where you will look for default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config). You should see equality indexes (nsIndexType: eq) for both of those attributes by default. Is one of them not currently indexed? A tiny correction... presence (pres) for objectclass, and equality (eq) for uid And we recommend to tune nsslapd-idlistscanlimit with the appropriate value to avoid unnecessary unindexed search. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#nsslapd_idlistscanlimit ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Need help to tune 389 DS
On 02/22/2017 03:27 AM, wodel youchi wrote: we have many entries like these * Unindexed Search #32105 (notes=A) (&(null=uid=lastname.lastname,ou=people,dc=domain,dc=tld)) - Bind DN: cn=directory manager * You've got two problems here. One is that you appear to be using "cn=directory manager" for one of your LDAP clients, and that is a very serious security risk. Don't do that! The other is that this application appears to be misconfigured. It looks like it's searching for an attribute whose value will be an LDAP DN, but it doesn't have the name of that attribute. It might be looking for a group by "member" but because it doesn't know the name of the attribute, it's searching for an attribute named "null". *Unindexed Component #1 (notes=U) ** - Search Base: ou=people,***dc=domain,dc=tld* - Search Filter: (&(objectclass=*)(uid=pat)) - Bind DN: uid=dovecot,***dc=domain,dc=tld** Take a look at either the 389 console or /etc/dirsrv/slapd-/dse.ldif (where you will look for default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config). You should see equality indexes (nsIndexType: eq) for both of those attributes by default. Is one of them not currently indexed? ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Need help to tune 389 DS
Hi, We have a simple installation of 389DS, a master/slave installation. Our directory server is mainly used with our mail and portal servers for now. We did create some custom attributes for our needs. Here is a simple entry model : *uid=lastname.firstname,ou=People,dc=domain;dc=tlddn: uid=lastname.firstname,ou=People,dc=domain,dc=tldou: SUPPORT TEAMrecruitmentDate: 20030510mailQuota: 2048576000 <%28204%29%20857-6000>teletexTerminalIdentifier: 3053maidenName: MaindeNameemployeeNumber: 28813gender: FdepartmentNumber: 1121employeeType: SmailAlternateAddress: f.lastname@domain.tlddisplayName: Lastname Firstnamemail: lastname.firstname@domain.tldjobTitle: Supervisorsn: Firstnamecn: LastnameobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: inetorgpersonobjectClass: shadowAccountobjectClass: mailrecipientobjectClass: customprofilemailMessageStore: /var/vmail/lastname.firstnameuid: lastname.firstnamemailHost: mail.domain.tldtitle: MuserPassword:: e1NIQX02TjBCaXpjcWRkNVJCUXlyVHV6TDlwT1NGK3c9* *webtelxmail : f.lastn...@telex.domain.tld* We run logconv against our directory Server and we get a pretty long result file, with some recommendations, but we don't know how proceed, especially with indexes. we have many entries like these * Unindexed Search #32105 (notes=A) - Date/Time: 13/Jan/2017:01:21:49 - Connection Number: 434118 - Operation Number: 74292 - Etime: 0 - Nentries: 0 - IP Address:172.16.16.9 - Search Base: ou=people,dc=domain,dc=tld - Search Scope: 2 (subtree) - Search Filter: (&(null=uid=lastname.lastname,ou=people,dc=domain,dc=tld)) - Bind DN: cn=directory manager* *Unindexed Search #76240 (notes=A) - Date/Time: * *13/Jan/2017:00:16:55 - Connection Number: 433231 - Operation Number: 205936 - Etime: 0 - Nentries: 0 - IP Address:Unknown_Host - Search Base: ou=people,* *dc=domain,dc=tld- Search Scope: 2 (subtree) - Search Filter: (&(null=uid=lastname2.firstname2,ou=people,* *dc=domain,dc=tld))Unindexed Component #1 (notes=U) - Date/Time: * *13/Jan/2017:00:01:19 - Connection Number: 433951 - Operation Number: 1 - Etime: 0 - Nentries: 0 - IP Address:172.16.16.1 - Search Base: ou=people,* *dc=domain,dc=tld - Search Scope: 2 (subtree) - Search Filter: (&(objectclass=*)(uid=pat)) - Bind DN: uid=dovecot,**dc=domain,dc=tld* In the end of the result file we got this : In the end of the result file we got this : FDs Taken:573 FDs Returned: 569 Highest FD Taken: 81 Broken Pipes: 0 Connections Reset By Peer:0 Resource Unavailable: 235 - 235 (T1) Idle Timeout Exceeded Max BER Size Exceeded:0 Binds:4627 Unbinds: 45 - LDAP v2 Binds: 24 - LDAP v3 Binds: 4603 - AUTOBINDs: 0 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds:0 - Directory Manager Binds: 4 - Anonymous Binds: 24 - Other Binds: 4599 - Connection Latency Details - (in seconds)<=1234-56-1011-15>15 -- (# of connections)250835554244 - Current Open Connection IDs - Conn Number: 434505 (172.16.16.8) Conn Number: 434171 (172.16.16.9) Conn Number: 434506 (172.16.16.8) Conn Number: 434301 (172.16.16.9) Conn Number: 434150 (172.16.16.9) Conn Number: 434118 (172.16.16.9) Conn Number: 434507 (172.16.16.8) Conn Number: 434508 (172.16.16.8) Conn Number: 434504 (172.16.16.8) - Errors - err=0295657Successful Operations err=32 627No Such Object err=49 44Invalid Credentials (Bad Password) err=424Size Limit Exceeded err=116Administrative Limit Exceeded (Look Through Limit) - Top 10 Failed Logins -- 12 uid=lastname.firstname,ou=people,dc=domain,dc=tld 12 uid=admin,ou=people,dc=domain,dc=tld 8 uid=lastname10.firstname10,ou=people,dc=domain,dc=tld 4 uid=lastname11.firstname11,ou=people,dc=domain,dc=tld 3 uid=lastname12.firstname12,ou=people,dc=domain,dc=tld 3 uid=lastname13.firstname13,ou=people,dc=domain,dc=tld 2 uid=dakar,ou=people,dc=domain,dc=tld >From the IP address(s) : 32 Unknown_Host 12 172.16.16.1 - Total Connection Codes - B1 289 Bad Ber Tag Encountered T1 235 Idle Timeout Exceeded U1 45 Cleanly Closed Connections - Top 10 Clients -
