Attribute für Agentenfunktionen

IT Asset Management (Cloud)

Mit dem YAML-Dateiformat können Sie bestimmte Funktionen und Merkmale des Kubernetes-Inventarisierungsagenten von Flexera konfigurieren, indem Sie die in diesem Hilfethema beschriebenen Einstellungen verwenden.

Hinweis: Wenn Sie Helm-Chart-Vorlagen einsetzen möchten, um die Bereitstellungen des Kubernetes-Inventarisierungsagent von Flexeraen zu beschleunigen, stehen Ihnen zwei vordefinierte Kubernetes-Helm-Chart-Vorlagen zur Verfügung, die aus Bibliotheken abgerufen werden können, die auf der Flexera AWS ECR gehostet werden - https://gallery.ecr.aws/flexera/:

Für den vollständigen Kubernetes-Inventarisierungsagenten von Flexera –https://gallery.ecr.aws/flexera/krm-chart
Für den Flexera-Kubernetes-Kompaktagenten – https://gallery.ecr.aws/flexera/lwk-chart.

Die Mehrheit der Optionen in der Datei values.yaml einer Helm Chart ist vordefiniert und zu jeder Option gibt es eine erläuternde Anmerkung. Für den vollständigen Kubernetes-Inventarisierungsagent von Flexeraen müssen Kunden die Optionen FlexNet Beacon URL (URL von FlexNet Beacon) und persistent storage (permanenter Speicher) und für den Kompaktagenten die Option FlexNet Beacon URL (URL von FlexNet Beacon) festlegen. Die Konfigurations- und Installationsschritte für den vollständigen Kubernetes-Inventarisierungsagent von Flexeraen finden Sie in der Onlinehilfe unter Helm Chart-Konfiguration und -Installation für den vollständigen Kubernetes-Inventarisierungsagenten von Flexera. Die Konfigurations- und Installationsschritte für den Kubernetes-Kompaktagenten finden Sie im Benutzerhandbuch Gathering FlexNet Inventory (FlexNet-Inventarisierung) unter Helm Chart-Konfiguration und -Installation für den Kubernetes-Kompaktagenten.

Integration des IBM-Lizenzservice

In Containern installierte Software von IBM erfordert die Nutzung des IBM-Lizenzservice, um die Lizenznutzung zu überwachen. Der Kubernetes-Inventarisierungsagent von Flexera ist mit dem IBM-Lizenzservice integriert und erfasst über das API des IBM-Lizenzservice die Kapazitätsnutzungsdaten des/r IBM-Produkts/e für diesen Cluster.

Zur Nutzung des IBM-Lizenzservice-API muss der Kubernetes-Inventarisierungsagent von Flexera zuerst das API suchen und dann das für die Authentifizierung verwendete Token abrufen. Dazu muss der Kubernetes-Inventarisierungsagent von Flexera mehrere unterschiedliche Ressourcentypen aus dem Cluster lesen, die er anderenfalls nicht zu lesen bräuchte. Die Berechtigungen zum Lesen dieser Ressourcen können bei der Installation aktiviert werden. Die Notwendigkeit des Hinzufügens dieser Berechtigungen kann ebenfalls umgangen werden, indem dem Kubernetes-Inventarisierungsagenten von Flexera alle benötigten Standardwerte in den Attributen der YAML-Datei bereitgestellt werden. (Die unter Erweiterte Attribute für den Kubernetes-Inventarisierungsagenten von Flexera aufgeführten Attribute sind darin nicht enthalten.)

Hinweis: Es muss der gesamte Satz an Werten zur Verfügung gestellt werden. Ist der Satz nicht vollständig, versucht der Kubernetes-Inventarisierungsagent von Flexera die fehlenden Werte zu ermitteln. Ausnahmen zu dieser generellen Aussage bilden die Einstellungen enable und tlsVerify (die auf jeden Fall erforderlich sind).

Bei Aktivierung (im Folgenden beschrieben) ermittelt der Kubernetes-Inventarisierungsagent von Flexera zuerst das Vorhandensein des IBM-Lizenzservice im Kubernetes-Cluster durch Suche nach der CustomResourceDefinition:

ibmLicensings.operator.ibm.com.

Tipp: Der Plural ibmLicensings ist in diesem Kontext kein Rechtschreibfehler, sondern hält sich an die Benennungskonvention von Kubernetes, bei der die Pluralform verwendet wird, wenn auf einen vollständig qualifizierten Ressourcentyp Bezug genommen wird.

Anschließend lädt er alle fehlenden Konfigurationswerte herunter, die erforderlich sind, um das API zu lokalisieren und sich bei ihm zu authentifizieren. Dazu liest er die Ressourcenkonfiguration ibmLicensing, sucht mithilfe der Etikettenauswahl nach Services im Kubernetes-Cluster und liest das Geheimnis, in dem das Token für die Authentifizierung enthalten ist.

Tipp: Wenn dieser Vorgang fehlschlägt oder der IBM-Lizenzservice im Kubernetes-Cluster nicht installiert ist, versucht der Kubernetes-Inventarisierungsagent von Flexera alle 5 Minuten, den Vorgang erneut durchzuführen. Der Grund dafür ist, dass Ihre Einstellungen in der YAML-Datei festlegen, dass Sie die Integration mit dem IBM-Lizenzservice aktivieren möchten. Wenn dieser erst zu einem späteren Zeitpunkt bereitgestellt wird, bewirken die regelmäßigen Überprüfungen durch den Kubernetes-Inventarisierungsagenten von Flexera, dass die Integration ohne weiteres Zutun Ihrerseits die Funktion aufnimmt. Wenn Sie das nicht beabsichtigt haben, setzen Sie die (als nächstes beschriebene) Einstellung einfach auf false zurück, um die Integration zu deaktivieren, da so auch der Vorgang der Überprüfung ausgeschaltet wird.

Der Kubernetes-Inventarisierungsagent von Flexera fragt bei folgenden Gelegenheiten nach dem API des IBM-Lizenzservice:

Sofort nach dem Start
Sofort nach der erfolgreichen Ermittlung des Service und der Konfiguration
Jeden Tag um 01:00 nachts (Ortszeit des Clusters)

Der Kubernetes-Inventarisierungsagent von Flexera verlangt bei jeder Abfrage des API einen Snapshot der Nutzung der letzten 180 Tage.

Aktivieren der Integration

Wenn dieses Attribut auf true gesetzt ist, ist die Integration des Kubernetes-Inventarisierungsagenten von Flexera mit dem IBM-Lizenzservice aktiv.

Wichtig: Voreingestellt ist der Wert false, bei dem der Kubernetes-Inventarisierungsagent von Flexera nicht mit dem IBM-Lizenzservice interagiert. Denken Sie daran, dass die Nutzung des IBM-Lizenzservice für die Compliance bei IBM-Lizenzen von Produkten, die in Kubernetes-Clustern ausgeführt werden, verpflichtend ist. Wenn Sie die Lizenzdaten, die vom IBM-Lizenzservice erfasst wurden, für Berichte in IT Asset Management importieren möchten, müssen Sie dieses Attribut auf true setzen.

Attribut	`spec.ibmLicensing.enable`
Typ	Boolescher Ausdruck
Beispiel	`true`

Mit dieser Einstellung sieht der entsprechende Abschnitt in der YAML-Datei ähnlich wie nachfolgend dargestellt aus:

apiVersion: agents.flexera.com/v1
kind: KRM
metadata:
  name: instance
spec:
  ibmLicensing:
    enable: true
...

Der Namensraum des IBM-Lizenzservice

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem vom IBM-Lizenzservice verwendeten Namensraum. Alternativ können Sie den Namensraum in diesem Attribut ausdrücklich angeben.

Attribut	`spec.ibmLicensing.namespace`
Typ	String
Beispiel	`ibm-common-services`

Der Service-Name

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem Service-Namen, der zur Anzeige des API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie den Namen in diesem Attribut ausdrücklich angeben.

Attribut	`spec.ibmLicensing.serviceName`
Typ	String
Beispiel	`ibm-licensing-service-instance`

Der Service-Port

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem TCP-Port im Service, der zur Anzeige des API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie den Port in diesem Attribut ausdrücklich angeben.

Attribut	`spec.ibmLicensing.servicePort`
Typ	Ganze Zahl (Integer)
Beispiel	`8080`

Das Service-Token

Wenn dieses Attribut ausgelassen wird, sucht der Kubernetes-Inventarisierungsagent von Flexera automatisch nach dem Token, das zur Authentifizierung beim API des IBM-Lizenzservice im Kubernetes-Cluster verwendet wird. Alternativ können Sie das Token in diesem Attribut ausdrücklich angeben.

Attribut	`spec.ibmLicensing.token`
Typ	String
Beispiel	`VoOMWJijBWuCxSxwgON11w7z`

Das Service-Protokoll

Wenn dieses Attribut ausgelassen wird, durchsucht der Kubernetes-Inventarisierungsagent von Flexera automatisch die Konfiguration, um zu ermitteln, ob das API des IBM-Lizenzservice über HTTPS bedient werden muss. Alternativ können Sie das Protokoll in diesem Attribut ausdrücklich angeben.

Attribut	`spec.ibmLicensing.https`
Typ	Boolescher Ausdruck
Beispiel	`true`

Das Service-Zertifikat

Wenn das API des IBM-Lizenzservice seine Dienste unter Verwendung eines nicht vertrauenswürdigen Zertifikats über HTTPS zur Verfügung stellt, kann diese Einstellung auf false gesetzt oder unbearbeitet gelassen werden (da der Standardwert „false“ lautet).

Wenn dieser Wert false (oder unspezifisch) lautet, versucht der Kubernetes-Inventarisierungsagent von Flexera nicht, die Echtheit des Zertifikats zu überprüfen.
Wenn dieser Wert true lautet, überprüft der Kubernetes-Inventarisierungsagent von Flexera das Zertifikat. Eine Verbindung mit dem IBM-Lizenzservice kann nicht hergestellt werden, wenn Folgendes gilt:
- Das Zertifikat ist nicht gültig.
- Das Zertifikat wurde von einem unbekannten Aussteller unterzeichnet.

Attribut	`spec.ibmLicensing.tlsVerify`
Typ	Boolescher Ausdruck
Beispiel	`false`

IT Asset Management (Cloud)

Current

Erweiterte Attribute für den Kubernetes-Inventarisierungsagenten von Flexera

IT Asset Management (Cloud)

Die folgenden Attribute steuern unbedeutendere Aspekte des Verhaltens des Kubernetes-Inventarisierungsagenten von Flexera. Alle haben sinnvolle Voreinstellungen, sodass es keinen triftigen Grund gibt, diese Attribute zu ändern, es sei denn, Sie benötigen eine sehr detaillierte Steuerung der Konfiguration in Ihrer Umgebung.

Inventarisierungsintervall

Legt die Zeitspanne fest, nach der der Kubernetes-Inventarisierungsagent von Flexera Inventar erfasst und hochlädt. Der Kubernetes-Inventarisierungsagent von Flexera legt die neuesten Daten zu jeder Cluster-Ressource, an deren Beobachtung er interessiert ist, in einem Zwischenspeicher (Cache) ab und behält Ressourcen in seinem Cache (selbst wenn diese gelöscht wurden), bis er sein Inventar das nächste Mal hochladen kann. Die Intervalleinstellung ist ein Kompromiss zwischen dem Datenvolumen, das im Cache zurückgehalten wird und bei einer bestimmten Inventarisierung hochgeladen werden kann, und der Anzahl der Inventarisierungen, die hochgeladen und importiert werden. Die Voreinstellung lautet 24h, sodass der Kubernetes-Inventarisierungsagent von Flexera sein festgelegtes Inventar einmal täglich erfasst und hochlädt.

Der Wert dieser Einstellung ist eine Zeichenfolge (String), bei der die von Kubernetes und der Programmiersprache Go etablierte Konvention beachtet wird. Diese schreibt eine ganze Zahl gefolgt von einem Einheitensuffix wie „s“ für Sekunden, „m“ für Minuten oder „h“ für Stunden vor, z. B. 12h für 12 Stunden.

Attribut	`spec.monitor.interval`
Typ	Dauer
Beispiel	`6h`

Eigenständige Aktualisierungen des Agenten und Richtlinien-Updates

Das Attribut downloadFromBeacon steuert, ob der Kubernetes-Inventarisierungsagent von Flexera Datenflüsse von seiner Inventarisierungsstation abwärts zulässt, wozu drei wichtige Kommunikationsarten gehören, die Einfluss auf den FlexNet-Inventarisierungsagenten haben, wenn er zur Software-Inventarisierung innerhalb des Containers angestoßen wird:

Updates der Agentenrichtlinie, die durch Inventarisierungsstationen als neue Versionen der Datei config.ini zur Verfügung gestellt werden, die vom zentralen Anwendungsserver verteilt wird
Weitere Erweiterungen der Inventarisierungsfunktionen, die als aktualisierte Versionen der InventorySettings.xml verteilt werden
Aktualisierte Versionen des FlexNet-Inventarisierungsagenten selbst

Der Standardwert dieses Attributs lautet true (wahr), unter der Annahme, dass Sie eine Software-Inventarisierung in Ihren Containern mit optimalen, vollständig aktualisierten Funktionen erwarten würden.

Wenn downloadFromBeacon auf true gesetzt oder ohne Spezifizierung gelassen wird, führt der Kubernetes-Inventarisierungsagent von Flexera die Richtlinienkomponente des FlexNet-Inventarisierungsagenten aus, um nach der neuesten Agentenrichtlinie (config.ini), nach Updates der Komponente für die Inventarisierung ohne Fußabdruck (ndtrack.sh) und nach der jüngsten Version der Datei mit Erweiterungsfunktionen InventorySettings.xml zu suchen und diese ggf. herunterzuladen.
Wenn downloadFromBeacon auf false gesetzt ist, lässt der Kubernetes-Inventarisierungsagent von Flexera diese Updates nicht zu. Stattdessen verwendet er die Version von ndtrack.sh, die mit dem Containerimage ausgeliefert wurde, und verwendet keine Kopie von InventorySettings.xml. Er verwendet außerdem die Datei config.ini, die mit dem Containerimage ausgeliefert wurde, auch wenn diese mit lokalen Patches für den Cluster aktualisiert werden kann (siehe Einspielen von Patches in die Datei config.ini mithilfe des Kubernetes-Inventarisierungsagenten von Flexera). Auch wenn es die empfohlene Herangehensweise ist, downloadFromBeacon in Situationen, in denen der Container während der Laufzeit unverändert bleiben muss, auf false (falsch) zu setzen, kann dies die Vollständigkeit des Inventars beeinflussen, das für Containerimages im Cluster erzeugt wird, insbesondere für Software von Anbietern wie Oracle und Microsoft.

Attribut	`spec.monitor.downloadFromBeacon`
Typ	Boolescher Ausdruck
Beispiel	`false`

Erfassen von Software-Inventar

Das Attribut imageInventory steuert die Erfassung von Software-Inventar der OCI-(Open-Container-Initiative-)Containerimages:

Wenn es auf true (der Standardwert) gesetzt oder ohne Spezifizierung gelassen wird, injiziert der Kubernetes-Inventarisierungsagent von Flexera die Inventarisierungskomponente des FlexNet-Inventarisierungsagenten (ndtrack.sh) in die Container im Cluster, um das Software-Inventar ihres Inhalts zu erhalten. Anschließend wird der Tracker (die Inventarisierungskomponente) wieder vollständig entfernt. Dieser Vorgang nennt sich Inventarerfassung ohne Fußabdruck.
Lautet die Einstellung false, deaktiviert der Kubernetes-Inventarisierungsagent von Flexera dieses Verhalten. Das bedeutet dann, dass der Kubernetes-Inventarisierungsagent von Flexera kein Software-Inventar aus einem Container im Cluster melden kann.
Wichtig: Wenn keine andere Inventardatenquelle die Software-Inventarisierung der Container übernimmt, kann der Lizenzstatus nicht korrekt ermittelt werden, was bei einem zukünftigen Compliance-Audit zu Problemen führen kann. Denken Sie daran, dass der IBM-Lizenzservice nur Software von IBM überwacht. Beachten Sie die Pflicht, den Verbrauch von Lizenzen anderer Software-Unternehmen zu überwachen.

Attribut	`spec.monitor.imageInventory`
Typ	Boolescher Ausdruck
Beispiel	`true`

Knotenkomponente

Das Attribut enable im node-Block der YAML-Datei bestimmt, ob die Komponente des Kubernetes-Inventarisierungsagenten von Flexera zur Überwachung von Knoten eingesetzt wird:

