[Date Prev][Date Next]
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
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:
> firstname.lastname@example.org wrote:
>> On Oct 2, 2009, at 23:00 , Howard Chu wrote:
>>> email@example.com wrote:
>>>> My last email was likely indecipherable, so re-sending as plain =20
>>>> This may sound like a strange question, but couldn't seem to find =20=
>>>> 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
>> 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
> really matches your slapd idle timeout requirements.
> Ciao, Michael.