Frequently Asked Questions

To better understand BigFix Patch for Rocky Linux, read the following questions and answers.

The Manage Download Plug-ins dashboard is not reflecting any data. What do I do?

Here are some steps you can do to troubleshoot the issue:

Gather the latest Patching Support site.
Activate the Download Plug-in Versions analysis, available from the Patching Support site.
Clear the BigFix console cache.

What are superseded patches?

Superseded Fixlets are Fixlets that contain outdated packages. If a Fixlet® is superseded, then there exists a newer Fixlet® with newer versions of the packages. The newer Fixlet® ID can be found in the description of the superseded Fixlet®.

Where are the deployment logs located on endpoints?

The logs are located in a folder called EDRDeployData in the client folder at /var/opt/BESClient/EDRDeployData.

Why is my action reporting back as a failed download?

Make sure your download plug-in has been updated to the latest version and is registered with the correct credentials.

What do I do when an action reports back with an installation failure?

Check to see if the conflict is caused by a vendor-acquired package. These must be removed for the installation to occur.

I am not able to patch an Fixlets on endpoints with the /var directory mounted as noexec. What do I do?

For the workaround, see Frequently Asked Questions.

How do I verify if the download plug-in was registered correctly?

Run a Fixlet with an action task to verify if the download plug-in is registered correctly. Verify that the patch download is successful. Otherwise, you might need to unregister the download plug-in and register it again.

How do I register a download plug-in? Do I use the register download plug-in task or the Manage Download Plug-in dashboard?

To register a download plug-in, you must use the Manage Download Plug-in dashboard in the Patching Support site. Existing register download plug-in tasks are being deprecated. To learn more about plug-in registration, see Frequently Asked Questions.

Note: You must also use the Manage Download Plug-in dashboard to unregister, configure, and upgrade download plug-ins. The existing unregister and edit download plug-in tasks are being deprecated. For more information about the dashboard, see the topic on Manage Download Plug-ins dashboard in the BigFix Knowledge Center.

Which version of the DNF native tools must be used?

The Patches for Rocky Linux native tools site requires version 3.2.19-18 or later.

An action failed and the logs contain DNF-specific errors. How do I troubleshoot the failed action?

For more information about DNF and errors that are related to it, see the YUM documentation at http://yum.baseurl.org and the DNF-related articles in the Red Hat Customer Portal.

Can previously configured repositories be configured again?

Yes, you can configure again a previously configured repository.

From the logs, can I tell if I am using the normal DFN process to the repository in the log?

Yes, the log indicates whether the normal DNF process in the repository is used.

What is the difference between registering a repository and importing a repository?

Use the import feature if you have existing repositories that are not included in the Repositories list in the dashboard. Use the register feature if you already have a repository in the Repository list, but you still need to link the repository with the endpoint.

What happens when the repository does not contain the package?

When a package is not found, the Fixlet fails. You can troubleshoot from EDR_DeploymentResult.txt, which is where the DNF output is logged.

Can I install several packages using 'Task: Install packages by using DNF?

Yes, you can install several packages with the task. Use a space to separate the rpm names.

What version of DNF does the DNF Transaction History dashboard support?

You must have a minimum DNF version of 3.2.28.

Which version of Rocky Linux does the DNF Transaction History dashboard support?

The dashboard supports Rocky Linux versions 8.

In the DNF Transaction History dashboard, what is the difference between rollback and undo?

The rollback command will undo all transactions up to the point of the specified transaction. The undo command will revert the selected transaction only.

What is the difference between the DNF Transaction History log and DNF Logs analyses?

Patch Management for Rocky Linux generates the DNF Transaction History log, which records the results of the actions that are taken in the DNF Transaction History dashboard. The log is located in /var/opt/BESClient/EDRDeployData/DNF_history.log.

The DNF log is the official log that is generated by DNF in /var/log/dnf.log by default. To change the default location, modify the log file settings in /etc/dnf.conf.

Does the DNF Transaction History dashboard show only dnf -update all?

Aside from dnf -update all, the Command Line column in the dashboard also shows the different transactions such as the following installation commands.

install bzip2
install net-tools
install vim enhance
install wget

To learn more about DNF commands, see the Red Hat Enterprise Linux website: https://access.redhat.com/.

How does the DNF Transaction History dashboard work if you have configured the BigFix client to use DNF repository?

The DNF Transaction History dashboard does not adversely affect your deployment if you have configured the BigFix client to use DNF repositories. If you already use a local DNF repository, it might be easier to provide the packages for rollback.

The client logs contains a prefetch plug-in error that prevents the Fixlet from completing successfully. What is causing the error? What should I do?

The ActionScript that was running on the endpoint might have been blacklisted, causing the prefetch plug-in issue.

To resolve this issue, restart the BigFix client to clear the blacklist. To prevent the script from being blacklisted, set the _BESClient_ActionManager_PrefetchPlugInTimeoutSeconds client configuration setting with sufficient time to process the patch. For more information, see Frequently Asked Questions.

Can I set the log level for the Rocky Linux Download Plug-in?

You can set the download plug-in to generate log messages depending on level of information that you need.

The logging level determines the amount of detail that the Rocky Linux Plug-in writes to the log files. Set the logging level in the %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\RockyLinuxProtocol\plugin.ini file.

Note: Logging level values are case-sensitive.

The following logging levels are listed in order of increasing amount of information logged:

ERROR: Contains errors related to the execution of the download plug-in, which might indicate an impending fatal error.
WARNING: Contains information about failed downloads, and reasons for failure.
INFO: Contains general information outlining the progress and successful downloads, with minimal tracing information.
DEBUG: Contains fine-grained information used for troubleshooting issues. This is the most verbose level available.
Note: Setting the logging level to DEBUG increases the amount of information to log, which might have an impact on performance. You must only increase the logging level to DEBUG when investigating an issue.

Where can I find the log for the Rocky Linux Download Plug-in? What are the possible log levels

Logging is controlled by the plugin.ini file. It is located with the download plug-in executable. By default, it is located in %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\RockyLinuxProtocol on Windows systems. On Linux system, it is in /var/opt/BESServer/DownloadPlugins/RockyLinuxProtocol. The log file is rotated on a daily basis, which means that a new log file is created and the old log file is renamed with the date that it is created from.

Will the Rocky Linux Download Plug-in configuration file (plugin.ini) be overwritten when there is a newer version of the download plug-in?

No, the configuration file will not be overwritten. The only time the configuration file is overwritten is when the download plug-in is reconfigured.

Can I reconfigure the Rocky Linux Download Plug-in proxy after registration?

Yes, you can update the proxy settings by configuring the download plug-in from the Manage Download Plug-ins dashboard.

What happens if I edit the DLRockyLinuxRepoList.json file with more repositories?

The changes that you make will be deleted when BigFix refreshes the Patching Support site as the file will be overwritten.

I have a subscription for extension products, can I configure the Rocky Linux Download Plug-in to access their assigned repositories?

Yes, you can. For more information, see Extending the Rocky Linux Download Plug-in.

Where should I save the extended repository list file?

The file can be stored in any location the download plug-in has access to. You must ensure that the BigFix server has permissions to access the location.

I am not able to install any packages since I upgraded to the Rocky Linux Plug-in. All tasks result in the following line: Failed add prefetch item {concatenation " ; " of lines of file (parameter "EDR_PkgRequest")}. What is wrong?

The BigFix Enhanced Security option -requireSHA256Downloads or Require SHA-256 Downloads option in the BigFix Administration tool might be enabled. This option configures all download verification to use only the SHA-256 algorithm. The Rocky Linux Download Plug-in might fail due to certain Rocky Linux repository metadata, which do not contain SHA-256 values for the packages in the repository, that are used by the plug-in.

Consider disabling the Require SHA-256 Downloads option to successfully deploy a patch. Security and package integrity is not compromised as another layer of checking and verification is done using the GPG signature of the package. For more information about the download option, see BigFix Platform Installation Guide at https://help.hcl-software.com/bigfix/9.5/platform/Platform/Installation/c_security_settings.html.

Can I configure the Rocky Linux Download Plug-in to only use the extended repository list?

Yes, you can by setting the onlyUseExtendedRepoListFile flag in the plugin.ini to yes.

When deploying multiple Fixlets in a baseline, is it possible to skip the broken dependencies and continue with the installation for the rest of the packages?

The Multiple-Package Baseline Installation task skips packages with broken dependencies whenever possible. Packages with dependency issues with Rocky Linux cannot be skipped. Another scenario where packages are not skipped is when dependency errors occur during installation, as indicated by the following error message:

File conflicts happen when two packages attempt to install files with the same
            name but different contents

. In such cases, the installation is canceled and no patches will be installed on the endpoints.

What are the possible causes of failure using the multiple-package baseline installation method?

The Fixlets might have failed to install due to the following reasons:

A custom site contained multiple baselines with the multiple-package baseline installation task running at the same time.
Two or more Fixlets required an update to multiple versions of the same package.
Two or more Fixlets required an update to the same package dependencies.
A Fixlet was immediately deployed after a baseline ran the multiple-package installation method. Not enough time was allowed to complete all DNF transactions and refresh the status on the endpoints for the multiple-package installation.
The DNF tool have not been patched, but a Rocky Linux release package is included in the baseline.
The Enable the Multiple-Package Baseline Installation feature task must be in the same baseline as the rest of the content. It should be added before the patch Fixlets and multiple-package installation tasks.
The Multiple-Package Baseline Installation feature only works when both the enable and installation tasks exist in the same baseline. For more information, see Installing multiple packages in a baseline.
The Enable the Multiple-Package Baseline Installation feature task must be added after any of these cleanup tasks: Delete Rocky Linux 8 Package List File for Multiple-Package Baseline Installation or TROUBLESHOOTING: Rocky Linux 8 Patching Deployment Logs - Cleanup.
The installation task with the correct Rocky Linux distribution, operating system version, service pack level, and architecture must be added at the end of the baseline.

My endpoints are on air-gapped environment, how should I configure BigFix to patch these endpoints?

For air-gapped environments, ensure to mirror the supported Rocky Linux repositories that host the packages needed to patch the endpoints. To do this, use the Rocky Linux Download Cacher to build the local repository on a location which the BigFix server has access to. This location is known as the local cache.

Note: The local cache must contain all the required repositories to avoid dependency resolution issues.

Configure the download plug-in configuration file, plugin.ini, to use the local cache when downloading files during deployment. Follow these steps:

Set the local cache configuration, localCache, to the location of the files that were downloaded using the download cacher tool.
Note: This location must be accessible to the BigFix server.
Set the localCacheOnly flag to yes. to download files from the download cache only and not from the vendor site.

I ran a baseline with the Multiple-Package Baseline Installation task. How can I view the list of Fixlets that failed in that baseline?

You can monitor of the overall progression of the deployment of the baseline and view the status of each sub-action in detail by using the View Action Info dialog.

To access this dialog:

Click the Action icon in the navigation tree.
Select an action in the Actions List Panel.
Select the Computers tab in the Work Area.
Right-click any computer in the list.
Either select Show Action Info from the context menu or select Show Action Info from the Edit menu.

For more details about the failed Fixlets, check the client log on the target endpoints at /var/opt/BESClient/__BESData/__Global/Logs.

The baseline that I ran with the multiple-package installation task completed successfully, but why does it still show as relevant.

It might be due to the Fixlet components that failed to install the packages with broken dependencies. The Multiple-Package Baseline Installation task, by default, ignores broken dependencies to allow packages without dependency issues to successfully be applied on the target endpoint.

Is there a way to check if the supported Rocky Linux repositories can be accessed?

From the command line, you can use the --check-baserepos and the --check-allrepos commands to check if the supported Rocky Linux repositories can be accessed. For more information about these commands, see Rocky Linux Download Cacher usage information.

For a list of the Rocky Linux repositories that BigFix supports, see the Support Matrix.

Is there a way to check for the required space when caching repository metadata and packages through the Rocky Linux Download Cacher tool?

Use the check-storagereq subcommand to check for the storage space requirement.

How can I save space when caching repository metadata and packages through the Rocky Linux Download Cacher tool?

Space-saving benchmarks are established with the use of the --sha1_download_dir.

Using the --sha1_download_dir have shown significant decrease in storage size, download size, and time when caching multiple repositories of the same Rocky Linux version. This is because many packages are duplicated among repositories with the same Rocky Linux version (for example, rockylinux-8.3-x64, rockylinux-8.4, rockylinux-8.5). Space is not saved if you only cache a single repository for each Rocky Linux version (for example, rockylinux-8.4, rockylinux-8.5).

An example output is as follows:

Caching rockylinux-8.3-x64, rockylinux-8.4, rockylinux-8.5 
(with --sha1_download_dir):
Total Repo Metadata and Packages will take up 28 GB of space 
instead of 37 GB (23% space saved)

What to do when Fixlets fail to install with the following message in the EDR log? "Warning: Nothing to install. Please check if you are using the latest kernel."

This message appears only in case of Fixlets that deploy kernel packages. A kernel Fixlet becomes relevant if the endpoint does not have the target kernel package installed or if the endpoint's active kernel is at a lower version than the target kernel package. An endpoint is still considered subject to kernel vulnerabilities even if it has the latest kernel installed but not using it actively.

To remediate the issue, restart the endpoint and ensure it is using the latest kernel available.