Bei der Einstellung true (der Standardwert) oder keiner Spezifizierung sind die normalen Vorgänge aktiviert.
Bei der Einstellung false wird die Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera nicht eingesetzt. Das bedeutet, dass kein Hardware-Inventar von den Worker-Knoten erfasst werden kann.

Warnung: Zwar steht die Option zum Deaktivieren der Knotenkomponente derzeit im Kubernetes-Inventarisierungsagenten von Flexera zur Verfügung, sie wird im Rest von IT Asset Management jedoch nicht unterstützt. Deaktivieren Sie die Knotenkomponente daher erst, wenn diese Warnung in einer künftigen Version nicht mehr vorhanden ist.

Attribut	`spec.node.enable`
Typ	Boolescher Ausdruck
Beispiel	`true`

Inventarisierungsintervall für Knoten

Das Attribut interval im node-Block der YAML-Datei legt fest, wie häufig (in welchen Zeitabständen) Hardware-Inventar für die Worker-Knoten im/in den Cluster(n) erfasst wird. Im Allgemeinen kann dieses Attribut ohne Spezifizierung gelassen werden, selbst wenn:

Sie über eine modifizierte Lizenz verfügen, die die Nutzung von IT Asset Management zur Bewertung des Sub-Capacity-Verbrauchs von IBM PVU-Lizenzen autorisiert (wenn die Bedingungen dieser modifizierten Lizenz verlangen, dass die zugrunde liegende Hardware alle 30 Minuten ausgewertet und ihr Bestand gemeldet wird), und
Sie IBM-Produkte auf einem oder mehreren Worker-Knoten ausführen, die durch IBM PVU-Lizenzen lizenziert sind und für Berechnungen des Sub-Capacity-Verbrauchs infrage kommen.

Das liegt daran, dass die Voreinstellung bereits auf 30m gesetzt ist, sodass es nicht nötig ist, eine Spezifizierung vorzunehmen, um die IBM-Anforderungen für die Meldung von Sub-Capacity-PVU-Punkten zu erfüllen.

Attribut	`spec.node.interval`
Typ	Dauer
Beispiel	`30m`

Inventarisierungsberechtigung für Knoten

Das Attribut privileged im node-Block der YAML-Datei legt fest, ob die Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera die Hardware-Daten von Worker-Knoten vollständig erfassen kann, insbesondere die Daten aus dem BIOS. Um dies zuzulassen, muss für die Container, die als Bestandteil der Knotenkomponente des Kubernetes-Inventarisierungsagenten von Flexera eingesetzt werden, das Attribut privileged in ihrem Sicherheitskontext gesetzt sein.

Bei der Einstellung true (der Standardwert) oder keiner Spezifizierung sind die normalen Vorgänge aktiviert.
Wenn die Einstellung false lautet, verfügen die Container der Knotenkomponente nicht über das Attribut privileged und können die entsprechenden Daten daher nicht melden.

Attribut	`spec.node.privileged`
Typ	Boolescher Ausdruck
Beispiel	`true`

Kontrollknoten erzwingen

In Kubernetes kann die Markierung (taint) node-role.kubernetes.io/master verwendet werden, um Pods zurückzuweisen, damit sie auf den Knoten der Kontrollebene (control plane) nicht eingeplant werden.

Wenn forceControlPlane auf true gesetzt ist, werden die Pods der Knotenkomponente mit einer entsprechenden Toleranz erstellt, um zu erzwingen, dass sie auf den Knoten der Kontrollebene ebenso eingeplant werden wie auf den Worker-Knoten.
Wenn dieser Wert auf „false“ (Standardwert) gesetzt oder nicht spezifiziert ist, wird die Toleranz auf die Pods der Knotenkomponente nicht angewendet. Inventar wird dann nur von den Worker-Knoten erfasst.

Attribut	`spec.node.forceControlPlane`
Typ	Boolescher Ausdruck
Beispiel	`true`

Erneute Versuche, eine Verbindung mit dem Knoten herzustellen

Diese Attribute brauchen nur selten gesetzt zu werden. Zusammen legen Sie das Verhalten der Knotenkomponente fest, während sie auf den Start der Monitorkomponente wartet:

Beim Start versucht ein Pod der Knotenkomponente, sich mit der Monitorkomponente zu verbinden.
Wenn der Verbindungsversuch fehlschlägt, wartet er für readyWait Sekunden und versucht dann erneut, eine Verbindung herzustellen.
Er wiederholt die Versuche readyRetries Mal, danach werden die Versuche eingestellt und der Pod ist fehlgeschlagen.
Die Knotenkomponente DaemonSet startet den Pod automatisch neu.

Attribut	`spec.node.readyWait`
Typ	Dauer
Beispiel	`10s`

Attribut	`spec.node.readyRetries`
Typ	Ganze Zahl (Integer)
Beispiel	`20`

Hochladen vom Knoten gescheitert

Dieses Attribut braucht nur selten gesetzt zu werden. Der Standardwert ist false, was bei einem Scheitern des Hochladens von Inventar dazu führt, dass der Pod weiter ausgeführt wird und den Upload des Inventars später erneut versuchen kann. Wenn dieses Attribut auf true gesetzt ist, führt ein fehlgeschlagenes Hochladen von Inventar dazu, dass der Pod der Knotenkomponente fehlschlägt.

Attribut	`spec.node.mustUpload`
Typ	Boolescher Ausdruck
Beispiel	`true`

Host-Pfade für Knoten-Einbindungen

Das Attribut mountHostFS im Knoten-Block der YAML-Datei bestimmt, ob die Knotenüberwachungskomponente des Kubernetes-Inventarisierungsagenten von Flexera die Datei /etc/os-release und das Verzeichnis /var/lib in schreibgeschützter Version nur mit Leserechten aus dem Dateisystem des Knoten-Hosts einbinden darf.

Die Datei /etc/os-release des Knotens wird in den krm-Daemonset-Pod als /flexera-daemonset-node-host-os-release (Zugriff nur mit Leserechten) eingebunden und BS-Inventar wird aus der Datei /flexera-daemonset-node-host-os-release erfasst und nicht aus /etc/os-release des krm-Daemonset-Pods (der die Ubuntu 22.04-BS-Info des Pod-Image und nicht die Infos über das eigentliche BS der Knoten zurückmelden würde).

Das Verzeichnis /var/lib des Knotens wird in den krm-Daemonset-Pod als /flexera-daemonset-node-host-var-lib/ (nur mit Lesezugriff) eingebunden und das Inventar an BS-Packages wird erfasst, indem das unten dokumentierte Attribut spec.node.collectHostRpmInfo aktiviert wird.

Wichtig: Für eine Änderung dieser Einstellung müssen Sie das Attribut spec.node.enable auf false setzen und die Einstellung übernehmen, dann auf true setzen und die Einstellung übernehmen. Dieses Vorgehen ist erforderlich, um die Volume-Einbindedefinitionen aus der krm-Daemonset-Definition zu entfernen bzw. zu dieser hinzuzufügen.

Beachten Sie außerdem: Die Verwendung einer hostPath-Einbindung (siehe hostPath volume type in der Onlinehilfe-Dokumentation von Kubernetes) kann durch eine Sicherheitsrichtlinie des Pods blockiert werden, die geprüft werden müsste, um diese Option für den krm-Daemonset-Pod zuzulassen.

Attribut	`spec.node.mountHostFS`
Typ	Boolescher Ausdruck
Beispiel	`true`

Erfassen von RPM-Package-Informationen des Knoten-Hosts

Das Attribut collectHostRpmInfo im Knoten-Block der YAML-Datei bestimmt, ob die Knotenüberwachungskomponente des Kubernetes-Inventarisierungsagenten von Flexera RPM-Package-Nachweise aus dem Dateisystem des Knoten-Hosts erfassen darf.

Das RPM-Package-Inventar wird aus dem eingebundenen Verzeichnis /flexera-daemonset-node-host-var-lib/ durch Zugriff auf die RPM-Sqlite-DB im Verzeichnis /flexera-daemonset-node-host-var-lib/rpm, falls dies existiert, mit folgenden RPM-Befehl erfasst: /bin/rpm --dbpath /flexera-daemonset-node-host-var-lib/rpm --query --all --queryformat ....

Wichtig: Das oben erwähnte Attribut spec.node.mountHostFS muss aktiviert sein (true), damit dieses Attribut funktionieren kann.

Attribut	`spec.node.collectHostRpmInfo`
Typ	Boolescher Ausdruck
Beispiel	`true`