Skip to content
This repository has been archived by the owner on Dec 31, 2022. It is now read-only.

Restart fails, fullstaq ruby not in sudo path #237

Closed
inopinatus opened this issue Apr 13, 2020 · 0 comments
Closed

Restart fails, fullstaq ruby not in sudo path #237

inopinatus opened this issue Apr 13, 2020 · 0 comments

Comments

@inopinatus
Copy link
Contributor

inopinatus commented Apr 13, 2020

After switching to fullstaq ruby (on Ubuntu 18.04), I found that a deploy did not restart unicorn, despite reporting success in the chef log.

This may be because on the command line,sudo /srv/www/appname/shared/scripts/unicorn.service restart no longer works, instead giving:

/usr/bin/env: ‘ruby’: No such file or directory

which occurs because /etc/sudoers includes a secure_path declaration that overrides pam_env i.e. the contents of /etc/environment is ignored.

Fix

I do not recommend modifying /etc/sudoers. Even seeing a modification to a PAM config made me uneasy, since it's shipped in a finely tuned balance with other critical security and operational parameters.

I have instead included

link '/usr/local/bin/ruby' do
  to "/usr/lib/fullstaq-ruby/versions/#{node['ruby-version']}-jemalloc/bin/ruby"
end

in my own setup.rb. Perhaps something with a similar outcome can sneak into opsworks_ruby.

Not sure why Fullstaq skips invoking update-alternatives(1) after package install, which is the commonly accepted behaviour for debian-style systems. Perhaps for multiple versions support.

@ajgon ajgon closed this as completed in 559c015 May 12, 2020
dotnofoolin pushed a commit to dotnofoolin/opsworks_ruby that referenced this issue Nov 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant