openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by bgmilne＠staff.telkomsa.net 17 Sep '07

17 Sep '07

On Thursday 13 September 2007 23:05:29 ando(a)sys-net.it wrote: > 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. I think I filed a previous ITS on this, but the servers exhibiting this behaviour in a remote site were lost (power supplies died) so I couldn't test Howard's fix at the time. We have recently installed some QA servers, which now also need to traverse a PIX firewall to get to the production master (from which they replicate one database), and I have seen the behaviour again (they go out of sync on most of the rare changes to this database until I restart them or the check kicks in). I note that a keepalive probably needs to be sent at least once an hour for a PIX not to drop the connection. I haven't looked up any relevant RFCs on this though ... I can now test a fix a lot more easily (since I can upgrade one of these servers at-will, as opposed to the previous slaves which were in production). Regards, Buchan

1 0

(ITS#5139) s/should/must/ in slapo-translucent(5)
by ando＠sys-net.it 15 Sep '07

15 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando slapo-translucent(5) states that: The Translucent Proxy overlay uses a remote LDAP server which is con- figured with the options shown in slapd-ldap(5). These slapd.conf options are specific to the Translucent Proxy overlay; they should appear after the overlay directive. I believe this "should" is rather a "must", since before the overlay directive is used, slapd cannot know that slapd-ldap(5) has anything to do with that database stanza. p.

1 0

(ITS#5138) back-ldap still mis-handles search controls
by hyc＠OpenLDAP.org 15 Sep '07

15 Sep '07

Full_Name: Howard Chu Version: RE23/RE24/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc ldap_build_entry() builds the entry's attributes by using ber_scanf until it gets to the end of the LDAP message. Unfortunately, it will read past the sequence of attributes and parse any attached controls as if they were also attributes. Fix coming up...

1 0

(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 14 Sep '07

14 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 14 Sep '07

14 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 14 Sep '07

14 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

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