Frequently Asked Questions

To better understand BigFix Patch for CentOS, 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 Error when /var is mounted as noexec.

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 Registering the CentOS Download Plug-in R2.

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 YUM native tools must be used?

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

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

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

What version of YUM is required to use the CentOS Custom Repository dashboard?

You must have a minimum YUM version of 3.2.19-18.

Which CentOS Linux is supported by the CentOS custom repository dashboard?

The dashboard supports CentOS Linux versions 5, 6, and 7.

Which version of the BigFix server supports the CentOS Custom Repository dashboard?

The CentOS Custom Repository dashboard supports version 9.0 and later of BigFix.

When deploying patches, should I use the existing method or go through the custom repository? Can the two methods co-exist?

The two methods can exist together. However, when deploying patches for single clients, you must choose between using the native tools or through the custom repository method.

How are dependencies resolved the CentOS Custom Repository dashboard is used?

YUM uses the metadata to resolve the dependencies to know which packages are needed.

Can the custom repositories be used for software installation?

Yes, you use custom repositories for software installation. To use custom repositories for software installation, follow these steps:

Ensure that the clients are registered through the Custom Repository dashboard.
Create a Fixlet in the custom site with the actionyum install<space><package name>. Ensure that you set the correct relevance or success criteria, that is, whether the Fixlet takes action against that client or endpoint. To learn more about creating Fixlets, see the Console Operator's Guide.

Note: It is important to ensure that the repositories are updated. Actions can fail if the packages are not available.

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 YUM process to the repository in the log?

Yes, the log indicates whether the normal YUM 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 YUM output is logged.

What happens if there are issues with the custom repository solution?

Users that encounter issues with the custom repository resolution can revert to the standard BigFix server solution. Users can run the task that is called Disable custom repository support - CentOS.

In the Endpoints tab of the CentOS Custom Repository Management dashboard, are the repositories that are listed in the lower part of the window that is used in sequence?

There is no sequence in the repositories that are listed in the Endpoints tab. When YUM queries the repositories, the repository that first gets the fetch query replies, including the package and its dependencies.

Through the CentOS Custom Repository Management dashboard, a patch was deployed through a custom repository that is not a mirror of the manufacturer site. The deployment failed and the EDR logs indicate that the rpm files could not be opened. What should I do?

When a custom repository that is not a mirror of the vendor site is used, it is possible that the default gpgcheck is being done as part of the installation and the gpg signature files might not be included. The rpm files might not be checked for authenticity and the installation might fail. To resolve this, ensure that when you register the endpoints in the CentOS Custom Repository Management dashboard, you added 'gpgcheck=0' to Additional fields.

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

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

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

You must have a minimum YUM version of 3.2.28.

Which version of CentOS Linux does the YUM Transaction History dashboard support?

The dashboard supports CentOS Linux versions 5, 6, and 7.

In the YUM 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 YUM Transaction History log and YUM Logs analyses?

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

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

Does the YUM Transaction History dashboard show only yum -update all?

Aside from yum -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 YUM commands, see the Red Hat Enterprise Linux website: https://access.redhat.com/.

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

The YUM Transaction History dashboard does not adversely affect your deployment if you have configured the BigFix client to use YUM repositories. If you already use a local YUM 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 Prefetch plug-in error.

Can I set the log level for the CentOS Download Plug-in R2?

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 CentOS Plug-in R2 writes to the log files. Set the logging level in the %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\CentOSR2Protocol\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 CentOS Download Plug-in R2? 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\CentOSR2Protocol on Windows systems. On Linux system, it is in /var/opt/BESServer/DownloadPlugins/CentOSR2Protocol. 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 CentOS Download Plug-in R2 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 CentOS Download Plug-in R2 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 DLCentOSRepoList.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 CentOS Download Plug-in R2 to access their assigned repositories?

Yes, you can. For more information, see Extending the CentOS Download Plug-in R2.

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 CentOS Plug-in R2. 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 CentOS Download Plug-in R2 might fail due to certain CentOS 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.hcltechsw.com/bigfix/9.5/platform/Platform/Installation/c_security_settings.html.

Can I configure the CentOS Download Plug-in R2 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 CentOS 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 YUM transactions and refresh the status on the endpoints for the multiple-package installation.
The YUM tool have not been patched, but a CentOS 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 CentOS 6 Package List File for Multiple-Package Baseline Installation or TROUBLESHOOTING: CentOS 7 Patching Deployment Logs - Cleanup.
The installation task with the correct CentOS 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 CentOS repositories that host the packages needed to patch the endpoints. To do this, use the CentOS Download Cacher R2 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 CentOS repositories can be accessed?

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

For a list of the CentOS 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 CentOS Download Cacher R2 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 CentOS Download Cacher R2 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 CentOS version. This is because many packages are duplicated among repositories with the same CentOS version (for example, centos-6.8-x64, centos-6.7-x64, centos-6.6-x64). Space is not saved if you only cache a single repository for each CentOS version (for example, centos-6.8-x64, centos-7.1-x64).

An example output is as follows:

Caching centos-6.8-x64, centos-6.7-x64, centos-6.6-x64 
(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.