6.6. 执行高级自定义 File Integrity Operator 任务
6.6.1. 重新初始化数据库
如果 File Integrity Operator 检测到计划进行的更改，则可能需要重新初始化数据库。
流程
使用
file-integrity.openshift.io/re-init注解FileIntegrity自定义资源（CR）：$ oc annotate fileintegrities/worker-fileintegrity file-integrity.openshift.io/re-init=
旧的数据库和日志文件已备份，新的数据库被初始化。旧的数据库和日志保留在
/etc/kubernetes下的节点上，参见使用oc debug生成的 Pod 中的以下输出：输出示例
ls -lR /host/etc/kubernetes/aide.* -rw-------. 1 root root 1839782 Sep 17 15:08 /host/etc/kubernetes/aide.db.gz -rw-------. 1 root root 1839783 Sep 17 14:30 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_38 -rw-------. 1 root root 73728 Sep 17 15:07 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_55 -rw-r--r--. 1 root root 0 Sep 17 15:08 /host/etc/kubernetes/aide.log -rw-------. 1 root root 613 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_38 -rw-r--r--. 1 root root 0 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_55
为了提供一些永久记录，生成的配置映射不归
FileIntegrity所有，因此需要手动清理。因此，任何之前的完整性失败仍在FileIntegrityNodeStatus对象中可见。
6.6.2. 机器配置集成
在 OpenShift Container Platform 4 中，集群节点配置通过 MachineConfig 对象提供。您可以假定因 MachineConfig 对象导致的对文件进行的更改是预期行为，不应该导致文件完整性扫描失败。为禁止由于 MachineConfig 对象更新导致对文件进行更改，File Integrity Operator 会监视节点对象；在更新节点期间，会暂停 AIDE 扫描。更新完成后，数据库会重新初始化并恢复扫描。
此暂停和恢复逻辑只适用于通过 MachineConfig API 进行的更新，因为它们反映在节点对象注解中。
6.6.3. 探索守护进程集
每个 FileIntegrity 对象代表多个节点上的扫描。扫描本身由守护进程集管理的 Pod 执行。
要查找代表 FileIntegrity 对象的守护进程集，请运行：
$ oc -n openshift-file-integrity get ds/aide-worker-fileintegrity
要列出该守护进程集中的 Pod，请运行：
$ oc -n openshift-file-integrity get pods -lapp=aide-worker-fileintegrity
要查看单个 AIDE Pod 的日志，调用其中一个 Pod 上的 oc logs。
$ oc -n openshift-file-integrity logs pod/aide-worker-fileintegrity-mr8x6
输出示例
Starting the AIDE runner daemon initializing AIDE db initialization finished running aide check ...
由 AIDE 守护进程创建的配置映射不会保留，在 File Integrity Operator 处理后会被删除。但是，如果失败和出错，这些配置映射的内容会被复制到 FileIntegrityNodeStatus 对象指向的配置映射中。
