Capistrano + thin + nginx with user not allowed to

Question

I have a scenario like this which I want to use capistrano to deploy my ruby on rails application:

1. The web application is on a thin cluster with the config file stored under /etc/thin. also an init script is in /etc/init.d/thin, so it would start automatically whenever my server needs a reboot
2. Also nginx is executed the same way (as an init script daemon)
3. To make sure in case if somebody hacked my webserver I don't want them to do something too horrible, so the web user is not allowed to sudo.
4. Thin and nginx both runs as the webuser to enforce such security

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?

Answer 1

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 ...

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.