Platform Service User Account Requirements

For consistent and appropriate access management across the Anzo platform environment, it is important to use the same service user account when installing and running all of the platform software. If possible, it is ideal to create an enterprise-level, LDAP-managed "anzo" service user account to use for installing and managing the platform. Having a central service account ensures that it is available across Anzo environments, enforces the use of a common user and group ID, and is managed in accordance with the permissions policies of your company.

This topic provides details about the access that the service user account is required to have to be able to install and run the components. It also includes important information about the account and its effect on the Anzo Server license as well as a caution on using local user accounts.

Account Access Requirements

The service user account should meet the following requirements:

  • The account should not have root user access.
  • The account must have a home directory on the local file system on the Anzo and AnzoGraph host servers.
  • The account should be used to install all of the component software. Make sure the account has read and write permissions for the installation directories. The default installation directory for Anzo components is /opt, but you can choose an alternate location during the installation.
  • The account should be used to start all component processes, i.e., the systemd units for all of the component services should be configured to run as the platform service user. Details about the systemd units are provided in the post-installation instructions for each component.
  • The account must have read and write access to the shared file store, i.e. the NFS mount location (see Platform Shared File Storage Requirements for more information). All files that are generated by the components will be owned by this user.

Additional Requirements for Container Image Integration

If you are considering using dynamic Kubernetes-based deployments or plan to deploy a single container image for testing (for example, with Docker or Podman), it is important to set the user account User ID (UID) and Group ID (GID) to 1000. Container images are hard-coded to run processes with a UID and GID of 1000. For integration between other components (such as the NFS) and the container environment, all components need to run with the same UID and GID.

If you are unable to map the user account UID and GID to 1000, you can modify anonuid and anongid in the NFS server export table to map all requests to 1000. To do so, add the following line to /etc/exports on the NFS server:

<mount_point> *(insecure,rw,sync,no_root_squash) x.x.x.x(rw,all_squash,anonuid=1000,anongid=1000

For example:

/global/nfs/data *(insecure,rw,sync,no_root_squash) x.x.x.x(rw,all_squash,anonuid=1000,anongid=1000)

Licensing and the User Account

When the Anzo server is initially installed, a server ID is generated based on a number of system properties, including the user account that runs the installation script. The server license is tied to that server ID. If Anzo is re-installed (for instance, during an upgrade) by a different user account, a new server ID is generated and the existing license becomes invalid for the current installation. Whenever you upgrade or re-install Anzo, it is important to use the same user account that was used for the initial installation.

If Anzo is inadvertently updated by the wrong user account, see Restoring the Server ID for instructions on correcting the issue.

Cambridge Semantics strongly recommends that you do not change the user running Anzo after installation. If it is absolutely necessary, the license can be changed so that it is associated with the new server ID, and Anzo can be restarted once the license is updated. However, using a new server ID resets (or regenerates from non-customer-specific templates) all previously configured OSGI properties to their default values. Changing the user should only be attempted if there is a complete record of all of the customized OSGI properties and their values as well as a thorough change log so that the configuration can be restored if necessary.

Caution on Using Temporary Local User Accounts

If necessary, you can create a temporary user account on the component host servers. Note, however, that using local accounts can cause issues when migrating Anzo or integrating with a central directory server. Any local user accounts must be assigned the same name, user ID, and group ID on all host servers and must also meet the requirements in Account Access Requirements above.