[Date Prev][Date Next]
Re: sessionlog question
Turbo Fredriksson wrote:
"Stephan" == Stephan Dühr <firstname.lastname@example.org> 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
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
The sessionlog only looks at the sid, and the provider and consumer sid
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
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:
So if you have multiple consumers replicating against the same provider,
the consumer configuration option 'syncrepl' is/should be IDENTICAL...
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
Symas: Premier OpenSource Development and Support