- openldap-bugs - openldap.org

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 20 Apr '11

20 Apr '11

Trying a more complex configuration I found my first problem. This is my configuration: logbase session dc=mycorp,dc=mydc.it logbase all ou=groups,dc=mycorp,dc=mydc.it logbase all ou=people,dc=mycorp,dc=mydc.it Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", I obtain this accesslog # 20110420141404.000000Z, log03, mydc.it dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it objectClass: auditBind reqStart: 20110420141404.000000Z reqEnd: 20110420141404.000001Z reqType: bind reqSession: 1000 reqAuthzID: reqDN: cn=manager,dc=mycorp,dc=mydc.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE # 20110420141404.000002Z, log03, mydc.it dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it objectClass: auditSearch reqStart: 20110420141404.000002Z reqEnd: 20110420141404.000003Z reqType: search reqSession: 1000 reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it reqDN: ou=groups,dc=mycorp,dc=mydc.it reqResult: 0 reqScope: sub reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (cn=minnie) reqAttr: dn reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: -1 As you can see, there isn't the unbind operation log... It's an error of mine?

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 20 Apr '11

20 Apr '11

I compiled HEAD/Master branch and I tried setting logbase directive. It seems to work as requested! Thanks Marco

1 0

(ITS#6909)
by diego.jesus.granados.lopez＠ericsson.com 18 Apr '11

18 Apr '11

--_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It was difficult to achieve, but I was able to include several errors (rega= rding line numbers) in my two-line patch XD The correct one: --- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c 200= 9-08-14 22:54:14.000000000 +0200 +++ ./servers/slapd/back-meta/search.c 2011-04-15 13:11:51.395261000 +0200 @@ -309,6 +309,8 @@ if ( rc =3D=3D LDAP_SUCCESS ) { candidates[ candidate ].sr_msgid =3D META_M= SGID_IGNORE; + binddn =3D msc->msc_bound_ndn; + cred =3D msc->msc_cred; goto retry; } } Regards, Diego --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Arial, sans-serif" size=3D"2"> <div>It was difficult to achieve, but I was able to include several errors = (regarding line numbers) in my two-line patch XD </div> <div> </div> <div>The correct one: </div> <div> </div> <div>--- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c&nbs= p;     2009-08-14 22:54:14.000000000 +0200</div> <div>+++ ./servers/slapd/back-meta/search.c  2011-04-15 13= :11:51.395261000 +0200</div> <div>@@ -309,6 +309,8 @@</div> <div> </div> <div>           &nbs= p;             = if ( rc =3D=3D LDAP_SUCCESS ) {</div> <div>           &nbs= p;            &= nbsp;        candidates[ candidate ].sr_= msgid =3D META_MSGID_IGNORE;</div> <div>+          &nbsp= ;            &n= bsp;       binddn =3D msc->msc_bound_ndn;<= /div> <div>+          &nbsp= ;            &n= bsp;       cred =3D msc->msc_cred;</div> <div>           &nbs= p;            &= nbsp;        goto retry;</div> <div>           &nbs= p;             = }</div> <div>           &nbs= p;     }</div> <div> </div> <div> </div> <div>Regards, </div> <div>Diego</div> <div> </div> </font> </body> </html> --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_--

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 15 Apr '11

15 Apr '11

Hi, it's me again, with another small but also very important bugfix for the previous two versions of my patch. This patch does not change the correct (as documented by the project) behaviour of "dnattr=... selfwrite". It can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110415.patch FYI and the log: Next to some simple always reproducible test-shellscripts (ldapmodify add/delete distinct values) I have been also using Apache Directory Studio to test and workout the intended behavior of my ACLs, which is the root cause for these two updates: I've not been aware of the difference between "to value" and "to all values", yet and all my testcases (ldif changetype modify) only have been using "to value" operations. I've used following ACL to test this second patch of my original patch: access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users read by * none access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description by users read by * none break access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member by dnattr=member selfwrite by * none Based on these ACL each user that is a member of a group entry seems to be just the only member of these group (from the user's point of view, in case the user accesses the group's member attribute by read). When using Apache Directoy Studio to delete this only/single/last group member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation. => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr "member" requested => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0) It seems to me that this appears to be a bug in ADS, where the client (ADS) tries to be more inteligent/comfortable/strict than needed. OTOH based on this strange behaviour I've learned something "new" (and quite important to me in regard to acl design and testcases during testing). Sorry for these kind of SPAM and the circumstances. Hopefully that's the last bugfix for that patch.

1 0

Re: (ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by rmeggins＠redhat.com 15 Apr '11

15 Apr '11

When https://bugzilla.mozilla.org/show_bug.cgi?id=172051 is fixed, error messages will magically appear.

1 0

Re: (ITS#6908) Query
by h.b.furuseth＠usit.uio.no 15 Apr '11

15 Apr '11

preeti(a)omnimessaging.com writes: > My OpenLdap Client file "ldapmodify" is missing. > Can you please provide me with the "openldap-client-2.3.32.tgz" file. Ask whoever provided your OpenLDAP installation. The OpenLDAP project distributes only source code, and openldap-2.3.32.tgz does include ldapmodify. Also, the ITS system is for bug reports, not help requests. The openldap-technical mailinglist is for issues related to use of OpenLDAP. https://www.openldap.org/lists/mm/listinfo/openldap-technical -- Regards, Hallvard

1 0

(ITS#6910) Ldap fails to start when duplicate entries are in /etc/hosts
by quanah＠zimbra.com 14 Apr '11

14 Apr '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) If an IP address entry for a host appears more than once in /etc/hosts, slapd fails to start, complaining the port is already in use. Failed to start slapd. Attempting debug start to determine error. daemon: listen(ldap://zre-ldap002.eng.vmware.com:389, 5) failed errno=98 (Address already in use) Sample /etc/hosts: zimbra@zre-ldap002:~$ cat /etc/hosts 127.0.0.1 localhost 10.137.242.52 zre-ldap002.eng.vmware.com zre-ldap002 10.137.242.52 zre-ldap002.eng.vmware.com zre-ldap002 It appears that we don't validate whether or not we've already tried to start up on a given interface...

1 0

(ITS#6909) High asynchronous traffic handled by back-meta causes multiple err=34 errors
by diego.jesus.granados.lopez＠ericsson.com 14 Apr '11

14 Apr '11

Full_Name: Diego Granados López Version: 2.4.21 OS: SUSE Linux Enterprise Server 10 SP3 (x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) The issue arises when running a large number (200+) of asynchronous clients issuing queries vs slapd. Back-meta is configured to use a single remote target. Eventually, during a connection re-bind (function meta_search_dobind_init), one thread goes into the block of code which starts on line 322: case LDAP_SERVER_DOWN: down:; /* This is the worst thing that could happen: * the search will wait until the retry is over. */ in that block, the meta_single_conn is cleaned up inside the call: meta_clear_one_candidate( op, mc, candidate ); Inside that function, the msc->msc_bound_ndn memory is freed if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) { ber_memfree_x( msc->msc_bound_ndn.bv_val, NULL ); BER_BVZERO( &msc->msc_bound_ndn ); } ; later, the call rc = meta_back_init_one_conn( op, rs, mc, candidate, LDAP_BACK_CONN_ISPRIV( mc ), LDAP_BACK_DONTSEND, 0 ); takes the connection to a healthy state again, but the problem is that binddn & cred vars, which had been assigned at function start, struct berval binddn = msc->msc_bound_ndn, cred = msc->msc_cred; are not being assigned to the new correct values, and after going into "goto retry" call, those vars are used in the bind retry, but they are pointing still to the previously freed memory , containing garbage). The remote server shows the incorrect content of the dns being send: cat /var/log/ldapfe* | grep "invalid dn (" Apr 8 12:41:17 xx slapd[10482]: conn=47925 op=0 do_bind: invalid dn ( Iµ) Apr 8 12:41:17 xx slapd[10482]: conn=47926 op=0 do_bind: invalid dn (àí@ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47928 op=0 do_bind: invalid dn (`úö¯ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47929 op=0 do_bind: invalid dn (0÷¯ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47927 op=0 do_bind: invalid dn (èº¬ª*) slapd[10482]: conn=47925 fd=155 ACCEPT from IP=172.80.0.168:56451 (IP=0.0.0.0:389) Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=0 do_bind: invalid dn ( Iµ) Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=0 RESULT tag=97 err=34 text=invalid DN Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=1 UNBIND Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 fd=155 closed Please find attached our proposed patch for this: --- servers/slapd/back-meta/search.c 2011-04-11 11:23:14.000000000 +0200 +++ /home/devel/ediegra_[...]/bin/openldap-2.4.21/servers/slapd/back-meta/search.c 2011-04-14 11:21:03.000000000 +0200 @@ -363,6 +363,10 @@ if ( rc == LDAP_SUCCESS ) { candidates[ candidate ].sr_msgid = META_MSGID_IGNORE; + binddn = msc->msc_bound_ndn; + cred = msc->msc_cred; goto retry; } } Kind regards, Diego

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by quanah＠zimbra.com 13 Apr '11

13 Apr '11

--On Wednesday, April 13, 2011 3:09 PM +0000 quanah(a)zimbra.com wrote: As a follow up -- This issue is caused by instantiating overlays outside of the database. Specifically this will trigger the problem: # INCLUDES include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/dyngroup.schema # RUNFILE LOCATIONS pidfile /usr/local/var/run/openldap/slapd.pid argsfile /usr/local/var/run/openldap/slapd.args security ssf=127 # MODULES modulepath /usr/local/libexec/openldap moduleload back_hdb moduleload refint moduleload dynlist moduleload memberof # OVERLAYS AND OVERLAY CONFIG overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=EMPTY overlay dynlist dynlist-attrset groupOfURLs memberURL member overlay memberof memberof-refint TRUE # DATABASE database hdb directory /usr/local/var/openldap-data # GLOBAL LDAP SETTINGS suffix "dc=example,dc=org" rootdn "cn=root,dc=example,dc=org" rootpw blahblahblah # SSL / TLS - note - these are all real, valid, issued certs. TLSCACertificatePath /etc/ssl/certs TLSCACertificateFile /etc/ssl/certs/gd_bundle.crt TLSCertificateFile /etc/ssl/certs/ldap.example.org.combined.crt TLSCertificateKeyFile /etc/ssl/private/ldap.example.org.key access to * by * write # PERFORMANCE index objectClass eq index cn eq,sub,pres,approx index uid eq,sub,pres index sn eq,sub,approx index member eq index givenName eq,sub,approx index mail eq,sub,approx #limits limits users size=10000 size.pr=unlimited -- 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#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by catchall＠bromberger.com 13 Apr '11

13 Apr '11

It went on for screens; here's the top of it: (gdb) thr apply all bt full Thread 3 (Thread 0x7ffff48fb700 (LWP 12771)): #0 0x00000000004d2d7d in over_op_func (op=0x0, rs=0x0, which=op_bind) at backover.c:698 oi = 0x0 on = 0x0 be = 0x0 db = {bd_info = 0x0, bd_self = 0x0, be_ctrls = '\000' <repeats 32 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 0, lms_t_hard = 0, lms_s_soft = 0, lms_s_hard = 0, lms_s_unchecked = 0, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_NONE, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0, sc_cleanup = 0, sc_private = 0x0} sc = 0x0 rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #1 0x00000000004d31f1 in over_aux_chk_controls (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:814 No locals. #2 0x0000000000454d49 in backend_check_restrictions (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, opdata=0x0) at backend.c:1039 fssf = 0x45419a bssf = 0x0 rc = 32768 i = 0 restrictops = 0 requires = 0 ---Type <return> to continue, or q <return> to quit--- opflag = 9482848 exopflag = 0 ssfs = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0x7ffff40fc220 updateop = 0 starttls = 0 session = 0 #3 0x000000000044580a in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:340 bd = 0x7ffff40fc3d0 #4 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #5 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, ---Type <return> to continue, or q <return> to quit--- __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fc670, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #7 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fc6c0 #8 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #9 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, ---Type <return> to continue, or q <return> to quit--- be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fc960, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #11 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fc9b0 #12 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #13 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, ---Type <return> to continue, or q <return> to quit--- be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fcc50, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #14 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #15 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fcca0 #16 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #17 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fcf40, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #18 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #19 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fcf90 #20 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #21 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, ---Type <return> to continue, or q <return> to quit--- sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd230, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #22 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #23 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd280 #24 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #25 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, ---Type <return> to continue, or q <return> to quit--- be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd520, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #26 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #27 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd570 #28 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #29 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 ---Type <return> to continue, or q <return> to quit--- oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd810, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #30 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #31 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd860 #32 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 ---Type <return> to continue, or q <return> to quit--- func = 0x80c078 rc = 32768 #33 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fdb00, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #34 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #35 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) ---Type <return> to continue, or q <return> to quit--- at search.c:372 bd = 0x7ffff40fdb50 #36 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #37 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fddf0, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" ---Type <return> to continue, or q <return> to quit--- #38 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #39 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fde40 #40 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #41 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fe0e0, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, ---Type <return> to continue, or q <return> to quit--- sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #42 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #43 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fe130 #44 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #45 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, ...

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by catchall＠bromberger.com 13 Apr '11

13 Apr '11

I don't know whether I did it correctly, but here's my first attempt at a gdb backtrace. Note that it keeps going - I went to #7500 before I gave up - it was just repeating, e.g., lines 5-7. Does this help? What else should I be providing? Seth. Starting program: /usr/local/libexec/slapd -d 256 -h "ldaps:///" -u openldap -g openldap -f /usr/local/etc/openldap/slapd.conf [Thread debugging using libthread_db enabled] ... conn=1000 op=4 MODRDN dn="uid=myuid,ou=Testing,dc=example,dc=org" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff4901700 (LWP 12020)] 0x000000000049af05 in ?? () (gdb) backtrace #0 0x000000000049af05 in ?? () #1 0x00000000004421e3 in backend_check_restrictions () #2 0x0000000000437220 in fe_op_search () #3 0x000000000049a577 in overlay_op_walk () #4 0x000000000049afb8 in ?? () #5 0x00000000004373f1 in fe_op_search () #6 0x000000000049a577 in overlay_op_walk () #7 0x000000000049afb8 in ?? () #8 0x00000000004373f1 in fe_op_search () #9 0x000000000049a577 in overlay_op_walk () #10 0x000000000049afb8 in ?? () #11 0x00000000004373f1 in fe_op_search () #12 0x000000000049a577 in overlay_op_walk () #13 0x000000000049afb8 in ?? () #14 0x00000000004373f1 in fe_op_search () #15 0x000000000049a577 in overlay_op_walk () #16 0x000000000049afb8 in ?? () #17 0x00000000004373f1 in fe_op_search () #18 0x000000000049a577 in overlay_op_walk () #19 0x000000000049afb8 in ?? () #20 0x00000000004373f1 in fe_op_search () #21 0x000000000049a577 in overlay_op_walk () #22 0x000000000049afb8 in ?? () #23 0x00000000004373f1 in fe_op_search () #24 0x000000000049a577 in overlay_op_walk () #25 0x000000000049afb8 in ?? () #26 0x00000000004373f1 in fe_op_search () #27 0x000000000049a577 in overlay_op_walk () #28 0x000000000049afb8 in ?? () #29 0x00000000004373f1 in fe_op_search () #30 0x000000000049a577 in overlay_op_walk () #31 0x000000000049afb8 in ?? () #32 0x00000000004373f1 in fe_op_search () #33 0x000000000049a577 in overlay_op_walk () #34 0x000000000049afb8 in ?? () #35 0x00000000004373f1 in fe_op_search () #36 0x000000000049a577 in overlay_op_walk () #37 0x000000000049afb8 in ?? () #38 0x00000000004373f1 in fe_op_search () #39 0x000000000049a577 in overlay_op_walk () #40 0x000000000049afb8 in ?? () #41 0x00000000004373f1 in fe_op_search ()

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by quanah＠zimbra.com 13 Apr '11

13 Apr '11

--On Wednesday, April 13, 2011 12:26 AM +0000 openldap(a)bromberger.com wrote: > Full_Name: Seth > Version: 2.4.25 > OS: Linux (Ubuntu) 2.6.35.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.13.140.242) > > > Using Apache Directory Studio to interface with hdb-based openldap server > via TLS. Moving a DN from one ou to another crashes slapd. The move (the > first one if there are multiples) appears to work before slapd segfaults. > An example in the logfile: > > > Apr 12 17:17:52 ldap slapd[11278]: conn=1000 op=13 MODRDN > dn="uid=someuserid,ou=Organizations,dc=example,dc=org" > Apr 12 17:17:52 ldap kernel: [974579.184525] slapd[11281]: segfault at > 7f0bdfab7ff8 ip 000000000049af05 sp 00007f0bdfab8000 error 6 in > slapd[400000+19e000] > > This is 100% reproducible. Also affects 2.4.23-0ubuntu3.5 (ubuntu > package) - I upgraded from source to try to work around this bug. > Please provide a gdb backtrace. --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#6789)
by sgallagh＠redhat.com 13 Apr '11

13 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has there been any progress on this issue? It causes a lot of headaches trying to debug connection issues in SSSD. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lsTIACgkQeiVVYja6o6Nh7wCdF5Sn/IsMpNH9gB8WA9A7tEgB ctUAoKPTUIL1rfZPnArrNBmAxQ/VuEq7 =DxDR -----END PGP SIGNATURE-----

1 0

(ITS#6908) Query
by preeti＠omnimessaging.com 13 Apr '11

13 Apr '11

Full_Name: Preeti Version: 2.3.32 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.143.122.119) My OpenLdap Client file "ldapmodify" is missing. Can you please provide me with the "openldap-client-2.3.32.tgz" file.

1 0

(ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by openldap＠bromberger.com 12 Apr '11

12 Apr '11

Full_Name: Seth Version: 2.4.25 OS: Linux (Ubuntu) 2.6.35.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.13.140.242) Using Apache Directory Studio to interface with hdb-based openldap server via TLS. Moving a DN from one ou to another crashes slapd. The move (the first one if there are multiples) appears to work before slapd segfaults. An example in the logfile: Apr 12 17:17:52 ldap slapd[11278]: conn=1000 op=13 MODRDN dn="uid=someuserid,ou=Organizations,dc=example,dc=org" Apr 12 17:17:52 ldap kernel: [974579.184525] slapd[11281]: segfault at 7f0bdfab7ff8 ip 000000000049af05 sp 00007f0bdfab8000 error 6 in slapd[400000+19e000] This is 100% reproducible. Also affects 2.4.23-0ubuntu3.5 (ubuntu package) - I upgraded from source to try to work around this bug.

1 0

(ITS#6906) fix Admin guide cachesize calculations to remove refence to Hash-format
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/TimMooney-110412-04.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here: http://www.openldap.org/lists/openldap-technical/201104/msg00088.html and Quanah clarified here: http://www.openldap.org/lists/openldap-technical/201104/msg00123.html The admin guide chapter on tuning still mentions that indexes are in Hash format, though that's no longer true. I've uploaded patch TimMooney-110412-04.patch against HEAD that clarifies that indexes are now also in B-tree format and so the same calculations for cache on dn2id can be used with each index. I also corrected one other typo, changing To avoid thrashing the, your cache to To avoid thrashing, your cache

1 0

(ITS#6904) correct the recommended backend verbiage in slapd.backends(5)
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

I've uploaded an additional patch, TimMooney-110412-03.patch, for slapd-bdb.5/slapd-hdb.5, that switches the "recommended" status from bdb to hdb. This should likely be applied in addition to the patch mentioned in the initial report.

1 0

(ITS#6905) fix up intros to chapters 5 and 6
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/TimMooney-110412-02.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here http://www.openldap.org/lists/openldap-technical/201104/msg00088.html the LDAP admin guide is very good, but I think that the intros to chapters 5 (configuring slapd via slapd-config) and chapter 6 (configuring slapd via slapd.conf) needed a bit of updating. Specifically - it's not very explicit that slapd-config is now preferred and slapd.conf should only be used as a last resort. - the Note that some backends don't support slapd-config was vague enough that it would prevent many people from choosing that route, because they wouldn't know whether a backend they needed would support the new-style config system. By specifically listing which backends don't support slapd-config, hopefully more people will be willing to begin with (or convert to) slapd-config. I also tried to - make it clear that chapters 5 and 6 were essentially explaining the same thing, but the slapd-config way is preferred. - Although slapd-config stores its configuration in text files, they shouldn't be edited manually. The patch against head has been uploaded. Any and all comments and feedback welcome.

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 12 Apr '11

12 Apr '11

Hi Quanah, slapd does have access to the files because it re-created after I deleted them on start. root@directory-proxy2:/var/lib/ldap# ls -la total 11752 drwxr-x--- 2 openldap openldap 4096 2011-04-12 16:01 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-04-12 16:01 alock -rw------- 1 openldap openldap 24576 2011-04-12 16:01 __db.001 -rw------- 1 openldap openldap 843776 2011-04-12 16:01 __db.002 -rw------- 1 openldap openldap 13115392 2011-04-12 16:01 __db.003 -rw------- 1 openldap openldap 2359296 2011-04-12 16:01 __db.004 -rw------- 1 openldap openldap 540672 2011-04-12 16:01 __db.005 -rw------- 1 openldap openldap 32768 2011-04-12 16:01 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-04-12 14:29 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-04-12 14:29 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-04-12 14:29 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-04-12 16:01 log.0000000001 root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 5519 0.0 0.6 56244 6316 ? Ssl 16:01 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d I've disabled apparmor as well.. On Tue, Apr 12, 2011 at 3:42 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates <tgates81(a)gmail.com> > wrote: > >> I can't get a back trace because it doesn't crash under gdb, slapd >> only responds to queries with error: >> >> client: >> result: 80 Other (e.g., implementation specific) error >> text: internal error >> server: >> bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery >> >> Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one >> (type=hdb, suffix="(null)"): bi_db_open failed! (-1) > > These all indicate permissions issues. It sounds like the slapd instance > does not have permissions to access the database. > > --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#6891)
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates <tgates81(a)gmail.com> wrote: > I can't get a back trace because it doesn't crash under gdb, slapd > only responds to queries with error: > > client: > result: 80 Other (e.g., implementation specific) error > text: internal error > server: > bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery > > Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one > (type=hdb, suffix="(null)"): bi_db_open failed! (-1) These all indicate permissions issues. It sounds like the slapd instance does not have permissions to access the database. --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#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 12 Apr '11

12 Apr '11

The patch that I submitted above has a memory leak due not freeing "ber" when returning error LDAP_X_CONNECTING from function ldap_send_initial_request(). I have uploaded a new version of the patch with this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode).

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 12 Apr '11

12 Apr '11

I can't get a back trace because it doesn't crash under gdb, slapd only responds to queries with error: client: result: 80 Other (e.g., implementation specific) error text: internal error server: bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery This happens after every restart, even after starting with fresh database directory. I've never had to specify a suffix dn inside of the database backend to pcache before, so I'm a little confused as to why this needed. When I had started slapd fresh from after upgrading 2.4.24 (when it was working fine) to 2.4.25, I got these error messages about it not having one: Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd startup: initiated. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup: warning, database 0 (hdb) has no suffix Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one: starting "(unknown)" Apr 12 14:25:34 directory-proxy2 slapd[2526]: hdb_db_open: need suffix. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd shutdown: initiated Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd destroy: freeing system resources. Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd stopped. I have output from strace and I can provide it if needed but it is very lengthy and doesn't seem to provide any useful information. On Mon, Apr 11, 2011 at 1:43 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, April 11, 2011 3:32 PM +0000 tgates81(a)gmail.com wrote: > >> Can someone confirm whether or not this is a bug or just a >> misconfiguration error on my part? I am at a complete loss. >> > > None of what you provided as output from gdb was output from gdb. Get a > valid backtrace. > > --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#6903) BerkeleyDB
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 9:38 AM +0000 h.b.furuseth(a)usit.uio.no wrote: > matdave(a)yahoo.com writes: >> New to openldap, downloaded latest stable version and tried to configure >> with Berkeley 11g from Oracle. >> Configure message along the lines of 'Berkeley (default) no' >> 'Berkeley not enabld/installed' > > See README, "REQUIRED SOFTWARE": > SLAPD: > BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, > 4.6, 4.7, or 4.8. It is highly recommended to apply the > patches from Oracle for a given release. > > Closing this ITS. And please use openldap-technical(a)openldap.org > for help requests. ITS is for bug reports and contributions. Probably worth reporting later versions of OpenLDAP support compiling against 5.x with no problem. 2.4.23 can be made to build against 5.x as well with the appropriate patch to configure. --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#6904) correct the recommended backend verbiage in slapd.backends(5)
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/0001-Update-to-reflect-that-hdb-is-now-pref… Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) The slapd.backends(5) man page still indicates that the bdb backend is the recommended database, even though Quanah has confirmed that for 2.4 and later, hdb is now preferred, see http://www.openldap.org/lists/openldap-technical/201104/msg00123.html I've uploaded a patch to ftp://ftp.openldap.org/incoming against HEAD that addresses this issue, you can find it as 0001-Update-to-reflect-that-hdb-is-now-preferred-backend.patch (Sorry for the name, I'll be more careful to follow the recommended naming conventions next time). Note that I used the word "supplanted" rather than "deprecated" in the new verbiage about bdb, since deprecated seems stronger. If you would prefer the term deprecated, let me know and I can upload a new patch with that change.

1 0

Re: (ITS#6903) BerkeleyDB
by h.b.furuseth＠usit.uio.no 12 Apr '11

12 Apr '11

matdave(a)yahoo.com writes: > New to openldap, downloaded latest stable version and tried to configure with > Berkeley 11g from Oracle. > Configure message along the lines of 'Berkeley (default) no' > 'Berkeley not enabld/installed' See README, "REQUIRED SOFTWARE": SLAPD: BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, 4.6, 4.7, or 4.8. It is highly recommended to apply the patches from Oracle for a given release. Closing this ITS. And please use openldap-technical(a)openldap.org for help requests. ITS is for bug reports and contributions. -- Hallvard

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs