Examples and Considerations

In this example, the following rules exist:

No operation routing rules are defined for search operations.

The following tables illustrate where the operations are routed to based on the keepconn key.

keepconn=1

keepconn=0

These tables show that keepconn=1 overrules the target server from a previous user-routing rule for all subsequent operations that do not have their own rule. A keepconn=1 can also be seen as a “switch-connection” operation. (Of course the switch is only applied if the operation was successful).

In this example, the following rules exist:

No operation-routing rules are defined for search operations.

The following tables illustrate where the operations are routed to based on the keepconn settings in the operation-routing rule:

Note that a server failure means that the server cannot be reached via the network for the rest of the test sequence; that is, it is not available again until end of the sequence.

Sequence 1: Keepconn=1 or keepconn=0

Sequence 2: keepconn=1

Sequence 2: keepconn=0

As the example shows, the reaction towards the client depends on when the target server drops out, although the client executes the same sequence. As the target servers are transparent to the client (the client is unaware of being physically connected to a DLP server and not to an LDAP server) this might look strange, because the client never “lost” the LDAP-connection but might still receive different results.

In this example, the following rules exist:

No operation-routing rules are defined for search operations.

The following tables illustrate where the operations are routed to based on various keepconn settings and failover=1 in the operation-routing rule:

Sequence 1: Keepconn=1

Sequence 1: Keepconn=0

Sequence 2: Keepconn=1

Sequence 2: Keepconn=0

Here are some condition/action pair examples.In these examples, C: refers to a condition and A: refers to an action.

When search results are changed/re-written, it is usually necessary to add additional rules in order to maintain a consistent approach to the database in subsequent calls.

To illustrate this concept, let’s look at the following simple example.Suppose there is a group of legacy clients that are accessing a DIT tree via LDAP calls.The DIT tree consists of a simple structure with a context prefix (CP) of o=companyX.The company decides to rename itself from companyX to companyZ and all the entries in the DIT need to reflect this change to the calling clients.

One way of achieving the result is to rename all entries in the DIT by changing the entry o=companyX to o=companyZ.This solution also implies that all clients must use o=companyZ as new target addresses; for example, for baseObjects in searches or in entry DNs for adds or modifys.But what if some of the legacy clients cannot be changed so easily?

A better approach is to use the DirX Directory LDAP proxy server with a simple rewriting rule like this:

C: (opr.req.type=search)

A: search.req.baseObject.replace(companyX,companyZ,NULL)

This rule changes any occurrence of companyX on-the-fly into companyZ in the baseObject of any search, making the search successful again for clients that are only aware of o=company.

Well, but what is returned now? The returned entries from the LDAP server will contain the new name o=companyZ again. Clients may now struggle to receive entries containing o=companyZ in their DNs although they have given a baseObject of o=companyX and therefore expect such resulting DNs.

Again, the DLP server can help by adding another simple result-rewriting action to another rule like:

C: (opr.req.type=search)

A: search.res.objectName.replace(companyZ,companyX,NULL)

Note that it must be another rule because the rule will now operate on results and so the ruleType must be ResRewrite. The baseObject change was performed by a ReqRewrite rule type.

By adding this result-rewriting rule, a client now receives the resulting entries as usual with the well-known old name companyX.

What if the client now decides to create a new group-of-names entry containing all received DNs as members from the previous search result? The client will surely issue an add request. As the client is only aware of o=companyX, the target DN of the add operation may again contain companyX and the member attributes will also contain the companyX name.

Clearly this add operation is bound to fail, as the LDAP servers no longer recognize companyX. Thus, it will be necessary to define further rules like

C: (opr.req.type=add)

A: add.req.entry.replace(companyX,companyZ,NULL)

A: add.req.attributes.replace(member,companyX,companyZ)

where the first action corrects the DN and the second action changes the members to the new name.

If you plan to deploy result rewriting, you need to have a full understanding of client behavior. You may need to add many more additional rules to manage the changes in subsequent add, modify, delete, moddn or compare operations properly.