openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5137) Potential double-free (on slab) in slapo-chain
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See subject. A fix is coming... p.

1 0

(ITS#5136) Normalized ordered values don't get added consistently
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando A malformed test in ordered_value_add() causes discarding the normalized values during addition from scratch of ordered values. Then a_nvals gets set to a_vals, resulting in incorrect use of normalized values. A fix is coming... p.

1 0

(ITS#5135) Dynlist does not release entry
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando AN entry acquired with overlay_entry_get_ov() is never released by overlay_entry_release_ov(). A fix is coming... p.

1 0

Re: (ITS#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Michael Ströder wrote: > Pierangelo Masarati wrote: >> Fixed in HEAD (HEAD only); please test. > > Still does not work. Something's missing in current HEAD synced now? Probably I forgot to commit the regenerated configure... :) 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#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

hyc(a)symas.com wrote: > Once again - does the DB_CONFIG file exist already? That's the only condition > that matters. If you edit the slapd.conf and then delete the existing DB_CONFIG > file, then of course the change will take effect on the next restart. Otherwise > not. Don't make this more complicated than it is. Well, that's a good point: the man page does not say that Berkeley will read its configuration from DB_CONFIG and only from that. It says "The dbconfig directive is just a convenience to allow all necessary configuration to be set in the slapd.conf file." which implies the above, but the more we imply the more we risk getting requests for clarification. I know that Berkeley will read its configuration only from DB_CONFIG, so this point didn't catch my attention at first. Adding such a (yes, redundant for those that already read Berkeley's documentation, but important enough, IMHO, to deserve repetition) statement would probably have made all the remaining unsaid things automatically and logically implied. > Look again. "Specify a configuration directive to be placed in the DB_CONFIG > file of the database directory." It does not say that it specifies settings to > be used by the database, through any temporary magical means. Nowhere does it > imply that the settings will have any effect at all. It simply says that if no > DB_CONFIG file was present, then one will be created. Whether the BDB library > will ever see these settings is completely unstated. Right, +1 for you :) > >> I believe it should clearly state that if DB_CONFIG is present, any >> dbconfig directives are simply ignored. > > I think such a statement is redundant, but I've added it. Thanks. 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#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Russ Allbery wrote: > Perhaps you're only looking at the database directory after slapd starts, > at which point slapd itself has already written out the DB_CONFIG file? I'm just reporting what has been reported to me by people asking for advice on interpreting slapd's behavior. If what has been reported to me is not correct then fine. I'm not going to install Debian just for the purpose of verifying this, but I think I can act on making our own manuals as clear as possible, without adding more than required. 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#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

Pierangelo Masarati wrote: > Howard Chu wrote: > >> The manpage also says "This allows one to set initial values without >> overwriting/destroying a DB_CONFIG file that was already customized >> through other means." If the dbconfig settings had any other effect they >> would (a) no longer be *initial* values and (b) overwrite/destroy an >> existing DB_CONFIG file. Clearly that's not the intended behavior. > > Indeed, I found the man page clear about the fact that Debian's behavior > was incorrect (actually, useless). But a second point arose: what if > dbconfig statements not present in the original DB_CONFIG were > subsequently added as dbconfig? This is what would need to disambiguate. Once again - does the DB_CONFIG file exist already? That's the only condition that matters. If you edit the slapd.conf and then delete the existing DB_CONFIG file, then of course the change will take effect on the next restart. Otherwise not. Don't make this more complicated than it is. > > Another point is that slapd-bdb(5) man page insists on the fact that the > DB_CONFIG is not overwritten, but it seems to leave room to speculation > that changes to the dbconfig could **temporarily** take effect, which is > not true. Look again. "Specify a configuration directive to be placed in the DB_CONFIG file of the database directory." It does not say that it specifies settings to be used by the database, through any temporary magical means. Nowhere does it imply that the settings will have any effect at all. It simply says that if no DB_CONFIG file was present, then one will be created. Whether the BDB library will ever see these settings is completely unstated. > I believe it should clearly state that if DB_CONFIG is present, any > dbconfig directives are simply ignored. I think such a statement is redundant, but I've added it. -- -- 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#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Howard Chu wrote: > The manpage also says "This allows one to set initial values without > overwriting/destroying a DB_CONFIG file that was already customized > through other means." If the dbconfig settings had any other effect they > would (a) no longer be *initial* values and (b) overwrite/destroy an > existing DB_CONFIG file. Clearly that's not the intended behavior. Indeed, I found the man page clear about the fact that Debian's behavior was incorrect (actually, useless). But a second point arose: what if dbconfig statements not present in the original DB_CONFIG were subsequently added as dbconfig? This is what would need to disambiguate. Another point is that slapd-bdb(5) man page insists on the fact that the DB_CONFIG is not overwritten, but it seems to leave room to speculation that changes to the dbconfig could **temporarily** take effect, which is not true. I believe it should clearly state that if DB_CONFIG is present, any dbconfig directives are simply ignored. 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#5134) dbconfig vs. DB_CONFIG
by rra＠stanford.edu 13 Sep '07

13 Sep '07

ando(a)sys-net.it writes: > I didn't mention that the whole discussion started because Debian seems > to ship with both a default DB_CONFIG installed in the database > directory, and the very same directives echoed in slapd.conf. The current Debian packages do not do this so far as I can determine. They do install a DB_CONFIG file when *upgrading* the slapd package, but only if a database already exists and no DB_CONFIG file exists, since that's known to cause extremely poor performance. A new installation of the slapd package does not create a separate DB_CONFIG file in the database directory. It puts dbconfig parameters into slapd.conf and then lets slapd write a DB_CONFIG file. Perhaps you're only looking at the database directory after slapd starts, at which point slapd itself has already written out the DB_CONFIG file? -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >>> Reading the man page, I thought that the directives don't modify >>> DB_CONFIG, but were applied at slapd's startup. >> For slapd.conf, the directives can only take effect after they are written to >> DB_CONFIG. They will only be written to DB_CONFIG at startup time, and only if >> no such file already existed. >> >> The main reason this directive was added was for the benefit of cn=config. >> Using it in slapd.conf is rather pointless. Once you start managing slapd >> through cn=config, you are expected to stop editing DB_CONFIG manually. > > I didn't mention that the whole discussion started because Debian seems > to ship with both a default DB_CONFIG installed in the database > directory, and the very same directives echoed in slapd.conf. People > find the dbconfig directives, modify them and complain because they > don't take effect. And, I couldn't disambiguate the man page because I > didn't find it clear enough about this point. The manpage also says "This allows one to set initial values without overwriting/destroying a DB_CONFIG file that was already customized through other means." If the dbconfig settings had any other effect they would (a) no longer be *initial* values and (b) overwrite/destroy an existing DB_CONFIG file. Clearly that's not the intended behavior. -- -- 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