Capistrano 3, Rails and Ubuntu 14.04

I recently tried deploying a new Rails 4 app and had the opportunity to try the revamped Capistrano 3. I will share my troubles and the solutions I came up with. This was a learning process and I wouldn’t be surprised if someone comes up with a better solution or something that I overlooked in the process.

Here it goes. This is not a Capistrano 3 Rails tutorial but rather tackles one particular problem with my setup: running sudo commands during the deployment setup.

I usually create a deployer user for this and set the forward_agent option to true in order to use my local user’s keys to login. I followed a sample github app and the comments on the default configuration files to configure my setup which is pretty straight forward:

From what I read on the interwebs the general trend is to keep the unicorn init script, the unicorn.rb and the nginx.conf inside the Rails app and commit it into the repo. I’m sure for a bigger application you would use Puppet or Chef
to manage the config files but since it’s a small one server app I think this should do fine.

The first problem I ran into was when my cap script tried to delete the default site under /etc/nginx/site-enabled. Since those files are owned by root, the cap recipe I was using was executing this command with sudo. Capistrano 3 comes with the pty option disabled by default and caused the script to fail with Permission Denied.

The obvious fix would be to set the pty to true and have the script prompt me for the sudo password during the deploy. It’s not so bad since this would only happen in the initial setup or any time I change the nginx and unicorn_init bash script. I set pty to true, but when I got the prompt and entered the root password nothing happened - the script looked like it froze. After more digging I think the culprit is the Net::SSH lib that sshKit is using to interact with SSH. I couldn’t find any problems related to this online so I got a bit worried - maybe I was doing something wrong. So I went on a tangent, managed to find a post on Stack Overflow that sounded like my problem. That post along with a bug discovered in the kernel related to the pseudo tty seem to suggest that maybe Net::SSH needs to be patched.

I would love to debug this further and confirm this is what’s causing the password prompt issue, maybe even contribute with a fix. But I do have to deploy this app :). So enabling the pty is not going to work, moving on.
The official Capistrano docs recommend enabling passwordless sudo, but this sounds pretty dangerous. In fact the Capistrano docs confirm this is a dangerous option.

I finally decided to use plain old Linux permissions to deal with this. My deployer user is part of the admin group so I changed the permissions and ownership for /etc/nginx/sites-enabled

sudo chown -R root:admin /etc/nginx/sites-enabled /etc/nginx/sites-available 
sudo chown root:admin /etc/nginx/sites-available/default
sudo chmod g+w /etc/nginx/sites-available/default
sudo chmod g+wx /etc/nginx/sites-enabled /etc/nginx/sites-available

This should give the deployer user access to delete the default config file, create a new one and symlink it. Follow the same procedure for the /etc/init.d and /etc/log_rotate.d.

Looking back I’m not sure which one of those solutions is worse in terms of security: passwordless sudo or updating the permissions. I hope there’s a quick solution for the pty problem because I would revert to that instead.

 
8
Kudos
 
8
Kudos