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:
j@telepaths.org wrote:
On Oct 2, 2009, at 23:00 , Howard Chu wrote:
j@telepaths.org 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.
-
j＠telepaths.org