Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
O
OpenLDAP
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
David Barchiesi
OpenLDAP
Commits
7a98b642
Commit
7a98b642
authored
21 years ago
by
Jong Hyuk Choi
Browse files
Options
Downloads
Patches
Plain Diff
update of the syncrepl directive
parent
9259a8c5
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/guide/admin/slapdconfig.sdf
+89
-59
89 additions, 59 deletions
doc/guide/admin/slapdconfig.sdf
with
89 additions
and
59 deletions
doc/guide/admin/slapdconfig.sdf
+
89
−
59
View file @
7a98b642
...
...
@@ -411,11 +411,41 @@ looks at the suffix line(s) in each database definition in the
order they appear in the file. Thus, if one database suffix is a
prefix of another, it must appear after it in the config file.
H4: updatedn <dn>
This directive is only applicable in a slave slapd. It specifies
the DN allowed to make changes to the replica. This may be the DN
{{slurpd}}(8) binds as when making changes to the replica or the DN
associated with a SASL identity.
Entry-based Example:
> updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:Replication with slurpd}} chapter for more information
on how to use this directive.
H4: updateref <URL>
This directive is only applicable in a slave slapd. It
specifies the URL to return to clients which submit update
requests upon the replica.
If specified multiple times, each {{TERM:URL}} is provided.
\Example:
> updateref ldap://master.example.net
H4: syncrepl
> syncrepl id=<replica ID>
> provider=ldap[s]://<hostname>[:port]
> [updatedn=<dn>]
> [binddn=<dn>]
> [bindmethod=simple|sasl]
> [binddn=<simple DN>]
...
...
@@ -425,41 +455,71 @@ H4: syncrepl
> [realm=<realm>]
> [authcId=<authentication ID>]
> [authzId=<authorization ID>]
> [updatedn=<dn>]
> [searchbase=<base DN>]
> [filter=<filter str>]
> [attrs=<attr list>]
> [scope=sub|one|base]
> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
> [type=refreshOnly|refreshAndPersist]
> [interval=dd:hh:mm]
This directive specifies an LDAP Sync replication between this
database and the specified replication provider site. The id=
parameter identifies the LDAP Sync specification in the database.
The {{EX:provider=}} parameter specifies a replication provider site as
an LDAP URI.
The LDAP Sync replication specification is based on the search
specification which defines the content of the replica. The replica
consists of the entries matching the search specification. As with
the normal searches, the search specification consists of
{{EX:searchbase}}, {{EX:scope}}, {{EX:filter}}, and EX:attrs}}
parameters.
The LDAP Sync replication has two types of operating modes. In the
{{EX:refreshOnly}} mode, the next synchronization session is
rescheduled at the interval time after the current session finishes.
The default interval is set to one day. In the {{EX:refreshAndPersist}}
mode, the LDAP Sync search remains persistent in the provider LDAP
server. Further updates to the provider replica will generate
searchResultEntry to the consumer.
> [interval=dd:hh:mm:ss]
This directive specifies the current database as a replica of the
master database at the provider site. The replica database at the
replication consumer site is kept up-to-date with the master
database using the LDAP Content Synchronization protocol.
See {{REF:draft-zeilenga-ldup-sync-04.txt}} for more information
on the protocol.
The {{EX:id}} parameter is used for identification of the current
syncrepl directive in the database, where the three-digit integer
{{EX:<replica ID>}} uniquely identifies the syncrepl specification
described by the current syncrepl directive.
The {{EX:provider}} parameter specifies the replication provider site
containing the master database as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are
{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
If <port> is not given, the standard LDAP port number (389 or 636) is used.
Note that syncrepl uses a consumer-initiated protocol, and hence its
specification is located at the consumer site, whereas the {{EX:replica}}
specification is located at the provider site. {{EX:syncrepl}} and
{{EX:replica}} are two independent replication mechanisms and they do
not represent the replication peers of each other.
The content of the syncrepl replica is defined using a search
specification as its result set. The consumer slapd will send
search requests to the provider slapd according to the search
specification. The search specification consists of {{EX:searchbase}},
{{EX:scope}}, {{EX:filter}}, and {{EX:attrs}} parameters
as in the normal search specification. The search requests
for the LDAP Content Synchronization operation is attached
a special control for synchronization and replica management.
The LDAP Content Synchronization protocol has two types of operation
modes : {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
The operation type is specified by the {{EX:type}} parameter.
In the {{EX:refreshOnly}} mode, the next synchronization search operation
is rescheduled periodically at the interval time after the current
synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} mode, a synchronization search
remains persistent in the provider slapd. Further updates to the
master replica will make searchResultEntry search responses
to the persistent synchronization search delivered to the consumer
slapd in order to synchronize the replica.
The schema checking can be enforced at the LDAP Sync consumer site
by turning on the {{EX:schemachecking}} parameter. The default is off.
The {{EX:binddn=}} parameter gives the DN for the LDAP Sync search
to bind as to the provider slapd. The content of the replica will
be subject to the access control privileges of the DN.
The {{EX:binddn}} parameter gives the DN for a LDAP Content Synchronization
search to bind as to the provider slapd. The search result, i.e., the
content of the replica, will be subject to the access control privileges
of the DN.
The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}}, depending
on whether simple password-based authentication or SASL authentication
...
...
@@ -477,41 +537,11 @@ credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
respectively. The {{EX:authzid}} parameter may be used to specify
a proxy authorization identity.
The
LDAP Sync
replication is supported in three native backends:
The
syncrepl
replication
mechanism
is supported in
the
three native backends:
back-bdb, back-hdb, and back-ldbm.
See the {{SECT:LDAP Sync Replication}} chapter for more information
on how to use this directive.
H4: updatedn <dn>
This directive is only applicable in a slave slapd. It specifies
the DN allowed to make changes to the replica. This may be the DN
{{slurpd}}(8) binds as when making changes to the replica or the DN
associated with a SASL identity.
Entry-based Example:
> updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:Replication with slurpd}} chapter for more information
on how to use this directive.
H4: updateref <URL>
This directive is only applicable in a slave slapd. It
specifies the URL to return to clients which submit update
requests upon the replica.
If specified multiple times, each {{TERM:URL}} is provided.
\Example:
> updateref ldap://master.example.net
See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
for more information on how to use this directive.
H3: BDB Database Directives
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment