Global Configuration parameter list

Global configuration parameters provide basic information that is automatically supplied as the default during catalog creation and update as well as during Patching and Remediation Job creation. The following sections describe the configuration parameters and how to configure these parameters:

To have basic information automatically supplied during catalog creation and update as well as Patching and Remediation Job creation, configure global patch configuration parameters.

To configure global patch configuration parameters

From the Configuration menu, select Patch Global Configuration.
The Patch Global Configuration dialog box is displayed.
Update the parameters as necessary.
The parameters are divided into the following tabs:
- All Operating Systems — Configuration parameters options for a proxy server
- Platform-specific tabs – For each platform (such as the Windows tab and the Solaris tab) – Parameters that apply only to that specific platform type
- Shavlik URL Configuration — Configuration for connecting to Shavlik for downloading Microsoft Windows patch related metadata
  The Shavlik metadata download occurs during Live Browse operations of the Hotfixes node in a Server Object, or during a Catalog Update Job run for an online Windows Patch Catalog. For Offline Windows Patch Catalogs the metadata files must be added as Depot Files, as noted in the Patch catalog - Windows Catalog page.
  Note
  
  If you need to download the Shavlik .xml files for offline usage, you can get them from here:
  http://xml.shavlik.com/data/oem/BMC-Bladelogic/data/8.0/pd5.xml
  http://xml.shavlik.com/data/oem/BMC-Bladelogic/data/8.0/hf7b.xml
  To use these .xml files offline, put them in an NSH path that is visible to the BMC Server Automation application server, and change the Shavlik URL to the full NSH path (including the file name), for example: //myappserver/opt/bmc/BladeLogic/patching/pd5.xml.

Parameters on the All Operating Systems tab

Parameter	Description
Proxy Settings:
Proxy Server Type	Select the type of proxy server used: SQUID NTLM NTLM-V2 None — Select this option when you are not using a proxy server. Before you use a proxy server while patching, note the following: Patching jobs do not use the same proxy server settings as the Application Server. If the Application Server is configured with an NSH proxy server, ensure that the user performing patching is assigned with `NSH_Proxy.Connect` permission in addition to the default permissions that are assigned to the PatchingUser role. The `NSH_Proxy.Connect` permission allows the user to acquire NSH proxy credentials required to perform patch analysis. For more information, see Setting up a Network Shell client to run in proxy mode. If a patch is available only via FTP and an HTTP or HTTPS proxy is used, BMC Server Automation initiates a CONNECT request to the proxy for the FTP connection. This may require additional configuration on your proxy, to accept CONNECT requests for FTP requests. The SUMA command used in the SUMA download option, does not allow BMC Server Automation to configure a proxy server automatically. The proxy server must be manually configured by using the System Management Interface Tool (SMIT), which is recommended by IBM. Click here to view steps for configuring the repository server using SMIT. To configure a proxy server on repository server while using the SUMA download option, perform the following steps: On the repository server, start the System Management Interface Tool (SMIT) by running the `smit` command. Select the Communications Applications and Services option. Select the Create/Change Service Configuration option. Select the Create/Change Service Configuration option, once again. Select the Create/Change Primary Service Configuration option. In the entry field for Connection type enter HTTP_PROXY. Enter the IP address, port number, and authentication user ID of the proxy server that you want to use. You can now use the proxy server for creating an online or offline catalog with the SUMA download option. If you are using Red Hat Helper server to connect to Red Hat CDN, you must use the proxy settings defined in the Proxy Settings parameter.
User Name	Enter the user name required to log onto the proxy server. If this parameter is defined, the Internet connection is through the proxy server.
Password	Enter the password associated with the defined user name required to log onto the proxy server.
Domain	Enter the domain name of the proxy server.
Host	Enter the IP address or host name of the proxy server.
Port	Enter the port number used for communication with the proxy server. For a list of all port numbers used by BMC Server Automation, see BMC Server Automation ports.

Catalog Settings:
Use last successful catalog run	If a catalog update fails you can use the last successful run of the Patch Catalog update while executing the Patching job. Select Yes, if you want to use the last successful catalog run as input to run a Patching job. Select No, if you do not want to use the last successful catalog run as input to run a Patching job. The Catalog update job must be run successfully for you to execute the Patching job. Note: A set of additional checks are applied during a catalog update. If any of these checks fail, you can still analyze and deploy the patches by using the last successful update of the Patch catalog, by selecting Yes. However, if catalog update fails after these checks complete, the catalog or the repository might have been modified. In this case, you cannot use the last successful update of the Patch catalog to deploy the patch.

Platform-specific parameters

Note

The following table describes parameters that are platform specific. You must enter this information for every platform that you want to patch using BMC Server Automation.

Parameter (Only for Red Hat Linux)	Description
RHN Username	(Red Hat Linux only) User name for accessing the Red Hat Network. The user name entered in this field will appear as the default user name when creating a Red Hat patch catalog. In case of a change in your Red Hat Network credentials, ensure that you update the user name entered in this field.
RHN Password	(Red Hat Linux only) Password for accessing the Red Hat Network. The password entered in this field will be appear as the default password when creating a Red Hat patch catalog. In case of a change in your Red Hat Network credentials, ensure that you update the password entered in this field.


Yum Process Priority (nice value)	(Red Hat Linux only) Set the priority of a process. The default value is 0. You can set the value withing a range of -20 to 19. These range limits denote: -20: Process has high priority and gets more resources, thus slowing down other processes. 19: Process has lower priority and runs slowly itself, but has less impact on the speed of other running processes.

Parameter ( Only for Solaris)	Description
Oracle Username	(Solaris only) User name for accessing the Oracle website
Oracle Password	(Solaris only) Password for accessing the Oracle website
Ldom option	(Solaris Only) Options to patch independent Solaris logical domains (LDoms) simultaneously. For more information, see Patching Job - Independent Solaris LDoms can be patched simultaneously. The following options are provided: None (default value) — This option ignores the LDoms and treats the targets as physical installations of Solaris. Use this option if you want to ignore the LDoms even if LDom packages are installed on your computer. Stop Ldoms using ldm stop — This option stops the LDoms using the `ldm stop` command (however, the guest LDoms are not gracefully shut down). Shutdown Ldoms using ldm-names as hostname — This option executes the `shutdown` command on the guests by using the `nexec` parameter, and by using ldm-name as the hostname for nexec.
Single User Mode and Reboot Override File	(Solaris Only) The location in the Depot for the file used to override single-user mode and reboot settings for a particular patch.
Solaris Updates List File	(Solaris Only) The location of the file containing released information from Oracle about clusters. Information contained in this file is used to prepopulate the filter selection lists found in the patch catalog wizard.

Parameter (Only for Microsoft Windows)

Description

Windows Filter Configuration File

(Microsoft Windows Only) The location of the product_categories.xml file, which contains product information and metadata mapping information from Shavlik. Information contained in this file is used to populate the filter selection lists found in the patch catalog wizard.

For information about refreshing and customizing the product_category.xml file, click the following link:

Refreshing and customizing the product_category.xml file

To refresh the product_categories.xml file, perform the following steps:
1. Ensure that the Windows Filter Configuration File field is empty. if it already points to an existing product_categories.xml file, click the button to delete the file.
2. Click the button to refresh the latest metadata information from Shavlik.
To customize the products in the product_categories.xml file, perform the following steps:
1. 1. Export the product_categories.xml file by clicking the button.
  2. Customize the products in the exported product_categories.xml file based on your requirement.
  3. Use the Windows Filter Configuration File field to point to the modified file.
    Note: If you customize the products in a product_categories.xml file, new products will not be updated when you click the button and will have to be added manually to the file. However, the sub categories of products will still be updated when you click the button, and so any manual customization in the product sub categories might be overwritten.
  4. If you no longer want to use the customized product_categories.xml file, click the button to delete the customized file and then click the button to refresh the latest metadata information from Shavlik.

Command Priority

(Microsoft Windows only) One of the commands that BMC Server Automation runs on target servers during Patching Jobs consumes a large amount of CPU power. On servers that only have a single CPU, this consumption can give the appearance of a system hang. It may also have an effect on other processes that are running on the target server.

If you are patching single-CPU Windows servers, you can lower the priority for this command by using the Command Priority option. This option causes this specific command to run at a lower priority, slowing down this process, and allowing other processes to proceed normally.

Possible values are:

Normal
Below Normal

Default value is Normal.
Note: Changing this option affects all Windows Patching Jobs.

