Versions Compared

Old Version 44

changes.mady.by.user Liz Nemsick

Saved on

compared with

New Version 45

changes.mady.by.user Liz Nemsick

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Function Name

Description

simpkv::delete

Deletes a key from a backend.

simpkv::deletetree

Deletes an entire folder from a backend.

simpkv::exists

Returns whether a key or key folder exists in a backend.

simpkv::get

Retrieves the a key’s value and any user-provided metadata stored for a key it from a backend.

simpkv::list

Returns a listing of all keys and sub-folders in a folder in a backend

The list operation does not recurse through any sub-folders. Only information about the specified key folder is returned.

simpkv::put

Sets the a key’s value and optional, user-provided metadata for a key it in a backend.

Backend logical structure

...

To facilitate implementations of this tree, key and folder names are restricted to sequences of alphanumeric, ‘.', ‘_', and ‘-’ characters, with '/' used as the path separator. Furthermore, when specifying the path to a key in an access operation, the path cannot contain relative path subsequences (e.g., '/./' or '/../').

...

  • Each backend has its own configuration.

  • All backends Each backend configuration block must specify simpkv plugin type (e.g., ‘file’, ‘ldap’) and a user-provided instance identifier.

    • A plugin is a backend interface written in Ruby and conforming to an explicit plugin API and expected behavior. It is the logic that actually affects the keystore operation when a simpkv::* function is called during a Puppet catalog compilation. For the ‘ldap' plugin, this will be the software that modifies key/value pairs stored in an LDAP server.

    • The same plugin can be used for multiple backend instances.

    • The combination of plugin type and instance identifier uniquely identifies a backend instance.

  • Each backend configuration block may specify additional, plugin-specific configuration (such as LDAP server URL and port, TLS configuration,…).

...

Value Type

Serialization Example

Basic value* 1 without metadata

{"value":"the value","metadata":{}}

{"value":10,"metadata":{}}

Basic value with user-provided metadata****3

{"value":true,"metadata":{"optional":"user","extra":"data"}}

Complex value** 2 with basic sub-elements with no user-provided metadata

{"value":[1,2,3],"metadata":{}}

Binary value*** 4 transformed by simpkv with no user-provided metadata

{"value":"<Base64 string>","encoding":"base64","original_encoding":"ASCII-8BIT","metadata":{}"}

*‘Basic value’ 1 ‘Basic value’ refers to a string, boolean, or numeric value.

**2 'Complex value’ value’ refers to an array or hash constructed from basic values.

3 simpkv currently only supports metadata hashes comprised of basic values.

***4 simpkv currently provides limited support for binary data.

  • simpkv attempts to detect when the value is Puppet Binary type, transforms it into Base64 and records the transformation with ‘encoding' and 'original_encoding' attributes in the JSON. It then uses those attributes to properly deserialize back to the binary on a retrieval operation.

  • simpkv does does not support binary data in arrays, hashes, or the metadata.

****simpkv currently only supports metadata hashes comprised of basic values.

LDAP Directory Information Tree design

...

  • There must be one LDAP backend DIT for all SIMP application data.

    • This is distinct from the DIT containing user accounts data.

    • Data to be stored must include simpkv data.

    • Data to be stored may in the future include other application data, (e.g., IP firewall data).

  • The simpkv data must be a subtree of the DIT.

  • The simpkv subtree must support partitioning the data into LDAP backend instances.

  • The simpkv subtree must allow storage of per-LDAP-backend-instance global and environment-specific key/value entries.

    • Entries may be stored in subtrees within the LDAP instance subtree.

    • Each key/value entry must be a leaf node in the LDAP instance subtree.

    • The DistinguishedName (DN) to each key/value entry throughout the entire DIT must be unique.

  • The JSON value of the key/value entry must be stored in some form in the key/value entry.

    • The key/value entry may have an a single attribute containing the JSON-encoded value.

    • The key/value entry may have multiple attributes that map to the value’s JSON attributes.

  • The tree must support efficient simpkv::get, simpkv::exists, and simpkv::list operations.

    • Folder and/or key objects may store data in attributes to leverage LDAP search capabilities.

    • The simpkv LDAP plugin should nothave to retrieve the entire tree or subtree in order to fulfill any of these operations.

  • Any custom schema attributeType or objectClass will be specified with an Object Identifier (OID) below the official SIMP Object Identifier (OID).

...