Cask installs that require a password fail

[ansibot]

From @edrozenberg on 2016-11-10T01:31:53Z

ISSUE TYPE

• Bug Report

COMPONENT NAME

homebrew_cask

ANSIBLE VERSION

ansible 2.2.0.0
  config file = 
  configured module search path = Default w/o overrides

CONFIGURATION

[defaults]
inventory             = hosts/hosts
vault_password_file   = ~/.ansible/vault/password.txt
retry_files_enabled   = False
retry_files_save_path = ~/.ansible/retry
remote_user           = root
nocows                = 0

[ssh_connection]
pipelining = True

OS / ENVIRONMENT

macOS Sierra 10.12.1 (16B2555)

One mac (controller) controlling another mac (minion) using normal ssh connection with ssh key.

SUMMARY

Some homebrew casks ask for a password during the installation process. It appears the ansible module does not provide a way to collect a password and pass it to the homebrew cask installer.

Currently, these casks that require a password need to be manually installed using 'brew cask install at the command line. Ansible cannot install them.

Found two casks so far that failed to install with Ansible, but work fine when done manually: microsoft-office and wireshark

STEPS TO REPRODUCE

- homebrew_cask: name=wireshark state=present

- homebrew_cask: name=microsoft-office state=present

EXPECTED RESULTS

wireshark cask and microsoft-office casks are installed

ACTUAL RESULTS

failed: [10.0.1.119] (item=wireshark) => {"failed": true, "item": "wireshark", "msg": "Error: Command failed to execute!\n\n==> Failed command:\n/usr/bin/sudo -E -- /usr/sbin/installer -pkg #<Pathname:/usr/local/Caskroom/wireshark/2.2.1/Wireshark 2.2.1 Intel 64.pkg> -target /\n\n==> Standard Output of failed command:\n\n\n==> Standard Error of failed command:\nsudo: no tty present and no askpass program specified\n\n\n==> Exit status of failed command:\n#<Process::Status: pid 29235 exit 1>"}

failed: [10.0.1.119] (item=microsoft-office) => {"failed": true, "item": "microsoft-office", "msg": "Error: Command failed to execute!\n\n==> Failed command:\n/usr/bin/sudo -E -- /usr/sbin/installer -pkg #<Pathname:/usr/local/Caskroom/microsoft-office/15.27.0_161010/Microsoft_Office_2016_15.27.0_161010_Installer.pkg> -target /\n\n==> Standard Output of failed command:\n\n\n==> Standard Error of failed command:\nsudo: no tty present and no askpass program specified\n\n\n==> Exit status of failed command:\n#<Process::Status: pid 12059 exit 1>"}

Copied from original issue: ansible/ansible-modules-extras#3415

[ansibot]

From @edrozenberg on 2016-11-10T01:31:53Z

Found that the issue has been discussed on homebrew cask, puppet, chef projects already:
Homebrew/homebrew-cask#5667
boxen/puppet-brewcask#22
kitchenplan/chef-homebrewalt#8

Some suggestions are to use sudo, but that would make the entire app owned by root instead of the regular user. Not sure if the issue needs to be tackled by the Ansible cask module or the homebrew cask project.

[ansibot]

From @ansibot on 2016-11-10T01:31:53Z

@indrajitr, ping. This issue is waiting on your response.
click here for bot help

[ansibot]

From @bcg62 on 2016-11-10T01:31:53Z

sous-chefs/homebrew#111

[ansibot]

From @rqelibari on 2016-11-10T01:31:53Z

You can currently circumvent this by doing it like this:

- name: "Run this task before homebrew_cask module, so that sudo cache gets refreshed."
  command: "echo none"
  become: yes

- name: "Install casks."
  homebrew_cask: name={{package}} state=present
  with_items: "{{ your_cask_apps_which_need_admin_rights }}"
  ignore_errors: yes
  loop_control:
     loop_var: package

What this actually does is nothing else then sudo -v does in bash scripts. And as such homebrew-cask will not ask you for a password.

[ansibot]

cc @danieljaouen @enriclluelles
click here for bot help

[gusc]

It looks like this workaround won't help when, for example installing java on a slower network connection - the sudo from the first call would timeout and ask a password when download finishes and sudo -E installer ... is launched.

[edrozenberg]

A few years later I've finally tackled this and found a solution via the use of a SUDO_ASKPASS env var now supported by Homebrew. No other approaches have worked.

Solution posted at:
geerlingguy/ansible-role-homebrew#73 (comment)

[danieljaouen]

I'm currently looking into the issue. Once #13620 is merged into devel, that should do the trick. All you would need to do once that happens is add a live: true to the associated task.

[danieljaouen]

Can everyone who still has this issue run a brew --version and an ansible --version for me? I'm looking into this issue, but I'm having problems replicating it with the latest Ansible and Homebrew.