openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by lists＠steffen-moser.de 22 Oct '16

22 Oct '16

Dear Mark, On 05/25/16 2:38 PM, Mark Bannister wrote: > Can anyone shed light on why my slapadd process on Solaris 11 was > hanging (slapd 2.4.30)? I was piping ‘gunzip -c’ through to slapadd > (from an overnight cron job). This usually works fine. I’m guessing > perhaps the gunzip process encountered an error, maybe an EPIPE was > sent, but the stack trace many days later from slapadd doesn’t look > right. Only 2 threads, and both of them in > ldap_pvt_thread_cond_wait(), but no other threads so what are they > waiting for exactly? I've just come across your problem report which you posted to the "openldap-its" mailing list in this year's May: http://www.openldap.org/lists/openldap-technical/201605/threads.html#00079 Today, I encountered a similar hang of our OpenLDAP 2.4.30 server on a Solaris 11.3(.11.6.0) host. It is quite interesting that the function "bdb_tool_entry_close" doesn't seem to play a role in my case, but "ldap_pvt_thread_cond_wait" and "ldap_int_thread_pool_wrapper" do seem to. My questions to your address and to the mailing list are: Has the bug/problem been fully analyzed and has it been fixed in the meantime? Mark, did you have another hang of this kind or any similar problems with your OpenLDAP installation? Thank you very much in advance for any helpful hints! Kind regards, Steffen -- ------------------------------------------------------------------------ Dipl.-Inf. Steffen Moser School of Advanced Professional Studies Room: 45.3.110 Ulm University Tel: +49.731.50-32407 Albert-Einstein-Allee 45 Fax: +49.731.50-32409 89081 Ulm, Germany http://saps.uni-ulm.de/

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠gmail.com 21 Oct '16

21 Oct '16

Is it just me, or the ITS WebUI is removing part of the message I typed ? Anyway, here is the complete descripton : Replication won't start if we set it up on running servers configured wit= h slapd.d. The scenario is the following : o We have 2 servers, one will become the provider, the other the consumer o They are initially empty%2ususing MDB (see the attached configurations, converted from slapd.conf to slapd.d) o We start the 2 servers o Step 1 : On the provider, we inject the following entry : dn: cn=3Dconfig changetype: modify add: olcServerId olcServerId: 1 - o Step 2 : On the provider, we inject the following entries : # Context entry dn: dc=3Dexample,dc=3Dcom changetype: add objectClass: domain objectClass: top dc: example # LDAPRoles, dc=3Dexample,dc=3Dcom dn: ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom objectClass: top objectClass: organizationalUnit ou: LDAPRoles dn: dc=3Dusers,dc=3Dexample,dc=3Dcom changetype: add dc: users objectClass: domain objectClass: top dn: cn=3DJohndoe,dc=3Dusers,dc=3Dexample,dc=3Dcom changetype: add objectClass: person objectClass: top sn: John Doe cn: Johndoe # replicator, LDAPRoles, dc=3Dexample, dc=3Dcom dn: cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom objectClass: top objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: secret cn: replicator o Step 3 : On the consumer, we inject the following entry : # Context entry dn: dc=3Dexample,dc=3Dcom changetype: add objectClass: domain objectClass: top dc: example o Step 4 : On the provider, we inject the following entries : dn: cn=3Dmodule{0},cn=3Dconfig changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - dn: olcOverlay=3Dsyncprov,olcDatabase=3D{1}mdb,cn=3Dconfig changetype: add objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncprovConfig olcOverlay: syncprov olcSpSessionLog: 10000 olcSpCheckpoint: 100 10 dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcLimits olcLimits: dn.exact=3D"cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dc= om" time.soft=3Dunlimited time.h ard=3Dunlimited size.soft=3Dunlimited size.hard=3Dunlimited - dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify replace: olcAccess olcAccess: {0}to dn.subtree=3D"dc=3Dexample,dc=3Dcom" by self write by = dn.exact=3D"cn=3D replicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom" read by anonymous auth = by * read - o Step 5 : On the consumer, we inject the following entry : dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcSyncrepl olcSyncrepl: rid=3D1 provider=3Dldap://10.61.155.18 bindmethod=3Dsimple b= i nddn=3D"cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom" credential= s=3Dsecret type=3DrefreshAndPersis t searchbase=3D"dc=3Dexample,dc=3Dcom" filter=3D"(objectclass=3D*)" scop= e=3Dsub schemacheck ing=3Don retry=3D"5 10 60 +" sizeLimit=3Dunlimited timelimit=3Dunlimited - At this point, one would expect the replication to kick on, and having th= e entries flowing from the producer to the consumer, but nothing happens. Ignoring the first step (ServerID setting), and applying the other steps,= just work fine. It seems that setting the ServerID blocks everything (FT= R, it does not help either to setup the consumer's ServerID). This is problematic in a scenario where we would try to make 2 servers be= ing replicated in a MMR typology with MirrorMode set, as the ServerID wi= l be mandatory. Here is the provider configuratio (this is in slapd.conf format for conve= nience, it is being converted to slapd.d before the server is started) : #########################################################################= ######## ## Provider configuration #########################################################################= ######### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include "/opt/symas/etc/openldap/schema/core.schema" include "/opt/symas/etc/openldap/schema/cosine.schema" include "/opt/symas/etc/openldap/schema/inetorgperson.schema" include "/opt/symas/etc/openldap/schema/misc.schema" # TLSCipherSuite <cipher-suite-spec> # Permits configuring what ciphers will be accepted and the # preference order. <cipher-suite-spec> should be a cipher # specification for the TLS library in use (OpenSSL, GnuTLS, or # Mozilla NSS). TLSCipherSuite HIGH:MEDIUM # Files in which to store the process id and startup arguments. # These files are needed by the init scripts, so only change # these if you are prepared to edit those scripts as well. pidfile "/var/symas/run/slapd.pid" argsfile "/var/symas/run/slapd.args" # Choose the directory for loadable modules. modulepath "/opt/symas/lib64/openldap" # Uncomment the moduleloads as needed to enable additional # functionalityi when configured. NOTE: We package many=20 # more modules options than those found below.=20 moduleload back_mdb.la moduleload back_monitor.la # Sample access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn=3D"" by * read access to * by self write by users read by anonymous auth #----------------------------------------------------------------------- # LOGGING loglevel stats sync ####################################################################### # config database ####################################################################### database config rootdn "cn=3DDirectory Manager,cn=3Dconfig" rootpw secret access to * by * none ####################################################################### # Sample LMDB database definitions ####################################################################### database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DDirectory Manager,dc=3Dexample,dc=3Dcom" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details describing # the creation of encrypted passwords. rootpw secret # Indices to maintain # index default sets the basic type of indexing to perform if there isn't= any indexing specified for a given attribute index default eq index objectClass index cn # The database directory MUST exist prior to running slapd AND=20 # should only be accessible by the slapd/tools. Mode 700 recommended. # One directory will be needed for each backend, so you should # create a subdirectory beneath /var/symas/openldap-data for each # new backend. This is also where the DB_CONFIG file needs to be # placed. directory "/var/symas/openldap-data/example" # Here we specify the maximum on-disk size of the database. It is=20 # Recommended to set this near the expected free-space availability # for the machine. This paramiter is not pre-allocated and simply=20 # represents the upward limit to which the database will be allowed # to grow. Note: Specified in *bytes*. Here, we set it to 1gb. maxsize 10485760 ####################################################################### # Monitor database ####################################################################### database monitor access to dn.subtree=3D"cn=3Dmonitor" by * read And here is the consumer configuration : #########################################################################= ######## ## Consumer configuration #########################################################################= ######### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include "/opt/symas/etc/openldap/schema/core.schema" include "/opt/symas/etc/openldap/schema/cosine.schema" include "/opt/symas/etc/openldap/schema/inetorgperson.schema" include "/opt/symas/etc/openldap/schema/misc.schema" # # TLSCipherSuite <cipher-suite-spec> # Permits configuring what ciphers will be accepted and the # preference order. <cipher-suite-spec> should be a cipher # specification for the TLS library in use (OpenSSL, GnuTLS, or # Mozilla NSS). TLSCipherSuite HIGH:MEDIUM # Files in which to store the process id and startup arguments. # These files are needed by the init scripts, so only change # these if you are prepared to edit those scripts as well. pidfile "/var/symas/run/slapd.pid" argsfile "/var/symas/run/slapd.args" # Choose the directory for loadable modules. modulepath "/opt/symas/lib64/openldap" # Uncomment the moduleloads as needed to enable additional # functionalityi when configured. NOTE: We package many # more modules options than those found below. moduleload back_mdb.la moduleload back_monitor.la # Sample access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn=3D"" by * read access to * by self write by users read by anonymous auth #----------------------------------------------------------------------- # LOGGING loglevel stats sync ####################################################################### # config database ####################################################################### database config rootdn "cn=3DDirectory Manager,cn=3Dconfig" rootpw secret access to * by * none ####################################################################### # Sample LMDB database definitions ####################################################################### database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DDirectory Manager,dc=3Dexample,dc=3Dcom" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details describing # the creation of encrypted passwords. rootpw secret # Indices to maintain # index default sets the basic type of indexing to perform if there isn't= any indexing specified for a given attribute index default eq index objectClass index cn # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. # One directory will be needed for each backend, so you should # create a subdirectory beneath /var/symas/openldap-data for each # new backend. This is also where the DB_CONFIG file needs to be # placed. directory "/var/symas/openldap-data/example" # Here we specify the maximum on-disk size of the database. It is # Recommended to set this near the expected free-space availability # for the machine. This paramiter is not pre-allocated and simply # represents the upward limit to which the database will be allowed # to grow. Note: Specified in *bytes*. Here, we set it to 1gb. maxsize 10485760 ####################################################################### # Monitor database ####################################################################### database monitor access to dn.subtree=3D"cn=3Dmonitor" by * read Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

