problem with authentication to AD server with translucent overlay

[juhlig]

I am using openldap 2.4.23-20 on Centos 6.2 server and trying to configure the 
translucent overlay to do simple user/password
authentication (or anything that works) to our Microsoft AD servers.

I can do authenticated commandline ldap searches with a Windows test account and password with no problems. I have tried to build a 
config based on the examples in the openldap admin and faq-o-matic web pages without success. All I get from the AD servers through my 
server are anonymous bind results.


If anyone has this working, I would appreciate any information or config file 
samples as I need to deploy the server ASAP.

thanks, John.

p.s. I am not including my config files (ldap.conf,slapd.conf,etc.) as they are essentially copies of the ones from the openldap 
website. However, if you wish to see them, I can reply with the latest of 100 iterations :(

Re: misconfigured read-only replica causes master slapd to crash

[Michael Ströder]

Kevan Carstensen wrote:

[1] http://www.openldap.org/its/index.cgi/Incoming?id=7113


Seems to be the same like ITS#6928:

http://www.openldap.org/its/index.cgi/Incoming?id=6928

I guess nobody ever took note of the debug trace I've grabbed from the 
provider server.


Ciao, Michael.

misconfigured read-only replica causes master slapd to crash

[Kevan Carstensen]

Hi,

We use a single master and two read-only replicas; we use back-bdb on
all systems. Each read-only replica replicates from the master with
syncrepl, configured to refreshAndPersist. During a particularly heavy
update load recently, replication on one of the read-only replicas
started to fail due to a misconfigured DB_CONFIG. The replica wrote the
following messages to its log repeatedly:

  Dec 14 04:01:08 pip-dev slapd[12645]: bdb(dc=csupomona,dc=edu): Lock table is 
out of available lock entries
  Dec 14 04:01:08 pip-dev slapd[12645]: => bdb_idl_delete_key: c_get failed: 
Cannot allocate memory (12)
  Dec 14 04:01:08 pip-dev slapd[12645]: conn=-1 op=0: attribute "memberUid" 
index delete failure
  Dec 14 04:01:08 pip-dev slapd[12645]: null_callback : error code 0x50
  Dec 14 04:01:08 pip-dev slapd[12645]: syncrepl_entry: rid=001 be_modify 
failed (80)
  Dec 14 04:01:08 pip-dev slapd[12645]: do_syncrepl: rid=001 rc 80 retrying

as it tried and failed to start replication again.

Shortly after, the master slapd crashed, writing nothing to its log
indicating why (or even referencing the crash at all). We initially
noticed this behavior with a 2.4.26 master and a 2.4.28 read-only
replica (we came upon this problem while performing some maintenance,
which is why there's a version mismatch). I reproduced the problem on a
2.4.28 master while researching ITS #7113 [1] (which describes this
problem more precisely and in more detail).  Has anyone else run into
this issue? Is there a good way to insulate the master slapd from
misconfigured replicas? Our replicas shouldn't break like this (we've
tuned our DB_CONFIG to ensure that they don't in the future), and
hopefully slapd can be modified so that the master doesn't crash even if
replicas do break, but we'd rather not have to worry about our master
crashing if our DB_CONFIG proves inadequate in the meantime.

[1] http://www.openldap.org/its/index.cgi/Incoming?id=7113

Thanks for any help,
-- 
Kevan Carstensen
Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

Re: Issue with index in OpenLDAP?

[Quanah Gibson-Mount]

Hi Mathieu,

It sounds like you didn't delete the cardnumber.bdb file before reindexing? 
That is what I'd have done.


Also, you previously had some questions about OpenLDAP tuning.  You may 
wish to read over 
.  Some of the 
bits in there have Zimbra specific names, but they all apply directly to 
OpenLDAP and BDB in general.


--Quanah

--On Wednesday, January 04, 2012 2:46 PM +0100 "External Mathieu DEDECKER 
(CAMPUS)"  wrote:



I will read the man page in order to have more informations about the
command.

I tried to reindex all the index of the database with the slapindex
command, but I allways the same behaviour:

Request1: cardnumber=2098001010034  (less than 1sec)
Request2: cardnumber=2090389917486  (nearly 20 sec).

Other .bdb files size have been updated, but my "cardnumber.bdb" has
still the same size.

Regards,

Mathieu


2012/1/4 Quanah Gibson-Mount 

Hi Mathieu,

If you read the slapindex man page, it is possibly to just recreate a
specific index file (for situations like this), rather than generating
all of them.

--Quanah


--On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu
DEDECKER (CAMPUS)"  wrote:



Hello Quanah,

First I would like to thank you for your answer.

Indeed, I also think that the "cardnumber" index is somehow corrupted.
His size is to small in comparison to other indexes

We suppressed all existing index and Used slapindex to re-create them all.

It's undergoing.

I will keep you informed about the solution.

Best Regards,

Mathieu


2012/1/3 Quanah Gibson-Mount 





--On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER
(CAMPUS)"  wrote:


Hi @All,

We meet a performance problem with our OpenLDAP.

We think that we face a problem with the index of the database, and we
think that the problem can be resolve by tunning the config (but not
sure).

We would like to be sure that our configuration is correct, in order to
confirm if we are on a wrong track or not.

[Description]

We have an attribute (cardNumber) which is indexed.

When we request the indexed attribute (cardNumber) with an LDAP Client
(Ldapbrowser), we have either fast or very long response time.

For the long response time, the CPU of the server hits 100%.

For example:

Request1: cardnumber=2098001010034  (less than 1sec)
Request2: cardnumber=2090389917486  (nearly 20 sec).

By checking the hit ratio of the attribute, we can see that cache is
correctly used (97%).


It sounds like you added an index to cardnumber after there was already
data for cardnumber in your database, and didn't run slapindex for that
attribute.  Alternatively, your cardnumber.bdb file is corrupted.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration









--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration






--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration

TLS issue (again)

[Olivier]

I had to renew my openssl certificates and now my ldap tls negociation
doesn't work anymore :

$ ldapsearch -ZZ -D uid=guillard,ou=staff,ou=people,dc=example,dc=fr
-W uid=guillard -h ldap2.th3.example.fr
ldap_start_tls: Connect error (-11)
additional info: TLS error -8172:Unknown code ___f 20

Here are the server configuration relevant directives :

olcTLSCACertificateFile  /etc/openldap/cacerts/CA.crt
olcTLSCertificateFile /etc/openldap/cacerts/server.crt
olcTLSCertificateKeyFile /etc/openldap/cacerts/server.key
olcTLSCipherSuite HIGH

( see at the very end of this mail : these certificates are correct since I have
  successfully proceed to openssl connexion tests).

and here are logs collected on the server side when receiving ldapsearch
request :

daemon: activity on 1 descriptor
daemon: activity on:
slap_listener_activate(7):
daemon: epoll: listen=7 busy
>>> slap_listener(ldap://ldap2.th3.example.fr:389)
daemon: listen=7, new connection on 15
daemon: added 15r (active) listener=(nil)
conn=1003 fd=15 ACCEPT from IP=10.10.86.93:41013 (IP=10.1.92.25:389)
daemon: activity on 2 descriptors
daemon: activity on: 15r
daemon: read active on 15
daemon: epoll: listen=7 active_threads=0 tvp=zero
connection_get(15)
connection_get(15): got connid=1003
connection_read(15): checking for input on id=1003
ber_get_next
ldap_read: want=8, got=8
  :  30 1d 02 01 01 77 18 800w..
ldap_read: want=23, got=23
  :  16 31 2e 33 2e 36 2e 31  2e 34 2e 31 2e 31 34 36   .1.3.6.1.4.1.146
  0010:  36 2e 32 30 30 33 37   6.20037
ber_get_next: tag 0x30 len 29 contents:
ber_dump: buf=0x7f272017aa70 ptr=0x7f272017aa70 end=0x7f272017aa8d len=29
  :  02 01 01 77 18 80 16 31  2e 33 2e 36 2e 31 2e 34   ...w...1.3.6.1.4
  0010:  2e 31 2e 31 34 36 36 2e  32 30 30 33 37.1.1466.20037
op tag 0x77, time 1325683329
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
conn=1003 op=0 do_extended
ber_scanf fmt ({m) ber:
ber_dump: buf=0x7f272017aa70 ptr=0x7f272017aa73 end=0x7f272017aa8d len=26
  :  77 18 80 16 31 2e 33 2e  36 2e 31 2e 34 2e 31 2e   w...1.3.6.1.4.1.
  0010:  31 34 36 36 2e 32 30 30  33 37 1466.20037
conn=1003 op=0 EXT oid=1.3.6.1.4.1.1466.20037
do_extended: oid=1.3.6.1.4.1.1466.20037
conn=1003 op=0 STARTTLS
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 15
  :  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00 0x
ldap_write: want=14, written=14
  :  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00 0x
conn=1003 op=0 RESULT oid= err=0 text=
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 15r
daemon: read active on 15
daemon: epoll: listen=7 active_threads=0 tvp=zero
connection_get(15)
connection_get(15): got connid=1003
connection_read(15): checking for input on id=1003
tls_read: want=3, got=3
  :  80 3a 01   .:.
tls_read: want=57, got=57
  :  03 01 00 21 00 00 00 10  00 00 35 00 00 04 00 00   ...!..5.
  0010:  05 00 00 2f 00 00 0a 00  00 09 00 00 64 00 00 62   .../d..b
  0020:  00 00 03 00 00 06 00 00  ff 70 1e 75 15 46 04 b3   .p.u.F..
  0030:  16 ed d1 87 1c 77 58 06  48.wX.H
tls_write: want=2157, written=2157
  :  16 03 01 08 68 02 00 00  4d 03 01 4f 04 52 81 3c   h...M..O.R.<
  0010:  c6 b8 b6 8a d8 4a 75 83  a7 fc 09 13 2c c8 d4 d4   .Ju.,...
  0020:  ce e7 12 73 80 bc 42 f6  f2 05 de 20 6c db 35 d1   ...s..B l.5.
  0030:  e0 2b bb 93 a4 c2 8c 82  df 51 58 0a 93 e6 c9 ff   .+...QX.
  0040:  10 0d 92 08 6c 96 3e f8  92 aa d8 83 00 35 00 00   l.>..5..
  0050:  05 ff 01 00 01 00 0b 00  06 d3 00 06 d0 00 02 e3   
  0060:  30 82 02 df 30 82 01 c7  02 09 00 a6 1d 1f 28 63   0...0.(c
  0070:  5e 6a 57 30 0d 06 09 2a  86 48 86 f7 0d 01 01 05   ^jW0...*.H..
  0080:  05 00 30 81 87 31 0b 30  09 06 03 55 04 06 13 02   ..0..1.0...U
  0090:  66 72 31 0f 30 0d 06 03  55 04 08 0c 06 66 72 61   fr1.0...Ufra
  00a0:  6e 63 65 31 11 30 0f 06  03 55 04 07 0c 08 6d 6f   nce1.0...Umo
  00b0:  6e 74 69 67 6e 79 31 0e  30 0c 06 03 55 04 0a 0c   ntigny1.0...U...
  00c0:  05 61 66 6e 69 63 31 0d  30 0b 06 03 55 04 0b 0c   .example1.0...U...
  00d0:  04 6c 64 61 70 31 0d 30  0b 06 03 55 04 03 0c 04   .ldap1.0...U
  00e0:  6c 64 61 70 31 26 30 24  06 09 2a 86 48 86 f7 0d   ldap1&0$..*.H...
  00f0:  01 09 01 16 17 6f 6c 69  76 69 65 72 2e 67 75 69   .olivier.gui
  0100:  6c 6c 61 72 64 40 6e 69  63 2e 66 72 30 1e 17 0d
llard@example.fr0...
  0110:  31 31 31 32 32 39 31 35  33 39 35 38 5a 17 0d 32   111229153958Z..2
  0120:  31 30 37 32 39 31 35 33  39 35 38 5a 30 81 a2 31   10729153958Z0..1
  0130:  0b 30 09 06 03 55 04 06  13 02 66 72 31 0f 30 0d   .

Re: Issue with index in OpenLDAP?

[External Mathieu DEDECKER (CAMPUS)]

I will read the man page in order to have more informations about the
command.

I tried to reindex all the index of the database with the slapindex
command, but I allways the same behaviour:

Request1: cardnumber=2098001010034  (less than 1sec)
Request2: cardnumber=2090389917486  (nearly 20 sec).

Other .bdb files size have been updated, but my "cardnumber.bdb" has still
the same size.

Regards,

Mathieu

2012/1/4 Quanah Gibson-Mount 

> Hi Mathieu,
>
> If you read the slapindex man page, it is possibly to just recreate a
> specific index file (for situations like this), rather than generating all
> of them.
>
> --Quanah
>
>
> --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu DEDECKER
> (CAMPUS)"  wrote:
>
>  Hello Quanah,
>>
>> First I would like to thank you for your answer.
>>
>> Indeed, I also think that the "cardnumber" index is somehow corrupted.
>> His size is to small in comparison to other indexes
>>
>> We suppressed all existing index and Used slapindex to re-create them all.
>>
>> It's undergoing.
>>
>> I will keep you informed about the solution.
>>
>> Best Regards,
>>
>> Mathieu
>>
>>
>> 2012/1/3 Quanah Gibson-Mount 
>>
>>
>> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER
>> (CAMPUS)"  wrote:
>>
>>
>> Hi @All,
>>
>> We meet a performance problem with our OpenLDAP.
>>
>> We think that we face a problem with the index of the database, and we
>> think that the problem can be resolve by tunning the config (but not
>> sure).
>>
>> We would like to be sure that our configuration is correct, in order to
>> confirm if we are on a wrong track or not.
>>
>> [Description]
>>
>> We have an attribute (cardNumber) which is indexed.
>>
>> When we request the indexed attribute (cardNumber) with an LDAP Client
>> (Ldapbrowser), we have either fast or very long response time.
>>
>> For the long response time, the CPU of the server hits 100%.
>>
>> For example:
>>
>> Request1: cardnumber=2098001010034  (less than 1sec)
>> Request2: cardnumber=2090389917486  (nearly 20 sec).
>>
>> By checking the hit ratio of the attribute, we can see that cache is
>> correctly used (97%).
>>
>>
>> It sounds like you added an index to cardnumber after there was already
>> data for cardnumber in your database, and didn't run slapindex for that
>> attribute.  Alternatively, your cardnumber.bdb file is corrupted.
>>
>> --Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Sr. Member of Technical Staff
>> Zimbra, Inc
>> A Division of VMware, Inc.
>> 
>> Zimbra ::  the leader in open source messaging and collaboration
>>
>>
>>
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> 
> Zimbra ::  the leader in open source messaging and collaboration
>

Re: slapd-ldap as proxy to active directory

[Aaron Richton]

On Wed, 4 Jan 2012, Liam Gretton wrote:


If you think there are (standard track) syntaxes that AD supports
and OpenLDAP misses, feel free to file a request for enhancement
using the ITS ().


It certainly would be useful. What does 'standard track' mean? I have a
suspicion anything created by MS would automatically be excluded ;-)


Typically it refers to something that's intended to be published as a 
Standard through the IETF, although I'd like to think that OpenLDAP would 
be receptive to similar proceedings from other competent organizations.


Try as a starting point: http://www.ietf.org/about/standards-process.html

Re: slapd-ldap as proxy to active directory

[Liam Gretton]

On 16/12/2011 15:14, Pierangelo Masarati wrote:

On 12/16/2011 03:35 PM, Liam Gretton wrote:

On my OpenLDAP AD proxy, as soon as slapd has started I do a
trivial search for a 'cn' attribute for a known record. After that,
it's possible to search on sAMAccountName or other attributes
without any problems.


You don't need 99% of what you said.  All you need is:


[...]


You don't need to create all the schema, only the portions that are
needed.  If an attribute uses a syntax that OpenLDAP's slapd does
not support (yet), you can use the closest one.  Usually, anything
that needs not be case insensitive can be octet string, which has an
equality rule.


I started that, but it quickly looked like a significant amount of work
for a number of attributes, so the quick and dirty solution was the
workaround I mentioned. I've put aside creating a custom AD schema for a
rainy day.


If you think there are (standard track) syntaxes that AD supports
and OpenLDAP misses, feel free to file a request for enhancement
using the ITS ().


It certainly would be useful. What does 'standard track' mean? I have a
suspicion anything created by MS would automatically be excluded ;-)


--
Liam Grettonliam.gret...@le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services   Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

Re: ldif_back_add: err: 68 text:

[Maxim Vetrov]

Buchan Milne пишет:

On Tuesday, 3 January 2012 03:33:42 Maxim Vetrov wrote:


Hi!

Trying to start test server (openldap 2.4.25) on my home box (FreeBSD
8.2 i386) I get this error:


Can you provide the commandline invocation that provided this error message?



...
ldif_back_add: "olcDatabase={0}config,cn=config"
oc_check_required entry (olcDatabase={0}config,cn=config), objectClass
"olcDatabaseConfig"
oc_check_allowed type "objectClass"
oc_check_allowed type "olcDatabase"
oc_check_allowed type "olcAddContentAcl"
oc_check_allowed type "olcLastMod"
oc_check_allowed type "olcMaxDerefDepth"
oc_check_allowed type "olcReadOnly"
oc_check_allowed type "olcRootDN"
oc_check_allowed type "olcSyncUseSubentry"
oc_check_allowed type "olcMonitoring"
oc_check_allowed type "structuralObjectClass"
oc_check_allowed type "entryUUID"
oc_check_allowed type "creatorsName"
oc_check_allowed type "createTimestamp"
oc_check_allowed type "entryCSN"
oc_check_allowed type "modifiersName"
oc_check_allowed type "modifyTimestamp"
ldif_back_add: err: 68 text:
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=68 matched="" text=""
slapd destroy: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.

Config I use:

# global configuration entry
dn: cn=config
objectClass: olcGlobal
cn: config
olcAttributeOptions: x-hidden lang-
olcLogLevel: conns config acl

# internal schema
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

include: file:///usr/local/etc/openldap/schema/core.ldif
include: file:///usr/local/etc/openldap/schema/cosine.ldif
include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif
#include: file:///usr/local/etc/openldap/schema/collective.ldif
include: file:///usr/local/etc/openldap/schema/nis.ldif



It looks as if you are treating the back-ldif database as if it is a text-
based configuration file, which in fact it is not. You should not be starting
slapd with this configuration file, but rather be running 'slapadd -n0' (or
similar) on this ldif to import an initial configuration. Further
administration of the configuration should be done over the LDAP protocol
(e.g. with ldapmodify, or a GUI LDAP tool).

While the documentation may not necessarily be explicit enough in this regard,
please read the notes at the beginning of the 'Configuring slapd' section of
the administrator guide, such as:

"Note: Although the slapd-config(5) system stores its configuration as (text-
based) LDIF files, you should never edit any of the LDIF files directly.
Configuration changes should be performed via LDAP operations, e.g.
ldapadd(1), ldapdelete(1), or ldapmodify(1). "


Regards,
Buchan





Thank you for answer!

Actually, I'm trying to apply recommendation from the the slapd-config 
where simple config.ldif is listed and the imported into the db with 
slapadd command. Anyway here is command sequence


Save the config in , create 
/usr/local/etc/openldap/slapd.d/ dir, set appropriate user&mode for it. 
Then, as root:
# sudo -u ldap slapadd -F /usr/local/etc/openldap/slapd.d/ -n 0 -l 
/home/muxas/projects/ldap-server/slapd-template.ldif
# /usr/local/libexec/slapd -h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ 
ldap://127.0.0.1/"; -u ldap -g ldap -F /usr/local/etc/openldap/slapd.d/ 
-d any


Slapadd runs without complains. But slapd does not start.

Maxim

Re: smbldap-populate error

[Adrián Arévalo Tirado]

I have "converted" the new configuration into the old one
(/etc/slap/slapd.conf). I saw in a forum that it was possible, so I deleted
slap.d directory and placed slapd.conf instead.

Anyway, I had to change the example slapd.conf
(/usr/share/slapd/slapd.conf) in order to match the old configuration,
which took me quite a while. There are lots of "errors" (or warnings
maybe), but I can follow the tutorials (the output of my commands is the
same as those on the tutorial), so I suppose that everything is OK

At least the LDAP part is well configured, Now I have to move on to the
Windows authentication.



2012/1/4 Simone Piccardi 

> Il 03/01/2012 19:59, Adrián Arévalo Tirado ha scritto:
> > First of all. Thanks for the response.
> >
> > I'm totally new to LDAP (so, excuse me if I ask for nonsenses) and, to
> > be honest, I don't know which method uses my distro (Debian 6) for
> > configuration. On every documentation I see, they use
> > /etc/slapd/slapd.conf, but in my case that file doesn't exist.
> >
> > Therefore, I'm using /usr/share/slapd/slapd.conf (The only slapd.conf I
> find).
> >
> Recent Debian use the cn=config by default on new installation. You have
> to add the samba schema (should be inside the samba-doc package), but I
> don't remember if there is an .ldif version or just the old samba.schema
> file.
>
> Having a working traditional slapd.conf configuration it's just matter
> to add an include for the samba.schema file.
>
> Simone
>
>

Re: smbldap-populate error

[Simone Piccardi]

Il 03/01/2012 19:59, Adrián Arévalo Tirado ha scritto:
> First of all. Thanks for the response.
> 
> I'm totally new to LDAP (so, excuse me if I ask for nonsenses) and, to
> be honest, I don't know which method uses my distro (Debian 6) for
> configuration. On every documentation I see, they use
> /etc/slapd/slapd.conf, but in my case that file doesn't exist.
> 
> Therefore, I'm using /usr/share/slapd/slapd.conf (The only slapd.conf I find).
> 
Recent Debian use the cn=config by default on new installation. You have
to add the samba schema (should be inside the samba-doc package), but I
don't remember if there is an .ldif version or just the old samba.schema
file.

Having a working traditional slapd.conf configuration it's just matter
to add an include for the samba.schema file.

Simone

Re: Issue with index in OpenLDAP?

[Quanah Gibson-Mount]

Hi Mathieu,

If you read the slapindex man page, it is possibly to just recreate a 
specific index file (for situations like this), rather than generating all 
of them.


--Quanah

--On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu DEDECKER 
(CAMPUS)"  wrote:



Hello Quanah,

First I would like to thank you for your answer.

Indeed, I also think that the "cardnumber" index is somehow corrupted.
His size is to small in comparison to other indexes

