The information on this page refers to LM-X v6.1.1 or newer, which introduced the vendor secure store API.

LM-X vendor secure store

Vendor secure store lets custom, vendor-specific data in LM-X server callbacks persist securely on the license server host. Vendor secure store is intended for small pieces of callback state data (such as counters, flags, timestamps, or similar data) that must survive license server restarts without being exposed in a license file or server configuration file.

The vendor secure store API is available from custom vendor code, including LmxServerStartup, LmxServerShutdown, LmxServerFunction, and other callbacks in lmx_server_conf.c.

For additional information, see Secure store.

How vendor secure store works

The LM-X license server registers the secure store implementation before loading the vendor callbacks. Vendor code uses the public helper functions declared in lmx_server_conf.h:

LMX_STATUS VendorStoreSave
(
   const char *szVirtualFilename,
   const char *szString
);

LMX_STATUS VendorStoreLoad
(
   const char *szVirtualFilename,
   char *szString
);

Parameters

szVirtualFilename
[in] Filename under which data should be stored in the virtual filesystem.

szString
[in] The content to store in the client store.

Return values

On success, this function returns the status code LMX_SUCCESS.

On failure, this function returns an error code in the format described in Return codes.


Each stored value is identified by a virtual filename. LM-X maps the virtual filename to an internal secure store entry, so the virtual filename is not a literal filesystem path.

Stored values persist across license server restarts on the same server host. They are not part of the license file, are not written to lmx-serv.yaml, and are not automatically shared between different license server machines.

Saving data

Use VendorStoreSave to save or replace a value.

LMX_STATUS LmxServerStartup(const LMX_LICENSE_INFO *pLI)
{
  (void)VendorStoreSave("startup_state", "server-started");

  return LMX_SUCCESS;
}

Passing NULL or an empty string as szString removes the stored value for the specified virtual filename.

VendorStoreSave("startup_state", "");
VendorStoreSave("startup_state", NULL);

Loading data

Use VendorStoreLoad to read a stored value. The output buffer should be large enough for the maximum LM-X long string plus the terminating null character.

void LmxServerFunction(char *szMessage)
{
  char szStoredValue[LMX_MAX_LONG_STRING_LENGTH + 1] = {0};
  LMX_STATUS Stat = VendorStoreLoad("startup_state", szStoredValue);

  if (Stat == LMX_SUCCESS)
  {
    strncpy(szMessage, szStoredValue, LMX_MAX_LONG_STRING_LENGTH);
    szMessage[LMX_MAX_LONG_STRING_LENGTH] = '\0';
  }
  else
  {
    strncpy(szMessage, "No stored value", LMX_MAX_LONG_STRING_LENGTH);
    szMessage[LMX_MAX_LONG_STRING_LENGTH] = '\0';
  }
}

If szString is NULL, VendorStoreLoad returns only the status. This is useful when you only need to check whether a value exists.

if (VendorStoreLoad("startup_state", NULL) == LMX_SUCCESS)
{
  /* The value exists. */
}

Status codes

The following status codes are returned by the vendor secure store API.

Status codeMeaning
LMX_SUCCESSThe save, load, or delete operation completed successfully.
LMX_INVALID_PARAMETERThe virtual filename was NULL.
LMX_NOT_IMPLEMENTEDThe license server has not registered vendor secure store callbacks. This can occur if the functions are called outside the supported license server runtime context.
LMX_FILE_READ_ERRORThe value could not be loaded or does not exist.
LMX_FILE_SAVE_ERRORThe value could not be saved or deleted.

Virtual filename rules

Virtual filenames are logical identifiers used by vendor code. The filenames are case-insensitive; for example, Customer_State and customer_state are identified as the same stored value.

Use stable names and avoid deriving names from untrusted input without validation. Although LM-X does not use the virtual filename as a literal filesystem path, predictable names make callback code easier to maintain and avoid accidental collisions between unrelated callback features.

Recommended usage

Use vendor secure store for small, server-local callback states that belong to the vendor library. Recommended uses include:

  • Persisting callback-specific counters or flags
  • Remembering the last successful custom server-side action
  • Storing small vendor-defined state used by LmxServerFunction
  • Preserving callback state across a license server restart


Avoid storing large values. The API is string-based, and callback response buffers are limited by LMX_MAX_LONG_STRING_LENGTH.

Do not use vendor secure store as a general-purpose database, audit log, license transport mechanism, or cross-server synchronization mechanism.

Distribution

The vendor secure store API is implemented through the vendor library shipped with the LM-X license server. When distributing a license server to end users, continue to ship the vendor-specific library (liblmxvendor.dll, liblmxvendor.so, or liblmxvendor.dylib) together with lmx-serv.

No additional configuration is required in lmx-serv.yaml to enable vendor secure store.

  • No labels