* This keeps us from hitting bugs in repoquery/yum plugins in certain
instances (#2559).
* The previous is also a small performance boost
* Also in is_installed(), when using the yum API, return if we detect
a package name has been installed. We don't need to also check
virtual provides in that case. This is another small performance
boost.
* Sort the list of packages returned by the list parameter.
Since use_unsafe_shell is suspicious from a security point
of view (or it wouldn't be unsafe), the less we have, the less
code we have to toroughly inspect for a security audit.
In this case, the '&&' can be replaced by doing 2 calls to run_command.
The yum module allows the 'name' parameter to be given as 'pkg', in
a similar way to some of the other package managers. This change
documents this alias.
The module's 'state' parameter has two other aliases, in line with
the 'apt' action; the 'state' parameter can take 'installed' as an
alias for 'present', and 'removed' as an alias for 'absent'. These
aliases are documented.
Closes#1189.
This will cause the settings in Ansible to override the system settings.
That will have no effect except on systems that have an out-of-Ansible
configuration that disables automatic installation of recommended
packages. Previously, ansible would use the OS default whenever
install_recommends wasn't part of the playbook. This change will cause
the Ansible default configuration setting of installing recommended
packages to override the configuration files set on the OS for things
installed through ansible, even when there is no install_recommends
specified in the playbook. Because the OS default matches the Ansible
default, this shouldn't have wide impact.
This was originally required to allow other methods in SourcesList to
fail, but subsequent changes rendered that unnecessary, and it's just
a cleanup now, and avoids passing in module separately to save().
1. Don't test check_mode in both the caller and in the callee.
2. Don't test HAVE_PYTHON_APT inside an if that tests HAVE_PYTHON_APT
3. Don't be irritatingly vague about why the module fails ("You may be
seeing this because…").
Note that if «apt-get -y install python-apt» succeeds with rc==0, but
for some reason python_apt is not usable afterwards, this will break
because the imports in install_python_apt aren't wrapped inside a
try/except.
In other words, we assume that install_python_apt either succeeds or
fails with a traceback. This commit doesn't affect that behaviour.
The original problem is: apt_repository.py connect to launchpad on
every playbook run. In this patch apt_repository.py checks if required
repository already exists or not. If no - paa will be added, if yes -
just skip actions.
* Import url(lib|parse|lib2) if needed by the module rather than relying
on module_utils.urls to do so.
* Remove stdlib modules from requirements
* Use the if __name__ conditional for invoking main()
* Only install yum-utils if needed (b/c we're going to use repoquery)
* Add a warning message explaining that why slower repoquery was used
rather than yum API.
commit logs it looks like we weren't previously doing that because of
commit 14479e6adc
The message there is that Yum API prints an error message if the
rhn-plugin is in use and no rhn-certificate is available. So instead of
using repoquery in preference always here we use repoquery in preference
if the rhn-plugin is enabled.
- Replaced some unsafe practice with default parameters. However looking at the code this does not seem to matter much as the calling functions always seem to supply these parameters anyway.
When subscribing a system with an activationkey, it seems (sometimes?)
required to pass the "--org <number>" parameter to subscription-manager.
Activation Keys can be created through the Red Hat Customer Portal, and
a subscription can be attached to those. This makes is easy to register
systems without passing username/passwords around.
The organisation ID can be retrieved by executing the following command
on a registered system (*not* the account number):
# subscription-manager identity
URL: https://access.redhat.com/management/activation_keys
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
Prior to this commit, Ansible would pass '--activationkeys <value>' as a
literal string, which the remote server would interpret as a single
argument to subscription-manager.
This led to the following failure message when using an activation key:
subscription-manager: error: no such option: --activationkey "mykey"
Update the arguments so that the remote server will properly interpret
them as two separate values.
The ordering of disabling/enabling yum repositories matters, and
the yum module was mixing and matching the order. Specifically,
when yum-utils isn't installed, the codepath which uses the yum
python module was incorrectly ordering enabling and disabling.
The preferred order is to disable repositories and then enable them
to prevent clobbering. This was previously discussed in
ansible/ansible#5255 and incompletely addressed in 0cca4a3.
In cases when the python-apt package is not installed, ansible will
attempt to install it. After this attempt, it tries to import the
needed apt modules, but forgets to import the apt.debfile module.
The result is that playbooks that use the dpkg argument on a machine
that does not initially have the python-apt package available will
fail with the following error
AttributeError: 'module' object has no attribute 'debfile'
This patch adds the appropriate import to the apt module to ensure
that necessary libraries are available in cases when the dpkg argument
is being used on a system that does not initially have the python-apt
package installed
