- openldap-bugs - openldap.org

(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

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

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

hyc(a)symas.com writes: > Raphaël Ouazana-Sustowski wrote: >> Thank you very much for the clarification. >> Just for the records, it seems that Debian packages (and maybe others) >> use dbconfig directives without warning users that they should not >> modify these parameters here... > Thanks for that bit of information, I was not aware of that. For the > record, Debian packagers have never asked us whether what they're doing > makes any bit of sense. Well, that's not exactly true, given that I have in fact talked with Quanah about this and he recommended setting everything in slapd.conf instead of using a separate DB_CONFIG file, although the code in the Debian package predates that. Certainly there should be a comment explaining that changes there only take effect if the DB_CONFIG file doesn't exist. I'll file a bug against the Debian package for whenever someone gets a chance to upload a new version. (I wish I had more time to work on this.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

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

13 Sep '07

<quote who="Howard Chu"> > Gavin Henry wrote: >> <quote who="Howard Chu"> >>> ghenry(a)suretecsystems.com wrote: >>>> I would say since dbconfig directives only work on a restart of slapd, >>>> and >>>> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >>>> precedence. If dbconfig changes could make a difference via >>>> back-config, >>>> which they can't without a restart, then dbconfig stuff should >>>> override >>>> any DB_CONFIG. >>> dbconfig behavior via cn=config is fully dynamic, and thus quite >>> different >>> from >>> slapd.conf. Changes to dbconfig via cn=config take effect immediately >>> and >>> will >>> completely rewrite the DB_CONFIG file. >> >> Understood, but a restart would still be needed to make the db env >> honour >> DB_CONFIG, right? > > NO. "Fully dynamic" and "take effect immediately" means exactly that. I > did not > say "the file is written immediately but there's no effect until the > server is > restarted." Immediate effect means immediate effect. Do we really have to > say > everything twice or thrice here before people get it? Ok, I get it. I didn't know the db env was reopened when needed with cn=config. Now I do. I'll make sure this is in the docs. I'll try to make it crystal clear! P.S. What does thrice mean? ;-)

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by ando＠sys-net.it 13 Sep '07

13 Sep '07

audrius.valunas(a)teo.lt wrote: > There is synchronous replication between mastyer and slave. When network > connectivity problems occur master closes tcp connection but slave doesn't > notice those problems, it still has tcp connection open, but in real it is not > receiving updates any more. > I think that can be solved adding some ack from slave because sending on such a > socket would fail and force slave to retry connection. Well, this should already be taken into consideration by SO_KEEPALIVE, which is always set when available on all connections. I concur that it usually requires quite a long time before a connection is actually checked (usually more than 2 hours), so some better policy could be put in place. 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

Raphaël Ouazana-Sustowski wrote: > Le Jeu 13 septembre 2007 22:40, Howard Chu a écrit : >> Raphaël Ouazana-Sustowski wrote: >>> Hi, >>> >>> Le Jeu 13 septembre 2007 21:29, hyc(a)symas.com a écrit : >>>> There is nothing ambiguous here. When slapd.conf is being used, the >>>> dbconfig >>>> directive *only* takes effect *if* no DB_CONFIG file exists. If one >>>> exists, the >>>> dbconfig directives are ignored. >>> So if someone first create its DB_CONFIG by putting dbconfig directives >>> in >>> slapd.conf, and then modify these directives, the modification has no >>> effect ? >> Correct. >> >>> 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. > > Thank you very much for the clarification. > > Just for the records, it seems that Debian packages (and maybe others) use > dbconfig directives without warning users that they should not modify > these parameters here... Thanks for that bit of information, I was not aware of that. For the record, Debian packagers have never asked us whether what they're doing makes any bit of sense. I believe it is the packager's responsibility to proactively check these things out; certainly we (OpenLDAP Project) cannot go out and poll every packager. -- -- 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 hyc＠symas.com 13 Sep '07

13 Sep '07

Pierangelo Masarati wrote: > Howard Chu wrote: >> "If (x) then (y)" is the complete definition of the behavior. You are >> looking for explanations for "If (!x)", but it should be well understood >> that such cases are irrelevant given this definition. > > That's actually an if (x) and (!y) then (z). What is missing is if (x) > and (y) (which happens to be (!z), but it could be anything...) Yes, but "anything" would require extra work. (Kinda like #pragma in gcc 1.x would start up NetHack, since the C spec said the behavior was totally implementation defined.) Nor does it make sense for any other outcome to exist. E.g. with your example, you're supposing the possibility that "if (x) and (y) then (z)" but then the outcome is identical for both "if (x) and (!y)" and "if (x) and (y)" which makes y completely irrelevant. Again, nobody would go to the bother of jumping thru the hoops for these extra conditions if they are ultimately irrelevant. -- -- 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 raphael.ouazana＠linagora.com 13 Sep '07

13 Sep '07

Le Jeu 13 septembre 2007 22:40, Howard Chu a écrit : > Raphaël Ouazana-Sustowski wrote: >> Hi, >> >> Le Jeu 13 septembre 2007 21:29, hyc(a)symas.com a écrit : >>> There is nothing ambiguous here. When slapd.conf is being used, the >>> dbconfig >>> directive *only* takes effect *if* no DB_CONFIG file exists. If one >>> exists, the >>> dbconfig directives are ignored. >> >> So if someone first create its DB_CONFIG by putting dbconfig directives >> in >> slapd.conf, and then modify these directives, the modification has no >> effect ? > > Correct. > >> 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. Thank you very much for the clarification. Just for the records, it seems that Debian packages (and maybe others) use dbconfig directives without warning users that they should not modify these parameters here... Regards, Raphael Ouazana.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Should be fixed now in HEAD/re24/re23. Please test. 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

Raphaël Ouazana-Sustowski wrote: > Hi, > > Le Jeu 13 septembre 2007 21:29, hyc(a)symas.com a écrit : >> There is nothing ambiguous here. When slapd.conf is being used, the >> dbconfig >> directive *only* takes effect *if* no DB_CONFIG file exists. If one >> exists, the >> dbconfig directives are ignored. > > So if someone first create its DB_CONFIG by putting dbconfig directives in > slapd.conf, and then modify these directives, the modification has no > effect ? Correct. > 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. -- -- 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: > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >> >>> There is nothing ambiguous here. When slapd.conf is being used, the >>> dbconfig directive *only* takes effect *if* no DB_CONFIG file exists. >>> If one exists, the dbconfig directives are ignored. >> >> I insist: I don't see it so clear, and I was pointed to it by other >> people that didn't find it clear as well. I'm not questioning what the >> code does, just this very bit of the man page. > > "If (x) then (y)" is the complete definition of the behavior. You are > looking for explanations for "If (!x)", but it should be well understood > that such cases are irrelevant given this definition. That's actually an if (x) and (!y) then (z). What is missing is if (x) and (y) (which happens to be (!z), but it could be anything...) 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

Gavin Henry wrote: > <quote who="Howard Chu"> >> ghenry(a)suretecsystems.com wrote: >>> I would say since dbconfig directives only work on a restart of slapd, >>> and >>> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >>> precedence. If dbconfig changes could make a difference via back-config, >>> which they can't without a restart, then dbconfig stuff should override >>> any DB_CONFIG. >> dbconfig behavior via cn=config is fully dynamic, and thus quite different >> from >> slapd.conf. Changes to dbconfig via cn=config take effect immediately and >> will >> completely rewrite the DB_CONFIG file. > > Understood, but a restart would still be needed to make the db env honour > DB_CONFIG, right? NO. "Fully dynamic" and "take effect immediately" means exactly that. I did not say "the file is written immediately but there's no effect until the server is restarted." Immediate effect means immediate effect. Do we really have to say everything twice or thrice here before people get 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 hyc＠symas.com 13 Sep '07

13 Sep '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> There is nothing ambiguous here. When slapd.conf is being used, the dbconfig >> directive *only* takes effect *if* no DB_CONFIG file exists. If one exists, the >> dbconfig directives are ignored. > > I insist: I don't see it so clear, and I was pointed to it by other > people that didn't find it clear as well. I'm not questioning what the > code does, just this very bit of the man page. "If (x) then (y)" is the complete definition of the behavior. You are looking for explanations for "If (!x)", but it should be well understood that such cases are irrelevant given this definition. -- -- 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 raphael.ouazana＠linagora.com 13 Sep '07

13 Sep '07

Hi, Le Jeu 13 septembre 2007 21:29, hyc(a)symas.com a écrit : > There is nothing ambiguous here. When slapd.conf is being used, the > dbconfig > directive *only* takes effect *if* no DB_CONFIG file exists. If one > exists, the > dbconfig directives are ignored. So if someone first create its DB_CONFIG by putting dbconfig directives in slapd.conf, and then modify these directives, the modification has no effect ? Reading the man page, I thought that the directives don't modify DB_CONFIG, but were applied at slapd's startup. (Note that english is not my native language either, if it was not already clear ;). Regards, Raphael Ouazana.

1 0

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

13 Sep '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> I would say since dbconfig directives only work on a restart of slapd, >> and >> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >> precedence. If dbconfig changes could make a difference via back-config, >> which they can't without a restart, then dbconfig stuff should override >> any DB_CONFIG. > > dbconfig behavior via cn=config is fully dynamic, and thus quite different > from > slapd.conf. Changes to dbconfig via cn=config take effect immediately and > will > completely rewrite the DB_CONFIG file. Understood, but a restart would still be needed to make the db env honour DB_CONFIG, right? Gavin.

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: > There is nothing ambiguous here. When slapd.conf is being used, the dbconfig > directive *only* takes effect *if* no DB_CONFIG file exists. If one exists, the > dbconfig directives are ignored. I insist: I don't see it so clear, and I was pointed to it by other people that didn't find it clear as well. I'm not questioning what the code does, just this very bit of the man page. 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

ghenry(a)suretecsystems.com wrote: > I would say since dbconfig directives only work on a restart of slapd, and > that if a DB_CONFIG is present, the DB_CONFIG should *always* take > precedence. If dbconfig changes could make a difference via back-config, > which they can't without a restart, then dbconfig stuff should override > any DB_CONFIG. dbconfig behavior via cn=config is fully dynamic, and thus quite different from slapd.conf. Changes to dbconfig via cn=config take effect immediately and will completely rewrite the DB_CONFIG file. -- -- 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 hyc＠symas.com 13 Sep '07

13 Sep '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.203.230.29) > Submitted by: ando > > > The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig > directive. In fact, what I gather from the text is that if no DB_CONFIG file > exists, any dbconfig directive will be used to generate one; otherwise, an > existing DB_CONFIG file will not be altered. What is unclear is what happens if > both a DB_CONFIG file and any dbconfig directives exist, and they differ? Who > takes the precedence? What if any dbconfig directive is not present in the > DB_CONFIG file? There is nothing ambiguous here. When slapd.conf is being used, the dbconfig directive *only* takes effect *if* no DB_CONFIG file exists. If one exists, the dbconfig directives are ignored. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs