Use sudo for installation of problematic casks (e.g. pkg)

[johndbritton]

When I try and install virtualbox using the brewcask provider the install fails. It seems to be failing due to a permissions error. Since virtualbox is a pkg a sudo and password entry is required. The run fails because there's no opportunity to collect the password.

Error: Execution of 'brew cask install virtualbox --appdir=/Applications' returned 1: ==> Downloading http://download.virtualbox.org/virtualbox/4.3.16/VirtualBox-4.3.16-95972-OSX.dmg
Already downloaded: /Library/Caches/Homebrew/virtualbox-4.3.16-95972.dmg
==> Running installer for virtualbox; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Error: Command failed to execute!

==> Failed command:
["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "#<Pathname:/opt/homebrew-cask/Caskroom/virtualbox/4.3.16-95972/VirtualBox.pkg>", "-target", "/"]

==> Output of failed command:
sudo: no tty present and no askpass program specified


==> Exit status of failed command:
#<Process::Status: pid 19736 exit 1>
==> sudo: no tty present and no askpass program specified
Error: /Stage[main]/People::Johndbritton::Packages/Package[virtualbox]/ensure: change from absent to present failed: Execution of 'brew cask install virtualbox --appdir=/Applications' returned 1: ==> Downloading http://download.virtualbox.org/virtualbox/4.3.16/VirtualBox-4.3.16-95972-OSX.dmg
Already downloaded: /Library/Caches/Homebrew/virtualbox-4.3.16-95972.dmg
==> Running installer for virtualbox; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Error: Command failed to execute!

==> Failed command:
["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "#<Pathname:/opt/homebrew-cask/Caskroom/virtualbox/4.3.16-95972/VirtualBox.pkg>", "-target", "/"]

==> Output of failed command:
sudo: no tty present and no askpass program specified


==> Exit status of failed command:
#<Process::Status: pid 19736 exit 1>
==> sudo: no tty present and no askpass program specified

[johndbritton]

@phinze I'd be happy to take a stab at fixing this, any ideas for what needs to be done?

[rmchale]

Any update on this? I also have this problem.

[lethjakman]

I've been looking into this issue as well...looks like it's being caused because you can't pass a password to sudo. Perhaps using visudo instead would be a better alternative, or maybe skipping sudo altogether as I don't believe that this solution is using sudo. However, I can't figure out what would be causing the sudo in here. Any help would be appreciated. Thanks!

[ChristinWhite]

I've been searching through the issues on several different forks and there are a number of people running into this issue; it all seems to happen with any package that requires a sudo (VirtualBox, SublimeText, Xtrafinder) and I've yet to see anyone post any kind of solution so far.

[lethjakman]

I don't think this should have to require sudo, is there a way we can test the install without it? Or is that something that's happening in the Cask?

[lethjakman]

Through some experimentation I do believe that it's the sudo that is messing things up. Virtualbox does not need sudo to install through cask, however sublime-text does (because it's trying to symlink into /usr/local/bin). So I think if there's a way to dodge that sudo we can get most of these working.

[johndbritton]

I'm pretty sure Boxen has a way to run as a privileged user, so rather than invoking sudo directly maybe it's possible to invoke the command while running as root via some puppet parameter.

cc/ @dgoodlad Any ideas / suggestions?

[dgoodlad]

Puppet's execute method takes a hash of options, one of which is :uid. We could set that to 0 for special casks when necessary.

See https://github.com/phinze/puppet-brewcask/blob/master/lib/puppet/provider/package/brewcask.rb#L87 and https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/execution.rb#L143

In fact, we could probably modify https://github.com/phinze/puppet-brewcask/blob/master/lib/puppet/provider/package/brewcask.rb#L82-L84 to handle special cases...

[bbck]

Just tried switching over my personal manifests to installing from homebrew-cask with the latest puppet-boxen release and I'm hitting this issue on a few of my apps.

[radeksimko]

I'd rather see a change being made in brewcask itself, so puppet knows when it's really necessary to use sudo/different uid.

It can be even detected right now by puppet, but the solution would probably waste some time & resources trying first installing the cask with standard uid and then installing the cask again with sudo:
https://github.com/jenkinsci/rpmsign-plugin/blob/master/src/main/java/jenkins/plugins/rpmsign/RpmSignPlugin.java#L143-159

@petems I'd rather not install all casks with sudo, it would be like killing a bee with a hammer.

[phinze]

I'd rather see a change being made in brewcask itself, so puppet knows when it's really necessary to use sudo/different uid.

This is a good idea!

If we added these details to the output of brew cask info - then the provider could check first and know when to sudo. Does that sound right?

[radeksimko]

@phinze Opened issue: Homebrew/homebrew-cask#8817

[ghost]

no problem with brewcask/virtualbox

This issue can be closed

[dominics]

@julienlavergne Do you mean you're not having this problem any more? Can you elaborate on how it was fixed? (Is the Virtualbox installer itself no longer requiring sudo?)

Or was this issue closed by @johndbritton just while we wait for upstream to merge Homebrew/homebrew-cask#8817 or similar?

If someone could point me to the fix, it'd be much appreciated.

[goofansu]

Is this bug solved? I installed following apps that required sudo all failed:

asepsis
grownotify
ksdiff
squirrel
qlimagesize
typinator

[dominics]

One thing worth mentioning is that even once we know which casks require sudo to be installed, we probably shouldn't just execute the cask command as uid 0 (as suggested above). Better to do the command as usual (running as the default_user), and clear away the timeout so that it works properly. That's because it's a bad assumption that sudo brew cask install blah will do the same thing as sudo -v && brew cask install blah (where sudo -v bumps the timestamp).

One hacky way to bump a user's sudo timestamp is just to touch the directory in /var/db/sudo (there seems to be no user-space way of telling sudo to create/bump a timestamp for another user as root, without requiring their password).

My current workaround looks something like:

def run(*cmds)
  begin
    brew_cmd = ['brew', 'cask'] + cmds
    execute brew_cmd, command_opts
  rescue Puppet::ExecutionFailure => e
    raise e unless e.message =~ /sudo: no tty present and no askpass program specified/

    warning <<-EOT.gsub(/\s+/, ' ').strip
      Initial execution of `#{brew_cmd.join(' ')}` failed because it requires sudo, and there's no TTY to accept a
      password. We are about to reattempt execution, after bumping the sudo timestamp for that user.
    EOT

    timestamp = "/var/db/sudo/#{default_user}"

    Dir.mkdir(timestamp, 0700) unless File.directory?(timestamp)
    FileUtils.touch(timestamp)

    execute brew_cmd, command_opts
  end
end

[johndbritton]

I closed the issue in response to #22 (comment), I haven't tried this again since I filed the issue.

[cmckni3]

I am having this issue when installing virtualbox

[ghost]

maybe open a new terminal and try this script:

while true; do sudo ls -l; sleep 2; done;

with enter password one time

-- 
Julien Lavergne
Sent with Airmail

On August 19, 2015 at 5:39:11 PM, Chris McKnight (notifications@github.com) wrote:

I am having this issue when installing virtualbox

—
Reply to this email directly or view it on GitHub.

[cmckni3]

@julienlavergne That worked. Thanks! That's something I have seen people do in their dotfiles to be able to get around the sudo timeout.

It really seems like a hack though.

[ghost]

Yeah it’s a hack but another solution doesn’t seem to be known.

-- 
Julien Lavergne
+33670273883
http://julienlavergne.com
Sent with Airmail

On August 20, 2015 at 7:58:00 AM, Chris McKnight (notifications@github.com) wrote:

@julienlavergne That's something I have seen people do in their dotfiles to be able to get around the sudo timeout.

It really seems like a hack though.

—
Reply to this email directly or view it on GitHub.

[dominics]

@johndbritton Can you please reopen this issue in that case? @julienlavergne was mistaken in saying "no problem with brewcask/virtualbox", nothing has been done to fix this, and the issue remains.

"open a new terminal and try this script"? As a workaround for a puppet module, that's pretty unacceptable. "another solution doesn’t seem to be known" is just wrong.

[ghost]

Why my opinion is mistaken ?

-- 
Julien Lavergne
+33670273883
http://julienlavergne.com
Sent with Airmail

On August 21, 2015 at 7:58:09 AM, Radek Simko (notifications@github.com) wrote:

Reopened #22.

—
Reply to this email directly or view it on GitHub.

[radeksimko]

To clarify the situation - I'm still not sure if it's worth keeping open or close... but brewcask is moving towards a state where there will be no symlinks, it will behave much more like standard drag & drop installations.

See Homebrew/homebrew-cask#13201 for details & reasons.

Currently only pkg and a few other bundle types require su perms. When the changes described in the linked issue get implemented, then suddenly de facto all apps will require su perms, therefore this boxen module will need to run all brew cask commands under su permissions, which will be the definitive solution to all these issues.

I'm not sure if there's any nice way of solving this problem at this moment. I'm not convinced that using sudo for installing apps into ~/Applications and generally for things that do not require sudo is a solution.

[ghost]

No pb with last VirtualBox installation if VirtualBox is correctly closed.

-- 
Julien Lavergne
+33670273883
http://julienlavergne.com
Sent with Airmail

On August 21, 2015 at 12:18:27 PM, Radek Simko (notifications@github.com) wrote:

To clarify the situation - I'm still not sure if it's worth keeping open or close... but brewcask is moving towards a state where there will be no symlinks, it will behave much more like standard drag & drop installations.

See Homebrew/homebrew-cask#13201 for details & reasons.

Currently only pkg and a few other bundle types require su perms. When the changes described in the linked issue get implemented, then suddenly de facto all apps will require su perms, therefore this boxen module will need to run all brew cask commands under su permissions, which will be the definitive solution to all these issues.

I'm not sure if there's any nice way of solving this problem at this moment. I'm not convinced that using sudo for installing apps into ~/Applications and generally for things that do not require sudo is a solution.

—
Reply to this email directly or view it on GitHub.

[sebroeder]

then suddenly de facto all apps will require su perms, therefore this boxen module will need to run all brew cask commands under su permissions, which will be the definitive solution to all these issues

@radeksimko As long as the user who runs boxen is an admin user, no sudo is required to copy applications into /Applications (non-MAS third party apps are usually installed with owner myadminuser and group admin). So the change in homebrew-cask’s default behaviour should not require sudo more often than the old one, or did I miss something?

[ghost]

All users are not admin by default

Envoyé de mon iPhone

Le 21 août 2015 à 13:30, Sebastian Röder notifications@github.com a écrit :

then suddenly de facto all apps will require su perms, therefore this boxen module will need to run all brew cask commands under su permissions, which will be the definitive solution to all these issues

As long as the user who runs boxen is an admin user, no sudo is required to copy applications into /Applications (non-MAS third party apps are usually installed with owner myadminuser and group admin). So the change in homebrew-cask’s default behaviour should not require sudo more often than the old one, or did I miss something?

—
Reply to this email directly or view it on GitHub.

[radeksimko]

@julienlavergne Understood, but better post this to the original thread to caskroom/homebrew-cask.

[dominics]

@julienlavergne I thought Virtualbox requires root privileges to install vboxnet drivers, among other things. Are you saying sudo -k && brew cask install virtualbox on a non-interactive terminal (no tty) works for you?

[n0ts]

Below sudo manifest, It's works.

  sudoers { 'installer':
    users    => $::boxen_user,
    hosts    => 'ALL',
    commands => [
      '(ALL) SETENV:NOPASSWD: /usr/sbin/installer',
    ],
    type     => 'user_spec',
  }

  package { 'virtualbox':
       provider => 'brewcask',
       require  => [ Homebrew::Tap['caskroom/cask'], Sudoers['installer'] ],
  }

[rypit]

@n0ts's suggestion above worked for me

[ghost]

Which suggestion finally?

From: RJ Pittman notifications@github.com
Reply: boxen/puppet-brewcask reply@reply.github.com
Date: December 7, 2015 at 3:51:35 PM
To: boxen/puppet-brewcask puppet-brewcask@noreply.github.com
CC: Julien Lavergne lavergne.julien@gmail.com
Subject:  Re: [puppet-brewcask] Use sudo for installation of problematic casks (e.g. pkg) (#22)

@n0ts's suggestion above worked for me

—
Reply to this email directly or view it on GitHub.

[rypit]

@julienlavergne #22 (comment)

[ghost]

When will this issue be fixed in puppet-brewcask? Next release?

[ldenman]

@n0ts that seems like a good workaround for targeting /usr/bin/installer. Some packages use additional commands like sudo -E /usr/bin/sqlite3 ... (SizeUp) which fails also when no sudo session is in play.

The only work arounds I have found are hacks like:

1.) run "sudo ls" right before running boxen
or for longer running installs
2.) in a new terminal run: " while true; do echo "refreshing sudo"; sudo echo; sleep 30; done; " and then run boxen in another terminal

@julienlavergne Great question. Has anyone made progress on this?

[ghost]

No improvement about your trick

Le 17 mars 2016 à 22:02, Lake Denman notifications@github.com a écrit :

@n0ts that seems like a good workaround for targeting /usr/bin/installer. Some packages use additional commands like sudo -E /usr/bin/sqlite3 ... (SizeUp) which fails also when no sudo session is in play.

The only work around I have found that works is lousy hacks like:

1.) run "sudo ls" right before running boxen
or for longer running installs
2.) in a new terminal run: " while true; do echo "refreshing sudo"; sudo echo; sleep 30; done; " and then run boxen in another terminal

@julienlavergne Great question. Has anyone made progress on this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[jacobbednarz]

Closing due to inactivity. If you have any new information, please raise it in boxen/puppet-homebrew since brewcask + homebrew merged.