- openldap-bugs - openldap.org

(ITS#7028) [PATCH] various manpage fixes
by jvcelak＠redhat.com 24 Aug '11

24 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: Submission from: (NULL) (209.132.186.34) Hi, I have uploaded various manual page fixes which are included in Fedora. ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-slapo-unique.patch - adds information about missing quotes around keyword and uri (maybe ITS #6181) - adds missing <attribute...> parameter ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-ldap_sync.patch - fixes invalid prototype of ldap_sync_destroy Jan

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

File at james-leddy-110823.patch.1 The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat Inc. Red Hat Inc. has not assigned rights and/or interest in this work to any party. I, James M. Leddy am authorized by Red Hat Inc., my employer, to release this work under the following terms. Red Hat Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

Full_Name: James M Leddy Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.187.233.202) >From RFC 2782: A client MUST attempt to contact the target host with the lowest-numbered priority it can reach. This patch sorts the DNS SRV records by their priority, and additionally gives records with a larger weight a higher probability of appearing earlier. This way, the DNS SRV records are tried in the order of their priority.

1 0

Re: (ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

hans.moser(a)ofd-z.niedersachsen.de schrieb: > Full_Name: Marc Patermann > Version: 2.4.26 > OS: SLES 11 SP1 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.37.205.30) This is only a double post (reloading the ITS page by accident) of #7025 and can be closed. Sorry. Marc

1 0

(ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

Full_Name: Marc Patermann Version: 2.4.26 OS: SLES 11 SP1 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.205.30) Hi, thankfully Howard tracked down the issue I posted on openldap-technical as "provider crash on high replication load" down to: "I believe the problem is much simpler - the backglue code doesn't install a handler for the Abandon operation, and this is preventing syncprov's abandon handler from running, so it never gets to clean up when a consumer connection closes. By now you should submit a bug report to the ITS so we can track this further. It should only require a small patch to the backglue code." The provider has three databases, which are glued together under one root database. Each of the three subordinates is replicated by about 60 consumers. On heavy replication load (all 180 consumers do initial sync), I can crash the server with on little mod on an object in one of the subordinate databases. If I can provide any further information on this, please let me know.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by masarati＠aero.polimi.it 23 Aug '11

23 Aug '11

> >> back-sql calls backsql_BindParamBerVal(), which indeed considers the >> data as >> SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but >> back-sql >> will need to know what attribute values need to be treated as binaries. >> A >> general approach to this requires to modify the attribute mapping, to >> add a >> "type" flag. >> >> p. >> > I have carefully read the documentation (man slapd-sql) but could not > find how to modify the attribute mapping and add a "type" flag. I meant: modify the code. Since back-sql is basically unmaintained (any volunteers out there?) this feature won't likely be added, not to mention the fact that it would break all existing installations. p.

1 0

(ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

Full_Name: Marc Patermann Version: 2.4.26 OS: SLES 11 SP1 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.205.30) Hi, thankfully Howard tracked down the issue I posted on openldap-technical as "provider crash on high replication load" down to: "I believe the problem is much simpler - the backglue code doesn't install a handler for the Abandon operation, and this is preventing syncprov's abandon handler from running, so it never gets to clean up when a consumer connection closes. By now you should submit a bug report to the ITS so we can track this further. It should only require a small patch to the backglue code." The provider has three databases, which are glued together under one root database. Each of the three subordinates is replicated by about 60 consumers. On heavy replication load (all 180 consumers do initial sync), I can crash the server with on little mod on an object in one of the subordinate databases. If I can provide any further information on this, please let me know.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by daniil＠chics.ru 22 Aug '11

22 Aug '11

> back-sql calls backsql_BindParamBerVal(), which indeed considers the data as > SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql > will need to know what attribute values need to be treated as binaries. A > general approach to this requires to modify the attribute mapping, to add a > "type" flag. > > p. > I have carefully read the documentation (man slapd-sql) but could not find how to modify the attribute mapping and add a "type" flag.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by Pierangelo Masarati 22 Aug '11

22 Aug '11

back-sql calls backsql_BindParamBerVal(), which indeed considers the data as SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql will need to know what attribute values need to be treated as binaries. A general approach to this requires to modify the attribute mapping, to add a "type" flag. p.

1 0

Re: (ITS#6993)
by masarati＠aero.polimi.it 22 Aug '11

22 Aug '11

> Hello > > This problem occurs at the end of the connection init. > At the end of the connection_init, the connection is provided to the > listener list (through slapd_add_internal call) and then, the connection > mutex is freed. > > ==> At this point, the connection is available to the listener but the > back end initialization has not been done. > > The backend_connection_init call is done out of the connection mutex > protection. > If the connection mutex is freed after the connection_init call, all the > back end should performed their initialization before it could be used > in the operation Thank you. I understand your point, and I agree that the connection initialization is not over until all backends had an opportunity to deal with it. My concern is about any harm this change may cause to existing code. A quick search in official backends and overlays shows that only slapo-rwm(5) is currently setting this hook. Let alone this possible bug, this fact triggers something in my mind: bi_connection_init() might not be the best place for your initialization to occur. In fact, this is intended to provide something to *all* connections, but a connection being created does not imply that your backend will be used, so it may be a waste of resources to initialize your backend for *all* connections. You might be better off initializing your backend's connections only when they are actually needed, i.e. each operation within your backend should (mutex-protected) check whether initialization occurred and, if it didn't, do it; if it's ongoing, just pause waiting for it to finish. p.

1 0

(ITS#6993)
by yann.carre＠alcatel-lucent.com 22 Aug '11

22 Aug '11

Hello This problem occurs at the end of the connection init. At the end of the connection_init, the connection is provided to the listener list (through slapd_add_internal call) and then, the connection mutex is freed. ==> At this point, the connection is available to the listener but the back end initialization has not been done. The backend_connection_init call is done out of the connection mutex protection. If the connection mutex is freed after the connection_init call, all the back end should performed their initialization before it could be used in the operation Regards Yann Carre

1 0

Re: (ITS#6993) Backend Connection problem
by masarati＠aero.polimi.it 22 Aug '11

22 Aug '11

[you must reply to the ITS to have your messages injected in the system] > Hello > > This problem occurs at the end of the connection init. > At the end of the connection_init, the connection is provided to the > listener list (through slapd_add_internal call) and then, the connection > mutex is freed. > > ==> At this point, the connection is available to the listener but the > back end initialization has not been done. > > The backend_connection_init call is done out of the connection mutex > protection. > If the connection mutex is freed after the connection_init call, all the > back end should performed their initialization before it could be used > in the operation

1 0

(ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by daniil＠chics.ru 21 Aug '11

21 Aug '11

Full_Name: Daniil Harun Version: 2.4.26 OS: FreeBSD, Linux URL: Submission from: (NULL) (80.85.151.246) OpenLDAP does not save the attribute "jpegphoto" in the sql database. Use back-sql, unixodbc and postgresql database. The reason for the problem of the use of the data type SQL_VARCHAR instead of SQL_LONGVARBINARY. slapd debug output: backsql_modify_internal(): adding new values for attribute "jpegPhoto" backsql_modify_internal(): arg(2)=1 backsql_modify_internal(): arg(1)="����"; executing "UPDATE personal SET jpegphoto=? WHERE id=?" backsql_modify_internal(): add_proc execution failed (rc=-1, prc=0) Return code: -1 nativeErrCode=7 SQLengineState=22021 msg="ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query" SQL tracing is enabled: [ODBC][23880][1313994179.641693][SQLPrepare.c][196] Entry: Statement = 0x293eae00 SQL = [UPDATE personal SET jpegphoto=? WHERE id=?][length = 42 (SQL_NTS)] [ODBC][23880][1313994179.641791][SQLPrepare.c][371] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.641886][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 2 Param Type = 1 C Type = -27 SQL_C_UBIGINT SQL Type = 4 SQL_INTEGER Col Def = 0 Scale = 0 Rgb Value = 0xbf1fc7a4 Value Max = 0 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.641988][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642182][SQLBindParamet[ODBC][23880][1313994179.641693][SQLPrepare.c][196] Entry: Statement = 0x293eae00 SQL = [UPDATE personal SET jpegphoto=? WHERE id=?][length = 42 (SQL_NTS)] [ODBC][23880][1313994179.641791][SQLPrepare.c][371] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.641886][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 2 Param Type = 1 C Type = -27 SQL_C_UBIGINT SQL Type = 4 SQL_INTEGER Col Def = 0 Scale = 0 Rgb Value = 0xbf1fc7a4 Value Max = 0 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.641988][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642182][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 1 Param Type = 1 C Type = 1 SQL_C_CHAR SQL Type = 12 SQL_VARCHAR Col Def = 2790 Scale = 0 Rgb Value = 0x29529700 Value Max = 2790 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.642284][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642741][SQLExecute.c][187] Entry: Statement = 0x293eae00 [ODBC][23880][1313994179.645733][SQLExecute.c][348] Exit:[SQL_ERROR] DIAG [22021] ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query er.c][217] Entry: Statement = 0x293eae00 Param Number = 1 Param Type = 1 C Type = 1 SQL_C_CHAR SQL Type = 12 SQL_VARCHAR Col Def = 2790 Scale = 0 Rgb Value = 0x29529700 Value Max = 2790 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.642284][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642741][SQLExecute.c][187] Entry: Statement = 0x293eae00 [ODBC][23880][1313994179.645733][SQLExecute.c][348] Exit:[SQL_ERROR] DIAG [22021] ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query OpenLDAP uses the wrong data - types SQL_C_CHAR,SQL_VARCHAR instead of SQL_C_BINARY,SQL_LONGVARBINARY. How to make use of the correct data types?

1 0

ITS#7021
by masarati＠aero.polimi.it 20 Aug '11

20 Aug '11

All in all, I think it is better to stick with the spec and with the documentation, although I also added some notes to slapo-ppolicy(5). p.

1 0

Re: (ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> Full_Name: Manuel Gaupp > Version: 2.4.26 > OS: Linux 2.6.18 (CentOS 5.6 x86_64) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.208.112.253) > > > Under the following circumstances OpenLDAP crashes when a chained search > does not return with result code 0: > - "rwm" overlay used in a global context > - "chain" overlay used in a database specifix context > > (gdb) bt > #0 0x0000000400040004 in ?? () > #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) > at result.c:539 > #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:724 > #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, > rs=0x42a07ca0) at chain.c:1165 > #5 0x00000000004820ca in over_back_response (op=0x197834b0, > rs=0x42a07ca0) > at backover.c:237 > #6 0x000000000042e535 in slap_response_play (op=0x197834b0, > rs=0x42a07ca0) > at result.c:505 > #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:579 > #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:499 > #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 > #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:402 > #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 > #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:247 > #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, > arg_v=<value optimized out>) at connection.c:1138 > #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) > at tpool.c:685 > #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 > #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 > > OpenLDAP 2.4.26 was built using: > ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb > > This issue can be reproduced using the following configuration > (referred as 'slapd.conf.proxy') > ------------------------------------------ > overlay rwm > # There might be some rewrite directives > database bdb > suffix "o=example" > rootdn "cn=admin,o=example" > rootpw secret > directory /root/db.proxy > overlay chain > chain-return-error true > chain-uri "ldap://localhost:38977" > ------------------------------------------ > The process is started on port 389 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" > > Create the following entry in this server: > dn: cn=ldap,o=example > objectclass: extensibleObject > objectclass: referral > ref: ldap://localhost:38977/cn=real,o=example > > To reproduce the error there has to be another server where the referral > points to. It contains the following minimal configuration: > (referred as 'slapd.conf.server') > ------------------------------------------ > database bdb > suffix "cn=real,o=example" > rootdn "cn=admin,cn=real,o=example" > rootpw secret > directory /root/db.server > ------------------------------------------ > The process is started on port 38977 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" > > Using the following ldapsearch, slapd crashes: > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "ou=abc,cn=ldap,o=example" 1.1 > > Whereas the following ldapsearch returns with "success" > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "cn=ldap,o=example" 1.1 > > Deactivating the "rwm" overlay prevents from this issue. So I think the > problem can be found somewhere in the rwm sources. I'm afraid that's unavoidable given the stacking order of the overlays. This will likely be fixed only when ITS#6166 is addressed, i.e. in OpenLDAP 2.5. p.

1 0

Re: (ITS#6993) Backend Connection problem
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> Full_Name: Yann Carre > Version: 2.4.26 > OS: red hat 5 (64 bits) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.208.49.20) > > > I work on a specific Backend > I have provided in my back end a function to the bi_connection_init > pointer. > This function adds a context needed in the operation backend function > (search, > ...) > > When several connections start up, my LDAP server crashes. > The crash arrives because the context is not created before the call to > do_searh. > The connection is provided to the application Backend before my Back end > connection_init. > I have checked it with the debugger and see that the thread with > initialize the > connection is suspend before the backend connection_init. In another > thread, the > search function is executed without any context attached to the > connection. > > This problem seems to be bring because the connection mutex is freed > before the > calling of the Back end connection_init in the function connection_init > (connection.c). > > I have moved this mutex after the backend connection_init and it seems to > work. > > Would you confirm this analysis and take the correction in account? Honestly, if that context you mention is connection-specific, I don't see how this could happen, since operations on that connection should not be possible until connection_init() returns. OTOH, if the context is global, you should initialize it differently, and protect it from being used before its initialization is complete, e.g. by a specific mutex that is completely internal to your backend. In any case, it is not clear how this can be an OpenLDAP bug. You should provide a clearer evidence. In the absence, I'd consider this ITS closed. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> masarati(a)aero.polimi.it wrote: >> The patch is the result of my reading in 5 minutes a single portion of a >> spec I read in detail years ago, so my interpretation could not be the >> most correct. > > But your interpretation makes sense: E.g. system accounts most times do > not > need to change their own password. And for security reasons you might want > to > avoid that. Think of a the case where the password of a more exposed > system is > known by an attacker (which is likely a very bad case anyway). But at > least > the attacker should not be able to disable this service by setting a new > password. > > Yes, this can be done with ACLs. But you might already have a password > policy > assigned to this special system accounts because you don't want the system > accounts' password to expire. So adding an extra ACL is more work > especially > if system accounts are spread across a more complicated DIT. Well, as a counter-example, if security is compromised, then setting pwdAllowUserChange to FALSE would only prevent password modification for users that fall under that password policy, while others would need to be protected anyway using ACLs. And if security is seriously compromised, none of these would work, because rootdn circumvents all checks. So giving different orthogonal means to obtain similar but not identical effects sounds to me making things more complicated than they ought to be. Given the fact that pwdAllowUserChange is a gross subset of ACLs, I'd rather discourage its usage through clear documentation than try to make it conform to some or some other interpretation of the specs. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 18 Aug '11

18 Aug '11

masarati(a)aero.polimi.it wrote: > The patch is the result of my reading in 5 minutes a single portion of a > spec I read in detail years ago, so my interpretation could not be the > most correct. But your interpretation makes sense: E.g. system accounts most times do not need to change their own password. And for security reasons you might want to avoid that. Think of a the case where the password of a more exposed system is known by an attacker (which is likely a very bad case anyway). But at least the attacker should not be able to disable this service by setting a new password. Yes, this can be done with ACLs. But you might already have a password policy assigned to this special system accounts because you don't want the system accounts' password to expire. So adding an extra ACL is more work especially if system accounts are spread across a more complicated DIT. Ciao, Michael.

1 0

(ITS#7023) TLSCACertificateFile description in slapd.conf.5 is missing critical information
by Frank.Swasey＠uvm.edu 18 Aug '11

18 Aug '11

Full_Name: Francis Swasey Version: 2.4.26 OS: Linux URL: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.… Submission from: (NULL) (132.198.107.64) The following referenced patch copies critical information that should be in the slapd.conf.5 man page from the admin guide: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.…

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 18 Aug '11

18 Aug '11

> masarati(a)aero.polimi.it wrote: >>>> Then the patch is trivial: >>>> [..] >>>> If there's consensus, I'll commit it. >>> >>> Seems like a pointless change. You must set ACLs for this type of >>> modification >>> to be allowed. Since you must set ACLs anyway, there is no good reason >>> to >>> use >>> the pwdAllowUserChange policy setting in the first place. In general >>> the >>> pwdAllowUserChange option is only useful on systems that do not already >>> provide fine grained access controls. >> >> Agree (see my previous message). For this purpose, I suggest to add, in >> slapo-ppolicy(5), a comment about discouraging the use of >> pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. > > I already knew that this can be achieved by ACLs but... > > 1. OpenLDAP should behave as stated in the ppolicy spec and the man-pages. > > 2. sometimes it'd be more handy to use this flag in an already existing > pwdPolicy entry than defining additional ACLs. > > Since this patch seems so trivial why not commit it? The patch is the result of my reading in 5 minutes a single portion of a spec I read in detail years ago, so my interpretation could not be the most correct. Since Howard implemented slapo-ppolicy(5), I believe his interpretation of the spec is more accurate. The fact that he interprets this flag as a complete replacement of ACLs on systems where they are not granular enough lets me think that its behavior should be broader (i.e. apply to all users) rather than strictly sticking to the word (i.e. apply to self only). That's why I'm seeking consensus before committing a patch (that could be harmful, as the current behavior of slapo-ppolicy(5) makes this flag work as a complete alternative to ACLs, while the new behavior, not complemented by appropriate ACLs, could allow anybody but self to change the pwd). p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 18 Aug '11

18 Aug '11

masarati(a)aero.polimi.it wrote: >>> Then the patch is trivial: >>> [..] >>> If there's consensus, I'll commit it. >> >> Seems like a pointless change. You must set ACLs for this type of >> modification >> to be allowed. Since you must set ACLs anyway, there is no good reason to >> use >> the pwdAllowUserChange policy setting in the first place. In general the >> pwdAllowUserChange option is only useful on systems that do not already >> provide fine grained access controls. > > Agree (see my previous message). For this purpose, I suggest to add, in > slapo-ppolicy(5), a comment about discouraging the use of > pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. I already knew that this can be achieved by ACLs but... 1. OpenLDAP should behave as stated in the ppolicy spec and the man-pages. 2. sometimes it'd be more handy to use this flag in an already existing pwdPolicy entry than defining additional ACLs. Since this patch seems so trivial why not commit it? Ciao, Michael.

1 0

RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 17 Aug '11

17 Aug '11

>Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS. The contributed works provided by Joshua Tree Software, LLC. and referenced in this ITS were created by Joshua Tree Software, LLC., who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. Shawn McKinney -------- Original Message -------- Subject: Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> Date: Wed, August 17, 2011 10:19 am To: "<shawn.mckinney(a)jtstools.com>" <shawn.mckinney(a)jtstools.com> Cc: openldap-its(a)OpenLDAP.org On Aug 15, 2011, at 7:15 PM, <shawn.mckinney(a)jtstools.com> <shawn.mckinney(a)jtstools.com> wrote: > The product named "Fortress Core" includes contributions that were created by JoshuaTree Software, LLC, who is the exclusive owner of the works. This contribution is made available as indicated by the copyright and license statements attached to the the work. Shawn, the wording of this statement is not sufficient clear for a couple of reasons. One, the term product doesn't necessarily refer to the contributed works. Two, "includes" language doesn't exclude the possibility that portions of the contributed work were created by others. We need the statement of origin to be quite clear. Assuming all of the contributed works were created by JohshuaTree Software, LLC, we suggest stating something of the form. The contributed works provided by <creator> and referenced in this ITS were created by <creator>, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. where <creator> was replaced with JoshuaTree Software, LLC. Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS. Regards, Kurt > > Shawn McKinney > -------- Original Message -------- > Subject: Re: (ITS#6995) Request for Contribution of Identity Access > Management Software to OpenLDAP Project > From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> > Date: Mon, August 15, 2011 2:35 pm > To: shawn.mckinney(a)jtstools.com > Cc: openldap-its(a)OpenLDAP.org > > Shawn, > > I have reviewed the submitted materials. > > Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail. > > The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work. > > It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms. > > The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions. > > It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed. > > Regards, Kurt > > On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote: > > > Full_Name: Shawn McKinney > > Version: All > > OS: All > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (99.34.198.251) > > > > > > Hello, > > > > We have created a new Identity and Access Management SDK, called Fortress, that > > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password > > policies, auditing and more. > > > > It has taken us 2.5 years of steady work to get it ready for this 1.0 release. > > This SDK has approximately 50K lines of Java code of which approximately 25K are > > dedicated to testing using JUnit automated tests to ensure it works correctly. > > There are in excess of 100 public APIs available for use. There is also a Java > > EE container plug-in that provides authentication and authorization services to > > Websphere, Tomcat and JBoss app servers in a declarative fashion. > > > > This product has not been published and we would like to release it as one of > > the products under OpenLDAP family of products. The product will be released > > under New BSD open source license (license information is contained in the > > source archives on ftp server). > > > > I have uploaded seven packages to our FTP server that contain the source, > > documentation and other items for you to look at. > > > > host: jtstools.com > > user: jtsguest1 > > pw: OpenLd@p1 > > > > The packages are as follows: > > > > Fortress Core SDK > > > > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes > > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes > > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes > > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes > > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf > > > > > > Fortress Realm (Java EE Container plug-ins) > > > > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes > > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes > > > > > > Package 4 contains complete javadoc for the APIs. > > > > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the > > overall summary of the SDK. > > > > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package > > descriptions along with detailed documentation describing the contents of the > > SDK. > > > > What we are requesting from the OpenLDAP foundation: > > > > 1. Source code repository to host the SDK and Realm packages. > > 2. Bug tracking. > > 3. Developer and User forums. > > 4. Wiki (this is a nice to have) > > > > Our goal is to run the open source project with your organization and cultivate > > a healthy developer and user community. We have high hopes for this product > > (and OpenLDAP) and consider the 2 products together as an open source > > alternative for IAM products that will compete with the commercial vendor > > offerings. > > > > Once 1.0 is released, we will begin working on 2.0 which will include UI's to > > control Fortress and OpenLDAP along with a policy server to wrap the Fortress > > Java APIs with HTTP/REST Web APIs to make it available to all platforms. > > > > Thanks in advance for your consideration. > > > > Shawn McKinney > > JoshuaTree Software > > shawn.mckinney(a)jtstools.com > > >

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

> masarati(a)aero.polimi.it wrote: >>> masarati(a)aero.polimi.it wrote: >>>> OTOH, by strictly interpreting the way its use is discussed in the >>>> draft, >>>> it should only apply to attempts by "self" to modify the password, so >>>> a >>>> modification performed by a different identity (provided ACLs permit >>>> it) >>>> should not be affected. >>> >>> Yes, that's my understanding too. >> >> Then the patch is trivial: >> >> diff --git a/servers/slapd/overlays/ppolicy.c >> b/servers/slapd/overlays/ppolicy.c >> index 6a693ac..d9afac9 100644 >> --- a/servers/slapd/overlays/ppolicy.c >> +++ b/servers/slapd/overlays/ppolicy.c >> @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) >> >> if (be_isroot( op )) goto do_modify; >> >> - if (!pp.pwdAllowUserChange) { >> + /* NOTE: according to draft-behera-ldap-password-policy >> + * pwdAllowUserChange == FALSE only prevents pwd changes >> + * by the user the pwd belongs to (ITS#7021) */ >> + if (!pp.pwdAllowUserChange&& >> dn_match(&op->o_req_ndn,&op->o_ndn)) { >> rs->sr_err = LDAP_INSUFFICIENT_ACCESS; >> rs->sr_text = "User alteration of password is not >> allowed"; >> pErr = PP_passwordModNotAllowed; >> >> If there's consensus, I'll commit it. > > Seems like a pointless change. You must set ACLs for this type of > modification > to be allowed. Since you must set ACLs anyway, there is no good reason to > use > the pwdAllowUserChange policy setting in the first place. In general the > pwdAllowUserChange option is only useful on systems that do not already > provide fine grained access controls. Agree (see my previous message). For this purpose, I suggest to add, in slapo-ppolicy(5), a comment about discouraging the use of pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by hyc＠symas.com 17 Aug '11

17 Aug '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> OTOH, by strictly interpreting the way its use is discussed in the >>> draft, >>> it should only apply to attempts by "self" to modify the password, so a >>> modification performed by a different identity (provided ACLs permit it) >>> should not be affected. >> >> Yes, that's my understanding too. > > Then the patch is trivial: > > diff --git a/servers/slapd/overlays/ppolicy.c > b/servers/slapd/overlays/ppolicy.c > index 6a693ac..d9afac9 100644 > --- a/servers/slapd/overlays/ppolicy.c > +++ b/servers/slapd/overlays/ppolicy.c > @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) > > if (be_isroot( op )) goto do_modify; > > - if (!pp.pwdAllowUserChange) { > + /* NOTE: according to draft-behera-ldap-password-policy > + * pwdAllowUserChange == FALSE only prevents pwd changes > + * by the user the pwd belongs to (ITS#7021) */ > + if (!pp.pwdAllowUserChange&& dn_match(&op->o_req_ndn,&op->o_ndn)) { > rs->sr_err = LDAP_INSUFFICIENT_ACCESS; > rs->sr_text = "User alteration of password is not allowed"; > pErr = PP_passwordModNotAllowed; > > If there's consensus, I'll commit it. Seems like a pointless change. You must set ACLs for this type of modification to be allowed. Since you must set ACLs anyway, there is no good reason to use the pwdAllowUserChange policy setting in the first place. In general the pwdAllowUserChange option is only useful on systems that do not already provide fine grained access controls. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

> masarati(a)aero.polimi.it wrote: >> OTOH, by strictly interpreting the way its use is discussed in the >> draft, >> it should only apply to attempts by "self" to modify the password, so a >> modification performed by a different identity (provided ACLs permit it) >> should not be affected. > > Yes, that's my understanding too. Then the patch is trivial: diff --git a/servers/slapd/overlays/ppolicy.c b/servers/slapd/overlays/ppolicy.c index 6a693ac..d9afac9 100644 --- a/servers/slapd/overlays/ppolicy.c +++ b/servers/slapd/overlays/ppolicy.c @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) if (be_isroot( op )) goto do_modify; - if (!pp.pwdAllowUserChange) { + /* NOTE: according to draft-behera-ldap-password-policy + * pwdAllowUserChange == FALSE only prevents pwd changes + * by the user the pwd belongs to (ITS#7021) */ + if (!pp.pwdAllowUserChange && dn_match(&op->o_req_ndn, &op->o_ndn)) { rs->sr_err = LDAP_INSUFFICIENT_ACCESS; rs->sr_text = "User alteration of password is not allowed"; pErr = PP_passwordModNotAllowed; If there's consensus, I'll commit it. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 17 Aug '11

17 Aug '11

masarati(a)aero.polimi.it wrote: > OTOH, by strictly interpreting the way its use is discussed in the draft, > it should only apply to attempts by "self" to modify the password, so a > modification performed by a different identity (provided ACLs permit it) > should not be affected. Yes, that's my understanding too. Ciao, Michael.

1 0

ITS#7008
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

I confirm that the issue is related to performing the operation with a privileged identity, which results in pooled connections taken nearly randomly regardless of the client's connection requesting paged results. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

> Full_Name: > Version: 2.4.26 > OS: > URL: > Submission from: (NULL) (84.128.254.201) > > > slapo-ppolicy(5) says: > > pwdAllowUserChange > > This attribute specifies whether users are allowed to change > their own passwords or not. If pwdAllowUserChange is set to > "TRUE", or if the attribute is not present, users will be > allowed to change their own passwords. If its value is > "FALSE", users will not be allowed to change their own pass- > words. > > Given this text I'd expect that admins can still set the userPassword > attribute. > Such a policy is often used for system/machine accounts where the machine > entity > itself does not have to change the password but an admin should be allowed > to do > so. By reading the code, I note that pwdAllowUserChange is not checked when the operation is performed by the rootdn, which in many senses can be seen as an administrator. If by administrator you mean a generic user that is logically granted administrative privileges (e.g. limited to this purpose) I concur it is not possible currently. By reading the man page (and the draft), this attribute seems to be essentially intended as a replacement (a workaround for the absence) of access control. So you could avoid setting it, and use ACLs instead. OTOH, by strictly interpreting the way its use is discussed in the draft, it should only apply to attempts by "self" to modify the password, so a modification performed by a different identity (provided ACLs permit it) should not be affected. p.

1 0

Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠OpenLDAP.org 17 Aug '11

17 Aug '11

On Aug 15, 2011, at 7:15 PM, <shawn.mckinney(a)jtstools.com> <shawn.mckinney(a)jtstools.com> wrote: > The product named "Fortress Core" includes contributions that were created by JoshuaTree Software, LLC, who is the exclusive owner of the works. This contribution is made available as indicated by the copyright and license statements attached to the the work. Shawn, the wording of this statement is not sufficient clear for a couple of reasons. One, the term product doesn't necessarily refer to the contributed works. Two, "includes" language doesn't exclude the possibility that portions of the contributed work were created by others. We need the statement of origin to be quite clear. Assuming all of the contributed works were created by JohshuaTree Software, LLC, we suggest stating something of the form. The contributed works provided by <creator> and referenced in this ITS were created by <creator>, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. where <creator> was replaced with JoshuaTree Software, LLC. Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS. Regards, Kurt > > Shawn McKinney > -------- Original Message -------- > Subject: Re: (ITS#6995) Request for Contribution of Identity Access > Management Software to OpenLDAP Project > From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> > Date: Mon, August 15, 2011 2:35 pm > To: shawn.mckinney(a)jtstools.com > Cc: openldap-its(a)OpenLDAP.org > > Shawn, > > I have reviewed the submitted materials. > > Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail. > > The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work. > > It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms. > > The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions. > > It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed. > > Regards, Kurt > > On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote: > > > Full_Name: Shawn McKinney > > Version: All > > OS: All > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (99.34.198.251) > > > > > > Hello, > > > > We have created a new Identity and Access Management SDK, called Fortress, that > > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password > > policies, auditing and more. > > > > It has taken us 2.5 years of steady work to get it ready for this 1.0 release. > > This SDK has approximately 50K lines of Java code of which approximately 25K are > > dedicated to testing using JUnit automated tests to ensure it works correctly. > > There are in excess of 100 public APIs available for use. There is also a Java > > EE container plug-in that provides authentication and authorization services to > > Websphere, Tomcat and JBoss app servers in a declarative fashion. > > > > This product has not been published and we would like to release it as one of > > the products under OpenLDAP family of products. The product will be released > > under New BSD open source license (license information is contained in the > > source archives on ftp server). > > > > I have uploaded seven packages to our FTP server that contain the source, > > documentation and other items for you to look at. > > > > host: jtstools.com > > user: jtsguest1 > > pw: OpenLd@p1 > > > > The packages are as follows: > > > > Fortress Core SDK > > > > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes > > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes > > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes > > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes > > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf > > > > > > Fortress Realm (Java EE Container plug-ins) > > > > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes > > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes > > > > > > Package 4 contains complete javadoc for the APIs. > > > > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the > > overall summary of the SDK. > > > > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package > > descriptions along with detailed documentation describing the contents of the > > SDK. > > > > What we are requesting from the OpenLDAP foundation: > > > > 1. Source code repository to host the SDK and Realm packages. > > 2. Bug tracking. > > 3. Developer and User forums. > > 4. Wiki (this is a nice to have) > > > > Our goal is to run the open source project with your organization and cultivate > > a healthy developer and user community. We have high hopes for this product > > (and OpenLDAP) and consider the 2 products together as an open source > > alternative for IAM products that will compete with the commercial vendor > > offerings. > > > > Once 1.0 is released, we will begin working on 2.0 which will include UI's to > > control Fortress and OpenLDAP along with a policy server to wrap the Fortress > > Java APIs with HTTP/REST Web APIs to make it available to all platforms. > > > > Thanks in advance for your consideration. > > > > Shawn McKinney > > JoshuaTree Software > > shawn.mckinney(a)jtstools.com > > >

1 0

ITS#7016
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

Fixed in master, please test. Now it should work correctly also in case the LDIF that is bootstrapped actually contains dn: olcDatabase=frontend,cn=config instead of dn: olcDatabase={-1}frontend,cn=config p.

1 0

RE: ITS#7020
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

> Could you help me to transfer this question to your openldap-technical > mailing list. All you need to do is: - subscribe to the list - post the message to the list's address Instructions here <http://www.openldap.org/lists/mm/listinfo/openldap-technical>. p.

1 0

(ITS#7022) Patch - Mozilla NSS - NSS_Init* functions are not thread safe
by rmeggins＠redhat.com 16 Aug '11

16 Aug '11

Full_Name: Rich Megginson Version: current tip of master branch OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-NSS_Init-functions-are-not-thread-safe… Submission from: (NULL) (76.26.104.137) The NSS_InitContext et. al, and their corresponding shutdown functions, are not thread safe. There can only be one thread at a time calling these functions. Protect the calls with a mutex. Create the mutex using a PR_CallOnce to ensure that the mutex is only created once and not used before created. Move the registration of the nss shutdown callback to also use a PR_CallOnce. Removed the call to SSL_ClearSessionCache() because it is always called at shutdown, and we must not call it more than once. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

hyc(a)symas.com wrote: > You seem to forget that nobody has any obligation to help you, at all. You're > imposing on the generosity of volunteers. And you seem to forget that my testing and filing ITS is also voluntary work. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > Howard Chu wrote: >> Of course, you've also been around the Project for pretty much its entire >> existence, and ought to know by now what information is needed in a useful bug >> report. > > I didn't expect having to provide a complete working setup for each small > issue. MMR setup with slapo-accesslog attached to each provider already says > it all. I also didn't expect to read non-sense about the accesslog DB itself > being replicated (see follow-up 1). > > Demanding more and more information for almost trivial things pretty much > reminds me of bad support for commercial products. You seem to forget that nobody has any obligation to help you, at all. You're imposing on the generosity of volunteers. If you're just going to complain about the response you get, as opposed to trying to help other people help you, then you should not be surprised if no help materializes. I even agree with you that follow-up #1 is nonsense. S#1t happens. Would you prefer that we moderate/censor all replies before they get posted? What exactly is it that you believe you're entitled to? > Now we'll see if this ITS will ever turn out something useful... With an attitude like that, why should anybody even take the time? > Ciao, Michael. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

Howard Chu wrote: > Of course, you've also been around the Project for pretty much its entire > existence, and ought to know by now what information is needed in a useful bug > report. I didn't expect having to provide a complete working setup for each small issue. MMR setup with slapo-accesslog attached to each provider already says it all. I also didn't expect to read non-sense about the accesslog DB itself being replicated (see follow-up 1). Demanding more and more information for almost trivial things pretty much reminds me of bad support for commercial products. Now we'll see if this ITS will ever turn out something useful... Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs >> on the provider side, when the Syncrepl control is present. Something else is >> going on here, but since you failed to provide any config info there's no way >> to tell where the problem is. > > Ah nice language, "you failed" boils down to "you suck". If you want to read that into it, that's your problem. Of course, you've also been around the Project for pretty much its entire existence, and ought to know by now what information is needed in a useful bug report. If, knowing what you know, you still choose not to file useful bug reports, that's also your problem. > Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz > > 0. Obviously you have to edit paths... > 1. Load schulung-initial-1.ldif to one of the providers. > 2. Modiy entry ou=schulung,dc=stroeder,dc=local. > > => > > dn: ou=schulung,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > [..] > > Tried this several times... > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 16 Aug '11

16 Aug '11

Full_Name: Version: 2.4.26 OS: URL: Submission from: (NULL) (84.128.254.201) slapo-ppolicy(5) says: pwdAllowUserChange This attribute specifies whether users are allowed to change their own passwords or not. If pwdAllowUserChange is set to "TRUE", or if the attribute is not present, users will be allowed to change their own passwords. If its value is "FALSE", users will not be allowed to change their own pass- words. Given this text I'd expect that admins can still set the userPassword attribute. Such a policy is often used for system/machine accounts where the machine entity itself does not have to change the password but an admin should be allowed to do so. Unfortunately if (pwdAllowUserChange=FALSE) no password change is allowed at all. slapd returns: "Insufficient access: User alteration of password is not allowed"

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

hyc(a)symas.com wrote: > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs > on the provider side, when the Syncrepl control is present. Something else is > going on here, but since you failed to provide any config info there's no way > to tell where the problem is. Ah nice language, "you failed" boils down to "you suck". Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz 0. Obviously you have to edit paths... 1. Load schulung-initial-1.ldif to one of the providers. 2. Modiy entry ou=schulung,dc=stroeder,dc=local. => dn: ou=schulung,dc=stroeder,dc=local auditContext: cn=accesslog,dc=stroeder,dc=local auditContext: cn=accesslog,dc=stroeder,dc=local [..] Tried this several times...

1 0

ITS#7016
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

Your analysis is correct. I think prefixing "frontend" with "{-1}" fixes the problem; however, back-config should recognize "frontent" as a special type of database that needs to go in place "{-1}" and can only be instantiated once, so the fix should probably be in back-config. p.

1 0

ITS#7020
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

The ITS is meant to discuss software bugs. Usage questions must be directed to the openldap-technical mailing list. This ITS will be closed. p.

1 0

(ITS#7020) How to design an architecture of OpenLDAP for satisfy our needs?
by hao.1.ma.ext＠nsn.com 16 Aug '11

16 Aug '11

Full_Name: ma hao Version: 2.3.43 OS: Linux(RH) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.161.106.50) Hi support, We got a problem about our authentication architecture. Here is our situation: We are using two parts for user authentication, which both are openldap service. One is password OpenLDAP service on remote server. One is groups information OpenLDAP service, which also is users permission info, on local server. In fact we could not get the user password in our local Openldap, pasword information stored in remote openldap which could not get our local group inforamtion. Do you have any idea to make our local OpenLDAP using remote OpenLDAP authorize the password and using local OpenLDAP supply groups information? Best Regards Ma Hao

1 0

RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 15 Aug '11

15 Aug '11

>Please submit a "statement of origin" in a follow-up to this ITS Let me try this again: The product named "Fortress Core" includes contributions that were created by JoshuaTree Software, LLC, who is the exclusive owner of the works. This contribution is made available as indicated by the copyright and license statements attached to the the work. Shawn McKinney JoshuaTree Software

1 0

RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 15 Aug '11

15 Aug '11

<html><body><span style=3D"font-family:Verdana; color:#000000; font-size:10= pt;"><div>Kurt, thanks for taking the time to look this over and allowing t= his to proceed.  We are looking forward to working with you and the ot= hers on this project in the near future.  This has been a long time co= ming for us and we appreciate this opportunity.</div><div><br></div><div>He= re's the statement of origin. <br></div><div><br></div><div>The product nam= ed "Fortress Core" includes contributions that were created by JoshuaTree S= oftware, LLC, who =0Ais the exclusive owner of the works.  This contri= bution is made =0Aavailable as indicated by the copyright and license state= ments attached to the the =0Awork.</div><div><br></div><div></div><div>Shaw= n McKinney</div><blockquote id=3D"replyBlockquote" webmail=3D"1" style=3D"b= order-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:= 10pt; color: black; font-family: verdana;">=0A<div id=3D"wmQuoteWrapper">= =0A-------- Original Message --------<br>=0ASubject: Re: (ITS#6995) Request= for Contribution of Identity Access<br>=0AManagement Software to OpenLDAP = Project<br>=0AFrom: Kurt Zeilenga <<a href=3D"mailto:Kurt@OpenLDAP.org">= Kurt(a)OpenLDAP.org</a>><br>=0ADate: Mon, August 15, 2011 2:35 pm<br>=0ATo= : <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.co= m</a><br>=0ACc: <a href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its@O= penLDAP.org</a><br>=0A<br>=0AShawn,<br>=0A<br>=0AI have reviewed the submit= ted materials.<br>=0A<br>=0AOther than a lack of a statement of origin, I f= ind no reason why these materials cannot be accepted. Please submit a "sta= tement of origin" in a follow-up to this ITS. This can simply be a stateme= nt to the effect that the all the submitted materials were authored by Josh= uaTree Software, JoshaaTree is the exclusive owner of the works, and that t= he contribution is made available as indicated by the copyright and license= statements in the work. If the work includes materials derived from works= to which others own or otherwise have rights to, please detail.<br>=0A<br>= =0AThe Foundation has no objection to the Project establishing a sub-projec= t of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub proje= cts, to develop works based upon your contribution. It is the Foundation u= nderstanding that Project is also willing to establish such a sub-project, = and extend commit privs to the key developers who produced the contributed = work.<br>=0A<br>=0AIt is noted that the OpenLDAP Foundation, if it accepts = the final contribution, would from time to time publish works derived (such= as the source repository itself, and possibly packaged source bundles) fro= m your contribution as well as possibly the contributions of others. The O= penLDAP Foundation will license its copyright right interests (initially li= kely quite limited) using the OpenLDAP Public License, and will encourage c= ommunity members to license their contributions in a manner consistent with= our general contribution guidelines. The OpenLDAP Public License is compa= tible with the 'New BSD open source license' and similar in its basic terms= .<br>=0A<br>=0AThe initial COPYRIGHT file (upon acceptance and initial publ= ication by the OpenLDAP Foundation) would be based on the COPYRIGHT file cu= rrently found in OpenLDAP Software distributions, excepting JoshuaTree Soft= ware would be named as the contributor of the materials for which the publi= shed work is derived from, and notice immediately following the Foundation'= s notice would be that provided by JoshauTree covering the work as contribu= tions.<br>=0A<br>=0AIt is noted that I recently attempted to re-download th= e materials and they were no longer available. That fine, we'd want you to= upload fresh zips to our servers once we all were ready to proceed.<br>=0A= <br>=0ARegards, Kurt<br>=0A<br>=0AOn Jul 14, 2011, at 6:51 PM, <a href=3D"h= ttp://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.com</a> wrote:<b= r>=0A<br>=0A> Full_Name: Shawn McKinney<br>=0A> Version: All<br>=0A&g= t; OS: All<br>=0A> URL: ftp://<a href=3D"http://ftp.openldap.org/incomin= g">ftp.openldap.org/incoming</a>/<br>=0A> Submission from: (NULL) (99.34= .198.251)<br>=0A> <br>=0A> <br>=0A> Hello,<br>=0A> <br>=0A> = We have created a new Identity and Access Management SDK, called Fortress, = that<br>=0A> uses Java and OpenLDAP to provide authentication, RBAC, ARB= AC, password<br>=0A> policies, auditing and more.<br>=0A> <br>=0A>= It has taken us 2.5 years of steady work to get it ready for this 1.0 rele= ase. <br>=0A> This SDK has approximately 50K lines of Java code of which= approximately 25K are<br>=0A> dedicated to testing using JUnit automate= d tests to ensure it works correctly. <br>=0A> There are in excess of 10= 0 public APIs available for use. There is also a Java<br>=0A> EE contai= ner plug-in that provides authentication and authorization services to<br>= =0A> Websphere, Tomcat and JBoss app servers in a declarative fashion. = <br>=0A> <br>=0A> This product has not been published and we would li= ke to release it as one of<br>=0A> the products under OpenLDAP family of= products. The product will be released<br>=0A> under New BSD open sour= ce license (license information is contained in the<br>=0A> source archi= ves on ftp server).<br>=0A> <br>=0A> I have uploaded seven packages t= o our FTP server that contain the source,<br>=0A> documentation and othe= r items for you to look at.<br>=0A> <br>=0A> host: <a href=3D"http://= jtstools.com">jtstools.com</a><br>=0A> user: jtsguest1<br>=0A> pw: Op= enLd@p1<br>=0A> <br>=0A> The packages are as follows:<br>=0A> <br>= =0A> Fortress Core SDK<br>=0A> <br>=0A> 1. source - fortressSrc-= 1.0.0-rc1.zip - 352K bytes<br>=0A> 2. source - fortressTestSrc-1.0.0-r= c1.zip - 159K bytes<br>=0A> 3. tutorial/doc - fortressSamples-1.0.0-rc= 1.zip - 766K bytes<br>=0A> 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.= 4M bytes<br>=0A> 5. ldap (folder) - Fortress schema and OpenLDAP slapd= .conf<br>=0A> <br>=0A> <br>=0A> Fortress Realm (Java EE Container = plug-ins)<br>=0A> <br>=0A> 6. source - fortressRealmSrc-1.0.0-rc1.z= ip - 45K bytes<br>=0A> 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 7= 6K bytes<br>=0A> <br>=0A> <br>=0A> Package 4 contains complete jav= adoc for the APIs. <br>=0A> <br>=0A> In package 4, this link, ./fortr= essDoc-1.0.0-rc1/index.html, contains the<br>=0A> overall summary of the= SDK.<br>=0A> <br>=0A> this link, ./oamCore/trunk/dist/docs/api/index= .html, contains package<br>=0A> descriptions along with detailed documen= tation describing the contents of the<br>=0A> SDK.<br>=0A> <br>=0A&gt= ; What we are requesting from the OpenLDAP foundation:<br>=0A> <br>=0A&g= t; 1. Source code repository to host the SDK and Realm packages.<br>=0A>= 2. Bug tracking.<br>=0A> 3. Developer and User forums.<br>=0A> 4. Wi= ki (this is a nice to have)<br>=0A> <br>=0A> Our goal is to run the o= pen source project with your organization and cultivate<br>=0A> a health= y developer and user community. We have high hopes for this product<br>=0A= > (and OpenLDAP) and consider the 2 products together as an open source<= br>=0A> alternative for IAM products that will compete with the commerci= al vendor<br>=0A> offerings. <br>=0A> <br>=0A> Once 1.0 is releas= ed, we will begin working on 2.0 which will include UI's to<br>=0A> cont= rol Fortress and OpenLDAP along with a policy server to wrap the Fortress<b= r>=0A> Java APIs with HTTP/REST Web APIs to make it available to all pla= tforms.<br>=0A> <br>=0A> Thanks in advance for your consideration.<br= >=0A> <br>=0A> Shawn McKinney<br>=0A> JoshuaTree Software<br>=0A&g= t; <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.c= om</a><br>=0A> <br>=0A<br>=0A=0A</div>=0A</blockquote></span></body></ht= ml>

1 0

Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠OpenLDAP.org 15 Aug '11

15 Aug '11

Shawn, I have reviewed the submitted materials. Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail. The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work. It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms. The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions. It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed. Regards, Kurt On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote: > Full_Name: Shawn McKinney > Version: All > OS: All > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.34.198.251) > > > Hello, > > We have created a new Identity and Access Management SDK, called Fortress, that > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password > policies, auditing and more. > > It has taken us 2.5 years of steady work to get it ready for this 1.0 release. > This SDK has approximately 50K lines of Java code of which approximately 25K are > dedicated to testing using JUnit automated tests to ensure it works correctly. > There are in excess of 100 public APIs available for use. There is also a Java > EE container plug-in that provides authentication and authorization services to > Websphere, Tomcat and JBoss app servers in a declarative fashion. > > This product has not been published and we would like to release it as one of > the products under OpenLDAP family of products. The product will be released > under New BSD open source license (license information is contained in the > source archives on ftp server). > > I have uploaded seven packages to our FTP server that contain the source, > documentation and other items for you to look at. > > host: jtstools.com > user: jtsguest1 > pw: OpenLd@p1 > > The packages are as follows: > > Fortress Core SDK > > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf > > > Fortress Realm (Java EE Container plug-ins) > > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes > > > Package 4 contains complete javadoc for the APIs. > > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the > overall summary of the SDK. > > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package > descriptions along with detailed documentation describing the contents of the > SDK. > > What we are requesting from the OpenLDAP foundation: > > 1. Source code repository to host the SDK and Realm packages. > 2. Bug tracking. > 3. Developer and User forums. > 4. Wiki (this is a nice to have) > > Our goal is to run the open source project with your organization and cultivate > a healthy developer and user community. We have high hopes for this product > (and OpenLDAP) and consider the 2 products together as an open source > alternative for IAM products that will compete with the commercial vendor > offerings. > > Once 1.0 is released, we will begin working on 2.0 which will include UI's to > control Fortress and OpenLDAP along with a policy server to wrap the Fortress > Java APIs with HTTP/REST Web APIs to make it available to all platforms. > > Thanks in advance for your consideration. > > Shawn McKinney > JoshuaTree Software > shawn.mckinney(a)jtstools.com >

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by masarati＠aero.polimi.it 15 Aug '11

15 Aug '11

> michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if >> there's an >> accesslog DB configured at the provider. IMO this does not make sense >> since the >> accesslog DB is not replicated and one might not want to load >> slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers >> the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be > filtering > out DSA-specific opattrs at the consumer side. Agree. User-wise, there could be a (set of) configuration option(s) that result in a safe default filtering, while allowing "expert" users (or for experimental reasons) to replicate things arbitrarily. Alternatives: 1) protect auditContext with ACLs at the producer's side 2) document the need to use filter="(!(objectClass=auditContext))" (or whatever is appropriate) when configuring the consumer. p.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if there's an >> accesslog DB configured at the provider. IMO this does not make sense since the >> accesslog DB is not replicated and one might not want to load slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be filtering > out DSA-specific opattrs at the consumer side. > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs on the provider side, when the Syncrepl control is present. Something else is going on here, but since you failed to provide any config info there's no way to tell where the problem is. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if there's an > accesslog DB configured at the provider. IMO this does not make sense since the > accesslog DB is not replicated and one might not want to load slapo-accesslog > module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers the > auditContext contains two values for auditContext and even the same one. Since a syncrepl operation is a regular LDAP search, the provider sends everything that matches the search request. Probably we should be filtering out DSA-specific opattrs at the consumer side. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 9:03 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> Delta-Syncrepl (normal and MMR modes) both use an accesslog database. >> So your contention that accesslog DBs are not replicated is somewhat >> incorrect. > > Up to now I thought that the accesslog DB itself is only accessible at the > provider and not replicated to the consumer. At least that's what's IMO > written in the OpenLDAP Admin Guide: I just wanted to be clear that accesslog can be used for replication. Thank you for providing such a nice test case example. ;) As for delta-syncrepl MMR, it exists, its in HEAD, and I have it working with RE24 just fine. It may well go into the next 2.4 release, so don't ignore it. ;) --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

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

quanah(a)zimbra.com wrote: > Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So > your contention that accesslog DBs are not replicated is somewhat incorrect. Up to now I thought that the accesslog DB itself is only accessible at the provider and not replicated to the consumer. At least that's what's IMO written in the OpenLDAP Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl "Delta-syncrepl works by maintaining a changelog of a selectable depth on the provider." Also in the Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl There's no accesslog database at the consumer (replica) configured. Delta-syncrepl in MMR mode is not finished yet, therefore I ignore this case for now. Because you are nitpicking in my case I set up a testbed. The accesslog DB itself is *not* replicated. Anyway the main issue here is that I regard replicating the attribute auditContext as not appropriate since you cannot access the referenced accesslog DB at the consumer. And it seems that with delta syncrepl the attribute is not replicated. But it seems to be replicated in a MMR setup with separate accesslog DBs configured at both providers. And this leads to this multiple but same(!) attribute values. We have four databases in our MMR test setup: cn=wsvdir-accesslog-de (for c=DE) cn=wsvdir-accesslog-system (for o=SYSTEM) o=SYSTEM (replicated in MMR setup) c=DE (replicated in MMR setup) In both providers I have dn: o=SYSTEM auditContext: cn=wsvdir-accesslog-system auditContext: cn=wsvdir-accesslog-system It does not happen in c=DE though. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 2:42 PM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if > there's an accesslog DB configured at the provider. IMO this does not > make sense since the accesslog DB is not replicated and one might not > want to load slapo-accesslog module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers > the auditContext contains two values for auditContext and even the same > one. Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So your contention that accesslog DBs are not replicated is somewhat incorrect. --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

1 0

(ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

Full_Name: Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.26.156) It seems that attribute auditContext is replicated to consumers if there's an accesslog DB configured at the provider. IMO this does not make sense since the accesslog DB is not replicated and one might not want to load slapo-accesslog module at all in the consumer's config. In a 2-way MMR setup with accesslog DB attached to both master providers the auditContext contains two values for auditContext and even the same one.

1 0

(ITS#7018) unique URI's host part must be empty
by masarati＠aero.polimi.it 13 Aug '11

13 Aug '11

Full_Name: Pierangelo Masarati Version: master,re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.144.24.27) Submitted by: ando If empty "host" part is checked, misconfigurations like in <http://www.openldap.org/lists/openldap-technical/201108/msg00116.html> would be easily detected. A fix is coming. p.

1 0

(ITS#7017) DDS overlay: TTL tolerance has inverse effect
by jvcelak＠redhat.com 11 Aug '11

11 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110811-dds-overlay-tolerance.patch Submission from: (NULL) (209.132.186.34) Hi! olcDDStolerance setting of DDS overlay has inverse effect and in fact it is shortening the real TTL of dynamic entries. I have uploaded the patch (against git master). Regards, Jan

1 0

(ITS#7016) slapd.ldif bootstrap fails on olcDatabase=frontend
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: ftp://ftp.openldap.org/incoming/ajf-20110811-slapd.ldif Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) Using a slapd.ldif (attached) closely based on the example from servers/slapd/slapd.ldif I find that the server will not bootstrap: $ slapadd -F ./config -n 0 -l slapd-try.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ slapadd -F ./config -l data.ldif -b dc=example,dc=org slapadd: bad configuration directory! The problem appears to be this entry in the LDIF: dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend olcAccess: to * by * read If 'frontend' is replaced with '{-1}frontend' in both places then the server works. At the least this needs changing in the example file slapd.ldif, in the manpage slapd-config(5), and in the admin guide. Some explanation as to why it is necessary would be welcome too! (I suspect it is because the cn=config DB has already been instantiated as DB zero, yet the frontend has to come ahead of all other DBs in some list). The error message is not very helpful, and winding up the debugging level just sent me up blind alleys so could the server please say a bit more about just what is bad about the config directory?

1 0

Re: (ITS#7015) slapd.ldif example file not installed
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Full_Name: Andrew Findlay > Version: 2.4.26 > OS: OpenSuSE 11.4 > URL: > Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) > > > slapdconf2.sdf says: > The distribution contains an example configuration file that will > be installed in the {{F: /usr/local/etc/openldap}} directory. > > There is an example file in the source: servers/slapd/slapd.ldif > but it is not installed anywhere. The corresponding slapd.conf example > does get installed, so this one should probably go alongside it. Fixed in master, please test. p.

1 0

(ITS#7015) slapd.ldif example file not installed
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) slapdconf2.sdf says: The distribution contains an example configuration file that will be installed in the {{F: /usr/local/etc/openldap}} directory. There is an example file in the source: servers/slapd/slapd.ldif but it is not installed anywhere. The corresponding slapd.conf example does get installed, so this one should probably go alongside it.

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Sounds like this may be related to ITS#6817. Please try adding a dummy > binddn > to your idassert-bind directive and re-test. First of all, I believe the real problem is that pr should not be used by the client in the first place. However, the cause of the issue might be something slightly different: back-ldap uses a pool of connections for special identities, including anonymous and rootdn; the latter is the case when identity assertion is used. So it seems plausible that although the client uses the same connection for repeated paged results requests, the proxy is using different ones. We already discussed the possibility to specially handle pr in proxies, in order to decouple its use by the client and the remote server. If slapd handles pr in the frontend, a proxy does not need to propagate pr requests to the remote server. Similarly, if a remote server *needs* pr, the client must not necessarily know about it. Something like this has already been implemented in back-meta(5), which can be instructed to silently continue unsolicited pr responses without informing the client about them (I should have ported this to back-ldap(5) as well). If this is the case (need to investigate in detail, yet), a quick fix could be to detect the presence of pr on a request, and bind the cookie to a specific connection until that cookie is gone. One thing that could be tried is to use slapo-sssvlv(5) on top of back-ldap and let it deal with the pr request. p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so > ldapsearch (and all tools) are fooled by not actually checking ld_errno > (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). Fixed in master. Also fixed timelimit (apparently, it was not honored). p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> Full_Name: Bjoern Jacke > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.159.216.39) > > > When TIMEOUT is set and happend to occur there is nothing that shows that > we > timed out. For example if you do a large/slow LDAP search using ldapsearch > and > then stop the conversation between slapd and ldapsearch by "killall -STOP > slapd" > then ldapsearch will terminate after TIMEOUT seconds and it will return > the > number of records that it got so far and exit with return code 0 and not > error > message. I'd expect that after TIMEOUT occuring that we get a warning and > a > return code != 0 libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so ldapsearch (and all tools) are fooled by not actually checking ld_errno (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). p.

1 0

Re: (ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 10 Aug '11

10 Aug '11

I'm sorry, in the meantime I found out that the binddn I used didn't have full access so the empty node couldn't get all attributes and then the broken directory got replicated back to the initial node. It was just a configuration problem on my part. Sorry again.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> I don't remember any particular reason why the argument count was omitted > here. Looking back over release 2.2 I don't see any special provision for > multiple arguments. I.e., it doesn't look like we need to accomodate > longer > argument lists here. And I don't see why we would want to NULL out any > existing settings. Sounds like we should just require argc == 2. Fixed in master, passes all tests for me. BTW, the original poster's address no longer exists, so I do not expect feedback. p.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by hyc＠symas.com 10 Aug '11

10 Aug '11

masarati(a)aero.polimi.it wrote: >> No, thanks. The problem is that these specific statements do not >> prescribe a fixed number of arguments. Moreover, the function that uses >> the value resets the field when passed a NULL argument. If this behavior >> needs to be preserved, I have the right fix handy. Otherwise it might >> need more work. > > To be more specific: slapd's TLS configuration is registered without > enforcing a specific number of arguments. This check is delegated to the > underlying calls to ldap_pvt_tls_set_option() performed by > config_tls_option(). This poses two problems: > > - since the argument of these parameters is ARG_STRING, if no arg is > passed then ch_strdup() fails > > - fixing this (by skipping ch_strdup() if argc == 1, for example) results > in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly > legitimate value (it means: clear any existing value), but it may not be > appropriate in this context. > > Please advise whether the right fix is skip ch_strdup(), or enforcing a > requirement for argc == 2 for TLS-related fields. I don't remember any particular reason why the argument count was omitted here. Looking back over release 2.2 I don't see any special provision for multiple arguments. I.e., it doesn't look like we need to accomodate longer argument lists here. And I don't see why we would want to NULL out any existing settings. Sounds like we should just require argc == 2. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> No, thanks. The problem is that these specific statements do not > prescribe a fixed number of arguments. Moreover, the function that uses > the value resets the field when passed a NULL argument. If this behavior > needs to be preserved, I have the right fix handy. Otherwise it might > need more work. To be more specific: slapd's TLS configuration is registered without enforcing a specific number of arguments. This check is delegated to the underlying calls to ldap_pvt_tls_set_option() performed by config_tls_option(). This poses two problems: - since the argument of these parameters is ARG_STRING, if no arg is passed then ch_strdup() fails - fixing this (by skipping ch_strdup() if argc == 1, for example) results in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly legitimate value (it means: clear any existing value), but it may not be appropriate in this context. Please advise whether the right fix is skip ch_strdup(), or enforcing a requirement for argc == 2 for TLS-related fields. p.

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 09 Aug '11

09 Aug '11

--00163683235cdfe3c004aa1933e0 Content-Type: text/plain; charset=ISO-8859-1 This seems to be a little old but I had attached the patch to close this issue and now I realize that I should provide it in a Uniform Resource Locator (URL) just as http://www.openldap.org/devel/contributing.html explains. So here it goes: http://xsun.eti.br/openldap/ldapsearch1_man_page.patch Sorry for this mistake. Thanks. Matheus Morais On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <matheus.morais(a)gmail.com>wrote: > Hi there, > > <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any > other program comes immediately to mind. </quote> > > Even sounds like an strange behave, as Quanah said, this information should > be included on ldapsearch man page IMHO. > > I believe that the following patch could close this BUG: > > --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 > 01:25:23.000000000 -0300 > +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 > -0300 > @@ -7,6 +7,8 @@ > .SH SYNOPSIS > .B ldapsearch > [\c > +.BR \-V [ V ]] > +[\c > .BR \-n ] > [\c > .BR \-c ] > @@ -107,6 +109,11 @@ > Option \fI\-L\fP controls the format of the output. > .SH OPTIONS > .TP > +.BR \-V [ V ] > +Prints the ldapsearch version and proceeds with the search. > +.B \-VV > +Prints the ldapsearch version and quit. > +.TP > .B \-n > Show what would be done, but don't actually perform the search. Useful > for > debugging in conjunction with \fB\-v\fP. > > Please review it. > > Thanks, > > Matheus Morais > --00163683235cdfe3c004aa1933e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems to be a little old but I had attached the patch to close this is= sue and now I realize that I should provide it in a Uniform Resource Locato= r (URL) just as=A0<meta http-equiv=3D"content-type" content=3D"text/html; c= harset=3Dutf-8"><a href=3D"http://www.openldap.org/devel/contributing.html"= >http://www.openldap.org/devel/contributing.html</a>=A0explains.<div> <br></div><div>So here it goes:</div><div><br></div><div><a href=3D"http://= xsun.eti.br/openldap/ldapsearch1_man_page.patch">http://xsun.eti.br/openlda= p/ldapsearch1_man_page.patch</a></div><div><br></div><div>Sorry for this mi= stake.</div> <div><br></div><div>Thanks.</div><div>Matheus Morais</div><div><br><div cla= ss=3D"gmail_quote">On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <span di= r=3D"ltr"><<a href=3D"mailto:matheus.morais@gmail.com">matheus.morais@gm= ail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hi there,<br><br><quote> That's..= . bizarre. Even slapd doesn't behave that way. Nor any other program = comes immediately to mind. </quote><br> <br>Even sounds like an strange behave, as Quanah said, this information sh= ould be included on ldapsearch man page IMHO.<br> <br>I believe that the following patch could close this BUG:<br><br>--- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300<br>+++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300<br> @@ -7,6 +7,8 @@<br>=A0.SH SYNOPSIS<br>=A0.B ldapsearch<br>=A0[\c<br>+.BR \-= V [ V ]]<br>+[\c<br>=A0.BR \-n ]<br>=A0[\c<br>=A0.BR \-c ]<br>@@ -107,6 +10= 9,11 @@<br>=A0Option \fI\-L\fP controls the format of the output.<br>=A0.SH= OPTIONS<br> =A0.TP<br>+.BR \-V [ V ]<br>+Prints the ldapsearch version and proceeds wit= h the search.<br>+.B \-VV<br>+Prints the ldapsearch version and quit.<br>+.= TP<br>=A0.B \-n<br>=A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for<br> =A0debugging in conjunction with \fB\-v\fP.<br><br>Please review it.<br><br= >Thanks,<br><font color=3D"#888888"><br>Matheus Morais<br> </font></blockquote></div><br></div> --00163683235cdfe3c004aa1933e0--

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 09 Aug '11

09 Aug '11

> Full_Name: Ashish Gawarikar > Version: 2.4.23 > OS: Redhat 5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.253.98.197) > > > In my slapd.conf file: > ... > TLSCertificateFile > TLSCertificateKeyFile > ... > > If I have the above, I get a core dump, with the error: > slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed. > > > Let me know if you need the core file. No, thanks. The problem is that these specific statements do not prescribe a fixed number of arguments. Moreover, the function that uses the value resets the field when passed a NULL argument. If this behavior needs to be preserved, I have the right fix handy. Otherwise it might need more work. p.

1 0

(ITS#7014) TLS: certificate hostnames are being checked when TLS_REQCERT is se to allow
by jvcelak＠redhat.com 09 Aug '11

09 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap/0001-TLS-do-not-check-hostname-whe… Submission from: (NULL) (209.132.186.34) Hello. If server certificate hostname does not match the server hostname, connection is closed even if client has set TLS_REQCERT to 'allow'. This is wrong - the documentation says, that bad certificates are being ignored when TLS_REQCERT is set to 'allow'. (Other certificate failures (like invalid CA) are handled as expected - at least with MozNSS.) I'm attaching patch, which fixes this behavior. The patch applies on master branch. (OpenLDAP FTP server for incoming patches reports 'No space left on device.', that's why I uploaded the patch to fedorapeople.org.) Regards, Jan

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 08 Aug '11

08 Aug '11

--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. And, at Quanah's prompting I tried it with an empty empty binddn and got similar results. Still a failure, sometimes after returning 1000 entries, sometimes after returning 2000 entries. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 08 Aug '11

08 Aug '11

--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> --On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: >> >>> --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: >>>>>> Your log shows that the subsequent search request initiates a new >>>>>> Bind to the remote server, which implies that it's not re-using the >>>>>> same connection as the first request. Since a paged results cookie >>>>>> is only valid within the context of a single connection, you get >>>>>> this error result. >>>>> >>>>> Not sure which log you are looking at. When I look at the log: >>>>> >>>>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>>>> lts.log.gz >>>>> >>>>> The only connection I see in the log is conn=1000 and it ends with: >>>>> >>>>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>>>> cookie is invalid ldap_read: want=8, got=7 >>>>> 0000: 30 05 02 01 07 42 00 0....B. >>>>> ldap_read: want=8, got=0 >>>>> >>>>> conn=1000 op=6 UNBIND >>>>> conn=1000 fd=11 closed >>>>> >>>>> These tests where made with a single ldapsearch request. The ldapsearch >>>>> tests fail when using the proxy and succeed when connecting directly to >>>>> the LDAP server with the database on it. >>>>> >>>>> A side node: the test case I submitted used ldapsearch, but the >>>>> problem was uncovered using a python application that is used for >>>>> syncing Gmail account data. >>>>> >>>>> Bill >>>> >>>> I have copied the backend server configuration to >>>> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >>>> copy of cn=config and there is a files based version the in ldap >>>> subdirectory as well. >>> >>> Where's the configuration for the slapd-ldap server? That's of the >>> most importance... >>> >>> --Quanah >> >> Of course, sorry about that. I have copied the files to the web site. > > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. I modified the configuration to include: idassert-bind bindmethod=SASL saslmech=GSSAPI mode=none binddn=cn=auth I am stilling getting the invalid-cookie error. % ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectclass=suPerson)(suVisibIdentity=world))" ou telephonenumber title ...lots of entries... # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MA0CAQAECGIdAAAAAAAA pagedresults: cookie=Yh0AAAAAAAA= # extended LDIF # # LDAPv3 # base <cn=people,dc=stanford,dc=edu> with scope subtree # filter: (&(objectclass=suPerson)(suVisibIdentity=world)) # requesting: ou telephonenumber title # with pagedResults control: size=1000 # # search result search: 3 result: 2 Protocol error text: paged results cookie is invalid # numResponses: 1002 # numEntries: 1000 Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#7013) OpenLDAP freezes and doesn't respond
by cgrosjean＠janua.fr 08 Aug '11

08 Aug '11

Full_Name: Cyril Grosjean Version: 2.4.26 OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.66.198.206) My OpenLDAP server freezes, after a few requests, and I can't understand why. I have a few LDAP clients (ldapsearch, a custom Java app. and ApacheDirectoryStudio), running from different systems, either locally on the OpenLDAP server, or on another OpenLDAP server, or on a remote workstation, and none manages to get an answer from OpenLDAP. The connection is established but each client gets stuck waiting for any result. We can reproduce the freeze, after a few requests coming from the custom Java application. The problem doesn't occur if we don't use that application. The last time, it occured only a few minutes after the OpenLDAP daemon was restarted, under very low load. I use OpenLDAP 2.4.26, over Red Hat Enterprise Linux Server release 5.4 (Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over VMWare. I also use BDB 4.8.30, and OpenLDAP's been compiled with the following options: ./configure --prefix=/opt/openldap-2.4.26 --enable-dynamic=yes --enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes --enable-accesslog=yes --enable-sssvlv=yes I noticed only 60 to 70 established connections on port 389 (according to netstat) when the freeze occurs. The OpenLDAP server is set in syncrepl mirror mode replication, and the other OpenLDAP server (only used as a hot stand-by) works fine (but doesn't receive any load). However, one can reproduce the problem with replication disabled. In the OpenLDAP accesslog, I usually see the client requests, but no lines for the responses. Also, I noticed sometimes the "deferring operation: binding" message : Jul 12 10:20:05 dev-ldap1 slapd[28525]: connection_input: conn=3377 deferring operation: binding Jul 12 10:20:07 dev-ldap1 slapd[28525]: conn=3378 fd=66 ACCEPT from IP=......:3823 (IP=0.0.0.0:389) I don't know if this message is linked or not to the main problem so I'd like to know if this message is harmless or not, and I mention it here just in case it could help. Below is a full backtrace of the slapd process when it freezes. We can reproduce the problem easily [root@rhvtq ldap-master1]# gdb GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". (gdb) bt full No stack. (gdb) attach 20884 Attaching to process 20884 Reading symbols from /opt/openldap-2.4.26/libexec/slapd...done. Reading symbols from /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2...done. Loaded symbols for /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2 Reading symbols from /opt/openldap-2.4.26/lib/liblber-2.4.so.2...done. Loaded symbols for /opt/openldap-2.4.26/lib/liblber-2.4.so.2 Reading symbols from /lib64/libuuid.so.1...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so Reading symbols from /lib64/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0x2b1c9a53dbd0 (LWP 20884)] [New Thread 0x48a36940 (LWP 21499)] [New Thread 0x40930940 (LWP 21498)] [New Thread 0x48235940 (LWP 21203)] [New Thread 0x47a34940 (LWP 21202)] [New Thread 0x47233940 (LWP 21201)] [New Thread 0x46a32940 (LWP 21200)] [New Thread 0x46231940 (LWP 21087)] [New Thread 0x45a30940 (LWP 21086)] [New Thread 0x4522f940 (LWP 21021)] [New Thread 0x44a2e940 (LWP 21020)] [New Thread 0x4422d940 (LWP 20891)] [New Thread 0x43a2c940 (LWP 20890)] [New Thread 0x4322b940 (LWP 20889)] [New Thread 0x42a2a940 (LWP 20888)] [New Thread 0x42229940 (LWP 20887)] [New Thread 0x41a28940 (LWP 20886)] [New Thread 0x41227940 (LWP 20885)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...done. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 (gdb) bt full #0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922 i = 0 rc = 0 listener_tid = (ldap_pvt_thread_t *) 0x1ef88c60 #2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983 i = 7 no_detach = 0 rc = -12 urls = 0x1ec6a460 "ldap://rhvtq:1389/" username = 0x1ec6a3b0 "" groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = (char **) 0x7ffff62c9618 configfile = 0x1ec6a4d0 "/opt/openldap/etc/openldap/slapd-master1.conf" configdir = 0x0 serverName = 0x7ffff62caa62 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x55db15 "" l = 4222019 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) thread apply all bt Thread 18 (Thread 0x41227940 (LWP 20885)): #0 0x00000031a7ad4018 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000429b23 in slapd_daemon_task (ptr=0x0) at daemon.c:2528 #2 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x41a28940 (LWP 20886)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1101171008) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x41a26fe0, rs=0x41a27150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x41a26fe0, rs=0x41a27150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x41a26fe0, rs=0x41a27150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x41a26fe0, rs=0x41a27150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4aef00, rs=0x41a27c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4aef00, rs=0x41a27c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4aef00, rs=0x41a27c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4aef00, rs=0x41a27c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x41a27d70, arg_v=0x1f4aef00) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x41a27d70, argv=0x69) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x42229940 (LWP 20887)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1109563712) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x42227fe0, rs=0x42228150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x42227fe0, rs=0x42228150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x42227fe0, rs=0x42228150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x42227fe0, rs=0x42228150) at backover.c:762 ---Type <return> to continue, or q <return> to quit--- #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4b2aa0, rs=0x42228c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4b2aa0, rs=0x42228c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4b2aa0, rs=0x42228c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4b2aa0, rs=0x42228c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x42228d70, arg_v=0x1f4b2aa0) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x42228d70, argv=0x61) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x42a2a940 (LWP 20888)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1f4ae470, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x428a8460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f4b09e0, tid=0x1f4ae470, id=1968, eip=0x428a8490, flag=0, lock=0x428a8460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x42a29d70, arg_v=0x1f4b09e0) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x42a29d70, argv=0x55) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x4322b940 (LWP 20889)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1126349120) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x43229fe0, rs=0x4322a150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x43229fe0, rs=0x4322a150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x43229fe0, rs=0x4322a150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x43229fe0, rs=0x4322a150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f1a3d80, rs=0x4322ac30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f1a3d80, rs=0x4322ac30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f1a3d80, rs=0x4322ac30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f1a3d80, rs=0x4322ac30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4322ad70, arg_v=0x1f1a3d80) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4322ad70, argv=0x31) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x43a2c940 (LWP 20890)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1f4b3740, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x438aa460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f2ac080, tid=0x1f4b3740, id=1968, eip=0x438aa490, flag=0, lock=0x438aa460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at backover.c:750 ---Type <return> to continue, or q <return> to quit--- #11 0x00000000004318b4 in fe_op_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x43a2bd70, arg_v=0x1f2ac080) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x43a2bd70, argv=0x57) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x4422d940 (LWP 20891)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1143134528) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x4422bfe0, rs=0x4422c150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x4422bfe0, rs=0x4422c150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x4422bfe0, rs=0x4422c150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x4422bfe0, rs=0x4422c150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f3ac600, rs=0x4422cc30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f3ac600, rs=0x4422cc30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f3ac600, rs=0x4422cc30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f3ac600, rs=0x4422cc30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4422cd70, arg_v=0x1f3ac600) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4422cd70, argv=0x62) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x44a2e940 (LWP 21020)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so ---Type <return> to continue, or q <return> to quit--- #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fc7ade0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x448ac460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f5bf860, tid=0x1fc7ade0, id=1968, eip=0x448ac490, flag=0, lock=0x448ac460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x44a2dd70, arg_v=0x1f5bf860) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x44a2dd70, argv=0x68) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x4522f940 (LWP 21021)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fcfb000, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x450ad460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x20012790, tid=0x1fcfb000, id=1968, eip=0x450ad490, flag=0, lock=0x450ad460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x20012790, rs=0x4522ec30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x20012790, rs=0x4522ec30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x20012790, rs=0x4522ec30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x4522ed70, arg_v=0x20012790) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x4522ed70, argv=0x5f) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 ---Type <return> to continue, or q <return> to quit--- #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x45a30940 (LWP 21086)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x2000f1d0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x458ae460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fed5290, tid=0x2000f1d0, id=1968, eip=0x458ae490, flag=0, lock=0x458ae460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x45a2fd70, arg_v=0x1fed5290) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x45a2fd70, argv=0x60) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x46231940 (LWP 21087)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2814ea in __lock_vec () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x00002b1c9a28212b in __lock_vec_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #6 0x000000000050f6fe in hdb_cache_entry_db_relock (bdb=0x1ed02f30, txn=0x207ff300, ei=0x1fe43b10, rw=1, tryOnly=0, lock=0x4622f180) at cache.c:198 #7 0x0000000000511817 in hdb_cache_modify (bdb=0x1ed02f30, e=0x1ee1ed68, newAttrs=0x201b6b30, txn=0x207ff300, lock=0x4622f180) at cache.c:1231 #8 0x00000000004da9ce in hdb_modify (op=0x20011d70, rs=0x46230c30) at modify.c:662 #9 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30, which=op_modify, oi=0x1ed31f10, on=0x0) at backover.c:671 #10 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30, which=op_modify) at backover.c:723 #11 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at backover.c:762 #12 0x000000000044dfd7 in fe_op_modify (op=0x20011d70, rs=0x46230c30) at modify.c:303 ---Type <return> to continue, or q <return> to quit--- #13 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30, which=op_modify, oi=0x1ed02760, on=0x0) at backover.c:671 #14 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30, which=op_modify) at backover.c:723 #15 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at backover.c:762 #16 0x000000000044d8e5 in do_modify (op=0x20011d70, rs=0x46230c30) at modify.c:177 #17 0x000000000042dbce in connection_operation (ctx=0x46230d70, arg_v=0x20011d70) at connection.c:1138 #18 0x000000000042e153 in connection_read_thread (ctx=0x46230d70, argv=0x66) at connection.c:1274 #19 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #20 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #21 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x46a32940 (LWP 21200)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1185098048) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x46a30fe0, rs=0x46a31150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x46a30fe0, rs=0x46a31150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x46a30fe0, rs=0x46a31150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x46a30fe0, rs=0x46a31150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4acf50, rs=0x46a31c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4acf50, rs=0x46a31c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4acf50, rs=0x46a31c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4acf50, rs=0x46a31c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x46a31d70, arg_v=0x1f4acf50) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x46a31d70, argv=0x63) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x47233940 (LWP 21201)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so ---Type <return> to continue, or q <return> to quit--- #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fbf4800, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x470b1460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fbf6de0, tid=0x1fbf4800, id=1968, eip=0x470b1490, flag=0, lock=0x470b1460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x47232d70, arg_v=0x1fbf6de0) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x47232d70, argv=0x67) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x47a34940 (LWP 21202)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1201883456) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x47a32fe0, rs=0x47a33150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x47a32fe0, rs=0x47a33150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x47a32fe0, rs=0x47a33150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x47a32fe0, rs=0x47a33150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe6e000, rs=0x47a33c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fe6e000, rs=0x47a33c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fe6e000, rs=0x47a33c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe6e000, rs=0x47a33c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x47a33d70, arg_v=0x1fe6e000) at connection.c:1138 ---Type <return> to continue, or q <return> to quit--- #20 0x000000000042e153 in connection_read_thread (ctx=0x47a33d70, argv=0x6a) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x48235940 (LWP 21203)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1210276160) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x48233fe0, rs=0x48234150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x48233fe0, rs=0x48234150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x48233fe0, rs=0x48234150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x48233fe0, rs=0x48234150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe91140, rs=0x48234c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fe91140, rs=0x48234c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fe91140, rs=0x48234c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe91140, rs=0x48234c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x48234d70, arg_v=0x1fe91140) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x48234d70, argv=0x64) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x40930940 (LWP 21498)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1083377984) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x4092efe0, rs=0x4092f150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x4092efe0, rs=0x4092f150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x4092efe0, rs=0x4092f150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x4092efe0, rs=0x4092f150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f5bf360, rs=0x4092fc30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f5bf360, rs=0x4092fc30) at result.c:505 ---Type <return> to continue, or q <return> to quit--- #8 0x0000000000443c2f in send_ldap_response (op=0x1f5bf360, rs=0x4092fc30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f5bf360, rs=0x4092fc30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4092fd70, arg_v=0x1f5bf360) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4092fd70, argv=0x25) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x48a36940 (LWP 21499)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1218668864) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x48a34fe0, rs=0x48a35150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x48a34fe0, rs=0x48a35150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x48a34fe0, rs=0x48a35150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x48a34fe0, rs=0x48a35150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fbf8d90, rs=0x48a35c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fbf8d90, rs=0x48a35c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fbf8d90, rs=0x48a35c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fbf8d90, rs=0x48a35c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x48a35d70, arg_v=0x1fbf8d90) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x48a35d70, argv=0x30) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 ---Type <return> to continue, or q <return> to quit--- #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2b1c9a53dbd0 (LWP 20884)): #0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922 #2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983 I've tried to upload bulky materials to the incoming directory of ftp.openldap.org but there was no space left to upload. My upload required 5950450 bytes only. So, I'm waiting for free disk space on the FTP server. BTW, here's the slapd.conf file : ########################################################################### # Section globale: les directives definies dans cette section s'appliquent # a tous les suffixes definis. # Cette section se termine juste avant la premiere directive "database" ########################################################################### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/vetoquinol.schema # Inclusion du fichier definissant les droits d'acces globaux # (cad s'appliquant a tous les suffixes (donnees, schema, cn=config, cn=monitor, etc ...)) include /etc/openldap/vtq-global-access.conf # Delai en secondes au bout duquel les connections inactives sont fermees par le serveur #idletimeout 600 # Allow LDAPv2 client connections. This is NOT the default. #allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd-master1.pid argsfile /var/run/openldap/slapd-master1.args logfile /var/log/openldap-master1-debug.log loglevel 256 #loglevel 8193 # Option utilisee en mode multi-maitre seulement # La valeur doit etre differente pour chaque instance d'annuaire serverID 1 # Load dynamic backend modules: # modulepath /usr/lib64/openldap # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. #TLSCACertificateFile /etc/openldap/OpenSSL_ca.crt #TLSCertificateFile /etc/openldap/OpenSSL_server.crt #TLSCertificateKeyFile /etc/openldap/OpenSSL_server.key #TLSCipherSuite TLSv1:SSLv3 # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # Inclusion du fichier definissant les droits d'acces pour dc=vetoquinol authz-policy to include /etc/openldap/vtq-access.conf include /etc/openldap/deleted-access.conf # Nombre maximum par defaut d'entrees renvoyees lors d'une recherche sizelimit 2000 # Module necessaire pour pouvoir demander a OpenLDAP # de trier les entrees renvoyees overlay sssvlv ####################################################################### # ldbm and/or bdb database definitions ####################################################################### ####################################################################### # Monitoring BDB database definition # ####################################################################### # Base (optionnelle) utilisee pour la supervision et l'obtention de statistiques # sur l'activite de l'annuaire database monitor rootdn cn=monitoring,cn=Monitor rootpw {SSHA}pdXDKQIKBa/oYZgDeNyum8VvJ8D0yTaZ #rootpw monitoring database hdb suffix "dc=vetoquinol" rootdn "cn=Manager,dc=vetoquinol" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw ********* # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. # Emplacement de la base pour le suffixe dc=vetoquinol directory /var/lib/ldap-master1/vtq # Indices to maintain for this database # Index generaux index objectclass,entryCSN,entryUUID,creatorsname,modifiersname eq index pwdaccountlockedtime,pwdfailuretime,pwdgraceusetime,uid,uniquemember pres index businessCategory,employeeType eq,pres index c,cn,employeeNumber,givenName,mail,sn,telephonenumber,l,departmentnumber eq,pres,sub # Index specifiques VTQ index vtq-langues,vtq-section,vtq-date-entree,vtq-date-sortie,vtq-date-mutation eq index vtq-activite eq,pres index vtq-ref-fonction eq,pres,sub # Extension pour pouvoir gerer des groupes dynamiques # Dans l'exemple ci-dessous: # - un groupe dynamique doit avoir la classe d'objet groupOfURLs # - l'attribut (du groupe dynamique) memberURL doit contenir une URL LDAP, # par exemple ldap://hostname:port/ou=people??one?(&(objectclass=vtq-personne)(c=FR)) # - l'attribut multi-valué (du groupe dynamique) uniqueMember est alors généré dynamiquement # et contient la liste des membres du groupe (donc une liste de DN) # overlay dynlist #dynlist-attrset groupOfURLs memberURL uniqueMember # Extension pour obtenir a partir d'un utilisateur # la liste des groupes auxquels il appartient #memberof-memberof-ad isMemberOf overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniqueMember memberof-refint TRUE # Definition des parametres de replication pour un annuaire maitre # L'appel au module syncprov est necessaire pour indiquer que l'annuaire est maitre # Le parametrage ci-dessous indique que la derniere ecriture sur la base est consignee # sur disque soit tous les 100 changements, soit au bout de 2 minutes overlay syncprov syncprov-checkpoint 100 2 # Definition des liens de replication # Le numero de rid doit etre different pour chaque suffixe replique # d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un meme suffixe # (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou esclave) # L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes # L'authentification aupres du maitre peut prendre jusqu'a 10 secondes # Tous les attributs et toutes les entrees sont repliques syncrepl rid=001 provider=ldap://rhvtq:2389 bindmethod=simple binddn="cn=replication user,ou=special users,dc=vetoquinol" credentials=********* searchbase="dc=vetoquinol" type=refreshAndPersist logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" retry="60 +" network-timeout=5 timeout=10 schemachecking=on attrs="*,+" filter="(objectclass=*)" # Activation du mode multi-maitre mirrormode on overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+02:00 # Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe dc=vetoquinol limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Recherche en nombre et en temps illimitee pour le compte de synchronisation vers AD sur le suffixe dc=vetoquinol limits dn.exact="cn=lsc user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le suffixe "dc=vetoquinol" # Lors de requetes ou cn=yellow pages se fait passer pour un autre utilisateur, # ce sont les limites de cet utilisateur qui s'appliquent limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # Emplacement de la strategie par defaut de gestion des mots de passe overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=vetoquinol" # L'option ci-dessous permet de renvoyer un code d'erreur explicite en cas de compte verrouille # Ne pas activer cette option donne moins d'informations en cas d'attaque #ppolicy_use_lockout # Hachage automatique des mots de passe entres en clair ppolicy_hash_cleartext # tuning base du suffixe dc=vetoquinol # Taille du cache des entrees cachesize 2000 # Taille du cache pour les recherches les plus demandees idlcachesize 6000 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb (3883008 octets au 5/07/2011) + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/vtq # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 ####################################################################### # Deleted Entries database definition # ####################################################################### database hdb suffix "o=deleted entries" rootdn "cn=Manager,o=deleted entries" rootpw ********* # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. # Emplacement de la base pour le suffixe o=deleted directory /var/lib/ldap-master1/deleted # Module necessaire pour pouvoir demander a OpenLDAP # de trier les entrees renvoyees overlay sssvlv # Index generaux index entryCSN,entryUUID,objectclass eq index employeeType eq,pres index cn,sn,employeeNumber eq,pres,sub # Definition des parametres de replication pour un annuaire maitre # L'appel au module syncprov est necessaire pour indiquer que l'annuaire est maitre # Le parametrage ci-dessous indique que la derniere ecriture sur la base est consignee # sur disque soit tous les 100 changements, soit au bout de 2 minutes overlay syncprov syncprov-checkpoint 100 2 # Definition des liens de replication # Le numero de rid doit etre different pour chaque suffixe replique # d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un meme suffixe # (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou esclave) # L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes # L'authentification aupres du maitre peut prendre jusqu'a 10 secondes # Tous les attributs et toutes les entrees sont repliques syncrepl rid=002 provider=ldap://rhvtq:2389 bindmethod=simple binddn="cn=replication user,ou=special users,dc=vetoquinol" credentials=********* searchbase="o=deleted entries" type=refreshAndPersist logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" retry="60 +" network-timeout=5 timeout=10 schemachecking=on attrs="*,+" filter="(objectclass=*)" # Activation du mode multi-maitre mirrormode on overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+02:00 # Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe o=deleted entries limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le suffixe "o=deleted entries" limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited # tuning base du suffixe o=deleted entries # Taille du cache des entrees # Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe principal (dc=vetoquinol) cachesize 200 # Taille du cache pour les recherches les plus demandees idlcachesize 600 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/deleted # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 ####################################################################### # Accesslog HDB database definition # ####################################################################### # Definition de la base (optionnelle) accesslog # Cette base permet d'optimiser la replication en ne repliquant # que la partie d'une entree qui est modifiee plutot que l'entree en entier database hdb suffix cn=accesslog directory /var/lib/ldap-master1/accesslog rootdn cn=accesslog # Definition des index pour optimiser l'acces au suffixe cn=accesslog # Seul un annuaire esclave accede a ce suffixe en principe pour savoir ce qui # a ete modifie depuis la session de replication precedente index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart #Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe cn=accesslog limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # tuning base du suffixe cn=accesslog # Taille du cache des entrees # Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe principal (dc=vetoquinol) cachesize 200 # Taille du cache pour les recherches les plus demandees idlcachesize 600 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/accesslog # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 The slapd.conf file is as follows

1 0

(ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by ashish＠sendmail.com 03 Aug '11

03 Aug '11

Full_Name: Ashish Gawarikar Version: 2.4.23 OS: Redhat 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.253.98.197) In my slapd.conf file: ... TLSCertificateFile TLSCertificateKeyFile ... If I have the above, I get a core dump, with the error: slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed. Let me know if you need the core file.

1 0

(ITS#7011) signal 6 got in ldap_abandon
by ogermain＠tibco.com 03 Aug '11

03 Aug '11

Full_Name: Olivier GERMAIN Version: 2.4.24 OS: Solaris 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.157.248.2) Dear All, One of our customer got a signal 6 during the execution of the ldap_abandon. This signal occurred whereas some maintenance was doing on a firewall which is not located on the same network. It seems that the ldap_abandon thrown this assert because it was a situation like a can't happen. I don't have much information on the action performed on the firewall which led to this sigabort. Please find the logs I have : 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:<static-func>+0x5b0 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:<static-func>+0x628 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ] 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:abort+0xd0 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:_assert+0x74 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac I am in the process of a reproduction of this signal 6 but I would like to share the following idea. Do you think there is a possibility to enhance the openldap library to avoid this assert? Is it possible that instead of having an assert, we have a exception or a status code which tell us something went wrong of obviously that we can handle in our source code. My best regards Olivier GERMAIN TIBCO Support team

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 02 Aug '11

02 Aug '11

whm(a)stanford.edu wrote: > --On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: > >> --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: >>>>> Your log shows that the subsequent search request initiates a new >>>>> Bind to the remote server, which implies that it's not re-using the >>>>> same connection as the first request. Since a paged results cookie >>>>> is only valid within the context of a single connection, you get >>>>> this error result. >>>> >>>> Not sure which log you are looking at. When I look at the log: >>>> >>>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>>> lts.log.gz >>>> >>>> The only connection I see in the log is conn=1000 and it ends with: >>>> >>>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>>> cookie is invalid ldap_read: want=8, got=7 >>>> 0000: 30 05 02 01 07 42 00 0....B. >>>> ldap_read: want=8, got=0 >>>> >>>> conn=1000 op=6 UNBIND >>>> conn=1000 fd=11 closed >>>> >>>> These tests where made with a single ldapsearch request. The ldapsearch >>>> tests fail when using the proxy and succeed when connecting directly to >>>> the LDAP server with the database on it. >>>> >>>> A side node: the test case I submitted used ldapsearch, but the >>>> problem was uncovered using a python application that is used for >>>> syncing Gmail account data. >>>> >>>> Bill >>> >>> I have copied the backend server configuration to >>> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >>> copy of cn=config and there is a files based version the in ldap >>> subdirectory as well. >> >> Where's the configuration for the slapd-ldap server? That's of the >> most importance... >> >> --Quanah > > Of course, sorry about that. I have copied the files to the web site. Sounds like this may be related to ITS#6817. Please try adding a dummy binddn to your idassert-bind directive and re-test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7010) Deadlock in Producer/Consumer Nodes
by ghola＠rebelbase.com 02 Aug '11

02 Aug '11

Full_Name: Duncan Idaho Version: 2.4.25 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.148.0.72) We are running a cluster of "synchronization hosts" that act as Producers for a large number of Consumers and additionally Consume from a single global read/write master. After several weeks of stable operation synchronization came to a halt on both nodes in the Producer/Consumer cluster simultaneously. Stack-trace: Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 ...back 1 page Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 [root@su1-admin-syncrepl01 ldap]# cat gdb.txt Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x459a6d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x459a6d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 9 (Thread 14872): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab89e58c0, rs=0x451a5c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab89e58c0, rs=0x451a5c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab89e58c0, rs=0x451a5c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab89e58c0, rs=0x451a5c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab89e58c0, rs=0x451a5c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x451a5d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x451a5d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 8 (Thread 16034): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000042db1c in send_ldap_ber (op=<value optimized out>, ber=0x449a43f0) at result.c:372 #2 0x00000000004308d8 in slap_send_search_entry (op=0x449a45a0, rs=0x449a4af0) at result.c:1410 #3 0x00000000004da80d in syncprov_qplay (ctx=<value optimized out>, arg=<value optimized out>) at syncprov.c:884 #4 syncprov_qtask (ctx=<value optimized out>, arg=<value optimized out>) at syncprov.c:1006 #5 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #6 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #7 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Thread 7 (Thread 16033): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2d554b70, rs=0x441a3c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2d554b70, rs=0x441a3c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2d554b70, rs=0x441a3c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2d554b70, rs=0x441a3c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2d554b70, rs=0x441a3c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x441a3d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x441a3d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 6 (Thread 11937): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0x2aaab802af20, rs=0x418f7c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0x2aaab802af20, rs=0x418f7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0x2aaab802af20, rs=0x418f7c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0x2aaab802af20, rs=0x418f7c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0x2aaab802af20, rs=0x418f7c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x418f7d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x418f7d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 5 (Thread 10755): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1d8ae85bd1 in __db_pthread_mutex_lock () from /usr/local/openldap/lib/libdb-5.1.so #2 0x00002b1d8ae8528a in __db_tas_mutex_lock () from /usr/local/openldap/lib/libdb-5.1.so #3 0x00002b1d8af1804c in __lock_get_internal () from /usr/local/openldap/lib/libdb-5.1.so #4 0x00002b1d8af189ea in __lock_vec () from /usr/local/openldap/lib/libdb-5.1.so #5 0x00002b1d8af1969b in __lock_vec_pp () from /usr/local/openldap/lib/libdb-5.1.so #6 0x00000000004bc6c1 in hdb_cache_entry_db_relock (bdb=0xe2bc780, txn=<value optimized out>, ei=0x2aaadaefc6a0, rw=1, tryOnly=<value optimized out>, lock=0x439a1640) at cache.c:198 #7 0x00000000004bcb70 in hdb_cache_modify (bdb=0x2b1d8f0fa00c, e=0x2b1df490e138, newAttrs=0x2b1e071d6918, txn=0x0, lock=0x0) at cache.c:1231 #8 0x0000000000495d13 in hdb_modify (op=0x439a2120, rs=0x439a1cb0) at modify.c:662 #9 0x000000000047e6c2 in overlay_op_walk (op=0x439a2120, rs=0x439a1cb0, which=op_modify, oi=0xe2be010, on=0x0) at backover.c:669 #10 0x000000000047ec27 in over_op_func (op=0x439a2120, rs=0x439a1cb0, which=op_modify) at backover.c:721 #11 0x000000000047240f in syncrepl_entry (si=0xe2c2800, op=0x439a2120, entry=0x2b1df490e408, modlist=0x439a2c68, syncstate=2, syncUUID=<value optimized out>, syncCSN=0x2aaade6b6ab0) at syncrepl.c:2694 #12 0x0000000000479cf7 in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:955 #13 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #14 0x000000000041f7ca in connection_read_thread (ctx=0x439a2d60, argv=<value optimized out>) at connection.c:1251 #15 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #16 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #17 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #18 0x0000000000000000 in ?? () Thread 4 (Thread 10752): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe6f0990, rs=0x410f6c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe6f0990, rs=0x410f6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe6f0990, rs=0x410f6c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe6f0990, rs=0x410f6c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe6f0990, rs=0x410f6c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x410f6d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x410f6d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (Thread 10749): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe5eefa0, rs=0x431a1c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe5eefa0, rs=0x431a1c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe5eefa0, rs=0x431a1c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe5eefa0, rs=0x431a1c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe5eefa0, rs=0x431a1c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x431a1d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x431a1d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 10748): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe5ebbf0, rs=0x429a0c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe5ebbf0, rs=0x429a0c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe5ebbf0, rs=0x429a0c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe5ebbf0, rs=0x429a0c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe5ebbf0, rs=0x429a0c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x429a0d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x429a0d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (Thread 10747): #0 0x000000322e2d4108 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041bc8b in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2528 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Logs at the time of the lock-up: Producer: Jul 28 22:27:08 admin02 slapd[5178]: conn=422733 op=92 MOD dn="thing=thing1,ou=things,dc=example,dc=net" Jul 28 22:27:08 admin02 slapd[5178]: conn=422733 op=92 MOD attr=stuff Jul 28 22:27:08 admin02 slapd[5178]: slap_queue_csn: queing 0x4b0883f0 20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 admin02 slapd[5178]: syncprov_sendresp: cookie=rid=001 ,csn=20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 admin02 slapd[5178]: syncprov_sendresp: cookie=rid=001 Producer later: Jul 29 07:04:55 admin02 slapd[5178]: Entry thing=thing1,ou=things,dc=example,dc=net CSN 20110728222708.058275Z#000000#000#000000 older or equal to ctx 20110728222708.058275Z#000000#000#000000 Producer/Consumer: Jul 28 22:27:08 su1-admin-syncrepl01 slapd[10745]: do_syncrep2: rid=001 cookie=rid=001,csn=20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 su1-admin-syncrepl01 slapd[10745]: slap_queue_csn: queing 0x2aaadecf4b00 20110728222708.058275Z#000000#000#000000 ^^ No more syncrepl logs after this Help!

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: > >> >> >> --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister >> <whm(a)stanford.edu> wrote: >> >>> >>> >>> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >>> <hyc(a)symas.com> wrote: >>> >>>> whm(a)stanford.edu wrote: >>>>> Full_Name: Bill MacAllister >>>>> Version: 2.4.26 >>>>> OS: Debian 6 >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (171.64.19.165) >>>>> >>>>> >>>>> We typically setup local proxy servers to support applications that >>>>> cannot support a GSSAPI bind to the directory server. The proxy >>>>> server allows anonymous access to the directory for connections from >>>>> the localhost and connects to the master using GSSAPI. We are >>>>> experiencing a failures when we attempt to use the paged results >>>>> control on the proxy. For example: >>>>> >>>>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >>>>> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >>>>> telephonenumber title >>>>> >>>>> ends with the error: >>>>> >>>>> # search result >>>>> search: 5 >>>>> result: 0 Success >>>>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>>>> pagedresults: cookie=KIMAAAAAAAA= >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>>>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>>>> # requesting: ou telephonenumber title >>>>> # with pagedResults control: size=1000 >>>>> # >>>>> >>>>> # search result >>>>> search: 6 >>>>> result: 2 Protocol error >>>>> text: paged results cookie is invalid >>>>> >>>>> # numResponses: 4005 >>>>> # numEntries: 4000 >>>>> >>>>> This result is not consistent. We have seen examples where 2000 and >>>>> 3000 entries being returned and then the error. Another test that we >>>>> performed with a slightly more complex filter, i.e. >>>>> >>>>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity= >>>>> world)))" >>>>> >>>>> returned usually returned 1000 entries before erroring. >>>>> >>>>> Issuing a similar search directly against the backend ldap server >>>>> completes without >>>>> error. >>>>> >>>>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>>>> >>>>> Logs generated running slapd standalone with '-d stats,packets' are >>>>> available at http://www.stanford.edu/~whm/files/ldap-debugging/. >>>> >>>> Your log shows that the subsequent search request initiates a new >>>> Bind to the remote server, which implies that it's not re-using the >>>> same connection as the first request. Since a paged results cookie >>>> is only valid within the context of a single connection, you get >>>> this error result. >>> >>> Not sure which log you are looking at. When I look at the log: >>> >>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>> lts.log.gz >>> >>> The only connection I see in the log is conn=1000 and it ends with: >>> >>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>> cookie is invalid ldap_read: want=8, got=7 >>> 0000: 30 05 02 01 07 42 00 0....B. >>> ldap_read: want=8, got=0 >>> >>> conn=1000 op=6 UNBIND >>> conn=1000 fd=11 closed >>> >>> These tests where made with a single ldapsearch request. The ldapsearch >>> tests fail when using the proxy and succeed when connecting directly to >>> the LDAP server with the database on it. >>> >>> A side node: the test case I submitted used ldapsearch, but the >>> problem was uncovered using a python application that is used for >>> syncing Gmail account data. >>> >>> Bill >> >> I have copied the backend server configuration to >> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >> copy of cn=config and there is a files based version the in ldap >> subdirectory as well. > > Where's the configuration for the slapd-ldap server? That's of the > most importance... > > --Quanah Of course, sorry about that. I have copied the files to the web site. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by quanah＠zimbra.com 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: > > > --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister > <whm(a)stanford.edu> wrote: > >> >> >> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >> <hyc(a)symas.com> wrote: >> >>> whm(a)stanford.edu wrote: >>>> Full_Name: Bill MacAllister >>>> Version: 2.4.26 >>>> OS: Debian 6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> We typically setup local proxy servers to support applications that >>>> cannot support a GSSAPI bind to the directory server. The proxy >>>> server allows anonymous access to the directory for connections from >>>> the localhost and connects to the master using GSSAPI. We are >>>> experiencing a failures when we attempt to use the paged results >>>> control on the proxy. For example: >>>> >>>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >>>> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >>>> telephonenumber title >>>> >>>> ends with the error: >>>> >>>> # search result >>>> search: 5 >>>> result: 0 Success >>>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>>> pagedresults: cookie=KIMAAAAAAAA= >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>>> # requesting: ou telephonenumber title >>>> # with pagedResults control: size=1000 >>>> # >>>> >>>> # search result >>>> search: 6 >>>> result: 2 Protocol error >>>> text: paged results cookie is invalid >>>> >>>> # numResponses: 4005 >>>> # numEntries: 4000 >>>> >>>> This result is not consistent. We have seen examples where 2000 and >>>> 3000 entries being returned and then the error. Another test that we >>>> performed with a slightly more complex filter, i.e. >>>> >>>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity= >>>> world)))" >>>> >>>> returned usually returned 1000 entries before erroring. >>>> >>>> Issuing a similar search directly against the backend ldap server >>>> completes without >>>> error. >>>> >>>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>>> >>>> Logs generated running slapd standalone with '-d stats,packets' are >>>> available at http://www.stanford.edu/~whm/files/ldap-debugging/. >>> >>> Your log shows that the subsequent search request initiates a new >>> Bind to the remote server, which implies that it's not re-using the >>> same connection as the first request. Since a paged results cookie >>> is only valid within the context of a single connection, you get >>> this error result. >> >> Not sure which log you are looking at. When I look at the log: >> >> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >> lts.log.gz >> >> The only connection I see in the log is conn=1000 and it ends with: >> >> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >> cookie is invalid ldap_read: want=8, got=7 >> 0000: 30 05 02 01 07 42 00 0....B. >> ldap_read: want=8, got=0 >> >> conn=1000 op=6 UNBIND >> conn=1000 fd=11 closed >> >> These tests where made with a single ldapsearch request. The ldapsearch >> tests fail when using the proxy and succeed when connecting directly to >> the LDAP server with the database on it. >> >> A side node: the test case I submitted used ldapsearch, but the >> problem was uncovered using a python application that is used for >> syncing Gmail account data. >> >> Bill > > I have copied the backend server configuration to > http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an > copy of cn=config and there is a files based version the in ldap > subdirectory as well. Where's the configuration for the slapd-ldap server? That's of the most importance... --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

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > >> whm(a)stanford.edu wrote: >>> Full_Name: Bill MacAllister >>> Version: 2.4.26 >>> OS: Debian 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> We typically setup local proxy servers to support applications that cannot >>> support a GSSAPI bind to the directory server. The proxy server allows >>> anonymous access to the directory for connections from the localhost and >>> connects to the master using GSSAPI. We are experiencing a failures when >>> we attempt to use the paged results control on the proxy. For example: >>> >>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost >>> "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title >>> >>> ends with the error: >>> >>> # search result >>> search: 5 >>> result: 0 Success >>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>> pagedresults: cookie=KIMAAAAAAAA= >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>> # requesting: ou telephonenumber title >>> # with pagedResults control: size=1000 >>> # >>> >>> # search result >>> search: 6 >>> result: 2 Protocol error >>> text: paged results cookie is invalid >>> >>> # numResponses: 4005 >>> # numEntries: 4000 >>> >>> This result is not consistent. We have seen examples where 2000 and 3000 >>> entries being returned and then the error. Another test that we performed with >>> a slightly more complex filter, i.e. >>> >>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" >>> >>> returned usually returned 1000 entries before erroring. >>> >>> Issuing a similar search directly against the backend ldap server completes >>> without >>> error. >>> >>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>> >>> Logs generated running slapd standalone with '-d stats,packets' are available at >>> http://www.stanford.edu/~whm/files/ldap-debugging/. >> >> Your log shows that the subsequent search request initiates a new >> Bind to the remote server, which implies that it's not re-using the >> same connection as the first request. Since a paged results cookie >> is only valid within the context of a single connection, you get >> this error result. > > Not sure which log you are looking at. When I look at the log: > > http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-results… > > The only connection I see in the log is conn=1000 and it ends with: > > conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results cookie is invalid > ldap_read: want=8, got=7 > 0000: 30 05 02 01 07 42 00 0....B. > ldap_read: want=8, got=0 > > conn=1000 op=6 UNBIND > conn=1000 fd=11 closed > > These tests where made with a single ldapsearch request. The ldapsearch > tests fail when using the proxy and succeed when connecting directly to > the LDAP server with the database on it. > > A side node: the test case I submitted used ldapsearch, but the > problem was uncovered using a python application that is used for > syncing Gmail account data. > > Bill I have copied the backend server configuration to http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an copy of cn=config and there is a files based version the in ldap subdirectory as well. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.4.26 >> OS: Debian 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> We typically setup local proxy servers to support applications that cannot >> support a GSSAPI bind to the directory server. The proxy server allows >> anonymous access to the directory for connections from the localhost and >> connects to the master using GSSAPI. We are experiencing a failures when >> we attempt to use the paged results control on the proxy. For example: >> >> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost >> "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title >> >> ends with the error: >> >> # search result >> search: 5 >> result: 0 Success >> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >> pagedresults: cookie=KIMAAAAAAAA= >> # extended LDIF >> # >> # LDAPv3 >> # base<cn=people,dc=stanford,dc=edu> with scope subtree >> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >> # requesting: ou telephonenumber title >> # with pagedResults control: size=1000 >> # >> >> # search result >> search: 6 >> result: 2 Protocol error >> text: paged results cookie is invalid >> >> # numResponses: 4005 >> # numEntries: 4000 >> >> This result is not consistent. We have seen examples where 2000 and 3000 >> entries being returned and then the error. Another test that we performed with >> a slightly more complex filter, i.e. >> >> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" >> >> returned usually returned 1000 entries before erroring. >> >> Issuing a similar search directly against the backend ldap server completes >> without >> error. >> >> We have seen the same behavior on OpenLDAP 2.4.23 as well. >> >> Logs generated running slapd standalone with '-d stats,packets' are available at >> http://www.stanford.edu/~whm/files/ldap-debugging/. > > Your log shows that the subsequent search request initiates a new > Bind to the remote server, which implies that it's not re-using the > same connection as the first request. Since a paged results cookie > is only valid within the context of a single connection, you get > this error result. Not sure which log you are looking at. When I look at the log: http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-results… The only connection I see in the log is conn=1000 and it ends with: conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results cookie is invalid ldap_read: want=8, got=7 0000: 30 05 02 01 07 42 00 0....B. ldap_read: want=8, got=0 conn=1000 op=6 UNBIND conn=1000 fd=11 closed These tests where made with a single ldapsearch request. The ldapsearch tests fail when using the proxy and succeed when connecting directly to the LDAP server with the database on it. A side node: the test case I submitted used ldapsearch, but the problem was uncovered using a python application that is used for syncing Gmail account data. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#7009) TIMEOUT with unexpected results
by bj＠sernet.de 02 Aug '11

02 Aug '11

Full_Name: Bjoern Jacke Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.159.216.39) When TIMEOUT is set and happend to occur there is nothing that shows that we timed out. For example if you do a large/slow LDAP search using ldapsearch and then stop the conversation between slapd and ldapsearch by "killall -STOP slapd" then ldapsearch will terminate after TIMEOUT seconds and it will return the number of records that it got so far and exit with return code 0 and not error message. I'd expect that after TIMEOUT occuring that we get a warning and a return code != 0

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 02 Aug '11

02 Aug '11

Quanah Gibson-Mount wrote: > --On Monday, August 01, 2011 9:47 PM +0000 hyc(a)symas.com wrote: >> Your log shows that the subsequent search request initiates a new Bind to >> the remote server, which implies that it's not re-using the same >> connection as the first request. Since a paged results cookie is only >> valid within the context of a single connection, you get this error >> result. > > Given that the client making the request is ldapsearch, which is not going > to rebind mid search, and you can see it is done with noprompt, so there's > no human interaction here, it seems like back-ldap is buggy here. Why is > *back-ldap* closing its connection to the upstream server and initiating a > new bind? You haven't provided any slapd configuration info. Without seeing that it's way premature to claim there's any bug here. Look at the log yourself. back-ldap *doesn't* close the connection. Don't spew garbage about what it does when it didn't actually do such a thing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by quanah＠zimbra.com 01 Aug '11

01 Aug '11

--On Monday, August 01, 2011 9:47 PM +0000 hyc(a)symas.com wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.4.26 >> OS: Debian 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> We typically setup local proxy servers to support applications that >> cannot support a GSSAPI bind to the directory server. The proxy server >> allows anonymous access to the directory for connections from the >> localhost and connects to the master using GSSAPI. We are experiencing >> a failures when we attempt to use the paged results control on the >> proxy. For example: >> >> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >> telephonenumber title >> >> ends with the error: >> >> # search result >> search: 5 >> result: 0 Success >> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >> pagedresults: cookie=KIMAAAAAAAA= >> # extended LDIF >> # >> # LDAPv3 >> # base<cn=people,dc=stanford,dc=edu> with scope subtree >> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >> # requesting: ou telephonenumber title >> # with pagedResults control: size=1000 >> # >> >> # search result >> search: 6 >> result: 2 Protocol error >> text: paged results cookie is invalid >> >> # numResponses: 4005 >> # numEntries: 4000 >> >> This result is not consistent. We have seen examples where 2000 and 3000 >> entries being returned and then the error. Another test that we >> performed with a slightly more complex filter, i.e. >> >> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=wo >> rld)))" >> >> returned usually returned 1000 entries before erroring. >> >> Issuing a similar search directly against the backend ldap server >> completes without >> error. >> >> We have seen the same behavior on OpenLDAP 2.4.23 as well. >> >> Logs generated running slapd standalone with '-d stats,packets' are >> available at http://www.stanford.edu/~whm/files/ldap-debugging/. > > Your log shows that the subsequent search request initiates a new Bind to > the remote server, which implies that it's not re-using the same > connection as the first request. Since a paged results cookie is only > valid within the context of a single connection, you get this error > result. Given that the client making the request is ldapsearch, which is not going to rebind mid search, and you can see it is done with noprompt, so there's no human interaction here, it seems like back-ldap is buggy here. Why is *back-ldap* closing its connection to the upstream server and initiating a new bind? --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

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 01 Aug '11

01 Aug '11

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.26 > OS: Debian 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > We typically setup local proxy servers to support applications that cannot > support a GSSAPI bind to the directory server. The proxy server allows > anonymous access to the directory for connections from the localhost and > connects to the master using GSSAPI. We are experiencing a failures when > we attempt to use the paged results control on the proxy. For example: > > ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost > "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title > > ends with the error: > > # search result > search: 5 > result: 0 Success > control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA > pagedresults: cookie=KIMAAAAAAAA= > # extended LDIF > # > # LDAPv3 > # base<cn=people,dc=stanford,dc=edu> with scope subtree > # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) > # requesting: ou telephonenumber title > # with pagedResults control: size=1000 > # > > # search result > search: 6 > result: 2 Protocol error > text: paged results cookie is invalid > > # numResponses: 4005 > # numEntries: 4000 > > This result is not consistent. We have seen examples where 2000 and 3000 > entries being returned and then the error. Another test that we performed with > a slightly more complex filter, i.e. > > "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" > > returned usually returned 1000 entries before erroring. > > Issuing a similar search directly against the backend ldap server completes > without > error. > > We have seen the same behavior on OpenLDAP 2.4.23 as well. > > Logs generated running slapd standalone with '-d stats,packets' are available at > http://www.stanford.edu/~whm/files/ldap-debugging/. Your log shows that the subsequent search request initiates a new Bind to the remote server, which implies that it's not re-using the same connection as the first request. Since a paged results cookie is only valid within the context of a single connection, you get this error result. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 01 Aug '11

01 Aug '11

Full_Name: Bill MacAllister Version: 2.4.26 OS: Debian 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) We typically setup local proxy servers to support applications that cannot support a GSSAPI bind to the directory server. The proxy server allows anonymous access to the directory for connections from the localhost and connects to the master using GSSAPI. We are experiencing a failures when we attempt to use the paged results control on the proxy. For example: ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title ends with the error: # search result search: 5 result: 0 Success control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA pagedresults: cookie=KIMAAAAAAAA= # extended LDIF # # LDAPv3 # base <cn=people,dc=stanford,dc=edu> with scope subtree # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) # requesting: ou telephonenumber title # with pagedResults control: size=1000 # # search result search: 6 result: 2 Protocol error text: paged results cookie is invalid # numResponses: 4005 # numEntries: 4000 This result is not consistent. We have seen examples where 2000 and 3000 entries being returned and then the error. Another test that we performed with a slightly more complex filter, i.e. "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" returned usually returned 1000 entries before erroring. Issuing a similar search directly against the backend ldap server completes without error. We have seen the same behavior on OpenLDAP 2.4.23 as well. Logs generated running slapd standalone with '-d stats,packets' are available at http://www.stanford.edu/~whm/files/ldap-debugging/. Bill

1 0

(ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 01 Aug '11

01 Aug '11

Full_Name: Stephan Version: 2.4.26 OS: Debian 5.0.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.100.101.1) Hi everybody, I have an odd problem with synchronisation. I have 5 nodes running multi master synchronisation. I recently updated one of them to 2.4.26 (they were all running 2.4.23 before) and started it with an empty database (the database directory contained nothing more than the DB_CONFIG file). Afterwards I noted that some attributes were missing, especially in the root of the directory tree, which looks like this: dn: o=test objectClass: organization o: test After the sync was complete, I could search for the o=test entry but couldn't see it: ldapsearch -H "ldaps://filled.test.xyz" -D cn=superman,o=test -W -x -b o=test o=test # extended LDIF # # LDAPv3 # base <o=test> with scope subtree # filter: o=test # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I played around a bit and am able to reproduce the problem. I tried combinations of 2.4.23 and 2.4.26, bdb and hdb backends, bdb versions 4.5.20-13 and 4.6.21 but the problem persists. If I take the output of slapcat on one of the nodes and feed it to the empty node before its startup everything seems to be ok. I increased the loglevel and can see the following (rid 1 being the node with the filled database and rid 2 the one with the empty database): On the empty node (rid2) I get lots of 'syncrepl_entry: rid=001 inserted UUID xxx' 'syncprov_matchops: skipping original sid 001' and 'syncrepl_entry: rid=001 be_add' Once the sync is complete the log on the formerly empty node says: Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110310162449.396663Z#000000#000#000000;20110801135804.526931Z#000000#001#000000;20110614092017.772141Z#000000#003#000000;20110722131433.793594Z#000000#004#000000;20110225131904.168266Z#000000#005#000000 Aug 1 17:24:55 empty slapd[7796]: slap_queue_csn: queing 0x9f901da8 20110801135804.526931Z#000000#001#000000 Aug 1 17:24:55 empty slapd[7796]: syncprov_matchops: skipping original sid 001 Aug 1 17:24:55 empty slapd[7796]: slap_graduate_commit_csn: removing 0x9f91f5f8 20110801135804.526931Z#000000#001#000000 Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 cookie= Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 be_search (0) Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 o=test Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 entry unchanged, ignored (o=test) Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 NEW_COOKIE: rid=001,sid=001,csn=20110801152321.168164Z#000000#000#000000;20110801135804.526931Z#000000#001#000000;20110614092017.772141Z#000000#003#000000;20110722131433.793594Z#000000#004#000000;20110225131904.168266Z#000000#005#000000 On the node from which it took the database (rid 1): Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Aug 1 17:24:54 filled last message repeated 7 times Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_search (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 o=test Aug 1 17:24:54 filled slapd[17862]: syncprov_sendresp: cookie= Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_modify o=test (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Aug 1 17:24:54 filled slapd[17862]: dn_callback : entries have identical CSN sambaDomainName=XYZ,ou=abc,o=test 20110722131010.624524Z#000000#004#000000 Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_search (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 sambaDomainName=XYZ,ou=abc,o=test Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 entry unchanged, ignored (sambaDomainName=XYZ,ou=abc,o=test) Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 cookie=rid=002,csn=20110801152321.168164Z#000000#000#000000 Aug 1 17:24:54 filled slapd[17862]: slap_queue_csn: queing 0x7eff600022c0 20110801152321.168164Z#000000#000#000000 Aug 1 17:24:54 filled slapd[17862]: slap_graduate_commit_csn: removing 0x7eff60007040 20110801152321.168164Z#000000#000#000000 It seems to me that the formerly empty node overwrites the entry on the node from which it took all the entries. This is what my config looks like: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE serverID 1 "ldaps://filled.test.xyz" serverID 2 "ldaps://empty.test.xyz" #filled syncrepl rid=2 provider=ldaps://filled.test.xyz:636 type=refreshAndPersist searchbase="o=test" retry="120 20 300 5 1800 5 3600 +" scope=sub bindmethod=simple binddn="cn=superman,o=test" credentials="hello" tls_reqcert=never mirrormode on And the other node: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE serverID 1 "ldaps://filled.test.xyz" serverID 2 "ldaps://empty.test.xyz" #filled syncrepl rid=2 provider=ldaps://empty.test.xyz:636 type=refreshAndPersist searchbase="o=test" retry="120 20 300 5 1800 5 3600 +" scope=sub bindmethod=simple binddn="cn=superman,o=test" credentials="hello" tls_reqcert=never mirrormode on It seems to me that the formerly empty node overwrites the other one after the sync. In some cases the entries don't go missing on the source node, they just don't get replicated to the formerly emtpy node. Unless I made some terrible mistake in the config this is seems to be a bug since in the administrator's guide http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%2… it says: "Syncrepl is self-synchronizing; you can start with a consumer database in any state from totally empty to fully synced and it will automatically do the right thing to achieve and maintain synchronization" All nodes are configured to use the same ntp source.

1 0

(ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hash_oldap＠cycdolphin.net 01 Aug '11

01 Aug '11

Full_Name: Philippe Kueck Version: 2.4.23 / 2.4.26 OS: RHEL 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.98.65.86) When compiled against Mozilla/NSS OpenLDAP does not accept wildcard certificates. This is probably because in tls_m.c the certificate CN (*.domain.example) is matched against the hostname (foo.domain.example), not against the domain (.domain.example). I suggest the following patch: --%snip%-- diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c openldap-2.4.26/libraries/libldap/tls_m.c --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000 +0200 +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000 +0200 @@ -2590,7 +2590,7 @@ if ( av->len == nlen && !strncasecmp( name, (char *)av->data, nlen )) { ret = LDAP_SUCCESS; } else if ( av->data[0] == '*' && av->data[1] == '.' && - domain && dlen == av->len - 1 && !strncasecmp( name, + domain && dlen == av->len - 1 && !strncasecmp( domain, (char *)(av->data+1), dlen )) { ret = LDAP_SUCCESS; } else { --%snip%-- Kind regards, Philippe Kueck

1 0

(ITS#7005) Collision of LDAP calls between Oracle, Curl and OpenLDAP libraries
by mahesh.babu.pothuri＠convergys.com 01 Aug '11

01 Aug '11

Full_Name: Mahesh P Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.126.170.20) Hi, We have one application which will use the Oracle DB, OpenLDAP and Curl libraries. We have started the LDAP server. And we want to perform search/add/update operations using LDAP calls ldap_search_ext_s(), ldap_add_ext_s() and ldap_modify_ext_s(). While performing the search Operation, getting the "Bad Search Filter" error. In the application code we have used the ldap_initialize() for getting the LDAP handle.I am thinking this problem is result of the collision of LDAP calls between Oracle Library and OpenLDAP,Curl libraries. When we did nm on libclntsh.so.11.1, got the references for 0000000001055732 T ldap_search_ext 0000000001055594 T ldap_search_ext_s 0000000001051714 T ora_ldap_search_ext 000000000105145a T ora_ldap_search_ext_s If we try to have a standalone program without any database connectivity same LDAP code is working fine for the search/add/modify operations. Kindly please advise how we can avoid the problem if we use Oracle DB, OpenLDAP and CURL functionality in out application code. Thanks Mahesh

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

hyc(a)symas.com wrote: > I guess we > need to keep using the NULL timeout while the connection is actually in its > Refresh phase, before it enters its Persist phase. Fixed now in master, please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > On Fri, Jul 29, 2011, Howard Chu wrote: > >> The ITS mailer only supports plaintext, no attachments. > > Sorry about that. Here's the log inline (5 attempts by syncrepl): I was able to reproduce this behavior. The culprit is the ldap_result() call in do_syncrep2() returning 0 due to a timeout. The actual sequence of events is that do_syncrep1() successfully binds to the master and sends a syncsearch request, then do_syncrep2() reads the search response. The first message is a Present UUID list which it parses successfully. It then loops back to look for the next message from the provider, but due to whatever timing vagaries, that message is not available yet. But anyway, do_syncrep2() returns with rc=0 and this resets the retry counter, as I said before. At the moment I don't have any good ideas how this could be fixed in the code. Timeouts of this sort are normal behavior for refreshAndPersist. I guess we need to keep using the NULL timeout while the connection is actually in its Refresh phase, before it enters its Persist phase. I think you could workaround it by using delta-syncrepl, which doesn't use a Present UUID list. This will require some more thought. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

On Fri, Jul 29, 2011, Howard Chu wrote: > The ITS mailer only supports plaintext, no attachments. Sorry about that. Here's the log inline (5 attempts by syncrepl): Jul 22 13:12:25 vmca02 slapd[23778]: slapd starting Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 fd=16 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH attr=* + Jul 22 13:12:26 vmca02 slapd[23778]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 ADD dn="uid=user68,ou=People,dc=example,dc=com" Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x43403110 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=2 UNBIND Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (0) Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user68,ou=People,dc=example,dc=com Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2c49060 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 closed Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user68,ou=People,dc=example,dc=com (0) Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 ADD dn="uid=user69,ou=People,dc=example,dc=com" Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x44405110 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2b40df0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 closed Jul 22 13:12:52 vmca02 slapd[23778]: conn=-1 op=0 ldap_back_retry: retrying URI="ldap://vmca01" DN="cn=monitor" Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c518d0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 fd=16 closed Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH attr=* + Jul 22 13:12:57 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:57 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=2 UNBIND Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 closed Jul 22 13:12:57 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH attr=* + Jul 22 13:13:02 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:02 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:02 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=2 UNBIND Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 closed Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH attr=* + Jul 22 13:13:07 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:07 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=2 UNBIND Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 closed Jul 22 13:13:07 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH attr=* + Jul 22 13:13:12 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:12 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:12 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=2 UNBIND Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 closed Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection!

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > --UugvWAfsgieZRqgk > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Jul 28, 2011, Howard Chu wrote: > >> I think we need to see more of the log than this. The only reason >> for your observed behavior to occur is that somewhere along the >> line, a step in the replication actually returned LDAP_SUCCESS, >> which resets the retry counter. So we need to see the complete log >> for at least one full cycle of "(4 retries left)", "(3 retries >> left)", "(4 retries left)". > > I've attached the full log of the test (from start to stop); it's > rather small in .gz format. I hope that will go through, otherwise > I can extract the requested full cycle and send that inline. The ITS mailer only supports plaintext, no attachments. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 28, 2011, Howard Chu wrote: > I think we need to see more of the log than this. The only reason > for your observed behavior to occur is that somewhere along the > line, a step in the replication actually returned LDAP_SUCCESS, > which resets the retry counter. So we need to see the complete log > for at least one full cycle of "(4 retries left)", "(3 retries > left)", "(4 retries left)". I've attached the full log of the test (from start to stop); it's rather small in .gz format. I hope that will go through, otherwise I can extract the requested full cycle and send that inline. --UugvWAfsgieZRqgk Content-Type: text/plain; charset=unknown-8bit Content-Disposition: attachment; filename="ldap.2.gz" Content-Transfer-Encoding: quoted-printable =1F=8B=08=08=D2=D72N=02=03ldap.2=00=D5=9DOs=1C=C7=91=C5=EF=FB)=C6=DC=0B=E9= =15=C1=AE?=3D=DD=8D=08=1C=B8$=1C=A2Cb(H=EA=E0=DD=D8@=0Cf=86=12V =86=1A=80= =B2=FC=ED=DDC=D22ATU=BF=AC=CAW=1D=F0=C1$aO=E6+LU=E5=FBe=02=D3=7F=FDp=B9=B0v= a=DC=B1=B1=C7=B6]=FC=F6n=BDj=EC=E2=FAr=F5~=F3=BF=D6u]=FF=7F=C7=9F=FE=B5=B8= =BEY=EDo.=AE~=FA=8F=BF=DEz=CD2=FC=9A=F5=EE=EA=EA=C44M=B3x=BB91=CB=C5=D3g=CF= N=7Fx=B3x=BB=DF=BD[=FC=F0=F4=CD=B7'O~[=ED=9F=EC?\=3D=B9=DC=AC=DE_,=1E=06=BE= =F8H=9Aj=F7=FE=A4Y=FC=F7=8B=97=CF=17=9B=AB=93=07=EB=AB=93w=AB=AB=D5O=DB=FD= =83=C5=BB=ED=CD=CF=BBQ=88=ED5c=AE=7F>y=FD=E2=FB=1F=BE;]\_=BF=3Di=B2B=BF:}= =FD=E3wo=167=AB=9FN=86n=B1=DD=EF=C7=AF=DDl=7F=BF9=C9=88f=16=AF_=3D=FBvq=BE= =BA=DE=9E<x=B0=B8^=EF=DEoO=ECb=B3=DDoGy=8B=B7=17=977=DB=FD=C9=83=87=BB=F3= =FF=DF=AEo=9E]=AE=AE=AFO=FE=FC=E8A~=A6=D5=CD=CD=FE=E4=CF=8B=FF=C2"lvg=D7=FF= =B8Z=EF=B7=EF=ED=F1b=7F=B19i=1A=B3=F8=EE=F9=D3=1F=CE=C6o=C2=D9=8B=97oN_}=7F= =FA=FC=C5=D37=A7=8B=C7=E3=F7=E5/=E3W=BF=3D{~=FA=DD=E9=9B=D3=DB =9CKK4=1F7]= =A7=B1=E9=A6S=DD=D9 =DFOm=BA=B2=98=C9M=07=86=067=1D=14=CD,=9E>=FF=A4=F3=C3= =F8=96~=B8=DE=EE=97=FD7=BB=0F'?lw=EF/=B7=DFl=D6'=DB=DFW=EF>=FFu=BD{=F7=00= =CBq=F8=D7=D9=AF=1F=B6=1F=B6g=EB=EB=AB=E3=C5=F8=D7=F1=F2Y4=BF{=E7=1BgL=B3= =B0=CD=F8=DF=9D=B5=E3=9F=D6=B9#=DF=99f9=FC=CF=7F6=1F=FF3=FEa>=FF=15=CC7=EE= =CC=F7=FB=DDog=D7=DB=AB=CD~{=FD=FE=B0=CC=DD/=17=DB=93=CF;=F5=9B=EB=CF=7F=8E= rNts=07=0FF=B5=EC=9FS_=9Em=AFn=F6=FF=08=9C=CC=D7=A7O=C7=C3~v=FA=F2=CD=AB=BF= =3D=FC=F8=D5=D7=7F{=F9=ECl|=DBs=0E=8B]=FC=F8=F2=B0=B5=B3=B6=DA=17=1B=D74=AD= |=E7=C6=D6z=BE=1D=DF=F7=D5~=FD=F3=E2a=F3=A8,=14v =0F=81]=B7=E6=DC=AA=9F=81C=BA=9F=F6=AB=CD=87=D5=CD=98q=F7=EE=DD=C5=CD=A7=C4= =FB=ED=BB=DDo=FFJ=ED=87f=A9=9D=FA=EB=AB{}=B9=BB=DEn=8A=DF=D4=D5f=03=BE!=827= =9E=F3=A6=B46=FD=9D=B1zEm:=95=BC=A8=95=C5L=16504X=D4=A0h=81=A26=08=8AZ,G=BC= =A8y=DF=B4_=17=B5=D6=1E=F5=B6=19:=93=BDw=B0=03}=EE=9B=CD[=ED=D4_};=D1=8B;= =BA=92=EC=F2\=BE=94=92=F2=AC=F0=1E=AA=95g=E8=AD =97g=F4r ]=DB=C9=D7>=FE=ECH=0F=D7=D4=D9=F9j=FD=CB=D9~=FBi=99=87?=0E=1B=F4=C7W/N=1E= =1C=FE=E7=E3'O>=C61=0F=16=CF_~B=B1=DD=D5=C5=CDn=FF=A0=EC=1B=F9E=EDo=ED=A3= =B2X=D8mQxY=1C=EAL=BF=D1>=B0W=1F./=CF=D6=AB=CB=CB=C3=BB=B08>=1C=D1=DD~|=936= =DB1=A5=F3=C5=DF=E3[=A5xH=97=E2=E2=F7A=96=EF=ED=EA=E2r=BB=11=A4=BD=C5=C2y'= =E6_=8D=11=C9=89=F9=F7Et=F9=EF=A5=EE=D7=8B=F1=FF=FF=C7qy=E8?=FE=FDb{=BD=B8= =DC=BE=BD=F9zA]Z=95=CB=E8=A1=94=C5LW~,4Z=F9'=A3=1D=DE=92V=C5a!=C2U=DA5=92L= =E1vM,=C2=F5=FEz1^<=B9v6=12=F5r=F7=13!=EA=FA=DD=FBE=F3=CD=E2f=B7[=EC.7=F9J= =04=D7h$=EA=E9=E1"B=99=E3=D9=EB=97=F07=E2=B0=B0=ED~1=DE=C9=DB_?=AC.=C7=B5.= =D67=BF+=7F=1F=BF=B0Y=87=8AxvpZ=BB=AB=EB-=C3mut=BF#=CCp1.t=7F3=16=82=1F=7F|= =F1|1=B4=E7=BD=EBW=F6=B1?o=DB=F1=BF=D6=EB=C7=FDy=D3<>=DF:;=9C=1B=D7o=CE=0BW= =944=1E]=05=E3=D1i8=81=AE=B2=13=E8=E6q=02=C85=1Bq=02`=D9 :=81=AE=C0 =B8=B8= =13p=C7=CD=84?=F1b'P=1A3=E1=04=E0=D0=90=13=00=A3)=94gY=A6Py=8EG()=CF=F1=A8%= =E59=B1=DAhy=96)A=ABK<=EA}(=CF=89=F7=BCVyNK=D0(=CF=F2=0Ce=E5=199=8AJ=F6_=BE= =B4=B8=13=90=C7=92;=81x=0E=81=13=C8Zt=81=13`=E7=8B8=81x=DAR8=07kE=C8c=E0{= =FB=AE=C7H=BFv,l=17=BB=AB=F1=9EYm=1E=9A=F6=D1=B8#v_|=FDO=AC@=13=8E=A9U<=A9= =93=A92lPQ=CC=B4=0D=C2B=A36=08=89=A6c=83=04=99"6=A8=A3=D8=A0=8Eb=83=BA=0C= =1B=D4QlPw=AFmP7=BF=0D=EA=E86=A8=ABl=83:Eo=D2U=F0&=9D=867=E9*{=93n=1Eo=82\= =B3=11=07=01=D6=DC=A0=83=A0u)=CC=84=AFY=EA9=81=E9Tr'P=163=E9=04=C0=D0=A0=13= =80=A2=A98=01I=A6=B0=130=94=86=88=A14DLFC=C4P=1A"=E6^7D=CC=FC=0D=11Co=88=98= =CA=0D=11=A3=D8=A50=15=BA=14F=A3Ka*w)=CC<] C=EBR@=17x=D8c=A0=D5<=E41=8CVsA/=D0=84c=EA=14=BD=C9d=AA=0CoR=143=EDM=B0=D0= =A87A=A2=E9x=13A=A6=887=A1t)=0C=A5Ka2=BA=14=86=D2=A50=F7=BAKa=E6=EFR=18z=97= =C2T=EER=18=C5.=85=A9=D0=A50=1A] S=B9Ka=E6=E9R=98=8E=E6M=90=0B<=E2M=C0j=1E=F4&]=05K! d'=9CV=AF=E7M=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6=E2M$=99=C2=DE=C4R=FA&= =96=D27=B1=19}=13K=E9=9B=D8{=DD7=B1=F3=F7M,=BDob+=F7M=ACb=DF=C4V=E8=9BX=8D= =BE=89=AD=DC7=B1=F3=F4M,=ADo=02]=E0ao=82V=F3=907=B1=B6=82=A5=90=05=EA=D3=AB= =19=14=BD=C9d=AA=0CoR=143=EDM=B0=D0=A87A=A2=E9x=13A=A6=887=E9)=DE=A4=A7x=93= >=C3=9B=F4=14o=D2=DFko=D2=CF=EFMz=BA7=E9+{=93^=D1=9B=F4=15=BCI=AF=E1M=FA=CA= =DE=A4=9F=C7=9B=F44o=82\=E0=11o=02V=F3=A07=E9+X Q=A0=89=8F'1=8D=9E7=99N%=F7&e1=93=DE=04=0C=0Dz=13(=9A=8A7=91d {=93=E8=E7=C0=14y=93X=D42o=12]m=C2=9BH=94=E0=A55=16=F5~x=13=E0S=C2=D8=DE=84= =FDq]=F2=0C=A5=DE=A4=E0C=B9=EE=D4=C2=ECO=E5=12x=93X=0E=917)=FD=D0*=A97=E1= =E6=8Bz=13=E8=9A=0D;=08=B4=E6=86=1C=C4=F4'=EA=E5Z"=97=F65=C6(:=81=C9T=19N= =A0(f=DA `=A1Q'=80D=D3q=02=82L=11'@=E9R8J=97=C2et)=1C=A5K=E1=EEu=97=C2=CD= =DF=A5p=F4.=85=AB=DC=A5p=8A] W=A1K=E14=BA=14=AEr=97=C2=CD=D3=A5=80=AE=D9=88=13=00kn=D0 =D0=9A#~=C2=9FX= =3D'0=9DJ=EE=04=CAb&=9D=00=18=1At=02P4=15' =C9=14v=02=9E=D2=13=F0=94=9E=80= =CF=E8 xJO=C0=DF=EB=9E=80=9F=BF'=E0=E9=3D=01_=B9'=E0=15{=02=BEBO=C0k=F4=04|= =E5=9E=80=9F=A7'=E0=DD|%9=EA1=D0j=1E=F2=18=A9=D7=8A=C6=0Cz=81&=1C=93S=F4&= =93=A92=BCIQ=CC=B47=C1B=A3=DE=04=89=A6=E3M=04=99"=DE=84=D2=A5=F0=94.=85=CF= =E8RxJ=97=C2=DF=EB.=85=9F=BFK=E1=E9] _=B9K=E1=15=BB=14=BEB=97=C2kt)|=E5.=85=9F=A7K=E1y=ED=02=E4=02=8Fx=13=B0=9A= =07=BDI_=C1R=88=02=B5=13NK=F1=F3=F6=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6= =E2M$=99=C2=DE=A4=A5=F4MZJ=DF=A4=CD=E8=9B=B4=94=BEI{=AF=FB&=ED=FC}=93=96=DE= 7i+=F7MZ=C5=BEI[=A1o=D2j=F4M=DA=CA}=93v=9E=BEIK=EB=9B@=17x=D8=9B=A0=D5<=E4M= ZW=C1R=C8=02M8-=C5O=18=9DN=95=E1M=8Ab=A6=BD =16=1A=F5&H4=1Do"=C8=14=F1&=94= =BEIK=E9=9B=B4=19}=93=96=D27i=EFu=DF=A4=9D=BFo=D2=D2=FB&m=E5=BEI=AB=D87i+= =F4MZ=8D=BEI[=B9o=D2=CE=D37ii}=13=E8=02=8Fx=13=B0=9A=07=BDI_=C1R=08=02=F9= =E3f=C2i=A9}=E6)=92J=EAMJc&=BC =1C=1A=F2&`4=05o"=CB=14=F2&=F1=08%=DE$=1E=B5= =C4=9B$V=1B=F5&2%hi=8DG=BD=0F=DE$=F1=9E=D7=F2&i =1A=DED=9E=A1=CC=9B=C8=F3E= =1F=0C/=0F%=B7&Yr%=AE=02]R=F0 =C8=7F=BC=D9/^=BE9}=F5=FD=E9=F3=17O=DF=9C.=1E= =8F=D7=EF_=C6=AF~{=F6=FC=F4=BB=D37=A7=05 =EAm=E7=F8=93v}=DB=9Eg<i=B7=3D=B6= =FD=B1[=A6=AF=FDN=E5=89=EE`*=D1=13=DD=15b=C6 =B9$=F4t!=C7=A3=DD}=A2{=D7`OtO=E6=88?=D1=DD8w=FB=89=EE=D6=F6ny44=CD=B2=05= =F6N_=F2D=F7u=EBM=AF=9E:=EF=11=EC*=B9=B3=EF=07=B5=95=17=97=BBd=86[[=F5=0E= =E4=E0/5_=9E=19=D3=B4=89C=D3c=97=D3W=CC4=FDZ=DD'=BAg=BD/=E1=A2=9D=15 =BB,=04g7=F2@w=DB=9Fg=9F=D7=A1=C8#=A4W=16=F8=0E=0E=F5V=E7=C6=8Cmz=9F=F6JE= =14J%,=A2=C51=E3E=14=0F=8D=14Q4=9AY=8C=A6.=B3=88&r=C4=8B=A8]7=B6=F5_=EE=1D= =D7=DA=F6=C8t=FD=B2k=B2=F7Nn%=D3=C8=9D_=C9=B4V=9ES=C9>y=F9GY[=E6VE=CA=D8=81= =98=E59=F7=8DYgo=94%=B0=92@Y=86^=1A=A9=A3=89=D7J=EBZF(q]K=E5=88=DE=FC+=D7= =B9=FC7E=FE=E9=D4=9B=ED=E5=F6f=9BW=DAR=19 =0B=F4=CBcg=D2[gP*mP*ai+=8E=19/mx= h=A4=B4=A1=D1JJ["G=9A=0Fo=976=BFt=E6=A8].]=EB=14=F6N=EC=EEuV=F2=3DBy=D3l=B9= K \=BE=82=13t=E7=F2=3D=BC6]=BDl=A3x=FA&Se=9C=BE=A2=98=E9=D3=87=85FO=1F=12= =ED=EE=E9K=B7.=1F`9=E2=A7o=BC=B5=FD=9D=D3=D7=1E-=9B~=D9=0C=D3[=B6=C8=AA=1C= =9A=8Ao=D5SgzZ=8D=DC=F9=9EVk=E5:=9E=16=DF=AD=90=A7E=C3E=EE6=F0~ =DEmJ=C62#=94p=CA=91=CE=91=EA=CB=DB=FC=D3=BB,5=96=82=B9=CA,=0BL=F7=F6=ACQ,m= =93=A92J[Q=CCti=C3B=A3=A5=0D=89=16(m=BD=A4=B4=F5=E5=3D=93q=EF=F4G=B6=ED=EC= =D0g=EF=9D=82=FAR=9C=BB=A8=BE=A8=AC\=AF=BE`[=06=AE/=BD=B6m/=FEv=DDZI=A4=B4= =81=F7S=B0=B4=F5z=A5-=F7g=0B{Ai=13=CF=02=CE=BD=DD=AC=19=A7=17,m=BD=B0=B4=D5= ]=E0=B8]=93[=C7=EA=95=B6=E9T=F2=D2V=163Y=DA=C0=D0`i=83=A2=05J['(m=B1=1C2j= =F3=CD=D1=D2vm=DBd=EF=9D=FC=D2V=9E=BB=A4=B4=E9=AC\=AD=B4=81[=06-m=C9=DD=810= =F6=B9=FAF=B9=B5=92piC=EF=A7Pi=93=BEK=89=D2&=0D=85=9D=DF=C2=E3{xS=D6=E7=8C= =D3=0B=96=B6NV=DAj/0=FDS=C2=D6)=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B= =94=B6=A5=A4=B49=0Dj=F3=EE=A8i=BCm=87=EC=BDSP=DA=8As=17=956=95=95=EB=956l= =CB=C0=A5=CD=95Q=9B=DD=AC=B47=CA=AD=95DJ=1Bx?=05K=9B=D3+m=B9?v=BD=14=946=97= =015[=C38=BD`i[ K[=E5=05=A6=1F=AEl=BDbi=9BL=95Q=DA=8Ab=A6K=1B=16=1A-mH=B4@ik%=A5=ADS=A1=B6= =EE=C8v=B6-=D8;=05=A5=AD8wQiSY=B9^i=C3=B6=0C\=DA=BA=92=D2=B6r]=EB=B47=CA=AD= =95DJ=1Bx?=05K[=A7W=DA=BA=CC=D2=D6 J['=FF=F1=DD=A6w=8C=D3=0B=96=B6VX=DA*/pHo=9DV=B1=B4M=A6=CA(mE1=D3=A5=0D=0B= =8D=966$Zii=1BT=A8m8j=9Dm;=8D=BD#=FB!=AE=A4~=84+V-u)=91=CB=17<A=A1=CBw=E2S= =89=ECR=EF=F4M=A7=92=9F=BE=B2=98=C9=D3=07=86=06O=1F=14-p=FA=BC=E0=F4=B5N=C3= X=B6=EEh|a3L=F7=DBZ=F5=9EIy=EE=12c=A9=B3r5c n=19=D4X=B6=AEp=1C=E0Z=ED=8Drk%= =E1=BB=0D=BD=9F$w[=86=B1=CC=FE=84?=8F=1B=CB6=E7=97=AB=BDa=9C^=D0Xz=99=B1=AC= =BD=C0=89=9F=FF=EB=14K=DBd=AA=8C=D2V=143]=DA=B0=D0hiC=A2=05J=9B=93=94=B6V= =E3=B7=03=DA=C3=0F=00=FA=AE=B3=D9{=A7=A0=B4=15=E7.*m*+=D7+m=D8=96=81K[=AB]= =DA=8A=BF]=B7V=12)m=E0=FD=14,m=AD^ik3K=9B=13=94=B66=E3=F7=C2<=E5=F4=82=A5= =CD K[=E5=05N=B4=DBz=C5=D26=99*=A3=B4=15=C5L=976,4Z=DA=90h=81=D2f%=A5Me=1C= =D0vG}k;=B3T=D8;=B2=9EI[=D8=B0^v=96=BA=94=C8=E5=0B=9E=A0=BB=97ow=DC=A4=7Fi= =CE=AA=FD=DA)=92Jz=FAJc&N=1F=1C=1A:}`=B4=C0=E93=F0=E9=8B=E7=10=19=CB=AE1G= =B6=F7=C3=E4=EFj&=F2=E5=1AK=85=DC=05=C6Ri=E5J=C6=12=DE2=98=B1=9C=D8=1D=C80= =CE=F5=DA=1B=E5=D6JBw=1B~?I=EE6=B1=B1=94=87=C2=CEo=E1=F1=FD=D8RX3N/h,=8D=C4= X=D6_=A0On=1D=D7(=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B=94=B6FR=DA=BC= =B4=B4=8D(a)r=B7=B4=F9#=D7=BAe?d=EF=9D=82=D2V=9C=BB=A8=B4=A9=AC\=AF=B4a[=06.m= ^w=D4=A9=F0=ED=BA=B5=92Hi=03=EF=A7`i=F3z=A5=CDg=96=B6FP=DA=BC=C6=CDO=DB=C3= =81=D2=D6=08K[=DD=05N|=C6=BD3z=A5m:=95=BC=B4=95=C5L=96604X=DA=A0hw?LVT=DA= =DA=BE=FC=C3d}=D7=F6G=ED=D29=93=BFw=F2K[y=EE=92=D2=A6=B3r=85Ot=C5=F7=0B=F4= =B1=ACS[c=B2=AE=BDm=97=CBA{=97=DCZI=B8=AE=A1=97S=A8=AE=B55?L6cKD=9EN=93=15+= =A7=90=8A/=0B=D7l=CE=BB-e=17T|;=D0=87=EF=E4=BE=A7=B7>&=BF=C1=1F=BES!_=E8=E1= ;=C813=CB=EC=13=FA=C7Ce$'=B4=E8=99?c=E4~=EA=C1(=CE=AA<=EA=06L%z=D4=8DB=CC= =84=A9=81CC=A6=06=8CV=FA=A8=1Bq=A6;=8F=BAIF=B8=F3=A8=1B=81}=EE=F5=1Fu=93^= =ED=BB=F7=8B=C7=E6=EE=B3n=C4R=C0=87M=D0=A5=E0=1F=D9=CD=97=82=7F=C4*] =FE=A1\5=A4=80=1F=A2RA =FAK=EF5=A4=80=BF=A4XC =F8K%=15=A4=A0?=86XC =F8c#|)=F0=A0=A1=86=94=E2=CA=16y=DC=9AX =8A=0E=3D=E9=81ej=124x=BF/|`=D9fXu= =AD}=BBy=BCZ=9F=BB=C7~=BD2=8FW=E7=C6?=EE=97=E7=FD=CA=0D}o=D6=DB=B2|q\=ED=F3= =9FX=06=E3j<=87=80=E7=FA=E2=C7=9E=C9x=8E=9D/=C2s=A0Y=0E=F1=1CNNwy=AE=07=1E= =C2=96=E09=97=E4=B9=89>=90S=E4=B9=C9T=19<W=143=CDsXh=94=E7=90h:<'=C8=14=E1= =B9=9E=C2s=3D=85=E7=FA=9C=B2=DESx=8E*E=C6s\)"=9E=E3J=11=F1=1C] =CEsl)=02=9E=A3K=C1y=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=96"=E19=BA=94=E2=CA= =96=E4=B9=9E=C2s=FD=FC<=D7=D3y=AE=AF=CCs=BD"=CF=F5=15x=AE=D7=E0=B9=BE2=CF= =F5=F3=F0=1Cb=96#<=07=92S=90=E7h=F393A=99^=8F=E7=A6S=C9y=AE,f=92=E7=C0=D0 = =CFA=D1TxN=92)=CCs=862=9F3=94=F9=9C=C9i=D3=1A=CA|=8E+E=C4sd)=12=9E#K=91=F0= =1C_ =CCst)8=CF=F1=A5=C0<=C7=97=02=F3=1C] =CEs|)0=CF=B1=A5=08x=8E/=A5=B8=B2=A5x=CEP=E6sf=FE=F9=9C=A1=CF=E7L=E5=F9=9CQ= =9C=CF=99 =F39=A31=9F3=95=E7sf=9E=F9=1Cd=96=C3<=87=92S=88=E7=8C=A3=F1=DC=04e=B6=8A<7= =99*=83=E7=8Ab=A6y=0E=0B=8D=F2=1C=12M=87=E7=04=99"<G=99=CF=19=CA|=CE=E4=B4i= =0De>=C7=95"=E39=AE=14=11=CFq=A5=88x=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=97= =82=F3=1C[=8A=80=E7=E8Rp=9E#K=91=F0=1C]JqeK=F2=1Ce>g=E6=9F=CF=19=FA|=CET=9E= =CF=19=C5=F9=9C=A90=9F3=1A=F39Sy>g=E6=99=CFAf9=C2s 9=05y=8E6=9F=B3=13=94=B9= =D4=E3=B9=E9Tr=9E+=8B=99=E4904=C8sP4=15=9E=93d =F3=9C=A5=CC=E7,e>gs=DA=B4=962=9F=E3J=11=F1=1CY=8A=84=E7=C8R$<=C7=97=02=F3= =1C] =CEs|)0=CF=F1=A5=C0<G=97=82=F3=1C_ =CCsl)=02=9E=E3K)=AEl)=9E=B3=94=F9=9C=9D=7F>g=E9=F39[y>g=15=E7s=B6=C2|=CEj= =CC=E7l=E5=F9=9C=9Dg>g=DD|`=15%E=94=C9B=A4=98z=ED=C8=0C=17=BB=AB=F1=F0=AF6= =0FM=FBh=DC=11=BB/=BE=FE'V=A0 =EE=ED=14 s2U=06a=16=C5L=13&=16=1A%L$=9A=0Ea 2E=08=9321=B4=94=89=A1=CDi=1C[=CA=C4=90+EF=98\)"=C2=E4J=11=11&] N=98l)=02=C2=A4K=C1 =93.=05'L=B6=14=01a=D2=A5=E0=84I=96"!L=BA=94=E2=CA=96$L= =CA=C4=D0=CE?1=B4=F4=89=A1=AD<1=B4=8A=13C[abh5&=86=B6=F2=C4=D0=CE31=B4=BC= =D1=1Db=C3#=84 2Y=900=FB `( =E4&x=B9=D7#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A3=CC0=1De=86=E9rZ=D9=8E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2t=94=19=A6=9B=7F=86=E9=E83LWy=86=E9=14g=98=AE=C2= =0C=D3i=CC0]=E5=19=A6=9Bg=86=E9h3L=C8=86=87 =13e=B2=10a:W=01=0Ce=81&xyP$=CC= =C9T=19=84Y=143M=98Xh=940=91h:=84)=C8=14!L=CA=0C=D3Qf=98.=A7=95=ED(3L=AE=14= =19ar=A5=88=08=93+ED=98t)8a=B2=A5=08=08=93.=05'L=BA=14=9C0=D9R=04=84I=97=82= =13&Y=8A=840=E9R=8A+[=920)3L7=FF=0C=D3=D1g=98=AE=F2=0C=D3)=CE0]=85=19=A6=D3= =98a=BA=CA3L7=CF=0C=D3=F5=AC=C7=3D@6<B=98 =93=05 =B3=AF=00=86=A2@>=CD=CB=BE= =D1#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A7=CC0=3De=86=E9sZ=D9=9E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2=F4=94=19=A6=9F=7F=86=E9=E93L_y=86=E9=15g=98=BE=C2= =0C=D3k=CC0}=E5=19=A6=9Fg=86=E9i3L=C8=86=87 =13e=B2=10azW=01=0Ce=81=D2=BC= =EC=8D"aN=A6=CA =CC=A2=98i=C2=C4B=A3=84=89D=D3!LA=A6=08aRf=98=9E2=C3=F49=AD= lO=99ar=A5=C8=08=93+ED=98\)"=C2=A4K=C1 =93-E@=98t)8a=D2=A5=E0=84=C9=96" L= =BA=14=9C0=C9R$=84I=97R\=D9=92=84I=99a=FA=F9g=98=9E>=C3=F4=95g=98^q=86=E9+= =CC0=BD=C6=0C=D3W=9Ea=FAyf=98=90Y=8Ep HNA=0E=A4=FD=FAg=EB=D3=AA=AC=1E=CFM= =A7=92=F3\Y=CC$=CF=81=A1A=9E=83=A2=A9=F0=9C$S=98=E7b=11=CAx.=16=B5=8C=E7=A2= =ABM=95u=89=14=9C=E7=B8RD<G=96"=E19=B2=14 =CF=F1=A5=C0<G=97=82=F3=1C_ =CCs|)0=CF=D1=A5=E0<=C7=97=02=F3=1C[=8A=80=E7=F8R=8A+[=8A=E7$Jp=98=8AV=EEz<= =97=92=A0=C3s=D2=0C=A5<'=CD=97=E29i=AC=1C=9E=8B=E5=10=F1\=C6=A2=8Bx=8E=9B/= =CAs=90Y=0E=F3=1CJN!=9E=8B=BDV=81=E7=86=B4*=A7=C8s=93=A92x=AE(f=9A=E7=B0=D0= (=CF!=D1txN=90)=C2s=03=85=E7=06 =CF=0D9e}=A0=F0=1CU=8A=8C=E7=B8RD<=C7=95"=E29=BA=14=9C=E7=D8R=04<G=97=82=F3= =1C] =CEsl)=02=9E=A3K=C1y=8E,E=C2st)=C5=95-=C9s=03=85=E7=86=F9yn=A0=F3=DCP=99=E7= =06E=9E=1B*=F0=DC=A0=C1sCe=9E=1B=E6=E19=C4,Gx=0E$=A7 =CF=0D=1C=9E=1B=8E=9B = =CA=F4Z<=87=A4=92=F2\i=CC=04=CF=C1=A1!=9E=03=A3)=F0=9C,S=88=E7=E2=11Jx.=1E= =B5=84=E7=12=AB=8D=97u=99=14=94=E7=D8R=04<G=97=82=F3=1C] =CEs5=A4=80<WA =CAs5=A4=80<WC =C8s=15=A4=A0<WC =C8s|)0=CF=D5=90R\=D9=E2<'S=82=C2T=A2r=D7=E2=B9=B4=04=0D=9E=93g(=E39y=BE8= =CF=C9c=C9y.=9EC=C0sY=8B.=E09v=BE=08=CF=81f9=C4s89=DD=E5=B9=F8k=15xn=822[E= =9E=9BL=95=C1sE1=D3<=87=85Fy=0E=89=A6=C3s=82L=11=9E=1B(<7Pxn=C8)=EB=03=85= =E7=A8Rd<=C7=95"=E29=AE=14=11=CF=D1=A5=E0<=C7=96"=E09=BA=14=9C=E7=E8Rp=9EcK= =11=F0=1C] =CEsd)=12=9E=A3K)=AElI=9E=1B(<7=CC=CFs=03=9D=E7=86=CA<7(=F2=DCP=81=E7=06=0D= =9E=1B*=F3=DC0=0F=CF=0D=F3=81U=9C=14A&=0B=92=E2=A0=F2=C1*=8A=81=CC=04=F7.= =F5=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84i(=13CC=99=18=9A=9C=C6= =B1=A1L=0C=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=0Debh=E6=9F=18=1A=FA= =C4=D0T=9E=18=1A=C5=89=A1=A9014=1A=13CSybh=E6=99=18=1A=DA=E8=0E=B2=E1a=C2D= =99,D=98=A9=D7=AA=81=A1,=D0=04/w=8A=849=99*=830=8Bb=A6 =13=0B=8D=12&=12M=87= 0=05=99"=84I=99a=1A=CA=0C=D3=E4=B4=B2=0De=86=C9=95"#L=AE=14=11ar=A5=88=08= =93.=05'L=B6=14=01a=D2=A5=E0=84I=97=82=13&[=8A=800=E9Rp=C2$K=91=10&]JqeK=12= &e=86i=E6=9Fa=1A=FA=0C=D3T=9Ea=1A=C5=19=A6=A90=C34=1A3LSy=86i=E6=99a=1A=DA= =0C=13=B2=E1=11=C2=04=99,H=98C=050=14=05=B2=13=BC=DC=EB=11=E6t*9a=96=C5L=12= &=18=1A$L(=9A aJ2=85 =D3Rf=98=962=C3=B49=ADlK=99ar=A5=88=08=93,EB=98d)=12=C2=E4K=81 =93.= =05'L=BE=14=980=F9R`=C2=A4K=C1 =93/=05&L=B6=14=01a=F2=A5=14W=B6=14aZ=CA=0C= =D3=CE?=C3=B4=F4=19=A6=AD<=C3=B4=8A3L[a=86i5f=98=B6=F2=0C=D3=CE3=C3=B4=B4= =19&d=C3=C3=84=892Y=880=AD=AF=00=86=B2@=13=BC<(=12=E6d=AA=0C=C2,=8A=99&L,4J= =98H4=1D=C2=14d=8A=10&e=86i)3L=9B=D3=CA=B6=94=19&W=8A=8C0=B9RD=84=C9=95""L= =BA=14=9C0=D9R=04=84I=97=82=13&] N=98l)=02=C2=A4K=C1 =93,EB=98t)=C5=95-I=98=94=19=A6=9D=7F=86i=E93L[y=86i=15= g=98=B6=C2=0C=D3j=CC0m=E5=19=A6=9Dg=86ii3L=C8=86G=08=13d=B2 a=0E=15=C0P=14= =C8=A5y=B9m=F4=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84=E9(3LG=99a= =BA=9CV=B6=A3=CC0=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=1De=86=E9=E6=9Fa:=FA= =0C=D3U=9Ea:=C5=19=A6=AB0=C3t=1A3LWy=86=E9=E6=99a:=DA=0C=13=B2=E1a=C2D=99,D= =98=CEW=00CY=A04/=B7F=910'Se=10fQ=CC4ab=A1Q=C2D=A2=E9=10=A6 S=840)3LG=99a= =BA=9CV=B6=A3=CC0=B9Rd=84=C9=95""L=AE=14=11a=D2=A5=E0=84=C9=96" L=BA=14=9C0= =E9Rp=C2dK=11=10&] N=98d)=12=C2=A4K)=AElI=C2=A4=CC0=DD=FC3LG=9Fa=BA=CA3L=A78=C3t=15f=98Nc=86= =E9*=CF0=DD<3L=C8,G8=10$=A7 =07=D2F=A7~=82N=AD=1E=CFM=A7=92=F3\Y=CC$=CF=81= =A1A=9E=83=A2=A9=F0=9C$S=98=E7<eb=E8)=13C=9F=D38=F6=94=89!W=8A=88=E7=C8R$<G= =96"=E19=BE=14=98=E7=E8Rp=9E=E3K=81y=8E/=05=E69=BA=14=9C=E7=F8R`=9EcK=11=F0= =1C_JqeK=F1=9C=A7L=0C=FD=FC=13CO=9F=18=FA=CA=13C=AF81=F4=15&=86^cb=E8+O=0C= =FD<=13C=C8,=87y=0E%=A7=10=CFy_=9B=E76=AB=ED=BB=DD=D5=F8=FD=FC=F9=C3=CDf=F7= =F7=AB1=C6=AF=1F=B6=D7=87c=B1=BA=DA=8Cg=E4=E2=E6b5=FE=EB=E8=ABp]=E4m9=FC=EB= =8F`=C7=8B=BF=AF=C6=D7=8F=E2=DE=8E;=EA0=0B=DD=EEW=87=E1=E1=F5=93=9B=D5=F5/= =D7=E3=158=C2=CB=D5=C5=F5=CF_E=1F=92=D1ov=EF=DF=1F=14=FD=13=11bZ$=A9=0F=02= =00=A5=C0<=C7=96"=E09=BE=94=EC=CA=16=E39O=99=18=FA=E9'=86=9E>1=F4=85'=86^qb= =E8=0BL=0C=BD=C6=C4=D0=17=9E=18=FAi&=86=90Y=1E=E69=94=9C=86x=CE=FB=D2<=B7^n= =AE=B77=FD=F7=F3=C7=BB=DB=F5=F6=D7=9B>=C6=CFw=9B=FD=E1X,o=D6=FD=19=B9=BC=BD= \=F6=7F=9B=7F=12=AE =BC-=87=BF=FD=11=ECd=F6=EB=B2=7F}/=EEM=BF=A3=0E=B3=D0= =CDny=18=1E=EE=8Fo=97=FB=9F=F6=FD=15=D8=C3=CB=CD=E5=FE=C7O=A2w=D1=E8=B7=DB= =B7o=0F=8A=FE=1F=FA=AF=82=96=7F=10=02=00 --UugvWAfsgieZRqgk--

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 28 Jul '11

28 Jul '11

ml+openldap(a)esmtp.org wrote: > The full log for one failed retry is: I think we need to see more of the log than this. The only reason for your observed behavior to occur is that somewhere along the line, a step in the replication actually returned LDAP_SUCCESS, which resets the retry counter. So we need to see the complete log for at least one full cycle of "(4 retries left)", "(3 retries left)", "(4 retries left)". > conn=1004 op=0 BIND dn="cn=manager" method=128 > conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 > conn=1004 op=0 RESULT tag=97 err=0 text= > conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" > conn=1004 op=1 SRCH attr=* + > srs csn 20110722201233.471069Z#000000#001#000000 > log csn 20110722201233.471069Z#000000#001#000000 > cmp 0, too old > log csn 20110722201252.820971Z#000000#001#000000 > Entry uid=user68,ou=People,dc=example,dc=com CSN > 20110722201233.471069Z#000000#001#000000 > older or equal to ctx 20110722201233.471069Z#000000#001#000000 > syncprov_search_response: > cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 > syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 > conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) > syncrepl_entry: rid=001 be_search (52) > syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com > null_callback : error code 0x34 > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed > (52) > do_syncrepl: rid=001 rc 52 retrying (4 retries left) > conn=1004 op=2 UNBIND > conn=1004 fd=15 closed > connection_read(15): no connection! > connection_read(15): no connection! > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by hyc＠symas.com 28 Jul '11

28 Jul '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… > Submission from: (NULL) (76.113.106.30) > > > If the olcTLSVerifyClient is set to a value other than "never", the server > should request that the client send a client certificate for possible use with > client cert auth (e.g. SASL/EXTERNAL). > If set to "allow", if the client sends a cert, and there are problems with it, > the server will warn about problems, but will allow the SSL session to proceed > without a client cert. > If set to "try", if the client sends a cert, and there are problems with it, the > server will warn about those problems, and shutdown the SSL session. > If set to "demand" or "hard", the client must send a cert, and the server will > shutdown the SSL session if there are problems. > I added a new member of the tlsm context structure - tc_warn_only - if this is > set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug > is set. This allows the server to warn but allow bad certs if "allow" is set, > and warn and fail if "try" is set. > > Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, > then the patch to 7001 This patch does not apply cleanly to git master. Please remember the devel guidelines - all submissions must be relative to git master. I've cleaned up the rejected parts of this patch so you don't need to resubmit this one. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6996) Bad cn=config quotes in Admin Guide
by hyc＠symas.com 28 Jul '11

28 Jul '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 2.4.26 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > http://www.openldap.org/doc/admin24/slapdconf2.html > contains a number of examples with quoted DNs in cn=config attributes: > olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf. There's nothing wrong here, the config parser accepts quotes for these attributes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by masarati＠aero.polimi.it 27 Jul '11

27 Jul '11

> Full_Name: Clément OUDOT > Version: 2.4.26 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.9.0.93) > > > I have a piece of code that does this singel modify operation on OpenLDAP: > * remove pwdPolicySubentry value > * replace userPassword value > > My password policy has pwdCheckQuality set to 2 (strict checking). My new > userPassword value is {SASL}bob(a)example.com. But the modify operation > failed > with: > > conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality > checking > policy > > > I was thinking than removing the pwdPolicySubentry was sufficient to > disable all > ppolicy constraint on the userPassword replacement in the same modify > operation. > Am I wrong or do I face a ppolicy overlay bug? I think this question should be directed to openldap-technical, as it is a usage question. In detail, I think the behavior of slapd and slapo-ppolicy(5) is correct, because pwdPolicySubentry was present when the operation initiated, and thus the behavior of slapo-ppolicy(5) needs to be based on the entry's content when the operation was initiated. I also think this may represent a possible field of application of the "relax" control, although neither draft-zeilenga-ldap-relax nor draft-behera-ldap-password-policy document it. Something like the relax control would allow to change a password despite the password policy, as soon as the final result complies with the protocol, including extensions. This would mean that slapo-ppolicy(5) constraints would eventually be evaluated for the entry as it results from the operation. But I think I've gone too far in discussing a usage question on the ITS. p.

1 0

(ITS#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by clem.oudot＠gmail.com 27 Jul '11

27 Jul '11

Full_Name: Clément OUDOT Version: 2.4.26 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.9.0.93) I have a piece of code that does this singel modify operation on OpenLDAP: * remove pwdPolicySubentry value * replace userPassword value My password policy has pwdCheckQuality set to 2 (strict checking). My new userPassword value is {SASL}bob(a)example.com. But the modify operation failed with: conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality checking policy I was thinking than removing the pwdPolicySubentry was sufficient to disable all ppolicy constraint on the userPassword replacement in the same modify operation. Am I wrong or do I face a ppolicy overlay bug?

1 0

(ITS#7003) Document typo
by xianhua.zhou＠gmail.com 26 Jul '11

26 Jul '11

Full_Name: Zhou Xianhua Version: 2.4 OS: Ubuntu11.04 URL: Submission from: (NULL) (116.231.39.45) page: http://www.openldap.org/doc/admin24/slapdconfig.html section: "6.2.2.1. backend <type>" There is a table's title called "Table 5.2: Database Backends", it should be "Table 6.2: Database Backends".

1 0

Re: (ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by richm＠stanfordalumni.org 25 Jul '11

25 Jul '11

On 07/11/2011 10:44 AM, thibault.lemeur(a)supelec.fr wrote: > Full_Name: Thibault Le Meur > Version: 2.4.23-15 > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (160.228.28.55) > > > Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd > process used an X509 "server" while my syncrepl processes were using the > /etc/openldap/ldap.conf client configuration file in order to connect to my > LDAPs Syncrepl providers. > > In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to > MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it > complains about the TLS context not beeing intitialized correctly (the server's > certificate isn't accepted as a client certificate). > > Here is the lightly obfuscated log: > > ---------------------------------------------------------- > ldap_connect_to_host: Trying 10.10.10.10:636 > ldap_pvt_connect: fd: 21 tm: -1 async: 0 > TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. > TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is > not valid - error -8101:Unknown code ___f 91. > TLS: error: unable to set up client certificate authentication for certificate > named PEM Token #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: unable to set up client certificate authentication using PEM Token > #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: could not initialize moznss security context - error -8101:Unknown > code ___f 91 > TLS: can't create ssl handle. > slap_client_connect: URI=ldaps://otherldap.mydom.fr > DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) > do_syncrepl: rid=125 rc -1 retrying (9 retries left) > ---------------------------------------------------------- > > Here is my syncrepl setup: > --------------------------------------------------------- > syncrepl rid=125 > provider=ldaps://otherldap.mydom.fr > type=refreshOnly > interval=00:00:03:00 > retry="60 10 300 +" > searchbase="dc=subranch,dc=mydom,dc=fr" > filter="(objectClass=*)" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=myreplicationAccount,dc=mydom,dc=fr" > credentials="MyVerySecretPassword" > --------------------------------------------------------- > > My setup related to TLS: > --------------------------------------------------------- > TLSCipherSuite HIGH > TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem > TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem > TLSCACertificateFile /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > And my /etc/openldap/ldap.conf: > --------------------------------------------------------- > TLS_CACERT /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > Here is the obfuscated certificate: > --------------------------------------------------------- > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 221 (0xdd) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, > CN=myCA/emailAddress=myemail(a)mydom.fr > Validity > Not Before: Oct 2 16:42:15 2007 GMT > Not After : Dec 14 16:42:15 2012 GMT > Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > ... > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Cert Type: > SSL Server > Netscape Comment: > TinyCA Generated Certificate > X509v3 Subject Key Identifier: > ... > X509v3 Authority Key Identifier: > keyid:... > DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr > serial:00 > > X509v3 Issuer Alternative Name: > <EMPTY> > > Netscape SSL Server Name: > myldap.mydom.fr > X509v3 Subject Alternative Name: > DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, > DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, > DNS:myldap.mydom.fr > X509v3 Extended Key Usage: critical > TLS Web Server Authentication, Code Signing > Signature Algorithm: sha1WithRSAEncryption > ... > --------------------------------------------------------- I think this ITS is superseded by http://www.openldap.org/its/index.cgi?findid=7001 and http://www.openldap.org/its/index.cgi?findid=7002 Note that even with openldap built with openssl (ol 2.4.latest and openssl 1.0.x), the syncrepl tls context is inherited from the main server context, and the server cert is sent as the client cert. If the server sets TLSVerifyClient to never or allow, syncrepl will work, because the server will ignore the problems with the client cert. But if TLSVerifyClient is set to "try", "demand", or "hard", syncrepl will fail because the server always sends the server cert as the client cert, and since the server cert cannot also be used as a client cert, the server will correctly reject it.

1 0

(ITS#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… Submission from: (NULL) (76.113.106.30) If the olcTLSVerifyClient is set to a value other than "never", the server should request that the client send a client certificate for possible use with client cert auth (e.g. SASL/EXTERNAL). If set to "allow", if the client sends a cert, and there are problems with it, the server will warn about problems, but will allow the SSL session to proceed without a client cert. If set to "try", if the client sends a cert, and there are problems with it, the server will warn about those problems, and shutdown the SSL session. If set to "demand" or "hard", the client must send a cert, and the server will shutdown the SSL session if there are problems. I added a new member of the tlsm context structure - tc_warn_only - if this is set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug is set. This allows the server to warn but allow bad certs if "allow" is set, and warn and fail if "try" is set. Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, then the patch to 7001

1 0

(ITS#7001) Patch - Mozilla NSS - memleak - free the return of tlsm_find_and_verify_cert_key
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-memleak-free-the-ret… Submission from: (NULL) (76.113.106.30) If tlsm_find_and_verify_cert_key finds the cert and/or key, and it fails to verify them, it will leave them allocated for the caller to dispose of. There were a couple of places that were not disposing of the cert and key upon error. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7000) Slapd crashed during modrdn in syncrepl
by tedcheng＠symas.com 25 Jul '11

25 Jul '11

Full_Name: Ted C. Cheng Version: trunk OS: RHEL 5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.194.135.105) 2655 static int 2656 syncrepl_entry( 2657 syncinfo_t* si, . 3082 retry_modrdn:; 3083 rs_reinit( &rs_modify, REP_RESULT ); 3084 rc = op->o_bd->be_modrdn( op, &rs_modify ); 3085 3086 /* NOTE: noSuchObject should result because the new superior 3087 * has not been added yet (ITS#6472) */ #ifdef SLAPD_CRASHED_MODRDN_SYNCREPL 3088 if ( rc == LDAP_NO_SUCH_OBJECT && !BER_BVISNULL( op->orr_nnewSup )) { #else /* fix */ 3088 if ( rc == LDAP_NO_SUCH_OBJECT && (op->orr_nnewSup != NULL ) && !BER_BVISNULL( op->orr_nnewSup )) { #endif /* SLAPD_CRASHED_MODRDN_SYNCREPL */ 3089 Operation op2 = *op;

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs