NCM::Component::spma::yumng¶
NAME¶
NCM::Component::spma::yumng - NCM SPMA configuration component for Yum, new generation
SYNOPSIS¶
This document describes how to control the behaviour of the package manager itself. For information on how to manage packages with Quattor, please check http://quattor.org/documentation/2013/04/05/package-management.html.
RESOURCES¶
/software/components/spma/active
: boolean
Activates/deactivates the component.
Flags for Yum processing:¶
/software/components/spma/process_obsoletes
: boolean
Make Yum replace obsoleted packages by their recommended counterparts. Defaults tofalse
to keep backwards compatibility.
/software/components/spma/userpkgs
: string (“yes|no”)
Whether SPMA should keep any packages the user may have installed manually.
Set to
no
to make the SPMA take full control of all your software installations. Set toyes
to preserve any packages you installed by hand. If you do so, SPMA will never remove a package.
/software/components/spma/userpkgs_retry
: boolean
Yum-based spma might get confused and fails when it tries to remove packages when
userpkgs
isno
while installing new ones. Typically it will (try to) remove a leaf package, that is also to be installed as a dependency of a new to-be-installed package.With
userpkgs_retry
set totrue
, the package update process will be retried in case of failure in 2 steps, a first retry while preserving the installed packages, and if this retry was succesful, followed by a second retry where it will (try to) remove leaf packages again.
/software/components/spma/excludes
: string[]
Packages listed in this list will be ignored by Yum. It will make them invisible from metadata. Globs can be used for items in this list.
/software/components/spma/yumconf
: string
Yum configuration file (/etc/yum.conf
) which SPMA will create on a box before any package operations.
/software/components/spma/whitelist
: string[]
List of globs to specify packages which are ignored by SPMA. These packages will remain in place and will not be removed upon SPMA execution. Typical use case is 3rd party custom installations where an installer is executed and it generates/installs packages on its own. Without this feature SPMA would remove such packages.
/software/components/spma/quattor_os_file
: string
File name which will contain custom build information generated by SPMA upon successful completion.
/software/components/spma/quattor_os_file
: string
String to be put in quattor_os_file upon successful SPMA completion.
/software/components/spma/proxy
: string (“yes|no”)
Whether to use a proxy.
/software/components/spma/proxytype
: string (“forward|reverse”)
Type of proxy (reverse or forward).
/software/components/spma/proxyhost
: string
Comma-separated list of proxy hosts. If you have a forward proxy you should specify only one. You may specify several reverse proxies here, and they will be appended to thebaseurl
entry of each repository’s configuration.
/software/components/spma/proxyport
: string
Port where the proxies are listening.
/software/components/spma/run
: string (“yes|no”)
Whether to actually run Yum operations that may install, remove or update packages.
/software/components/spma/fullsearch
: boolean
Yum-based spma will try to verify that all version locked packages can actually be found in the provided repositories. For packages that have versions with wildcards specified, a full (and possibly slow) search of each pattern can be performed by settingfullsearch
to true. By default, the fullsearch is not performed, and for any packages that have versions with wildcards, it is assumed that the repositories contain them.
FILES¶
/etc/spma.conf
/var/lib/spma-target.cf
SEE ALSO¶
You must read this document to understand how to manage packages with Quattor:
http://quattor.org/documentation/2013/04/05/package-management.html,
These links detail experiences and strategies relevant for managing software installations in large sites: