Page Comparison

...

Below is an example of the Option 1 DIT in which simpkvEntry is a custom LDAP object class with simpkvKey and simpkvJsonValue attributes holding the key and value, respectively:

...

The second design option enforces DN case invariance without impacting the existing simpkv API. Its simpkv subtree has the same essential layout as that of Option 1, including the use of the ‘instances’, 'globals', and ‘environments’ grouping “folders”. However, in this design the LDAP plugin transforms any problematic attributes that are to be used in a DN for a key/value pair to an encoded representation (e.g., hexadecimal, Base 64) . For example, with a hexadecimal transformation, all backend instance identifiers, key names, and folder names would be represented in hex, minus the ‘0x’ or ‘0X’ preface**. . (The Puppet environment does not require transformation, as Puppet environment names must be lowercase.) So, key paths production/app1/key1 and production/App1/Key1 would be mapped to
simpkvHexId=61707031,simpkvHexId=6b657931,ou=production,ou=environments,...
and
simpkvHexId=41707031,simpkvHexId=4b657931,ou=production,ou=environments,...
respectively, where simpkvHexId is an attribute of both a simpkvFolder LDAP object used to represent backend identifiers/folders and a simpkvEntry LDAP object used to store the key/value pair.

**Puppet environment names are not allowed to include uppercase letters.

In addition, in this design includes an attribute with the raw identifier in each node with an encoded identifier in its RDN in would contain an attribute with the raw identifier.

...

RDN. Although this means a little more data must be stored in the DIT, this extra information will support external searches of the LDAP tree

...

Some ‘OrganizationalUnits’ in Option 1 would now be represented by a custom object that had encoded and raw identifier attributes.

...

using the raw backend instance identifiers, key names, and folder names. In other words, users can search the LDAP tree without being forced to mimic the transformations done in simpkv::* functions.

Below is an example of the Option 2 DIT in which

• simpkvFolder is a custom LDAP object class with simpkvHexId and simpkvId attributes holding the transformed backend identifier/folder and raw identifier/folder, respectively

• simpkvEntry is a custom LDAP object class with simpkvHexId, simpkvId and simpkvJsonValue attributes holding the transformed key, raw key and JSON-formatted value, respectively.

Recommendation

...

• It yields a DIT that is simple to understand and navigate.

• An API change is not unexpected for simp/simpkv, since it is still experimental (version < 1.0.0) and not used by default.

• SIMP can help users with the transition to lowercase key names for any existing simpkv key paths or simplib::passgen password names (whether using legacy mode or simpkv mode).

  • Any SIMP-provided modules that uses simplib::passgen can be modified to ensure the password names are downcased.

  • The simplib::passgen function that uses simpkv can be modified to downcase existing password names that have any uppercase letters and then to emit a warning.

  • In the script SIMP will provide to import any existing simpkv key entries or simplib::passgen passwords into an LDAP simpkv backend, there can be a check for uppercase letters in the destination key paths. The script can either skip the import of the problematic entries, or convert to lowercase and warn the user of the conversion. Then, it would be up to the user to make any adjustments to their manifests.

...