Hash Distribution Algorithm

For a hash-based distribution algorithm, the most difficult part is to define what hash function would avoid re-distribution. To reduce entry re-distribution, it is also possible to configure the proxy with the maximum number of distribution "slots" upfront, say 10 slots, then associate multiple slots with each service instance.

S1,S2,S3 --> SVC1
S4,S5,S6 --> SVC2
S7, S8, S7, S10 --> SVC3

When the amount of entries stored on SVC1 exceed some limits, a new service instance is set up (say SVC4), one (or more) slots formerly managed by SVC1 are moved to SVC4 (the content of SVC1 is re-distributed to SVC1 and SVC4) and the proxy configuration is changed accordingly, for instance

S1,S2 --> SVC1
S3 --> SVC4
S4,S5,S6 --> SVC2
S7, S8, S7, S10 --> SVC3

This does not solve the re-distribution problem. However, it is much easier to deal with this issue as the number of entries to be re-distributed is much smaller compared to a configuration where the max number of slots has not been planned upfront.

sunkeyvalue

Which I think is not an option in that case since the sunkeyvalue attribute is meant to be generic place holder for any key value pair and needs to be mulivalued.

The other thing, the value of this attribute being XML, it contains a special character which forces the value to be base64 encoded in LDIF (and thus in the DB representation of the entry). This increases the size of the value by at least 30%, thus the size of the data to write.

Directory Server 6 made serious improvement over this use case and the replication historical information will be lighter than with 5.2...

DN Binding with Empty Password

Bind with a DN and an empty password is a valid LDAP operation per the
LDAP v3 specifications (RFC 2251) and results in the user being
identified but not authenticated and not authorized...
The result is that the bind is successful but the connection is treated
as an anonymous operation.

Note that this behavior is now discouraged in RFC 4513 and Directory
Server 6 has a configuration parameter to accept or reject these requests.

DS Instance Life cycle

"Disorderly shutdown" message is logged when DS starts and does not find the guardian file that DS writes when it closes the database properly.

Then the server starts and opens the database in recovery mode. If it doesn't start at all, without starting the recovery, it might be a corruption of the config file (dse.ldif). There should be 2 other copies of the dse.ldif in the config directory: dse.ldif.bak (the previous version), dse.ldif.startok (the last one used to start the server). A working dse.ldif can be rebuilt from these files.

If it does go through the recovery mode but fails to recover the database, then you're in trouble. It means that either the DB files are corrupted or the transaction log file is.

One way to quickly recover the server can be to make a backup of another server with the same configuration (other master) and restore it on this server.