1 0

(ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠apache.org 21 Oct '16

21 Oct '16

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.92.161.247) Replication won't start if we set it up on running servers configured with slapd.d. The scenario is the following : o We have 2 servers, one will become the provider, the other the consumer o They are initially empty%2ususing MDB (see the attached configurations, converted from slapd.conf to slapd.d) o We start the 2 servers o Step 1 : On the provider, we inject the following entry : dn: cn=config changetype: modify add: olcServerId olcServerId: 1 -

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 20 Oct '16

20 Oct '16

--001a114741aec1bad3053f481b06 Content-Type: text/plain; charset=UTF-8 On 20 October 2016 at 09:35, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > > Hmm. Nevermind, it's probably better to leave that to the user. > It gets ugly for a library to meddle with the current thread's > signals. I.e. it must check if SIGPIPE was already pending > before the call, and don't collect it on EPIPE in that case. > Yeah, I agree. Your changes LGTM. Interesting point re atomic int write, I wasn't entirely sure how mc_error could be accesses, so I decided to play it safe. -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com --001a114741aec1bad3053f481b06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On 20 October 2016 at 09:35, Hallvard Breien Furuseth <span dir=3D"ltr">&lt= ;<a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth= @usit.uio.no</a>></span> wrote:<blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hmm.=C2=A0 Nevermind, it's probably better to leave that to the user.<b= r> It gets ugly for a library to meddle with the current thread's<br> signals.=C2=A0 I.e. it must check if SIGPIPE was already pending<br> before the call, and don't collect it on EPIPE in that case.<span class= =3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquote></div><d= iv><br></div><div>Yeah, I agree. Your changes LGTM.</div><div><br></div><di= v>Interesting point re atomic int write, I wasn't entirely sure how mc_= error could be accesses, so I decided to play it safe.</div><div><br></div>= -- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Lo= renz Bauer =C2=A0| =C2=A0Systems Engineer<br>25 Lavington St., London SE1 0= NZ<br><br><a href=3D"http://www.cloudflare.com" target=3D"_blank">www.cloud= flare.com</a></div> </div></div> --001a114741aec1bad3053f481b06--

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by h.b.furuseth＠usit.uio.no 20 Oct '16

20 Oct '16

I wrote: > And.. duh, we've forgotten mdb_copy without MDB_CP_COMPACT. > I'll do it later if nobody beats me to it. Hmm. Nevermind, it's probably better to leave that to the user. It gets ugly for a library to meddle with the current thread's signals. I.e. it must check if SIGPIPE was already pending before the call, and don't collect it on EPIPE in that case. -- Hallvard

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by h.b.furuseth＠usit.uio.no 20 Oct '16

20 Oct '16

On 27/09/16 22:14, lmb(a)cloudflare.com wrote: >On 26 September 2016 at 20:48, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: >> I think we can skip sigwait() too since the thread will exit when done. >> (...) > > That's what my initial patch did. At least on OS X this leads to the > process receiving SIGPIPE and dying. OK. I've put a fixed version including that comment in branch "mdb/its8504-sigpipe" @ <git://git.uio.no/u/hbf/openldap.git>. We can squash the commits later: Never clear mc_error, we'd lose failure in the other thread. It's not mutex-protected, which is OK: If both threads set it, we'll get one of the errors. LMDB already expects atomic int. And.. duh, we've forgotten mdb_copy without MDB_CP_COMPACT. I'll do it later if nobody beats me to it. Test: Comment out SIGPIPE in mdb_copy.c, then run bash$ (sleep 1; ./mdb_copy testdb; echo exit $? >&2) | true exit 141 Exit values >= 128 are aborts from signals.

1 0

Re: (ITS#8520) Maximum number os entries
by quanah＠symas.com 18 Oct '16

18 Oct '16

--On Tuesday, October 18, 2016 6:41 PM +0000 teresarosado.net(a)gmail.com wrote: > Full_Name: Teresa Rosado > Version: 2015-11-15 > OS: Win Xp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.65.44.71) Hello, The ITS system is for reporting software bugs. Questions about the software and how it functions should be directed to the openldap technical list. Please see: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8520) Maximum number os entries
by teresarosado.net＠gmail.com 18 Oct '16

18 Oct '16

Full_Name: Teresa Rosado Version: 2015-11-15 OS: Win Xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.65.44.71) Dear Sirs, What is the maximum number of entries your OpenLDAP server can have on DB? What is the maximum number of entries your OpenLDAP server can return on ldapsearch command? BR Teresa

1 0

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by h.b.furuseth＠usit.uio.no 17 Oct '16

17 Oct '16

[Copied from IRC chat] The fix is wrong - this commit broke cursor tracking: 37081325f7356587c5e6 "ITS#8406 fix xcursors after cursor_del" Demo: mtest_rand -v -f700 -i3 -p0x1000 -r1276664687.3 It sets C_DEL on the wrong xcursor, one which is at a different key than the deleted key. Like this: put key1, data1 put[cursor] key2, data2 del key1, data1 Now [cursor].mx_cursor has C_DEL. This also breaks - probably the same bug: mtest_rand -v -c7 -f326 -p0x800 -r2712746413 -- Hallvard

1 0

Re: (ITS#8519) Mahesh
by quanah＠symas.com 17 Oct '16

17 Oct '16

--On Monday, October 17, 2016 2:17 PM +0000 maheshwar.reddy(a)secure-24.com wrote: > Full_Name: Maheshwar Reddy > Version: 2.4.4 > OS: CentOS 6.5 > URL: ftp://ftp.openldap.org/incoming/Mahesh The ITS system is for reporting bugs. Usage/help requests should be directed to the openldap-techincal(a)openldap.org mailing list. Please see <http://www.openldap.org/lists/> for more information. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs