.. -*- mode: rst -*-
.. _client-tools-yum:
============================
Bcfg2 RPM/YUM Client Drivers
============================
The RPM and YUM client drivers provide client support for RPMs
(installed directly from URLs) and Yum repositories.
Features
========
* Full RPM package identification using epoch, version, release and
arch.
* Support for multiple instances of packages with the Instance tag.
* Better control of the RPM verification using the pkg_checks,
pkg_verify and verify_flags attributes.
* Support for install only packages such as the kernel packages.
* Support for per instance ignoring of individual files for the RPM
verification with the Ignore tag.
* Multiple package Instances with full version information listed in
interactive mode.
* Support for installation and removal of gpg-pubkey packages.
* Support for controlling what action is taken on package verification
failure with the install_action, version_fail_action and
verify_fail_action attributes.
Installation
============
isprelink
---------
``isprelink`` is a Python module that can greatly improve the
performance of the ``RPM`` driver. It should be installed on any
system that has prelink installed and will be using the ``RPM`` driver.
Source can be found at ftp://ftp.mcs.anl.gov/pub/bcfg/isprelink-0.1.2.tar.gz
To compile and install prelink, execute::
python setup.py install
in the rpmtools directory. The elfutils-libelf-devel package is required
for the compilation.
There may also be RPMs available in the repositories for your distro.
Configuration and Usage
=======================
Loading of RPM
--------------
The RPM driver can be loaded by command line options, client
configuration file options or as the default driver for RPM packages.
From the command line::
bcfg2 -n -v -d -D Action,POSIX,Chkconfig,RPM
This produces quite a bit of output so you may want to redirect the
output to a file for review.
In the ``bcfg2.conf`` file::
[client]
drivers = Action,Chkconfig,POSIX,RPM
Configuration File Options
--------------------------
A number of paramters can be set in the client configuration for both
the RPM and YUM drivers. Each driver has its own section (``[RPM]`` or
``[YUM]``), and most of the same options are accepted by each driver.
An example config might look like this::
[RPM]
pkg_checks = true
pkg_verify = true
erase_flags = allmatches
installonlypackages = kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-default, kernel-largesmp-devel, kernel-largesmp, kernel-xen, gpg-pubkey
install_action = install
version_fail_action = upgrade
verify_fail_action = reinstall
installonlypackages
^^^^^^^^^^^^^^^^^^^
Install-only packages are packages that should only ever be installed
or deleted, not upgraded.
It is best practice to only ever install/delete kernel packages, the
wisdom being that the package for the currently running kernel should
always be installed. Doing an upgrade would delete the running kernel
package.
``gpg-pubkey`` will be automatically added to the list of install-only
packages.
Example::
[RPM]
installonlypackages = kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-default, kernel-largesmp-devel, kernel-largesmp, kernel-xen, gpg-pubkey
This option is not honored by the ``YUM`` driver.
erase_flags
^^^^^^^^^^^
erase_flags are rpm options used by 'rpm -erase' in the client ``Remove()``
method. The RPM erase is written using rpm-python and does not use
the rpm command.
The erase flags are specified in the client configuration file as a
comma separated list and apply to all RPM erase operations. The
following rpm erase options are supported. See the rpm man page for
details::
noscripts
notriggers
repackage
allmatches
nodeps
This option is not honored by the ``YUM`` driver.
pkg_checks
^^^^^^^^^^
The RPM/YUM drivers do the following three checks/status:
#. Installed
#. Version
#. rpm verify
Setting pkg_checks = true (the default) in the client configuration file
means that all three checks will be done for all packages.
Setting pkg_checks = false in the client configuration file means that
only the Installed check will be done for all packages.
The true/false value can be any combination of upper and lower case.
.. note::
#. pkg_checks must evaluate true for both the client (this option)
and the package (see the Package Tag pkg_checks attribute
below) for the action to take place.
#. If pkg_checks = false then the Pkgmgr entries do not need the
version information. See the examples towards the bottom of
the page.
pkg_verify
^^^^^^^^^^
The RPM/YUM drivers do the following three checks/status:
#. Installed
#. Version
#. rpm verify
Setting pkg_verify = true (the default) in the client configuration
file means that all three checks will be done for all packages as long
as pkg_checks = true.
Setting pkg_verify = false in the client configuration file means that
the rpm verify wil not be done for all packages on the client.
The true/false value can be any combination of upper and lower case.
.. note::
#. pkg_verify must evaluate true for both the client (this option)
and the package instance (see the Instance Tag pkg_verify
attribute below) for the action to take place.
install_action
^^^^^^^^^^^^^^
``install_action`` controls whether or not a package instance will be
installed if the package instance isn't installed.
If install_action = install then the package instance is installed.
If install_action = none then the package instance is not installed.
.. note::
#. install_action must evaluate true for both the client (this
option) and the package instance (see the Instance Tag
install_action attribute below) for the action to take place.
version_fail_action
^^^^^^^^^^^^^^^^^^^
``version_fail_action`` controls whether or not a package instance
will be updated if the installed package instance isn't the same
version as specified in the configuration.
If version_fail_action = upgrade then the package instance is upgraded
(or downgraded).
If version_fail_action = none then the package instance is not upgraded
(or downgraded).
.. note::
#. verion_fail_action must evaluate true for both the client (this
option) and the package instance (see the Instance Tag
version_fail_action attribute below) for the action to take
place.
verify_fail_action
^^^^^^^^^^^^^^^^^^
``verify_fail_action`` controls whether or not a package instance will
be reinstalled if the installed package instance fails the Yum or RPM
verify.
If verify_fail_action = reinstall then the package instance is reinstalled.
If verify_fail_action = none then the package instance is not reinstalled.
.. note::
#. verify_fail_action must evaluate true for both the client (this
option) and the package instance (see the Instance Tag
verify_fail_action attribute below) for the action to take
place.
#. The driver will not attempt to reinstall a package instance if
the only failure is a configuration file.
Interactive Mode
----------------
Running the client in interactive mode (-I) prompts for the actions to
be taken as before. Prompts are per package and may apply to multiple
instances of that package. Each per package prompt will contain a list
of actions per instance.
In the RPM driver, actions are encoded as:
* D - Delete
* I - Install
* R - Reinstall
* U - Upgrade/Downgrade
An example follows::
Install/Upgrade/delete Package aaa_base instance(s) - R(*:10.2-38.*) (y/N)
Install/Upgrade/delete Package evms instance(s) - R(*:2.5.5-67.*) (y/N)
Install/Upgrade/delete Package gpg-pubkey instance(s) - D(*:9c800aca-40d8063e.*) D(*:0dfb3188-41ed929b.*) D(*:7e2e3b05-44748aba.*) D(*:a1912208-446a0899.*) D(*:9c777da4-4515b5fd.*) D(*:307e3d54-44201d5d.*) (y/N)
Install/Upgrade/delete Package module-init-tools instance(s) - R(*:3.2.2-62.*) (y/N)
Install/Upgrade/delete Package multipath-tools instance(s) - R(*:0.4.7-29.*) (y/N)
Install/Upgrade/delete Package pam instance(s) - R(*:0.99.6.3-29.1.*) (y/N)
Install/Upgrade/delete Package perl-AppConfig instance(s) - U(None:1.52-4.noarch -> *:1.63-17.*) (y/N)
Install/Upgrade/delete Package postfix instance(s) - R(*:2.3.2-28.*) (y/N)
Install/Upgrade/delete Package sysconfig instance(s) - R(*:0.60.4-3.*) (y/N)
Install/Upgrade/delete Package udev instance(s) - R(*:103-12.*) (y/N)
GPG Keys
--------
GPG is used by RPM to 'sign' packages. All vendor packages are signed
with the vendors GPG key. Additional signatures maybe added to the rpm
file at the users discretion.
It is normal to have multiple GPG keys installed. For example, SLES10
out of the box has six GPG keys installed.
To the RPM database all GPG 'packages' have the name 'gpg-pubkey', which
may be nothing like the name of the file specified in the rpm -import
command. For example on Centos 4 the file name is RPM-GPG-KEY-centos4.
For SLES10 this means that there are six packages with the name
'gpg-pubkey' installed.
RPM does not check GPG keys at package installation, while YUM does.
RPM uses the rpm command for installation and does not therefore check
GPG signatures at package install time. RPM uses rpm-python for
verification and does by default do signature checks as part of the
client Inventory process. To do the signature check the appropriate
GPG keys must be installed. rpm-python is not very friendly if the
required key(s) is not installed (it crashes the client).
The RPM driver detects, on a per package instance basis, if the
appropriate key is installed. If it is not, a warning message is
printed and the signature check is disabled for that package instance,
for that client run only.
GPG keys can be installed and removed by the RPM driver. To install a
GPG key configure it in Pkgmgr/Rules as a package and add gpg-pubkey
to the clients abstract configuration. The gpg-pubkey package/instance
is treated as an install only package. gpg-pubkey packages are
installed by the RPM driver with the rpm -import command.
gpg-pubkey packages will be removed by ``bcfg2 -r packages`` if they are
not in the clients configuration.
Ignoring Files during Verification
----------------------------------
The :ref:`path-ignore` Path tag is used to exempt individual files
from the RPM verification. This is done by comparing the verification
failure results with the ignore Path. If there is a match, that entry
is not used by the client to determine if a package has failed
verification.
Path ignore entries can be specified at both the Package level, in
which case they apply to all Instances, and/or at the Instance level,
in which case they only apply to that instance.
See :ref:`path-ignore` for more details.
Example:
.. code-block:: xml