openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 25 Jan '07

25 Jan '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> hyc(a)OpenLDAP.org wrote: >> >> >>> I presume there's some kind of callback for registering new suffixes >>> but I >>> haven't looked very hard. >>> >> >> This highlights some other issues lurking in here - back-monitor >> basically doesn't deal with dynamic configuration well at all. It >> assumes that all databases and overlays have been fully configured by >> the time it starts - an assumption that was valid for old-style >> slapd.conf use, but not with back-config. >> >> The monitor_subsys_database_init_one() function probably needs to be >> split into separate pieces so that database and overlay info can be >> set up and removed incrementally. >> > The point is that back-monitor has no clean means to detect what > database is serving what naming context, since it was designed way ahead > of back-config. So when time came to introduce monitor customization, > the best mechanism I could find was the extended filter on the naming > context. This is really creating trouble. The best solution would be to > re-design back-monitor so that the database section mimics back-config > using X-ORDERED 'SIBLING' style (and is updated accordingly, especially > when entry renaming will be supported by back-config). > > The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get > rid of those "cn=Database X", "cn=Overlay Y" stuff and so. One approach would be to add a pointer to the backend struct that points to its cn=config entry. Then back-monitor can simply pull the DN from there and strip the cn=config suffix. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4805) memory leak in syncrepl code
by hyc＠symas.com 25 Jan '07

25 Jan '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There seems to be few memory leaks in syncrepl code (detected by valgrind when > running test048); one is when parsing an entry and sync "present" or "done". > It's now fixed in HEAD/re23. Others are being investigated I've plugged everything that I saw in test048 in HEAD. As you can tell by the number of commits, there were several loose ends to chase down. Not sure how many are directly relevant to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 24 Jan '07

24 Jan '07

dieter(a)dkluenter.de wrote: > Hi, > this is my test setup OK. This was a bug in back-bdb/id2entry.c, syncprov is fine. Fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think > I understand part of the problem. > > The particular entry was modified after the current refresh session began, so > that entry is omitted from the current refresh results. Since the entry is > actually missing from the refresh data, the consumer treats it as deleted. > Since the entry has children, it cannot actually be deleted, so it gets > turned into a glue entry. > > So there's two issues - the provider should still send the UUID of the entry, > so that the consumer doesn't consider it deleted. But also, this problem > ought to have self-corrected. Once the replication transitioned from Refresh > to Persist phase, the modified entry should have been sent to the consumer, > and the glue entry should have been replaced by the correct data. > > Looks like both problems are in the syncprov overlay. syncprov.c is now patched in HEAD to always send the UUIDs of the present entries. That appears to prevent the problem from arising. It's a bit difficult to automate a test for this because it requires such exact timing; a modification must occur on the provider while the consumer is just beginning its refresh search. Currently I can only test this by inserting a Debug message and a sleep() in the provider to indicate that the consumer is connected, and to give time to issue a modification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by ando＠sys-net.it 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > wells_robert_frank(a)yahoo.com wrote: >> --0-2146048140-1169674999=:43135 >> Content-Type: text/plain; charset=iso-8859-1 >> Content-Transfer-Encoding: 8bit >> >> Apologies - >> >> This did in fact work. I had not been aware of the backend DB functionality. > > Apparently few people are, since most other LDAP servers don't support this > part of the LDAP specification. Although he claimed he needed subtree rename, in his example all was needed was just plain rename, which has been supported by OpenLDAP since ever (when LDAPv3 introduced rename, i.e. modrdn with new rdn). p.

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Allan E. Johannesen wrote: >>>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: >> hyc> Since you mention that this occurs more often in 2.3.33 than in "previous >> hyc> releases" - what previous version are you comparing to? >> >> Well, I should have said I've never seen it before. I've generally been >> running the new releases within a day of release, and I rebuild the data at >> each release, so everything starts clean. Therefore, it _may_ have existed >> previously, but never showed up in the days during which the given releases >> ran. >> >> I guess I only mentioned that since someone saw it several releases ago in a >> different ITS. I never saw it before. >> In 2.3.33, it happened right after loading the data. I thought I did it wrong, >> so I loaded things again and it was fine. After some days, though, it (meaning >> the change to "objectClass: glue") happened again. > > The only change to syncrepl between 2.3.32 and .33 was one or two debug > messages, no functional changes. In 2.3.32 there was no change to syncrepl at > all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only > change in 2.3.31 was also in debug messages, not functional changes. So as > unlikely as it seems, at the moment this appears to be a coincidence and the > bug must be older. > > If you see this happening repeatedly, turn on the sync debug level and > capture that output for a while. When you notice the problem, you should also > see some number of "syncrepl_del_nonpresent" messages in the log. We'll > probably need to see a large chunk of the log to be able to follow the > sequence of events. Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think I understand part of the problem. The particular entry was modified after the current refresh session began, so that entry is omitted from the current refresh results. Since the entry is actually missing from the refresh data, the consumer treats it as deleted. Since the entry has children, it cannot actually be deleted, so it gets turned into a glue entry. So there's two issues - the provider should still send the UUID of the entry, so that the consumer doesn't consider it deleted. But also, this problem ought to have self-corrected. Once the replication transitioned from Refresh to Persist phase, the modified entry should have been sent to the consumer, and the glue entry should have been replaced by the correct data. Looks like both problems are in the syncprov overlay. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