We suppressed all existing index and Used slapindex to re-create them all.

It's undergoing.

I will keep you informed about the solution.

Best Regards,

Mathieu


2012/1/3 Quanah Gibson-Mount 


--On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER
(CAMPUS)"  wrote:


Hi @All,

We meet a performance problem with our OpenLDAP.

We think that we face a problem with the index of the database, and we
think that the problem can be resolve by tunning the config (but not
sure).

We would like to be sure that our configuration is correct, in order to
confirm if we are on a wrong track or not.

[Description]

We have an attribute (cardNumber) which is indexed.

When we request the indexed attribute (cardNumber) with an LDAP Client
(Ldapbrowser), we have either fast or very long response time.

For the long response time, the CPU of the server hits 100%.

For example:

Request1: cardnumber=2098001010034  (less than 1sec)
Request2: cardnumber=2090389917486  (nearly 20 sec).

By checking the hit ratio of the attribute, we can see that cache is
correctly used (97%).


It sounds like you added an index to cardnumber after there was already
data for cardnumber in your database, and didn't run slapindex for that
attribute.  Alternatively, your cardnumber.bdb file is corrupted.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration






--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Issue with index in OpenLDAP?

[External Mathieu DEDECKER (CAMPUS)]

Hello Quanah,

First I would like to thank you for your answer.

