Michael, Yes, that has been a theory of mine - I am investigating the =20 possibility, however I should point out that we recently =20 decommissioned our old LDAP system, which used slapd on Etch - it uses =20=
the same firewalls for out-of-zone-access, and was not affected by =20 this problem. However, I should also point out that since my last update, the =20 problem has not returned. Using a six-member multimaster mesh has =20 proven fruitful so far, but we'll see how it plays out over the next =20 couple of days. Thanks for your help ... On Oct 4, 2009, at 06:00 , Michael Str=F6der wrote: > [email protected] wrote: >> On Oct 2, 2009, at 23:00 , Howard Chu wrote: >> >>> [email protected] wrote: >>>> My last email was likely indecipherable, so re-sending as plain =20 >>>> text: >>>> >>>> ##### >>>> >>>> This may sound like a strange question, but couldn't seem to find =20= >>>> the >>>> answer in the docs: >>>> >>>> Would the global "idletimeout" parameter interfere with >>>> 'refreshAndPersist' operations in any way? >>> No, that would be stupid. >>> >> Yes Howard -- that would be incredibly stupid. But I had to ask. >> [..] >> SOME of the servers receiving updates are separated by firewalls, >> yes ... HOWEVER (a) there are special policies in place, allowing >> these hosts to communicate via LDAP[S]; this can be confirmed by >> running ldapsearch routines from every possible vantage point TO =20 >> every >> possible provider, etc., > > Note that firewalls are doing connection tracking enforcing their =20 > own timeouts > for idle connections. So please check whether the firewall =20 > configuration > really matches your slapd idle timeout requirements. > > Ciao, Michael.
