DirXMLDev 0.62.0

Upgrading: two things a deploy now does differently.

• New Remote Loader drivers need two secrets. A deploy that creates a driver whose auth server is REMOTE(hostname=… port=…)… now counts it as a Remote Loader driver, as it does one with the Remote Loader shim. It needs <driver>.remote-loader-password and <driver>.driver-object-password in the secrets file, or the deploy is refused (--allow-missing-secrets overrides). Existing drivers are not affected unless you pass --secrets all and the secrets file has those keys.
• --secrets missing|all stays within --driver. A one-driver deploy no longer plans or sets other drivers' secrets.

Added

• The driver object password, the one the Remote Loader signs in to the engine with, is a secret kind of its own:
  key <driver>.driver-object-password, and driver.secrets set --kind driver-object. It is set as a user's
  password is, with an LDAP modify of the driver object's userPassword. remove refuses it: eDirectory replaces
  an object password but has no clearing it.
  • A deploy: a new Remote Loader driver needs it, as it needs the Remote Loader password. On an existing driver,
    --secrets all sets either one only when the secrets file has it, since both have to match the Remote Loader's
    own configuration.
• driver.secrets list says whether the driver object, application and Remote Loader passwords are set, from the
  engine's GetPasswordsState (no values).

Fixed

• A driver whose Remote Loader connection is in its auth server (REMOTE(hostname=… port=…)…, as Designer writes it
  for a native shim such as AD's), or whose shim is the Remote Loader proxy, is now seen as a Remote Loader driver.
  Before, only a Remote Loader shim parameter counted, so a deploy never set such a driver's Remote Loader password.
• vault.deploy --driver … --secrets missing|all now reaches only the drivers it is scoped to. Before, it planned the
  secrets of every driver in the set, so a one-driver deploy was refused for other drivers' missing secrets (or would
  have set them).
• engine.stats and driver.status print a driver's cache size with its unit (cache=465 bytes), so it is not
  taken for a number of events. The engine reports the cache's size in bytes; driver.cache view counts the events
  (465 bytes was 2 events). The JSON fields cacheSize and unprocessedSize keep their names and values; the docs
  now say they are bytes. docs/operate.md no longer says driverset.status counts events or that
  driver.cache clear takes its count from GetDriverStats.