[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: sessionlog question

Turbo Fredriksson wrote:

"Stephan" == Stephan Dühr <stephan.duehr@dass-it.de> writes:



   Stephan> the FAQ
   Stephan> (http://www.openldap.org/faq/data/cache/1125.html) says
   Stephan> that sessionlog is used with a replication id (sessionlog
   Stephan> <rid> <changelimit>), but in the Admin-Guide it's session
   Stephan> log id (sessionlog <sid> <limit>).  This is a bit
   Stephan> confusing.

It's only confusing if you take 'sid' and 'rid' literally. The 'r' in
'rid' I asume means REMOTE (and I'm _guessing_ that the 's' in 'sid'
means something like SOURCE - have no idea if that's the case, it just
seem logical to me :).

Basically they say the exact same thing... 

No. Guessing is seldom a good way to form an understanding of any system.

rid is replica ID, sid is session ID. The two are different and intended for different purposes. Whether they're actually of value is a separate question.

   Stephan> That means, even if i have multiple
   Stephan> consumers replicating the same stuff from a provider, i
   Stephan> only need one sessionlog. Or is it so that the consumer
   Stephan> uses the rid to forge the syncrepl cookie?

The 'sessionlog' goes (ONLY) on the provider. The number you specify
(sid or rid - whatever) must match the 'rid=' value you have on the
consumer.


The sessionlog only looks at the sid, and the provider and consumer sid must match.

So if you have multiple consumers replicating against the same provider,
the consumer configuration option 'syncrepl' is/should be IDENTICAL...

No. The point behind the rid is to allow multiple consumers to be distinguished from each other. This is used as a shortcut for satisfying the conditions of draft-zeilenga-ldup-sync-05 section 3.1:
A sequence of Sync Operations where the last cookie returned by the
server for one operation is provided by the client in the next
operation are said to belong to the same Synchronization Session.

 The client MUST specify the same content controlling parameters (see
 Section 3.5) in each Search Request of the session.  The client SHOULD
 also issue each Sync request of a session under the same
 authentication and authorization associations with equivalent
 integrity and protections.  If the server does not recognize the
 request cookie or the request is made under different associations or
 non-equivalent protections, the server SHALL return the initial
 content as if no cookie had been provided or return an empty content
 with the e-syncRefreshRequired LDAP result code.

The draft recommends calculating a hash of the search parameters and passing that in the sync cookie to insure that the search parameters from each sync request are identical. The OpenLDAP implementation uses an rid instead; so it is assumed that all requests with the same rid are using identical search parameters.

In practice this requirement is of little value and is contrary to one of syncrepl's other design points - the provider is not supposed to need to maintain any special state about individual consumers. Verifying that the search parameters are identical between requests would require the provider to maintain a list of all the syncrepl requests it has received, and OpenLDAP doesn't do this. So in fact this requirement and the rid are basically ignored.

Looking at the code again, there's another bug here - the consumer provides no config keyword for specifying the sid. Therefore the only way to use the sessionlog is by manually specifying a cookie on the consumer slapd command line.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support