Parameter (Only for SuSE)	Description
SuSE Service Packs List File	(SuSE Only) The location of the file containing released information of service packs from Novell. Information contained in this file is used to prepopulate the filter selection lists found in the patch catalog wizard.
Novell Username	(SuSE Only) Username for accessing SuSE Linux Enterprise 9 URLs.
Novell Password	(SuSE Only) Password for accessing SuSE Linux Enterprise 9 URLs.
Novell Mirror Username	(SuSE Only) Username for accessing SuSE Linux Enterprise 10 and SuSE Linux Enterprise 11 mirror URLs.
Novell Mirror Password	(SuSE Only) Password for accessing SuSE Linux Enterprise 10 and SuSE Linux Enterprise 11 mirror URLs.

Parameter (Only for AIX)	Description
AIX Updates List File	(AIX Only) The location of the file containing released information from IBM about available Technology Levels and Service Packs. Information contained in this file is used to prepopulate the Technology Level and Service Pack filter selection lists found in the patch catalog wizard.
Analysis Option	(AIX Only) Select one of the following choices: Stop Analysis if any applied fileset found — Select to stop analysis if any fileset is found in the applied state on a target server. Analysis ends on that server but continues on all other target servers included in the Patching Job if the servers do not have filesets in the applied state. This option can also be set for an individual Patching Job. Continue Analysis if any applied fileset found — Analysis continues even if a fileset in the applied state is found on the target server.
Precommit Option	(AIX Only) Select one of the following actions: Commit All Applied — The state of all currently installed filesets is changed from Applied to Commit. None — The state of all currently installed filesets in the Applied state does not change.
Deploy Option	(AIX Only) Select one of the following actions: Apply and Commit — During deployment, all filesets for the target server are installed in the Commit state. Apply Only — During deployment, all filesets for the target server are installed in the Apply state.

Parameter	Description
Catalog Object Processor Batch Size	The default batch size used for parallel processing during a Catalog Update Job. The number of catalog objects processed by each batch. If no value is entered, the default value is 300. Note: Setting a lower default value speeds up catalog update but uses more work item threads and consumes more resources on the BMC Server Automation Console; conversely, setting a higher default value slows down catalog update but uses less work item threads and consumes fewer resources. After you set this value, do not change it unless specifically required.
Analysis Server Results Batch Size	The default batch size used for parallel processing during a Patching Job. The number of analysis processes handled by each batch. If no value is entered, the default value is set at 100. Note: Setting a lower default value speeds up analysis but consumes more resources on the BMC Server Automation Console; conversely, setting a higher default value slows down analysis but consumes fewer resources. After you set this value, do not change it unless specifically required.
Action on Failure	The action that BMC Server Automation takes if a patch fails to deploy: Ignore — Ignore the failure. The Deploy Job continues and the results show the job as succeeding. Abort — End the job and start a rollback. Continue — Continue despite the failure. The Deploy Job continues and the results show the job as failing. Note: On Linux platforms, patches are deployed by using the `blyum` utility. As a result, if you are applying a series of RPMs, and `blyum` fails to deploy any of the RPMs, it stops at that point. The value set in Action on Failure is ignored.
HTTP/HTTPS/FTP Connection Retry	(Windows, Solaris, Red Hat Linux, SuSE, and AIX) The number of attempts made before reporting failure if BMC Server Automation fails to connect to a vendor site.
HTTP/HTTPS/FTP Connection Timeout	(Windows, Solaris, Red Hat Linux, SuSE, and AIX) The length of time, in milliseconds, that BMC Server Automation waits before making another attempt to connect to the vendor site.
Patch deploy success return codes	The Deploy Job sends commands to the OS which in turn sends responses back to BMC Server Automation indicating that the commands succeeded. In most cases, standard commands are used but occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as success return codes.
Patch deploy failure return codes	The Deploy Job sends commands to the OS which in turn sends responses back to BMC Server Automation indicating that the commands failed. In most cases, standard commands are used. However, occasionally the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as failure return codes.
Patch deploy warning return codes	The Deploy Job sends commands to the OS which in turn sends warnings back to BMC Server Automation. In most cases, standard warnings are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as warning return codes.
Patch deploy reboot return codes	The Deploy Job sends commands to the OS which in turn sends back a request for reboot to BMC Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as reboot return codes.
Patch undeploy success return codes	(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS returns an exit code if the action was successful. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy success return codes.
Patch undeploy failure return codes	(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS returns an exit code if the action failed. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy failure return codes.
Patch undeploy warning return codes	(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS may return a warning. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy warning return codes.
Patch undeploy reboot return codes	(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS may send back a request for reboot to BMC Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as reboot return codes
Debian Linux Updates List File	(Ubuntu and Debian Only) The location of the file containing information for Version, Base URL, Distribution, Component, and Architecture. Information contained in this file is used to prepopulate the filters in the distributions tree view found in the patch catalog wizard. See Patch catalog - Ubuntu Catalog or Patch catalog - Debian Catalog for more information about the distributions tree view.
SSL CA Cert File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64) architectures)	The location of the CA certificate file (redhat-cacert.pem) that is copied from the `/etc/rhsm/ca/` directory of the Red Hat target server, see the Before you begin section of Creating a patch catalog.
SSL Client Cert File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64)* architectures)*	The location of the subscription certificate file (client-cert.pem) that is downloaded from the Red Hat subscription management service, see the Before you begin section of Creating a patch catalog.
SSL Client Key File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64) architectures)	The location of the system ID file (client-key.pem) that is downloaded from the Red Hat subscription management service, see the Before you begin section of Creating a patch catalog.

Options on the yum.conf tab for Red Hat Enterprise Linux, Oracle Enterprise Linux, and SUSE Linux Enterprise servers

On the yum.conf tab, perform either of the following actions:

Select the Use Default check box if you want to use a yum.conf file with default settings provided with BMC Server Automation.

Or

Deselect the Use Default check box if you want to use a custom yum.conf file. You can customize the yum.conf file to configure the different patch analysis and deployment parameters. Your desired entries should be added in the text box provided.
Click here to see a sample of a yum.conf file.
Example of a yum.conf file:
[main]
debuglevel=4
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=RedHat-release
tolerant=1
obsoletes=1
plugins=0
gpgcheck=0
bootloader=1

Note

The system default /etc/yum.conf file is not used in either case.

In addition to the options listed in the sample yum.conf above, if you want to avoid the removal of old RPMs during patch analysis when a native yum is used, you can include the installonly_limit option in the yum.conf file. For more information, see the description of this issue in Troubleshooting Patch Management issues.

For more information about all the options that you can include in the yum.conf file, see the yum.conf man page.

You can also customize the yum.conf file when you create a Patching Job. For more information, see Patching Job - Analysis Options for Red Hat Enterprise Linux, Oracle Enterprise Linux, and SUSE Linux Enterprise.

Parameters on the Shavlik URL Configuration tab

The Shavlik URL Configuration tab provides information about the configuration files required by Microsoft Windows.

PD5.cab or PD5.xml — Windows patch packaging information
HF7b.cab or HF7b.xml — Windows patch analysis SDK
oemcatalog.zip — Required by the Application Server to decrypt metadata files
partner.manifest.xml — Used internally by Shavlik

The following table lists the fields that are available for configuring the Shavlik files. To edit the details, select the file and click Edit Patch Configuration File.

Parameter	Description
Shavlik URL Configuration Type	(Read-only) The name of the configuration file downloaded from the Shavlik Technologies website.
URI (http URL/NSH path)	URL of the Shavlik Technologies website from where the PD5.xml or HF7b.xml, OemCatalog.zip, or partner.manifest.xml configuration file can be downloaded. Alternatively, you can enter the NSH location of the files on your servers. You can change this parameter to any URL that has valid copies of these files. Note: If a patch is available only via FTP and if an HTTP or HTTPS proxy is used, BMC Server Automation initiates a CONNECT request to the proxy for the FTP connection. This may require additional configuration on your proxy, to accept CONNECT requests for FTP requests.
Download	Select this parameter to begin downloading from the Shavlik Technologies website by using the URL that you provided in the URI box. The configuration files are stored on the file server in the templates directory.
Description	Enter a description for the URL/NSH path you entered in the URI box.
Check for updates	Select this option if you want to automatically check for updates and overwrite the existing PDF5.xml or HF7b.xml, oemcatalog.zip, or partner.manifest.xml files before every job run. However, if you leave this option unchecked, you must click Download to manually check for updates and overwrite the PDF5.xml or HF7b.xml, oemcatalog.zip, or partner.manifest.xml files. Warning: If this option is selected, you might experience performance degradation with windows hotfixes, when multiple job servers are running a single snapshot job on several hundred targets at the same time. If this occurs, you can try leaving this option unchecked, and manually checking for updates by clicking Download.

Where to go from here

Ensure that you have completed all tasks listed in Preparatory tasks for patch management.