openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(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

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

17 May '19

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) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use. By the way, please help close ITS#8986 as this version is a resend of the patch.

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--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>

1 0

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

17 May '19

--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, I am not very familiar with gdb. Can you help me doing that? ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 16:58:59 =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 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --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_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ 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">I am not very familiar with gdb. = Can you help me doing that?<br> </p> <strong><span style=3D"font-family:"Arial","sans-serif"= ; color:#0098CC"></span></strong> <div id=3D"Signature"></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 16:58:59<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 3:50 PM +0000 jpayan= ides(a)prosodie.com wrote:<br> <br> > Full_Name: JPh Ayanides<br> > Version: 2.4.47<br> > OS: Linux Debian<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a><br> > Submission from: (NULL) (195.46.216.78)<br> ><br> ><br> > Hello, I cannot succeed in making the following configuration to work.= <br> > Instead of that, openldap crashes.<br> ><br> > I have 2 openldap servers in master-slave: the slave is installed on a= <br> > machine named rada, and a master is installed on another machine named= <br> > simby. The ppolicy is activated on rada and simby, and I use chain and= <br> > updateref in order to sync failures in ppolicy coming from rada back t= o<br> > simby. When I test that feature, with trying a bind with a wrong<br> > password,  openldap on the slave crashes. I failed in understandi= ng why,<br> > even with gdb.<br> <br> Ensure you have debugging symbols installed, and provide a full backtrace <= br> of all threads from gdb.<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_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_--

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