This mirrors a nearly identical change made to apt_repository.py.
Also removes the use of apt-get --force-yes as it can be dangerous
and should not be necessary (apt_repository.py does not use it).
Repeating the explanation from the apt_respository change below:
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 thoroughly inspect for a security audit.
In this case, the '&&' can be replaced by doing 2 calls to run_command.
Since there is no shell escape of the password parameter, a password with
a single quote (or even worst, a single quote and a pipe) could have
unattended consequences. Also, the less we use use_unsafe_shell=True, the
better.
Without this change, some trouble may occur when "deb" parameter
is used as env vars controlling dpkg are not set. For example,
installing a package that requires user input will never end since
DEBIAN_FRONTEND=noninteractive is not set.
So export env vars in APT_ENV_VARS before run dpkg, like in cases
using apt-get/aptitude.
* 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.
