openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7126) MDB_cursor.mc_top is used uninitialized
by h.b.furuseth＠usit.uio.no 13 Jan '12

13 Jan '12

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard test027-emptydn uses MDB_cursor.mc_top uninitialized. To force a crash, initialize it to 0xdead in mdb_cursor_init() or mdb_cursor_open(). Crash at line 4669: mdb_xcursor_init1(): mx->mx_db.md_pad = mc->mc_pg[mc->mc_top]->mp_pad; where mc_top is still 0xdead. Does not happen in 2.4.28.

1 0

(ITS#7125) Misplaced connection_done() calls
by h.b.furuseth＠usit.uio.no 13 Jan '12

13 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.26 - 2.4.28 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard Connection.c_mutex gets unlocked twice since since commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60 (Add strictrefresh syncrepl option): connection_done() is called inside connection_<first/next>() loops, but connection_next() does the same inlined. The functions should be used as: for (c=connection_first(...); c; c=connection_next(c,...)) {...} connection_done(c); though connection_done(c) is currently unnecessary when c==NULL. Fixing.

1 0

RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 12 Jan '12

12 Jan '12

Dear team, Could you please provide me the roadmap of OpenLDAP directory server for 2012? We are interested in finding out ¡€ Any new releases planning in 2012. If any, what are the new features? ¡€ Any plan to support Windows7, RHEL6.x and AIX 7.1? Thanks& Best regards, Henry -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2012Äê1ÔÂ12ÈÕ 20:22 To: Qingyun Zhu Subject: Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? *** 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#7124. 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#7124) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7124) 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=7124 Please remember to retain your issue tracking number (ITS#7124) 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.

1 0

(ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 12 Jan '12

12 Jan '12

Full_Name: Henry Zhu Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.138.101.62) Could you please provide me the roadmap of OpenLDAP directory server for 2012? We are interested in finding out ¡€ Any new releases planning in 2012. If any, what are the new features? ¡€ Any plan to support Windows7, RHEL6.x and AIX 7.1?

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 12 Jan '12

12 Jan '12

Howard Chu wrote: > ondrej.kuznik(a)acision.com wrote: >> On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: >>> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c >>> has an example of such overlay. To try it, initialize the overlay and >>> add these entries: >>> >>> dn: olcTestAttrOne=zero,$OVERLAY_DN >>> objectclass: olcTestOne >>> >>> dn: olcTestAttrTwo=one,$OVERLAY_DN >>> objectclass: olcTestTwo >>> >>> dn: olcTestAttrOne=two,$OVERLAY_DN >>> objectclass: olcTestOne >>> >>> dn: olcTestAttrTwo=three,$OVERLAY_DN >>> objectclass: olcTestTwo >>> >>> After a restart compare the output of slapcat -n0 with the output of >>> ldapsearch -b cn=config, you should see at least one different entry. >>> You might also try to modify the entries before and after the restart. >>> For those that do not match you get "no such object" as the dn is no >>> longer in the ldif database. >> >> The issue is in bconfig.c:4726, the code treats all siblings as part of >> one ordering (contrary to what >> http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html >> implies since cn=config seems to treat everything as X-ORDERED >> 'SIBLINGS'), while back-ldif orders them accordingly. >> Also its caller (config_ldif_resp) does not expect any reordering to be >> necessary, after all it should be (and is) reading a valid cn=config db, >> so the entry renaming then never gets propagated to back-ldif causing >> this desync. >> > This ITS still appears to me to be invalid. bconfig treats all siblings *of > the same type* as a single ordering. Your demonstration code is claiming your > entries are all of the same type, even though they aren't. I.e., all entries > in cn=config of a given type have only one distinguished naming attribute. You > have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config > doesn't distinguish them in its sort order. Additionally, you have hijacked the Cft_Overlay type for your custom entries, even though that type is reserved for actual overlay config entries. You should be using Cft_Misc for your custom entries. All of the other Cft_* types are reserved for all of the built in cn=config objectclasses. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 12 Jan '12

12 Jan '12

ondrej.kuznik(a)acision.com wrote: > On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c >> has an example of such overlay. To try it, initialize the overlay and >> add these entries: >> >> dn: olcTestAttrOne=zero,$OVERLAY_DN >> objectclass: olcTestOne >> >> dn: olcTestAttrTwo=one,$OVERLAY_DN >> objectclass: olcTestTwo >> >> dn: olcTestAttrOne=two,$OVERLAY_DN >> objectclass: olcTestOne >> >> dn: olcTestAttrTwo=three,$OVERLAY_DN >> objectclass: olcTestTwo >> >> After a restart compare the output of slapcat -n0 with the output of >> ldapsearch -b cn=config, you should see at least one different entry. >> You might also try to modify the entries before and after the restart. >> For those that do not match you get "no such object" as the dn is no >> longer in the ldif database. > > The issue is in bconfig.c:4726, the code treats all siblings as part of > one ordering (contrary to what > http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html > implies since cn=config seems to treat everything as X-ORDERED > 'SIBLINGS'), while back-ldif orders them accordingly. > Also its caller (config_ldif_resp) does not expect any reordering to be > necessary, after all it should be (and is) reading a valid cn=config db, > so the entry renaming then never gets propagated to back-ldif causing > this desync. > This ITS still appears to me to be invalid. bconfig treats all siblings *of the same type* as a single ordering. Your demonstration code is claiming your entries are all of the same type, even though they aren't. I.e., all entries in cn=config of a given type have only one distinguished naming attribute. You have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config doesn't distinguish them in its sort order. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by thomas＠koeller.dyndns.org 10 Jan '12

10 Jan '12

On Tuesday 10 January 2012 09:56:02 Pierangelo Masarati wrote: > > Now, if ldapdb is incompatible with slapd at a fundamental level, and > > causes problems when loaded, I think not to load it is the right thing > > to do, and this is what my patch does. > > An alternative solution consists in creating a specific folder > containing plugins one wants to load, and start slapd with SASL_PATH set > to point to that folder. This allows fine tuning of what to load > without modifying a single line of code. That is certainly true, however, it misses the point I am trying to make. I want to provide a fix for the problem I encountered. >From a user's perspective, it is certainly preferable for the whole thing to 'just work', instead of being provided with instructions about how to configure one's system to avoid problems that arise when using the standard configuration. This places the burden on the user, for no other gain than being able to load a module that cannot be used anyway. With the change I proposed, slapd can work with every standard cyrus-sasl installation right away, no special configuration required, and the problem is solved once and forever. Thomas

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by masarati＠aero.polimi.it 10 Jan '12

10 Jan '12

On 01/10/2012 12:32 AM, thomas(a)koeller.dyndns.org wrote: > On Monday 02 January 2012 19:22:28 masarati(a)aero.polimi.it wrote: > >> I note that Cyrus SASL already provides built-in ways to select what >> plugins must be loaded (e.g. auxprop_plugin, although I'm not an expert of >> Cyrus SASL configuration, so I suggest you carefully read the >> documentation). >> >> p. > > You are probably referring to this paragraph (quotation from > 'cyrus-sasl-2.1.25/doc/options.html'), regarding the > use of the ldapdb plugin: > >> This plugin is not for use with slapd itself. When OpenLDAP is built with >> SASL support, slapd uses its own internal auxprop and canonuser module. By >> default, without configuring anything else, slapd will fail to load the >> ldapdb module when it's present. This is as it should be. If you don't like >> the "auxpropfunc: error -7" message that is sent to syslog by slapd, you can >> stop it by creating /usr/lib/sasl2/slapd.conf with: >> >> auxprop_plugin: slapd >> >> which will force the SASL library to ignore all other auxprop modules. > > When I was debugging the problem I described, I found that the measure > described above did not stop ldapdb from being loaded. It only seems to > avoid _use_ of the ldapdb plugin, which is still loaded along with all > other plugins present, and that was what caused the problem. > > Now, if ldapdb is incompatible with slapd at a fundamental level, and > causes problems when loaded, I think not to load it is the right thing > to do, and this is what my patch does. An alternative solution consists in creating a specific folder containing plugins one wants to load, and start slapd with SASL_PATH set to point to that folder. This allows fine tuning of what to *load* without modifying a single line of code. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by thomas＠koeller.dyndns.org 09 Jan '12

09 Jan '12

On Monday 02 January 2012 19:22:28 masarati(a)aero.polimi.it wrote: > I note that Cyrus SASL already provides built-in ways to select what > plugins must be loaded (e.g. auxprop_plugin, although I'm not an expert of > Cyrus SASL configuration, so I suggest you carefully read the > documentation). > > p. You are probably referring to this paragraph (quotation from 'cyrus-sasl-2.1.25/doc/options.html'), regarding the use of the ldapdb plugin: > This plugin is not for use with slapd itself. When OpenLDAP is built with > SASL support, slapd uses its own internal auxprop and canonuser module. By > default, without configuring anything else, slapd will fail to load the > ldapdb module when it's present. This is as it should be. If you don't like > the "auxpropfunc: error -7" message that is sent to syslog by slapd, you can > stop it by creating /usr/lib/sasl2/slapd.conf with: > > auxprop_plugin: slapd > > which will force the SASL library to ignore all other auxprop modules. When I was debugging the problem I described, I found that the measure described above did not stop ldapdb from being loaded. It only seems to avoid _use_ of the ldapdb plugin, which is still loaded along with all other plugins present, and that was what caused the problem. Now, if ldapdb is incompatible with slapd at a fundamental level, and causes problems when loaded, I think not to load it is the right thing to do, and this is what my patch does. Thomas

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by ghenry＠OpenLDAP.org 06 Jan '12

06 Jan '12

Thanks, will do! ----- Original Message ----- > It was getting on my nerves and I had to spend a lot of time > to clear up the situation. Being a beginner in both areas > Debian Distribution and OpenLDAP-Server I entered the docs > via Quick Start and immediately stuck headover in the mud > of outdated and inconsistent docs / references.. > > Please add at least a note about the new configuration > method and a link to the explaining wiki page > http://www.openldap.org/doc/admin24/slapdconf2.html > > in Quick-Start: > http://www.openldap.org/doc/admin24/quickstart.html > > As you link to http://www.openldap.org/doc/admin24/slapdconfig.html > from there in section 8 about Configuration you should > also add a note and link there or even better add an own section > about the dynamic configuration method in Quick-Start. > > Thanks in advance and cheers > > Gabriele > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

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