openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com 11 Aug '07

11 Aug '07

<quote who="Pierangelo Masarati"> > Gavin Henry wrote: > >> OK, thanks. Do you have any reference for custom monitoring examples? > > Not sure what you mean. By "custom monitoring" I mean that pieces of > code may register callbacks in back-monitor to enrich the monitor > entries with dynamically generated data. Right now, the only code that > exploits this functionality is back-bdb/back-hdb, but it's something we > use intensively for custom modules we develop (the monitor database can > be proficiently used as an interface for non-persistent interaction with > the DSA). Ah, right. Sorry, I misunderstood custom as something done via configuration in the front end, not via callbacks. > > With reference to code, see servers/slapd/back-bdb/monitor.c (the API is > implemented in servers/slapd-back-monitor/init.c). Will do, sounds very useful indeed. > > What back-bdb/hdb publishes by means of this API is not documented, > AFAIK; it might be worth mentioning somewhere in the docs, as this > monitoring could be quite useful for tuning. Nothing that cannot be > accessed thru db_stat, the advantage is access via LDAP protocol. Exactly, sounds very useful and one that I can investigate and document in the Monitoring section, with implementation examples (not code) in the Tuning and Maintenance sections of our guide. > > A recent addition was the capability to monitor what unindexed > attributes were used in searches. Yeah, I commented on that previously. Nice. Gavin. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Gavin Henry wrote: > OK, thanks. Do you have any reference for custom monitoring examples? Not sure what you mean. By "custom monitoring" I mean that pieces of code may register callbacks in back-monitor to enrich the monitor entries with dynamically generated data. Right now, the only code that exploits this functionality is back-bdb/back-hdb, but it's something we use intensively for custom modules we develop (the monitor database can be proficiently used as an interface for non-persistent interaction with the DSA). With reference to code, see servers/slapd/back-bdb/monitor.c (the API is implemented in servers/slapd-back-monitor/init.c). What back-bdb/hdb publishes by means of this API is not documented, AFAIK; it might be worth mentioning somewhere in the docs, as this monitoring could be quite useful for tuning. Nothing that cannot be accessed thru db_stat, the advantage is access via LDAP protocol. A recent addition was the capability to monitor what unindexed attributes were used in searches. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com 11 Aug '07

11 Aug '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Ok. What can the rootdn do on the monitor database then? Write to >> anything? >> I can update the "Monitoring" section with this info then ;-) > > As usual, the privilege of the rootdn consists in bypassing ACLs. In > this case, you just need the rootdn, it doesn't need to be able to bind > (i.e. no rootpw and no fancy SASL rules to map someone with that > identity), since it will only be used for internal purposes, namely to > look up where bdb custom monitoring will be placed. OK, thanks. Do you have any reference for custom monitoring examples? Gavin. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

ITS#4211
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Quanah, for which is which, HEAD now has back-config support for both slapo-rwm and slapd-relay. You may resume your configuration replication experiments... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by ando＠sys-net.it 11 Aug '07

11 Aug '07

ghenry(a)suretecsystems.com wrote: > Ok. What can the rootdn do on the monitor database then? Write to anything? > I can update the "Monitoring" section with this info then ;-) As usual, the privilege of the rootdn consists in bypassing ACLs. In this case, you just need the rootdn, it doesn't need to be able to bind (i.e. no rootpw and no fancy SASL rules to map someone with that identity), since it will only be used for internal purposes, namely to look up where bdb custom monitoring will be placed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5088) ObjectClass inheritance check in back-sql
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When extra objectClasses for an entry are listed in table ldap_entry_objclasses, if any of them is structural and derived from the objectClass used to map the RDBMS data to LDAP, the entry is now rejected because the computed objectClass does not match the objectClass used to map data, although the entry would be perfectly valid from an LDAP standpoint. This is now fixed in HEAD/re23. p.

1 0

(ITS#5087) slapacl is broken for back-hdb
by hyc＠OpenLDAP.org 10 Aug '07

10 Aug '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The tool_id2entry_get function neglects the fix_dn step for hdb, so every retrieved entry has a zero-length DN. A patch to HEAD is coming. Really there should never have been such a function, tool_entry_get should have been used for this purpose.

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 10 Aug '07

10 Aug '07

On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: > donn(a)u.washington.edu wrote: >> Full_Name: Donn Cave >> Version: 2.4.4 >> OS: Red Hat Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.95.135.150) >> In "while" loop at 2656, I find old->a_vals are like [..., a, >> b, ...] and >> new->a_vals are like [..., b, a, ...]. >> Matches are found at old [i] == new [k = j+1] and old [k = i+1] == >> new [j], but >> this just shows that neither an add nor a delete is called for, >> and the loop end >> is reached without having incremented i or j. >> Actual attribute values I'm looking at right now in the debugger are >> eduPersonAffiliation: old [ member, alum, employee, faculty ], >> new [ member, >> alum, faculty, employee ]. I built the replica from a slapcat >> dump on the idle >> master, started the slapd syncrepl client and applied a lot of normal >> modifications to the master, until it hit the infinite loop. It >> has been a >> recurrent problem. > > Now fixed in HEAD, please test. Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify (20) Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify failed (20) I could put some more research into this, but tell me if this doesn't make sense. Suppose this mysteriously swapped order: a,b,... b,a,... Your fix increments the first list's index, so next iteration it's b,... b,a,... which is fine, but next iteration is ... a,... "a" looks new at this point, and I try to add it, but it isn't new - we just forgot that it was in "old" - and I get error 0x14 (LDAP_TYPE_OR_VALUES_EXISTS) Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > On Aug 10, 2007, at 1:53 PM, Howard Chu wrote: >> You didn't mention how your syncrepl is configured but it seems >> that this can only occur for refreshAndPersist mode, with old >> entries being ldapadd'd to the running master. > > It is indeed refreshAndPersist ... > >> In fact, since entryCSN is NO-USER-MODIFICATION it shouldn't even >> be possible to add entries this way to a running server. Before we >> can "catch the problem in the master" we need more information on >> how the problem was caused. > > The master server had updatedn defined to itself. Changes, logged from > another server, were applied with ldapmodify. "Don't do this" ... You're essentially creating the same inconsistency that a naive multimaster setup introduces. Since 2.4.4 has real multimaster support, you should not be doing things this way. Note that a proper configuration works with either refreshOnly or refreshAndPersist mode, and cascaded to an arbitrary depth. Your current setup only works with refreshAndPersist, and cannot be cascaded reliably. I.e. your setup is inherently broken. -- -- Howard Chu Chief Architect, 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#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: Red Hat Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > In "while" loop at 2656, I find old->a_vals are like [..., a, b, ...] and > new->a_vals are like [..., b, a, ...]. > > Matches are found at old [i] == new [k = j+1] and old [k = i+1] == new [j], but > this just shows that neither an add nor a delete is called for, and the loop end > is reached without having incremented i or j. > > Actual attribute values I'm looking at right now in the debugger are > eduPersonAffiliation: old [ member, alum, employee, faculty ], new [ member, > alum, faculty, employee ]. I built the replica from a slapcat dump on the idle > master, started the slapd syncrepl client and applied a lot of normal > modifications to the master, until it hit the infinite loop. It has been a > recurrent problem. Now fixed in HEAD, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP 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