Allan E. Johannesen wrote: >>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: > > hyc> Since you mention that this occurs more often in 2.3.33 than in "previous > hyc> releases" - what previous version are you comparing to? > > Well, I should have said I've never seen it before. I've generally been > running the new releases within a day of release, and I rebuild the data at > each release, so everything starts clean. Therefore, it _may_ have existed > previously, but never showed up in the days during which the given releases > ran. > > I guess I only mentioned that since someone saw it several releases ago in a > different ITS. I never saw it before. > > These are the build times of the past few releases: > > drwxrwxr-x 10 imphss 2000 4096 Dec 19 08:57 .snapshot/weekly.0/openldap-2.3.31/ > drwxrwxr-x 10 imphss 2000 4096 Jan 7 10:33 .snapshot/weekly.0/openldap-2.3.32/ > drwxrwx--- 10 aej 101 4096 Jan 18 14:29 .snapshot/weekly.0/openldap-2.3.33/ > > In 2.3.33, it happened right after loading the data. I thought I did it wrong, > so I loaded things again and it was fine. After some days, though, it (meaning > the change to "objectClass: glue") happened again. The only change to syncrepl between 2.3.32 and .33 was one or two debug messages, no functional changes. In 2.3.32 there was no change to syncrepl at all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only change in 2.3.31 was also in debug messages, not functional changes. So as unlikely as it seems, at the moment this appears to be a coincidence and the bug must be older. If you see this happening repeatedly, turn on the sync debug level and capture that output for a while. When you notice the problem, you should also see some number of "syncrepl_del_nonpresent" messages in the log. We'll probably need to see a large chunk of the log to be able to follow the sequence of events. > > hyc> Please provide the relevant section of your slave slapd.conf - the > hyc> database clause and its syncrepl statement at least. Are there any ACLs on > hyc> the provider that would prevent the slave from seeing parts of the > hyc> affected entries? > > In the client: > > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > > # limits for different users > > limits dn=wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU size=unlimited time=unlimited > limits dn=cn=application,ou=access,dc=wpi,dc=edu size=unlimited time=unlimited > limits dn="cn=pam,ou=access,dc=wpi,dc=edu" size=unlimited time=unlimited > limits users size=200 time=10 > limits anonymous size=20 time=1 > > directory /var/openldap-data > > # replication > > syncrepl rid=1 provider=ldap://ldapv2.wpi.edu type=refreshAndPersist retry="60 +" > searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl saslmech=gssapi > > > > Its keytab is k5start'd as ldap-manager, this is from the provider: > > > > sasl-regexp uid=ldap-manager/.*,cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=access,dc=WPI,dc=EDU??one?(cn=manager) > sasl-regexp uid=(.*),cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=people,dc=WPI,dc=EDU??one?(uid=$1) > > ####################################################################### > # bdb database definitions > ####################################################################### > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by hyc＠symas.com 24 Jan '07

24 Jan '07

wells_robert_frank(a)yahoo.com wrote: > --0-2146048140-1169674999=:43135 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > Apologies - > > This did in fact work. I had not been aware of the backend DB functionality. Apparently few people are, since most other LDAP servers don't support this part of the LDAP specification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by hyc＠symas.com 24 Jan '07

24 Jan '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.28 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in > cn=config Thanks for the report. The libldap function to retrieve this option was actually missing. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by erici＠motown.cc.utexas.edu 24 Jan '07

24 Jan '07

Full_Name: Eric Irrgang Version: 2.3.28 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in cn=config

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