Fixlet “RHSA-2022:1915 - Httpd:2.4 Security And Bug Fix Update - Red Hat Enterprise Linux 8 (x86_64)” has relevance of:
exists file "/var/opt/BESClient/EDRDeployData/Module_cmd_output.txt"
What is this relevance and how does this file get created?
The file gets created by Task 601 “List enabled modules to file using RHSM Download plugin - RHEL 8 - x86_64 (Prerequisite).bes” in the “Patches for RHEL 8” site
I’ll ask the patch team to advise, as I’m not intimately familiar with this, but it appears to be checking whether Modules are enabled for any given product (Modules basically behave to group RPM packages together into a single baseline, that must all be upgraded together, while isolating the Module/group from other RPM packages on the system). I don’t think Modules can be detected with built-in inspectors, hence the need to run some ‘dnf’ commands periodically to report on them.
This is new to RHEL 8, there was no Module functional in RHEL 7 and earlier, as far as I recall. A very large number of the RHEL 8 fixlets rely on Module patching and include the relevance that checks for the Module_cmd_output.txt, so if you’ll need to run that task on your RHEL 8 systems to get a clear picture of what updates are applicable.
Do you know if that Task 601 “List enabled modules to file using RHSM Download plugin - RHEL 8 - x86_64 (Prerequisite).bes” should need to be ran on a reoccurring schedule or just once at time of computer registration?
Based on the fixlet description, it should be re-run periodically (in case Module packages are added or removed). The description and the default action settings recommend re-running it once a day.
Does this fixlet also require a configured RHEL Download Plugin to run on the root server that connects to RedHat for package data? Is this fixlet documented anywhere?
Also .bes at the end of the task name seems like a bug
Agree on the .bes in the title name being a bug, I reported that to the Patch team yesterday.
We have a description of the Module/Stream patching functionality at https://help.hcltechsw.com/bigfix/10.0/patch/Patch/Patch_RH/deployment_of_modular_fixlet_on_rhel8.html?hl=dnf
The task does appear to require the RHSM plugin. Are you using local yum repos? I’ll check whether there’s a different task (or something we need to add) to enable that functionality without the RHSM plugin
Yes, we are using local yum repos by setting _BESClient_RHEL_AllowYumDownloads=1
Running the task “List enabled modules to file using RHSM Download plugin - RHEL 8 - x86_64 (Prerequisite)" allowed the rhel8 patch fixlet to install successfully, even with the _BESClient_RHEL_AllowYumDownloads=1 client setting set so that is good to see.
What I don’t understand is why these patch fixlets require Module_cmd_output.txt evaluation. RHEL7/RHEL8 both receive packages and decencies via yum/dnf from the repo. Why does it matter that “dnf module list” be ran by the task to generate the output so the fixlet can evaluate it when the fixlet already knows what rpm packages are installed that it will patch.
If the above is necessary, In order to not have this task re-occurring on all RHEL8 endpoints for the patch fixlet to be relevant, Can a BigFix Client inspector be created to retrieve the module/appstream list? Understanding this is an enhancement that I would need to submit an Idea for but the fewer moving parts the better.
