apt module hangs when aptitude asks for user input

[Debilski]

Issue Type:

Bug Report

Ansible Version:

ansible 1.6 (devel d287179) last updated 2014/04/30 10:47:45 (GMT +200)

Environment:

Debian 7

Summary:

aptitude unfortunately says the following on its man page:

-y, --assume-yes
       When a yes/no prompt would be presented, assume that the user entered “yes”. In
       particular, suppresses the prompt that appears when installing, upgrading, or removing
       packages. Prompts for “dangerous” actions, such as removing essential packages, will still
       be displayed. This option overrides -P.

This is contrary to apt-get -y, which will simply abort after having found a ‘“dangerous” action’.
So, in short using -y is not enough to make aptitude fully non-interactive and may regularly (e.g. it also chokes on non-authenticated packages) cause ansible to freeze without further notice.

Steps To Reproduce:

Example task apt: upgrade=safe update_cache=yes to be executed on a machine with e.g. unauthenticated packages.

Real output of aptitude safe-upgrade -y on that machine would be:

# aptitude safe-upgrade -y
The following packages will be upgraded: 
  iceweasel libmms0 libmozjs24d mcollective-puppet-agent mcollective-puppet-common xulrunner-24.0 
6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 22.5 MB/22.5 MB of archives. After unpacking 127 kB will be freed.
WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

  xulrunner-24.0 iceweasel libmozjs24d 

Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": 

… and there it waits for user input.

Expected Results:

Ansible should simply fail the apt task.

Actual Results:

Ansible hangs and gives no information whatsoever.

[jimi-c]

Can you try the following patch on the apt module?

diff --git a/library/packaging/apt b/library/packaging/apt
index 1bce437..3024ecf 100755
--- a/library/packaging/apt
+++ b/library/packaging/apt
@@ -392,7 +392,7 @@ def upgrade(m, mode="yes", force=False,
         if apt_cmd == APT_GET_CMD:
             force_yes = '--force-yes'
         else:
-            force_yes = ''
+            force_yes = '--assume-yes --allow-untrusted'
     else:
         force_yes = ''
 

[Debilski]

That would only work with force=yes, right? (Cannot quite test it at the moment because the formerly failing packets have now been added to a ‘good’ repository.) So, without force, it would still freeze. (And I wouldn’t want to use force but rather fail in this case.)

There doesn’t seem to be a --forbid-untrusted option in aptitude, unfortunately (or an option to make it completely non-interactive). At least from what I could find…

[jimi-c]

Yes, you would have to force it. The only other option would be to add another configuration option for aptitude (aptitude_options, like dpkg_options), however it looked like most of the relevant configuration options were represented by command-line flags.

[mpdehaan]

It sounds like we should have some code that catches that there is a prompt and then fails suggesting adding force.

[mpdehaan]

Hi!

Thanks very much for your interest in Ansible. It sincerely means a lot to us.

On September 26, 2014, due to enormous levels of contribution to the project Ansible decided to reorganize module repos, making it easier
for developers to work on the project and for us to more easily manage new contributions and tickets.

We split modules from the main project off into two repos, http://github.com/ansible/ansible-modules-core and http://github.com/ansible/ansible-modules-extras

If you would still like this ticket attended to, and believe this problem or idea is still present in the latest version of Ansible (1.7.2) or the development branch, we will need your help in having it reopened in one of the two new repos, and instructions are provided below.

We apologize that we are not able to make this transition happen seamlessly, though this is a one-time change and your help is greatly appreciated --
this will greatly improve velocity going forward.

Both sets of modules will ship with Ansible, though they'll receive slightly different ticket handling.

To locate where a module lives between 'core' and 'extras'

• Find the module at http://docs.ansible.com/list_of_all_modules.html
• Open the documentation page for that module
• If the bottom of the docs say "This is an extras module", submit your ticket to https://github.com/ansible/ansible-modules-extras
• Otherwise, submit your pull request to update the existing module to https://github.com/ansible/ansible-modules-core
• action_plugins (modules with server side components) still live in the main repo. If your ticket affects both, open the ticket
  on the module repo just the same.

Additionally, should you need more help with this, you can ask questions on:

• the ansible-project mailing list: https://groups.google.com/forum/#!forum/ansible-project

Thank you very much!

[mpdehaan]

Hi!

Thanks very much for your interest in Ansible. It sincerely means a lot to us.

On September 26, 2014, due to enormous levels of contribution to the project Ansible decided to reorganize module repos, making it easier
for developers to work on the project and for us to more easily manage new contributions and tickets.

We split modules from the main project off into two repos, http://github.com/ansible/ansible-modules-core and http://github.com/ansible/ansible-modules-extras

If you would still like this ticket attended to, and believe this problem or idea is still present in the latest version of Ansible (1.7.2) or the development branch, we will need your help in having it reopened in one of the two new repos, and instructions are provided below.

We apologize that we are not able to make this transition happen seamlessly, though this is a one-time change and your help is greatly appreciated --
this will greatly improve velocity going forward.

Both sets of modules will ship with Ansible, though they'll receive slightly different ticket handling.

To locate where a module lives between 'core' and 'extras'

• Find the module at http://docs.ansible.com/list_of_all_modules.html
• Open the documentation page for that module
• If the bottom of the docs say "This is an extras module", submit your ticket to https://github.com/ansible/ansible-modules-extras
• Otherwise, submit your pull request to update the existing module to https://github.com/ansible/ansible-modules-core
• action_plugins (modules with server side components) still live in the main repo. If your ticket affects both, open the ticket
  on the module repo just the same.

Additionally, should you need more help with this, you can ask questions on:

• the ansible-project mailing list: https://groups.google.com/forum/#!forum/ansible-project

Thank you very much!