I am trying to deploy an Amazon EC2 instance using rubber. On running
cap rubber:create_staging I get the following timeout:
* 2014-04-06 20:14:09 executing `rubber:postgresql:setup_apt_sources'
servers: ["production.foo.com"]
** sftp upload #<StringIO:0x0000000420a748> -> /tmp/configure_postgresql_repository
[production.foo.com] /tmp/configure_postgresql_repository
[production.foo.com] done
* sftp upload complete
* executing "sudo -p 'sudo password: ' bash -l /tmp/configure_postgresql_repository"
servers: ["production.foo.com"]
[production.foo.com] executing command
command finished in 1161ms
* executing "sudo -p 'sudo password: ' bash -l -c 'apt-get -q update'"
servers: ["production.foo.com"]
connection failed for: production.foo.com (Timeout::Error: execution expired)
I tried increasing the timeout to 60 seconds, but it didn't work.
Any suggestions?
Looks like the user you are using to connect with to the instance using Rubber/Capistrano doesn't have passwordless sudo access. Try creating the file /etc/sudoers.d/90-user-you-use-for-rubber with the following content:
user-you-user-for-rubber ALL=(ALL) NOPASSWD:ALL
Related
Trying to deploy a simple rails to staging on ec2 with rubber. Process fails with following error. Have been trying for days to find a solution but can't figure it out.
Anyone know why it fails?
* 2014-03-05 15:20:13 executing `deploy:setup'
* executing "sudo -p 'sudo password: ' mkdir -p /mnt/bott.ly-production /mnt/bott.ly-production/releases /mnt/bott.ly-production/shared /mnt/bott.ly-production/shared/system /mnt/bott.ly-production/shared/log /mnt/bott.ly-production/shared/pids"
servers: ["staging.bott.ly"]
[staging.bott.ly] executing command
command finished in 1134ms
* executing "sudo -p 'sudo password: ' chmod g+w /mnt/bott.ly-production /mnt/bott.ly-production/releases /mnt/bott.ly-production/shared /mnt/bott.ly-production/shared/system /mnt/bott.ly-production/shared/log /mnt/bott.ly-production/shared/pids"
servers: ["staging.bott.ly"]
[staging.bott.ly] executing command
command finished in 1439ms
triggering after callbacks for `rubber:bootstrap'
* 2014-03-05 15:20:17 executing `rubber:collectd:bootstrap'
* executing "echo $(grep Rubber /etc/collectd/collectd.conf 2> /dev/null)"
servers: ["staging.bott.ly"]
[staging.bott.ly] executing command
command finished in 1208ms
* 2014-03-05 15:20:20 executing `deploy:setup'
* executing "sudo -p 'sudo password: ' mkdir -p /mnt/bott.ly-production /mnt/bott.ly-production/releases /mnt/bott.ly-production/shared /mnt/bott.ly-production/shared/system /mnt/bott.ly-production/shared/log /mnt/bott.ly-production/shared/pids"
servers: ["staging.bott.ly"]
[staging.bott.ly] executing command
command finished in 1187ms
* executing "sudo -p 'sudo password: ' chmod g+w /mnt/bott.ly-production /mnt/bott.ly-production/releases /mnt/bott.ly-production/shared /mnt/bott.ly-production/shared/system /mnt/bott.ly-production/shared/log /mnt/bott.ly-production/shared/pids"
servers: ["staging.bott.ly"]
[staging.bott.ly] executing command
command finished in 269ms
** updating code for bootstrap
* 2014-03-05 15:20:24 executing `deploy:update_code'
* getting (via checkout) revision to C:/Users/solanmi/AppData/Local/Temp/20140305142024
executing locally: xcopy . "C:/Users/solanmi/AppData/Local/Temp/20140305142024" /S/I/Y/Q/E
378 File(s) copied
command finished in 4328ms
* processing exclusions...
* Compressing C:/Users/solanmi/AppData/Local/Temp/20140305142024 to C:/Users/solanmi/AppData/Local/Temp/20140305142024.tar.gz
executing locally: tar czf 20140305142024.tar.gz 20140305142024
command finished in 51ms
shell command failed with return code pid 8760 exit 53
Looks like you are deploying from Windows and you may be missing the tar command locally or it's not in your $PATH
If you want to use Cygwin I recommend you install it using the it's Setup64 or Setup-x86 program. I believe the tar package is one of the default packages that get installed. If not you can find it here: http://gnuwin32.sourceforge.net/packages/gtar.htm
I'm following along with Ryan Bates' Railscast on Monit http://railscasts.com/episodes/375-monit?view=asciicast, the monitoring system for Rails applications. In it, he creates a capistrano recipe for monit (see below) which runs with the command cap monit:setup. When I run it, it fails with this message
command finished in 200ms
failed: "sh -c 'sudo -p '\\''sudo password: '\\'' service monit reload'" on 192.XXX.XXX.XXX
It's obviously a password related error, but I can't figure out why it's happening because the earlier commands that the script runs start stop restart syntax reload seem to run successfully until it gets to reload.
Noting that the second last line in the script uses root, I thought it might also be a root issue, since I'm logged into my server with a different user name (but with sudo permissions). Therefore, I changed root in the second last line to my user name and ran cap monit:setup again but I got the same error.
* 2013-07-10 05:52:01 executing `monit:syntax'
* executing "sudo -p 'sudo password: ' service monit syntax"
servers: ["192.XXX.XXX.XXX"]
[192.XXX.XXX.XXX] executing command
** [out :: 192.XXX.XXX.XXX] Control file syntax OK
command finished in 248ms
* 2013-07-10 05:52:02 executing `monit:reload'
* executing "sudo -p 'sudo password: ' service monit reload"
servers: ["192.XXX.XXX.XXX"]
[192.XXX.XXX.XXX] executing command
** [out :: 192.XXX.XXX.XXX] Usage: /etc/init.d/monit {start|stop|restart|force-reload|syntax}
command finished in 200ms
failed: "sh -c 'sudo -p '\\''sudo password: '\\'' service monit reload'" on 192.XXX.XXX.XXX
the Monit.rb recipe
namespace :monit do
desc "Install Monit"
task :install do
run "#{sudo} apt-get -y install monit"
end
after "deploy:install", "monit:install"
desc "Setup all Monit configuration"
task :setup do
monit_config "nginx"
syntax
reload
end
after "deploy:setup", "monit:setup"
%w[start stop restart syntax reload].each do |command|
desc "Run Monit #{command} script"
task command do
run "#{sudo} service monit #{command}"
end
end
end
def monit_config(name, destination = nil)
destination ||= "/etc/monit/conf.d/#{name}.conf"
template "monit/#{name}.erb", "/tmp/monit_#{name}"
run "#{sudo} mv /tmp/monit_#{name} #{destination}"
run "#{sudo} chown root #{destination}"
run "#{sudo} chmod 600 #{destination}"
end
What is the proper way to deploy:setup and to do a cold deploy with Capistrano?
Using
this deploy.rb
Capistrano v2.14.2
Vagrant to virtualize my server,
this is my scenario:
when running deploy:setup, Capistrano makes use of root privileges to prepare the directory structure for deployment:
$ cap deploy:setup
* 2013-02-28 14:50:21 executing `deploy:setup'
* executing "sudo -p 'sudo password: ' mkdir -p /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids"
servers: ["example.com"]
[example.com] executing command
command finished in 29ms
* executing "sudo -p 'sudo password: ' chmod g+w /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids"
servers: ["example.com"]
[example.com] executing command
command finished in 11ms
yet upon deploy:cold Capistrano attempts to checkout (from git in this case) and write as the vagrant user – the user specified in deploy.rb:
$ cap deploy:cold
* 2013-02-28 14:50:47 executing `deploy:cold'
* 2013-02-28 14:50:47 executing `deploy:update'
** transaction: start
* 2013-02-28 14:50:47 executing `deploy:update_code'
updating the cached checkout on all servers
executing locally: "git ls-remote git#github.com:mariusbutuc/realtime-faye.git master"
command finished in 2360ms
* executing "if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q git#github.com:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi"
servers: ["example.com"]
[example.com] executing command
** [example.com :: out] fatal: could not create work tree dir '/home/vagrant/example/shared/cached-copy'.: Permission denied
command finished in 26ms
*** [deploy:update_code] rolling back
* executing "rm -rf /home/vagrant/example/releases/20130228195049; true"
servers: ["example.com"]
[example.com] executing command
command finished in 7ms
failed: "sh -c 'if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q git#github.com:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi'" on example.com
Of course, the deploy:check report bares no surprises: the vagrant user cannot write in the directories created during deploy:setup since the two users belong to different groups – root:root versus vagrant:vagrant:
$ cap deploy:check
[...]
The following dependencies failed. Please check them and try again:
--> You do not have permissions to write to `/home/vagrant/example'. (example.com)
--> You do not have permissions to write to `/home/vagrant/example/releases'. (example.com)
--> `/home/vagrant/example/shared' is not writable (example.com)
What is the reasoning behind this, and what prerequisite is not satisfied yet so the deployment passes this issue?
The deploy:setup task probably should not be using sudo to create the app directory, since that is likely causing it to be owned by root.
You can turn that off in your deploy.rb file with:
set :use_sudo, false
Since there are no group setting in Capistrano my workaround is to extend such a setting, for example:
set :user, 'vagrant'
set :group, 'vagrant'
and then create a task to "fix" the ownership after running deploy:setup:
after "deploy:setup", :setup_ownership
task :setup_ownership do
run "#{sudo} chown -R #{user}:#{group} #{deploy_to} && chmod -R g+s #{deploy_to}"
end
But the only thing better than fixing an issue is not having it in the first place, so Stuart's answer is both wiser and more elegant.
I am having an issue with using rubber, whenever I try cap rubber:bootstrap and had a staging instance, it always stuck on this error.
* executing "sudo -p 'sudo password: ' bash -l -c 'cd /mnt/localstore-production/releases/20120519213905 && RUBBER_ENV=production RAILS_ENV=production ./script/rubber config --force --file=\"role/graphite_server\"'"
servers: ["production.localstore.com"]
[production.localstore.com] executing command
** [out :: production.localstore.com] Instance not found for host: ip-10-2-118-252
** [out :: production.localstore.com]
command finished in 5849ms
failed: "/bin/bash -l -c 'sudo -p '\\''sudo password: '\\'' bash -l -c '\\''cd /mnt/localstore-production/releases/20120519213905 && RUBBER_ENV=production RAILS_ENV=production ./script/rubber config --force --file=\"role/graphite_server\"'\\'''" on production.localstore.com
Actually the issue was that I changed the static IP of the instance from the AWS Console, so why the host info of the instance changed some how.
So I use this command cap rubber:referesh to refresh every thing and then bootstrap the instance and it solved my problem.
When do the cap deploy everything works fine except the ferret-server, while restarting server its try to stop the ferret_server in production mode and try to start the ferret_server but it fails due to permission problem .Here is the output from my deploy file** transaction: commit
executing deploy:restart'
triggering before callbacks fordeploy:restart'
executing `ferret:stop'
executing "cd /home/sj/reelinfo/current; script/ferret_server -e production stop || true"
servers: ["67.23.28.171"]
[67.23.28.171] executing command
** [out :: 67.23.28.171] sh: script/ferret_server: Permission denied
command finished
executing "chown www-data -R /home/sj/reelinfo/current/"
servers: ["67.23.28.171"]
[67.23.28.171] executing command
command finished
executing "touch /home/sj/reelinfo/current/tmp/restart.txt"
servers: ["67.23.28.171"]
[67.23.28.171] executing command
command finished
triggering after callbacks for `deploy:restart'
executing `ferret:start'
executing "cd /home/sj/reelinfo/current; script/ferret_server -e production start"
servers: ["67.23.28.171"]
[67.23.28.171] executing command
** [out :: 67.23.28.171] sh: script/ferret_server: Permission denied
command finished
failed: "sh -c \"cd /home/sj/reelinfo/current; script/ferret_server -e production start\"" on 67.23.28.171
I've had this problem as well, the issue is that script/ferret_server did not have executable permissions.
I added the following deploy task to handle the permissions:
before "deploy:restart", "correct_ferret_server_permissions"
task :correct_ferret_server_permissions do
run "chmod a+x #{current_path}/script/ferret_server
end