Indeed, I also think that the "cardnumber" index is somehow corrupted. His
size is to small in comparison to other indexes

We suppressed all existing index and Used slapindex to re-create them all.

It's undergoing.

I will keep you informed about the solution.

Best Regards,

Mathieu

2012/1/3 Quanah Gibson-Mount 

> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER
> (CAMPUS)"  wrote:
>
>  Hi @All,
>>
>> We meet a performance problem with our OpenLDAP.
>>
>> We think that we face a problem with the index of the database, and we
>> think that the problem can be resolve by tunning the config (but not
>> sure).
>>
>> We would like to be sure that our configuration is correct, in order to
>> confirm if we are on a wrong track or not.
>>
>> [Description]
>>
>> We have an attribute (cardNumber) which is indexed.
>>
>> When we request the indexed attribute (cardNumber) with an LDAP Client
>> (Ldapbrowser), we have either fast or very long response time.
>>
>> For the long response time, the CPU of the server hits 100%.
>>
>> For example:
>>
>> Request1: cardnumber=2098001010034  (less than 1sec)
>> Request2: cardnumber=2090389917486  (nearly 20 sec).
>>
>> By checking the hit ratio of the attribute, we can see that cache is
>> correctly used (97%).
>>
>
> It sounds like you added an index to cardnumber after there was already
> data for cardnumber in your database, and didn't run slapindex for that
> attribute.  Alternatively, your cardnumber.bdb file is corrupted.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> 
> Zimbra ::  the leader in open source messaging and collaboration
>