Patching config.ini through Flexera Kubernetes Inventory Agent

IT Asset Management (Cloud)

The Flexera Kubernetes Inventory Agent delegates several functions to the FlexNet Inventory Agent installed within its container. As always throughout IT Asset Management, the FlexNet Inventory Agent uses, as its primary configuration source, the config.ini file. When outside of containers, changes made at the central application server are distributed in the config.ini file to inventory beacons, and the FlexNet Inventory Agent installed locally on inventory devices regularly requests its updated configuration from there.

However, this process does not repeat on a regular schedule for the FlexNet Inventory Agent installed within containers – the config.ini file is updated from the inventory beacon only once, at container start-up (see the processing summary at the end of this topic). As well, the configuration may need to be customized for specific Kubernetes deployments. Whereas making such changes to a file in the container might be difficult within Kubernetes, the Flexera Kubernetes Inventory Agent includes a way to patch the local config.ini within the container.

At the high level:

Changes are supplied as patch files, each of which may contain one or more changes that need to be made to the config.ini file for FlexNet Inventory Agent within the container.
The patch files are stored within a ConfigMap in the cluster (a resources that stores key-value pairs as data sets). When used as the data source for a mounted volume within the container, each entry becomes a file, with the key being the file's name, and the value being the file's content. (Where multiple changes are needed, they may be combined into one patch file, or be listed as individual patch files, whichever is more convenient for your processes.)
When policy updates are enabled (which is the default, unless in the YAML file you have set spec.monitor.downloadFromBeacon to false), the patches are automatically applied to config.ini both:
- Before agent policy is downloaded (in case there are SSL configuration options required for communication with the inventory beacon); and
- After the Flexera Kubernetes Inventory Agent downloads the latest updates to config.ini from its inventory beacon, thereby ensuring that a policy update from the central application server does not negate the local patches to the config.ini file within this cluster.
(For a more complete description of this interaction, see the listing that follows this process.)

To use the Flexera Kubernetes Inventory Agent to patch config.ini:

Ensure that a sufficiently recent version of the Flexera Kubernetes Inventory Agent is installed.
As a minimum, version 1.3.0 must be installed. If this or a more recent version is already installed, no further action on this point is needed. If an earlier version is installed, update it by following the standard download/installation process until the install.sh script has successfully completed.
Tip: If you don't already know which version of Flexera Kubernetes Inventory Agent is installed within the cluster, it is reflected in the version of the deployed container image. For example, this container image:
```
flexera/krm:1.3.0
```
includes version 1.3.0 of Flexera Kubernetes Inventory Agent. You can inspect the image using the relevant controller deployment (all one command line, here wrapped for presentation):
```
kubectl get deployments --namespace flexera 
    krm-controller -o jsonpath={.spec.template.spec.containers[0].image}
```
On the same device used to install the Flexera Kubernetes Inventory Agent, prepare a file containing the patch to config.ini. Save the completed patch file in the current directory, accessible to your Kubernetes commands.
- You may give your patch files any file name you prefer, but all patch files must use the .ini file name extension.
- Patches consist of setting a value for a preference. You can find all the agent preferences described in detail in the Gathering FlexNet Inventory reference, and each description includes the registry path for the computer preference.
- The patch must be defined in the format used in config.ini:
  - The first line has the equivalent of the registry path in square brackets
  - The next line has the preference name and (if required) value.
