sudo best practice #127

Closed
grosser opened this Issue Oct 18, 2011 · 7 comments

Projects

None yet

6 participants

@grosser
grosser commented Oct 18, 2011

whats the simples / best way to use the same commands with sudo ?

my current solution is

# /root/.bashrc
export PATH="$home/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

ln -s /home/micha/.rbenv/ /root/.rbenv

@grosser
grosser commented Oct 18, 2011

Improved version without any hacks:

function rbenvsudo(){
  executable=$1
  shift 1
  sudo $(rbenv which $executable) $* 
}

could you add this to rbenv, sure lots of people what this especially if they used rvmsudo before...

@josh
Contributor
josh commented Oct 18, 2011

We made some changes to better support calling shims in sudo. See #66 and 964c12f.

However, rbenv itself isn't intended to be invoked in a sudo shell unless you specifically set that up in you root env.

@josh josh closed this Oct 18, 2011
@grosser
grosser commented Oct 18, 2011

so the intended way is to install it separately in /root ?

@fluxsaas

hey,
i also would like to know what the best approach is. i have to setup foreman for my production server (capistrano task):

  sudo bundle exec foreman export upstart /etc/init -a #{application} -u #{user} -l #{release_path}/log/foreman"

obviously it's not working, because of the "sudo". it's better to install rbenv for sudo ? or did i miss sth. ?

i could do:

 sudo $(rbenv which foreman) export upstart /etc/init -a #{application} -u #{user} -l #{release_path}/log/foreman"

it finds foreman, but breaks with an error: "/usr/bin/env: ruby: No such file or directory"

 sudo env
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

the rbenv ruby is not set in my sudo path. after reading the ticket: #66 (comment) it should be added ?

i did not followed the guide on https://github.com/sstephenson/rbenv/wiki/Using-rbenv-in-production#wiki-method1 but i installed it for my deploy user. so it "should" be fine.

update:

a workaround is to use:

  sudo env PATH=$PATH bundle exec foreman export upstart /etc/init -a #{application} -u #{user} -l #{release_path}/log/foreman"

which preserves the PATH variables of the "normal" user so it finds the rbenv gems and ruby.

but still wrong isn't it ?

@mrrooijen

@fluxsaas I just add this function to my env (for example .bashrc) then just run rbenvsudo foreman export upstart /etc/init works perfectly fine for me as a non-root UNIX user, it'll write the conf files to /etc/init without running into permission errors.

https://gist.github.com/2290928

@henry74
henry74 commented Nov 10, 2014

Can someone explain how I would incorporate this script into the mina workflow? Do I add a separate run command into the deploy.rb file? Do I run it manually? Sorry it's hard to follow all the different comments/solutions/suggestions.

@mislav
Collaborator
mislav commented Nov 14, 2014

@henry74 Maybe somebody who solved this can help you, but we generally don't provide support for various usage of rbenv in combination with 3rd party software.

rbenv will always work when rbenv executable and "$(rbenv root)"/shims directory are on the top of the PATH. It's that simple, really. However, deployment environments and sudo often clear out the PATH (this is by design) and set up their own without respecting ~/.bash_profile or similar shell initialization files. In such cases, the person who is setting up the deployment environment has to ensure that rbenv in PATH will be preserved. It all boils down to having correct PATH, so always start debugging from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment