322
322
> chain-return-error TRUE
325
H3: Read-Back of Chained Modifications
327
Occasionally, applications want to read back the data that they just wrote.
328
If a modification requested to a shadow server was silently chained to its
329
producer, an immediate read could result in receiving data not yet synchronized.
330
In those cases, clients should use the {{B:dontusecopy}} control to ensure
331
they are directed to the authoritative source for that piece of data.
333
This control usually causes a referral to the actual source of the data
334
to be returned. However, when the {{slapo-chain(5)}} overlay is used,
335
it intercepts the referral being returned in response to the
336
{{B:dontusecopy}} control, and tries to fetch the requested data.
325
339
H3: Further Information
327
341
{{:slapo-chain(5)}}
1088
This overlay implements the provider-side support for syncrepl
1089
replication, including persistent search functionality
1102
This overlay implements the provider-side support for the LDAP Content Synchronization
1103
({{REF:RFC4533}}) as well as syncrepl replication support, including persistent search functionality.
1092
1105
H3: Sync Provider Configuration
1107
There is very little configuration needed for this overlay, in fact for many situations merely loading
1108
the overlay will suffice.
1110
However, because the overlay creates a contextCSN attribute in the root entry of the database which is
1111
updated for every write operation performed against the database and only updated in memory, it is
1112
recommended to configure a checkpoint so that the contextCSN is written into the underlying database to
1113
minimize recovery time after an unclean shutdown:
1116
> syncprov-checkpoint 100 10
1118
For every 100 operations or 10 minutes, which ever is sooner, the contextCSN will be checkpointed.
1120
The four configuration directives available are {{B:syncprov-checkpoint}}, {{B:syncprov-sessionlog}},
1121
{{B:syncprov-nopresent}} and {{B:syncprov-reloadhint}} which are covered in the man page discussing
1122
various other scenarios where this overlay can be used.
1095
1124
H3: Further Information
1097
{{:slapo-syncprov(5)}}
1126
The {{:slapo-syncprov(5)}} man page and the {{SECT:Configuring the different replication types}} section
1100
1129
H2: Translucent Proxy
1105
This overlay can be used with a backend database such as slapd-bdb (5)
1134
This overlay can be used with a backend database such as {{:slapd-bdb}}(5)
1106
1135
to create a "translucent proxy".
1108
Content of entries retrieved from a remote LDAP server can be partially
1109
overridden by the database.
1137
Entries retrieved from a remote LDAP server may have some or all attributes
1138
overridden, or new attributes added, by entries in the local database before
1139
being presented to the client.
1141
A search operation is first populated with entries from the remote LDAP server,
1142
the attributes of which are then overridden with any attributes defined in the
1143
local database. Local overrides may be populated with the add, modify, and
1144
modrdn operations, the use of which is restricted to the root user of the
1145
translucent local database.
1147
A compare operation will perform a comparison with attributes defined in the
1148
local database record (if any) before any comparison is made with data in the
1112
1152
H3: Translucent Proxy Configuration
1154
There are various options available with this overlay, but for this example we
1155
will demonstrate adding new attributes to a remote entry and also searching
1156
against these newly added local attributes. For more information about overriding remote
1157
entries and search configuration, please see {{:slapo-translucent(5)}}
1159
Note: The Translucent Proxy overlay will disable schema checking in the local
1160
database, so that an entry consisting of overlay attributes need not adhere
1161
to the complete schema.
1163
First we configure the overlay in the normal manner:
1165
> include /usr/local/etc/openldap/schema/core.schema
1166
> include /usr/local/etc/openldap/schema/cosine.schema
1167
> include /usr/local/etc/openldap/schema/nis.schema
1168
> include /usr/local/etc/openldap/schema/inetorgperson.schema
1170
> pidfile ./slapd.pid
1171
> argsfile ./slapd.args
1173
> modulepath /usr/local/libexec/openldap
1174
> moduleload back_bdb.la
1175
> moduleload back_ldap.la
1176
> moduleload translucent.la
1179
> suffix "dc=suretecsystems,dc=com"
1180
> rootdn "cn=trans,dc=suretecsystems,dc=com"
1182
> directory ./openldap-data
1184
> index objectClass eq
1186
> overlay translucent
1187
> translucent_local carLicense
1189
> uri ldap://192.168.X.X:389
1191
> acl-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials="blahblah"
1193
You will notice the overlay directive and a directive to say what attribute we
1194
want to be able to search against in the local database. We must also load the
1195
ldap backend which will connect to the remote directory server.
1197
Now we take an example LDAP group:
1199
> # itsupport, Groups, suretecsystems.com
1200
> dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
1201
> objectClass: posixGroup
1202
> objectClass: sambaGroupMapping
1205
> sambaSID: S-1-5-21-XXX
1207
> displayName: itsupport
1209
> memberUid: joebloggs
1211
and create an LDIF file we can use to add our data to the local database, using
1212
some pretty strange choices of new attributes for demonstration purposes:
1214
> [ghenry@suretec test_configs]$ cat test-translucent-add.ldif
1215
> dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
1216
> businessCategory: frontend-override
1218
> employeeType: special
1219
> departmentNumber: 9999999
1220
> roomNumber: 41L-535
1222
Searching against the proxy gives:
1224
> [ghenry@suretec test_configs]$ ldapsearch -x -H ldap://127.0.0.1:9001 "(cn=itsupport)"
1225
> # itsupport, Groups, OxObjects, suretecsystems.com
1226
> dn: cn=itsupport,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
1227
> objectClass: posixGroup
1228
> objectClass: sambaGroupMapping
1231
> SAMBASID: S-1-5-21-XXX
1233
> displayName: itsupport
1235
> memberUid: joebloggs
1236
> roomNumber: 41L-535
1237
> departmentNumber: 9999999
1238
> employeeType: special
1240
> businessCategory: frontend-override
1242
Here we can see that the 5 new attributes are added to the remote entry before
1243
being returned to the our client.
1245
Because we have configured a local attribute to search against:
1247
> overlay translucent
1248
> translucent_local carLicense
1250
we can also search for that to return the completely fabricated entry:
1252
> ldapsearch -x -H ldap://127.0.0.1:9001 (carLicense=LIVID)
1254
This is an extremely feature because you can then extend a remote directory server
1255
locally and also search against the local entries.
1257
Note: Because the translucent overlay does not perform any DN rewrites, the local
1258
and remote database instances must have the same suffix. Other configurations
1259
will probably fail with No Such Object and other errors
1116
1261
H3: Further Information
1126
This overlay can be used with a backend database such as slapd-bdb (5)
1271
This overlay can be used with a backend database such as {{slapd-bdb(5)}}
1127
1272
to enforce the uniqueness of some or all attributes within a subtree.
1130
1275
H3: Attribute Uniqueness Configuration
1277
This overlay is only effective on new data from the point the overlay is enabled. To
1278
check uniqueness for existing data, you can export and import your data again via the
1279
LDAP Add operation, which will not be suitable for large amounts of data, unlike {{B:slapcat}}.
1281
For the following example, if uniqueness were enforced for the {{B:mail}} attribute,
1282
the subtree would be searched for any other records which also have a {{B:mail}} attribute
1283
containing the same value presented with an {{B:add}}, {{B:modify}} or {{B:modrdn}} operation
1284
which are unique within the configured scope. If any are found, the request is rejected.
1286
Note: If no attributes are specified, for example {{B:ldap:///??sub?}}, then the URI applies to all non-operational attributes. However,
1287
the keyword {{B:ignore}} can be specified to exclude certain non-operational attributes.
1289
To search at the base dn of the current backend database ensuring uniqueness of the {{B:mail}}
1290
attribute, we simply add the following configuration:
1293
> unique_uri ldap:///?mail?sub?
1295
For an existing entry of:
1297
> dn: cn=gavin,dc=suretecsystems,dc=com
1299
> objectClass: inetorgperson
1302
> mail: ghenry@suretecsystems.com
1304
and we then try to add a new entry of:
1306
> dn: cn=robert,dc=suretecsystems,dc=com
1308
> objectClass: inetorgperson
1311
> mail: ghenry@suretecsystems.com
1313
would result in an error like so:
1315
> adding new entry "cn=robert,dc=example,dc=com"
1316
> ldap_add: Constraint violation (19)
1317
> additional info: some attributes not unique
1319
The overlay can have multiple URIs specified within a domain, allowing complex
1320
selections of objects and also have multiple {{B:unique_uri}} statements or
1321
{{B:olcUniqueURI}} attributes which will create independent domains.
1323
For more information and details about the {{B:strict}} and {{B:ignore}} keywords,
1324
please see the {{:slapo-unique(5)}} man page.
1133
1326
H3: Further Information
1143
This overlay can be used to enforce a specific order for the values
1144
of an attribute when it is returned in a search.
1336
The Value Sorting overlay can be used with a backend database to sort the
1337
values of specific multi-valued attributes within a subtree. The sorting occurs
1338
whenever the attributes are returned in a search response.
1147
1340
H3: Value Sorting Configuration
1342
Sorting can be specified in ascending or descending order, using either numeric
1343
or alphanumeric sort methods. Additionally, a "weighted" sort can be specified,
1344
which uses a numeric weight prepended to the attribute values.
1346
The weighted sort is always performed in ascending order, but may be combined
1347
with the other methods for values that all have equal weights. The weight is
1348
specified by prepending an integer weight {<weight>} in front of each value
1349
of the attribute for which weighted sorting is desired. This weighting factor
1350
is stripped off and never returned in search results.
1352
Here are a few examples:
1354
> loglevel sync stats
1357
> suffix "dc=suretecsystems,dc=com"
1358
> directory /usr/local/var/openldap-data
1363
> valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com alpha-ascend
1365
For example, ascend:
1367
> # sharedemail, Groups, suretecsystems.com
1368
> dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
1369
> objectClass: posixGroup
1374
> memberUid: dovecot
1376
> memberUid: suretec
1378
For weighted, we change our data to:
1380
> # sharedemail, Groups, suretecsystems.com
1381
> dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
1382
> objectClass: posixGroup
1386
> memberUid: {4}admin
1387
> memberUid: {2}dovecot
1388
> memberUid: {1}laura
1389
> memberUid: {3}suretec
1391
and change the config to:
1394
> valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com weighted
1396
Searching now results in:
1398
> # sharedemail, Groups, OxObjects, suretecsystems.com
1399
> dn: cn=sharedemail,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
1400
> objectClass: posixGroup
1405
> memberUid: dovecot
1406
> memberUid: suretec
1150
1410
H3: Further Information