For example, suppose your patch is to disable the use of certificate revocation lists within the cluster. Looking up the reference, you see the registry path is defined as [Registry]\ManageSoft\Common (where the placeholder for various forms of [Registry] is to be omitted, since config.ini functions as one of those forms). So you create a file called (say) patch.ini that contains these two lines:
```
[ManageSoft\Common]
CheckCertificateRevocation=False
```
Tip: To handle multiple changes:
- To include multiple patches in the same file, add a similar pair of lines for each setting change. For readability, you may choose to leave a blank line between each pair of lines defining a patch.
- To include multiple separate files, list them separately in the next step, but beware of defining overlapping modifications in different files. When multiple files are specified, they are processed in the order they appear in the directory listing (by default, alphabetically sorted by file name). If there are overlapping modifications, the last one processed provides the persistent value.
Create a configmap in the flexera namespace to store your patch file(s).
Tip: The flexera namespace is mandatory.
You may name the configmap as you please (as always, using only lowercase alphanumeric characters, '-' or '.'). For example, we might name it agent-config. Assuming our previous example of patch.ini as the file containing the patch to be applied, the command line becomes:
```
kubectl create configmap agent-config --namespace flexera --from-file=patch.ini
```
Of course, substitute your own values for the configmap name and the patch file name.
Edit the YAML file for the Flexera Kubernetes Inventory Agent (see Editing configuration for the Flexera Kubernetes Inventory Agent) to reference the newly-created configmap.
This is achieved by setting the spec.monitor.configPatch attribute, the value of which is a ConfigMapVolumeSource, a Kubernetes type that describes how a configmap should be converted into a storage volume. Typically, the value only needs to refer to the configmap by name. For example, using the same example agent-config name for the configmap, the edited section of the YAML file becomes:
```
apiVersion: agents.flexera.com/v1
kind: KRM
spec:
  monitor:
    configPatch:
      name: agent-config
```

Tip: Further background information for a deeper understanding of the processes involved: once you have created your patch(es) and identified them in a configmap, the automated process for applying updates to the config.ini file fits in with the overall instantiation and operational cycle for the Flexera Kubernetes Inventory Agent like this:

The container for the Flexera Kubernetes Inventory Agent is created, and at this time it contains the unmodified config.ini pseudo-registry configuration file that was initially deployed with the FlexNet Inventory Agent.
The configmap defined in the YAML file is mounted as a file system.
The binary for the Flexera Kubernetes Inventory Agent starts running within the container.
The Flexera Kubernetes Inventory Agent creates a simple bootstrap config file that specifies the links to/from its inventory beacon with the MGSFT_BOOTSTRAP_DOWNLOAD and MGSFT_BOOTSTRAP_UPLOAD settings (learn more about these in the Gathering FlexNet Inventory reference, in the topic Agent third-party deployment: Configure the Bootstrap File for UNIX). It then runs mgsconfig -a, which applies the 'answer file' to the configuration.
Now the Flexera Kubernetes Inventory Agent detects the mounted ConfigMap file system, and runs mgsconfig -i for each file in that file system whose name ends with the .ini suffix. This applies the patches to the config.ini file. These patches may potentially contain settings required for communication with the inventory beacon, and so are applied at this time before any attempt is made to download policy.
The Flexera Kubernetes Inventory Agent now uses the policy component from the FlexNet Inventory Agent, running mgspolicy -t machine to fetch the latest config.ini file that is available from its inventory beacon.
Note: This update of config.ini from the inventory beacon happens only once, at this point in the container start-up. Long-running containers do not check with any inventory beacon for updates to agent policy settings (in the config.ini file) on any regular schedule. In this, they differ from the FlexNet Inventory Agent installed on a free-standing device (not in any container).
Because the downloaded device policy is unlikely to include any of the cluster-specific patches, the Flexera Kubernetes Inventory Agent re-runs mgsconfig -i for all the available .ini files to restore the patches to the newly-downloaded config.ini file.
The Flexera Kubernetes Inventory Agent connects to Kubernetes and begins collecting inventory data, flushing its collected data into an .ndi file.
Asynchronously, the FlexNet Inventory Agent may be triggered to collect software inventory from the container as well. It saves its inventory to its own .ndi file in the persistent storage you declared in the YAML file.
The Flexera Kubernetes Inventory Agent then runs another component of the FlexNet Inventory Agent, ndupload, to transfer the .ndi file(s) to the inventory beacon (using the settings in the config.ini file).
The two agents continue collecting inventory data for a period (by default, 24 hours), and then repeat the cycle of flushing collected data to .ndi file(s) and uploading them to the inventory beacon.

IT Asset Management (Cloud)

Current