RE25 testing call (2.5.18) #1

[Quanah Gibson-Mount]

his is the first testing call for OpenLDAP 2.5.18.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE25:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.5.18 Engineering
   Fixed libldap exit handling with OpenSSL3 again (ITS#9952)
   Fixed slapd-meta with dynlist (ITS#10164)
   Fixed slapd-meta binds when proxying internal op (ITS#10165)
   Fixed slapo-accesslog startup initialization (ITS#10170)
   Fixed slapo-dynlist with abandoned operations (ITS#10044)
   Build
   Fixed build with gcc14.x (ITS#10166)
   Fixed back-perl with clang15 (ITS#10177)
   Minor Cleanup
   ITS#10171
   ITS#10173
   ITS#10179
   ITS#10186


Regards,
Quanah

RE26 testing call (2.6.8) #1

[Quanah Gibson-Mount]

This is the first testing call for OpenLDAP 2.6.8.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE26:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.6.8 Engineering
   Fixed libldap exit handling with OpenSSL3 again (ITS#9952)
   Fixed slapd-meta with dynlist (ITS#10164)
   Fixed slapd-meta binds when proxying internal op (ITS#10165)
   Added slapo-nestgroup overlay (ITS#10161)
   Added slapo-memberof 'addcheck' option (ITS#10167)
   Fixed slapo-accesslog startup initialization (ITS#10170)
   Fixed slapo-dynlist with abandoned operations (ITS#10044)
   Build
   Fixed build with gcc14.x (ITS#10166)
   Fixed back-perl with clang15 (ITS#10177)
   Contrib
   Added slapo-alias contrib module (ITS#10104, ITS#10182)
   Fixed slapo-autogroup to work with slapo-dynlist (ITS#10185)
   Documentation
   Fixed slapo-memberof exattr requirements (ITS#7400)
   Fixed slapo-memberof is no longer deprecated (ITS#7400)
   Minor Cleanup
   ITS#10103
   ITS#10171
   ITS#10172
   ITS#10173
   ITS#10179
   ITS#10186
   ITS#10188
   ITS#10193

Regards,
Quanah

Re: timeout and network-timeout values of zero for syncrepl in LAN replication

[Quanah Gibson-Mount]

--On Monday, April 8, 2024 3:08 PM +0900 Christopher Paul 
 wrote:




Hello OpenLDAP-technical list,

I'm curious about community perspectives on a specific LDAP replication
timeout and network-timeout settings:


Setting "timeout=0" or "network-timeout=0" within a syncrepl/olcSyncrepl
definition for replication settings is not the best practice for LAN
environments. These parameters, when set to zero, instruct syncrepl to
wait indefinitely for connections and replication operations to conclude.


Within a LAN context, establishing new connections should ideally occur
in less than a second. Delays beyond a couple of seconds should kick in
the retry logic. This suggests that a more fitting network-timeout range
is between 1 to 5 seconds.

Concerning the "timeout" parameter, the ideal range might be between 60
to 120 seconds, to handle operations exceeding a minute, but again,
kicking in retry logic if they exceed two minutes. I admit that my stance
on the "timeout" setting is tentative, given that search operation
duration hinges more on the provider's responsiveness rather than network
speed alone.

This approach ensures that LDAP replication remains both responsive and
resilient, without compromising on efficiency or performance. Thoughts?


It's generally never been an issue in the networks I've been on.  Also with 
refreshAndPersist these settings are only for the initial connection.  If I 
was doing refreshOnly I'd definitely want to tweak them.  I'd make sure and 
set the tcp keepalive settings as well for sync replication, because the 
biggest grief I've had since moving to syncrepl around 2006 is with 
firewalls and other network devices.


There was someone I corresponded with many years ago who was doing syncrepl 
in an unstable network environment (their nodes were distributed across 
Mexico IIRC, and the links were not stable), and managed to get it solid 
when tweaking the parameters you mention.  If they're still active, it'd be 
interesting to hear their feedback.


--Quanah