Reputation: 10586
I have a scenario like this which I want to use capistrano to deploy my ruby on rails application:
Now when I need to do the deployment, I would need the files to be installed under /home/webuser/railsapps/helloworld, and I need the cap script restart my thin afterwards. I want to keep all files owned by the webuser, so the cap script primary user is running as webuser. Now the problem arise when I want to restart the thin daemon because webuser can't sudo.
I am thinking if its possible to invoke two separate sessions- webuser for file deployment, and then a special sudoer to restart the daemon. Can anyone give me a sample script on this?
Upvotes: 2
Views: 2722
Reputation: 574
Just noticed you don't allow user to sudo :-) Well this answer will help others:
A little late the party but I've just done this:
namespace :deploy do
desc "Start the Thin processes"
task :start do
run "cd #{current_path} && bundle exec sudo thin start -C /etc/thin/dankit.yml"
end
desc "Stop the Thin processes"
task :stop do
run "cd #{current_path} && bundle exec sudo thin stop -C /etc/thin/dankit.yml"
end
desc "Restart the Thin processes"
task :restart do
run "cd #{current_path} && bundle exec sudo thin restart -C /etc/thin/dankit.yml"
end
end
Adding sudo to the bundle exec sudo thin start
works.
Upvotes: 0
Reputation: 1223
If you are running Thin as the webuser then can the webuser not end the process? You could restart Thin again without the daemon, so long as you pass the server everything in /etc/thin it should be fine. The daemon, as far as I understand it, is just a convenient way to bypass having to manually launch a program at boot.
The only time you'll come unstuck is when you have to edit the contents of /etc/thin. Assuming you're using aliases to your webuser's thin.yml bits, this will only happen when you want to add / remove a program. When this happens, it might be worth just manually adding/deleting the alias.
This is all assuming the webuser can end the Thin process to start with. I don't know otherwise. Last time it was an issue for me was when I didn't have a way to run the app on my local machine because it's implementation was pretty much tied to the server's layout. Every time I edited something, I had to send it to SVN, switch tabs in the terminal to an ssh shell, pull it from SVN, switch tabs to another ssh and restart the daemon and see whether or not i'd broken it. It got me down, so I installed Thin locally, got the app to read config files, and now I only have to upload once every few days.
Upvotes: 0
Reputation: 2046
why not use sudo for the deployment routine and then chown -R on the RAILS_ROOT? You could tell Capistrano to change the ownership prior to aliasing the release as current.
Upvotes: 1
Reputation: 5765
An alternative to this would be running nginx as a normal user, say on port 8080 then using IPTables to redirect requests from port 80 to port 8080, from memory
iptables -A PREROUTING -t tcp -m tcp -p 80 -j DNAT --dport 8080
Will send all packets destined to port 80 to port 8080, which can be bound as a normal user.
Upvotes: 0
Reputation: 4329
This might not be what you want, but you can actually do something like this in your sudoers file:
someuser ALL=NOPASSWD: /etc/init.d/apache2
that lets someuser run /etc/init.d/apache2
If you try to do something else:
$ sudo ls
[sudo] password for someuser:
Sorry, user someuser is not allowed to execute '/bin/ls' as root on ...
Upvotes: 4