Re: (ITS#6320)

[j@telepaths.org]

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.