openldap-bugs May 2019

openldap-bugs@openldap.org

19 participants
51 discussions

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 09:11:21AM +0000, jpayanides(a)prosodie.com wrote: > Hello Quanah, > > what I have done: > > > /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= > :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= > ps aux | grep ldap > > gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 > > (gdb) set logging on > (gdb) thread apply all bt full > (gdb) cont > <crashing operation> > > Here is the dump. > > Seems to crash when returning from libpthread Hi Jean-Philippe, the backtrace you recorded was during normal operation, you need to do the opposite, continue to let the program crash, with gdb intercepting that. Then you can use 'thread apply all bt full' to inspect the state of slapd at the point it crashed, so what should you do: > (gdb) cont > <crashing operation> > (gdb) thread apply all bt full Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: multipart/alternative; boundary="_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_" --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, what I have done: /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= ps aux | grep ldap gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 (gdb) set logging on (gdb) thread apply all bt full (gdb) cont <crashing operation> Here is the dump. Seems to crash when returning from libpthread -- Jean-Philippe ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 17:30:42 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : RE: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">what I have done:</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0"></p> <div>/var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390= ldaps://*:637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u= root -g root ; ps aux | grep ldap<br> </div> <div> <div><br> </div> <div>gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684<br> <br> </div> (gdb) set logging on</div> <div>(gdb) thread apply all bt full</div> <div>(gdb) cont</div> <div><crashing operation><br> </div> <br> <p></p> <p style=3D"margin-top:0;margin-bottom:0">Here is the dump.</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0">Seems to crash when returning fro= m libpthread<br> </p> <p style=3D"margin-top:0;margin-bottom:0">--</p> <p style=3D"margin-top:0;margin-bottom:0">Jean-Philippe<br> </p> <div id=3D"Signature"> <meta content=3D"text/html; charset=3DUTF-8"> </div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 17:30:42<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> RE: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 4:09 PM +0000 "= AYANIDES, JEAN-PHILIPPE" <br> <jpayanides(a)prosodie.com> wrote:<br> <br> ><br> ><br> > Hello Quanah,<br> ><br> > I am not very familiar with gdb. Can you help me doing that?<br> <br> <br> Start slapd on the server that's crashing<br> Get the process ID of slapd<br> <br> gdb /path/to/slapd PID<br> <br> For example, if slapd is located in /usr/sbin, and the process ID is 1234:<= br> <br> gdb /usr/sbin/slapd 1234<br> <br> At the (gdb) prompt, enter the command "cont" to continue executi= on<br> <br> Run your operation that causes slapd to crash.  This should drop you b= ack <br> to the (gdb) prompt.<br> <br> Then run the command:<br> <br> thr apply all bt full<br> <br> This will provide the full backtrace.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_-- --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; name="gdb.txt" Content-Description: gdb.txt Content-Disposition: attachment; filename="gdb.txt"; size=2695; creation-date="Mon, 20 May 2019 09:10:06 GMT"; modification-date="Mon, 20 May 2019 09:10:06 GMT" Content-Transfer-Encoding: base64 ClRocmVhZCAzIChUaHJlYWQgLTEyMjc2OTkyODAgKExXUCAxNTY4NykpOgojMCAgMHhiN2M4ODY3 OSBpbiBlcG9sbF93YWl0ICgpIGZyb20gL2xpYi90bHMvbGliYy5zby42Ck5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzEgIDB4MDgwNzljYmQgaW4gc2xhcGRfZGFlbW9uX3Rhc2sgKHB0 cj0weDApIGF0IGRhZW1vbi5jOjI1MzkKICAgICAgICBhY3RpdmUgPSAwCiAgICAgICAgbCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGxhc3RfaWRsZV9jaGVjayA9IDE1NTgzNDMwMzgK ICAgICAgICBlYmFkZiA9IDAKIzIgIDB4YjdjZjQwYmQgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20g L2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzMgIDB4YjdjODgwMWUgaW4gY2xvbmUgKCkgZnJvbSAvbGliL3Rscy9saWJjLnNvLjYKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoKVGhyZWFkIDIgKFRocmVhZCAtMTIzMTg5MzU4NCAo TFdQIDE1Njg4KSk6CiMwICAweGI3Y2Y2YzAxIGluIHB0aHJlYWRfY29uZF93YWl0QEBHTElCQ18y LjMuMiAoKSBmcm9tIC9saWIvdGxzL2xpYnB0aHJlYWQuc28uMApObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMxICAweDA4MTc4ZGNmIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBw ZXIgKHhwb29sPTB4ODJhOWMzMCkgYXQgdHBvb2wuYzo2ODMKICAgICAgICB0YXNrID0gKGxkYXBf aW50X3RocmVhZF90YXNrX3QgKikgMHgwCiAgICAgICAgd29ya19saXN0ID0gKGxkYXBfaW50X3Rw b29sX3BsaXN0X3QgKikgMHgxCiAgICAgICAgY3R4ID0ge2x0dV9pZCA9IDMwNjMwNzM3MTIsIGx0 dV9rZXkgPSB7e2x0a19rZXkgPSAweDgwZDM3ZjAsIGx0a19kYXRhID0gMHg4MzViNGQwLAogICAg ICBsdGtfZnJlZSA9IDB4ODBkMzgyMCA8c2xhcF9zbF9tZW1fZGVzdHJveT59LCB7bHRrX2tleSA9 IDB4ODMzZmE4OCwgbHRrX2RhdGEgPSAweDgzNjZkNTAsCiAgICAgIGx0a19mcmVlID0gMHg4MTMz OGQwIDxiZGJfcmVhZGVyX2ZyZWU+fSwge2x0a19rZXkgPSAweDAsIGx0a19kYXRhID0gMHgwLAog ICAgICBsdGtfZnJlZSA9IDB9IDxyZXBlYXRzIDMwIHRpbWVzPn19CiAgICAgICAga2N0eCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGtleXNsb3QgPSAxMzEKICAgICAgICBoYXNoID0g PHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJsZGFw X2ludF90aHJlYWRfcG9vbF93cmFwcGVyIgojMiAgMHhiN2NmNDBiZCBpbiBzdGFydF90aHJlYWQg KCkgZnJvbSAvbGliL3Rscy9saWJwdGhyZWFkLnNvLjAKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMyAgMHhiN2M4ODAxZSBpbiBjbG9uZSAoKSBmcm9tIC9saWIvdGxzL2xpYmMuc28u NgpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCgpUaHJlYWQgMSAoVGhyZWFkIC0xMjEy NTE2MTI4IChMV1AgMTU2ODQpKToKIzAgIDB4YjdjZjUxODMgaW4gcHRocmVhZF9qb2luICgpIGZy b20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzEgIDB4MDgwNzZmMWEgaW4gc2xhcGRfZGFlbW9uICgpIGF0IGRhZW1vbi5jOjI5MzIKICAg ICAgICBpID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgcmMgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KIzIgIDB4MDgwNjI5NTcgaW4gbWFpbiAoYXJnYz0xMSwgYXJndj0weGJmODA3NDI0 KSBhdCBtYWluLmM6MTAxNwogICAgICAgIGkgPSAxMQogICAgICAgIG5vX2RldGFjaCA9IDAKICAg ICAgICByYyA9IDAKICAgICAgICB1cmxzID0gMHg4MjgwMDA4ICJsZGFwOi8vKjozOTAgbGRhcHM6 Ly8qOjYzNyIKICAgICAgICB1c2VybmFtZSA9IDB4ODI4MDA1OCAicm9vdCIKICAgICAgICBncm91 cG5hbWUgPSAweDgyODAwNjggImxkYXAiCiAgICAgICAgc2FuZGJveCA9IDB4MAogICAgICAgIHN5 c2xvZ1VzZXIgPSAxNjgKICAgICAgICBwaWQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4KICAgICAg ICB3YWl0ZmRzID0gezExLCAxMn0KICAgICAgICBjb25maWdmaWxlID0gMHg4MjgwMDI4ICIvYXBw bGkvb3BlbmxkYXAtcHJlcHJvZC9ldGMvc2xhcGQuY29uZiIKICAgICAgICBjb25maWdkaXIgPSAw eDAKICAgICAgICBzZXJ2ZXJOYW1lID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2Nw ID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2NwX2VudHJ5ID0gPHZhbHVlIG9wdGlt aXplZCBvdXQ+CiAgICAgICAgZGVidWdfdW5rbm93bnMgPSAoY2hhciAqKikgMHgwCiAgICAgICAg c3lzbG9nX3Vua25vd25zID0gKGNoYXIgKiopIDB4MAogICAgICAgIGwgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KICAgICAgICBzbGFwZF9waWRfZmlsZV91bmxpbmsgPSAxCiAgICAgICAgc2xhcGRf YXJnc19maWxlX3VubGluayA9IDEKICAgICAgICBmaXJzdG9wdCA9IDx2YWx1ZSBvcHRpbWl6ZWQg b3V0PgogICAgICAgIF9fUFJFVFRZX0ZVTkNUSU9OX18gPSAibWFpbiIKIzAgIDB4YjdjZjUxODMg aW4gcHRocmVhZF9qb2luICgpIGZyb20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCkNvbnRpbnVp bmcuCltOZXcgVGhyZWFkIC0xMjM3MTQwNTYwIChMV1AgMTY4NzYpXQoKUHJvZ3JhbSBleGl0ZWQg d2l0aCBjb2RlIDAxNzcuCg== --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_--

1 0

Re: (ITS#9026) slapd
by ryan＠nardis.ca 20 May '19

20 May '19

Hello, On Mon, May 20, 2019 at 03:38:49AM +0000, vkelkar(a)ucsd.edu wrote: >Version: 2.4.47 >OS: ubuntu This ITS tracks issues about OpenLDAP software itself. It sounds like your issue relates to the Ubuntu slapd package. In that case it should be reported in the Ubuntu tracker (Launchpad), or to Canonical support. In any case, your message did not really include enough information to diagnose your issue. When you report the issue elsewhere, please include the complete terminal output from the apt-get or dpkg command you ran, and the exact version of the slapd package (can be obtained from e.g. 'dpkg-query -W slapd'). I will close this ITS for now. It can be reopened if the issue actually turns out to be a problem with OpenLDAP software. Thanks Ryan

1 0

(ITS#9026) slapd
by vkelkar＠ucsd.edu 19 May '19

19 May '19

Full_Name: Vikram Kelkar Version: 2.4.47 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.110.67.70) We are having issues uninstalling slapd. We did apt-get install slapd and are trying to remove the package but for some reason it cannot. We tried remove, purge, and even went to the dpkg and removed slapd from there. The issue is we are running an iRedMail script and it will not let us run it because it says Error processing package slapd, exit status(1).

1 0

Re: (ITS#9025) Suggested enhancement: Automatically order module loading according to dependencies
by quanah＠symas.com 18 May '19

18 May '19

--On Saturday, May 18, 2019 9:48 AM +0000 james(a)turnersoft.co.uk wrote: > Full_Name: James Turner > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.86.27.193) > > > As OpenLDAP 2.4, system administrators have to make sure that they > configure the correct order in which modules are loaded during sever > startup. (e.g. load "back_monitor" last, "auditlog" typically second from > last). Configuring this order incorrectly often prevents the server from > starting up, or modules from functioning as expected. I've never encountered a situation where the order in which moduleload executes matters. Can you please provide an example configuration exhibiting problematic behavior based on moduleload order? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9025) Suggested enhancement: Automatically order module loading according to dependencies
by james＠turnersoft.co.uk 18 May '19

18 May '19

Full_Name: James Turner Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.86.27.193) As OpenLDAP 2.4, system administrators have to make sure that they configure the correct order in which modules are loaded during sever startup. (e.g. load "back_monitor" last, "auditlog" typically second from last). Configuring this order incorrectly often prevents the server from starting up, or modules from functioning as expected. Is it feasible for a future version of OpenLDAP to determine the correct module loading order automatically (e.g. using dependency metadata for each module) so that everything "just works" without the sysadmin having to figure it out by hand? Step 1: Parse all the olcModuleList objects under cn=config to obtain a complete set of {path,module name} tuples. Step 2: Topologically sort the list based on known dependencies between the modules. Step 3: Load the modules in the correctly sorted order. In terms of design, this arguably strengthens the conceptual model that the objects under cn=config declare the OpenLDAP configuration which can be modified as the system runs, rather than an imperative sequence of actions to carry out at startup.

1 0

Re: (ITS#8060) mdb_from_db (bdb import)
by quanah＠symas.com 17 May '19

17 May '19

--On Tuesday, February 17, 2015 5:07 PM +0000 graehl(a)gmail.com wrote: > Full_Name: Jonathan Graehl > Version: n/a > OS: n/a > URL: > ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch > Submission from: (NULL) (104.174.227.200) > > > (see 0001-mdb_from_db-new-options-bugfix.patch) > > mdb_from_db utility for direct import from Berkeley DB to mdb > > Apparently this can only be distributed in binary form using older > berkeley db versions, but building the utility from source for bulk > import should be fine. Hello, This submission is missing a required IPR, as noted at <https://www.openldap.org/devel/contributing.html#notice> An IPR is necessary to consider this work. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 5:30 PM +0000 khng300(a)gmail.com wrote: > Bump. I've added this to the review list. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Bump. Ka Ho

1 0

Re: (ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 5:02 PM +0000 khng300(a)gmail.com wrote: > Full_Name: Ka Ho Ng > Version: mdb.master > OS: FreeBSD 12.0-RELEASE > URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch > Submission from: (NULL) (2001:470:fa95:1300::3) > > By the way, please help close ITS#8986 as this version is a resend of the > patch. The correct path is to follow up to your original ITS, not submit a new one. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2019