rubber / rubber

A capistrano/rails plugin that makes it easy to deploy/manage/scale to various service providers, including EC2, DigitalOcean, vSphere, and bare metal servers.

The rubber plugin enables relatively complex multi-instance deployments of RubyOnRails applications to Amazon's Elastic Compute Cloud (EC2).

See the documentation in the github wiki for more details: http://github.com/rubber/rubber/wiki

rubber's Issues

Documentation for using Amazon RDS rather than local MySQL

I'd like to try 'rubber' but would intend to use RDS in production. I'd like to know how to set that up with 'rubber' (I can do it easily by manually editing the config/database.yml file).

root's cron failing to run ruby scripts

I'm getting the following types of emails from my rubber-created staging box.

Subject: Cron root@staging BACKUP_DIR=/mnt/db_backups DBUSER=mydomain DBPASS= DBNAME=sparkbuy_staging DBHOST=staging.mydomain.com /mnt/mydomain-staging/releases/20110314004810/script/cron-rake rubber:backup_db

Body:
internal:lib/rubygems/custom_require:29:in require': no such file to load -- open4 (LoadError) from <internal:lib/rubygems/custom_require>:29:inrequire'
from script/cron-sh:11:in `

'

'open4' is part of the rubber.yml 'gems' value:

gems: [open4, aws-s3, bundler, [rubber, "#{Rubber.version}"]]

And root's crontab has a whole host of environment variables, presumably setup to allow for rvm execution:

# cron clears out enviroment variables, so we need to add these in
# to make sure we are running the correct ruby (rvm env vars, plus paths)
GEM_HOME='/mnt/mydomain-staging/shared/bundle/ruby/1.9.1'
MY_RUBY_HOME='/usr/local/rvm/rubies/ruby-1.9.2-p180'
rvm_selfcontained='0'
rvm_path='/usr/local/rvm'
PATH='/mnt/mydomain-staging/shared/bundle/ruby/1.9.1/bin:/usr/local/rvm/gems/ruby-1.9.2-p180/bin:/usr/local/rvm/gems/ruby-1\
.9.2-p180@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p180/bin:/usr/local/rvm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:\
/usr/bin:/sbin:/bin:/usr/X11R6/bin'
rvm_interactive_flag='0'
rvm_version='1.2.7'
rvm_ruby_string='ruby-1.9.2-p180'
GEM_PATH=''
RUBYOPT='-I/usr/local/rvm/gems/ruby-1.9.2-p180/gems/bundler-1.0.10/lib -rbundler/setup rubygems'
RUBY_VERSION='ruby-1.9.2-p180'
BUNDLE_GEMFILE='/mnt/mydomain-staging/releases/20110314083153/Gemfile'
BUNDLE_BIN_PATH='/usr/local/rvm/gems/ruby-1.9.2-p180/gems/bundler-1.0.10/bin/bundle'

Gem::Specification#default_executable= is deprecated with no replacement

RubyGems 1.7.0 deprecated the default_executable property in Gem::Specification and now throws a warning when bundler tasks are run.

Should be easily fixable by just removing the line from the gemspec.

Disable rdoc and ri installation

We should modify the gemrc config to disable rdoc and ri generation. This is almost never useful on a server and just adds unnecessary time to bootstrapping a machine.

rake gems:install not being called

On a Rails 2.3 app without bundler, rake gems:install is no longer being called, causing deploys to fail.

Is there any way to access ec2 region settings?

postgresql with password fails

Hi, when I use a password for the postgresql user, the bootstrapping fails, because "PASSWORD" is joined with "NOCREATEROLE" without an intermediate " ". changing line 40 in deploy-postgresql.rb to this:

create_user_cmd << " PASSWORD '#{env.db_pass}'" if env.db_pass

fixed this.
Best regards
-- Frank

Store instance data in SimpleDB instead of the filesystem

It'd be nice not to have to keep the instance-foo.yml files in source control to keep them synchronized, and SimpleDB has a substantial free usage quota...

rubber.yml: key_file error checking could be less obscure

In your rubber.yml file, you get the following after you vulcanize:

key_name: gsg-keypair
key_file: "#{Dir[(File.expand_path('~') rescue '/root') + '/.ec2/*' + cloud_providers.aws.key_name].first}"

If for some reason your gsg-keypair is wrong, then the expression
above will produce the key_file "" (ie, blank string). This is b/c the
Dir[].first expression for an invalid or non-existant path produces
nil:
Dir['peace on earth'].first => nil
With no error checking this gets passed into the guts of Net::SSH,
where it throws out a completely opaque error message. True, somewhere
in the message, it is probably trying to complain about the blank file
name, but

• the file name is blank, so you can't see it.
• key_file wasn't blank to begin with, so you are looking for a
  complaint about your key_file, not about nothing.

SSH complaints about nothing are the worst kind of errors to
debug ... :(

At a minimum, rubber should check for the existance of key_file early
on, and throw error message clearly pointing to that line in
rubber.yml as being the problem.

That would probably be enough, although I do wonder if the line
"#{Dir[(File.expand_path('~') rescue '/root') + '/.ec2/*' +
cloud_providers.aws.key_name].first}" might be changed like so:

"#{tmp=(File.expand_path('~') rescue '/root') + '/.ec2/*' +cloud_providers.aws.key_name;Dir[tmp].exist? ? Dir[tmp].first : tmp +" doesn't exist"}"

This might accomplish the same thing, athough it does seem less
elegant.

Thanks,
Rob.

/etc/hosts gets out of whack as private IPs change

Recently I've been noticing the private IPs assigned to instances changing rather frequently. This seems to be much more common for Windows hosts. Using the private hostname should always resolve to the correct IP, using Amazon's internal DNS servers, but Rubber prevents that lookup from happening leading to connection issues.

Support for postgresql?

I'd prefer to use PostgreSQL for my DB. Any support code already kicking around before I try to tackle myself?

rubber:create not working

At this time I'm having issues running cap rubber:create - it will hang trying to connect to the remote instance. I have to use CTRL-C, then use cap rubber:refresh to get going again.

I have no issues logging into the server manually. Also, after the rubber:refresh, everything works fine.

munin plugin generation should use ruby path

rubber's system for generating munin plugins relies on the plugin doing something like "!#/usr/bin/env ruby". While this generally works, munin is run as non-login shell, so the path does not have /usr/local/bin in it, which means munin loads the wrong ruby if you have REE installed.

The solution is to have rubber generate a full path to the script using rubber_env.ruby_prefix.

Update Zerigo API

It looks like rubber uses a deprecated version of the Zerigo API for DNS. We should update to the latest version before they remove support completely for the deprecated one.

Rakefile isn't being vulcanized as part of base

Had several weird problems with a vanilla staging instance created with Rubber, and the root cause turned out to be Rakefile wasn't being vulcanzied. On IRC (#rubberec2 on freenode), nirvdrum had me vulcanize base again to be sure, and while it generated a new Capfile et al, it never asked about my Rakefile.

Once I manually updated my Rakefile to look like the template, my problems went away.

This was on rubber 1.11.0. No earlier version of rubber was used to vulcanize the project.

Store the AMI ID an instance was created with

While debugging a production issue recently I realized it'd be very handy to have the AMI ID for each instance to see what they were created with. This info can be pulled from Amazon, but it probably makes sense to just store this in the local instance file.

Cannot destroy bundle

As can be seen in the following trace, rubber:describe_bundles seems to work fine, but when I try to delete a bundle using the AMI ID, things break.

 ~/d/w/gumshoe /master> cap rubber:describe_bundles
    triggering load callbacks
  * executing `rubber:init'
  * executing `rubber:describe_bundles'
 ** ID: ami-16dc3e7f
 ** Location: gumshoe_images_dev/ie6.manifest.xml
 ** ID: ami-98a84af1
 ** Location: gumshoe_images_dev/staging-20091111_2057.manifest.xml
 ~/d/w/gumshoe /master> cap rubber:destroy_bundle
    triggering load callbacks
  * executing `rubber:init'
  * executing `rubber:destroy_bundle'
The id of the image to be destroyed: ami-98a84af1
/Library/Ruby/Gems/1.8/gems/rubber-1.1.6/lib/rubber/cloud/aws.rb:258:in `destroy_image': Could not find image: ami-98a84af1, aborting destroy_image (RuntimeError)
    from /Library/Ruby/Gems/1.8/gems/rubber-1.1.6/lib/rubber/recipes/rubber/bundles.rb:16:in `load'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:139:in `instance_eval'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:89:in `execute_task'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions_without_help'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:44:in `each'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:44:in `execute_requested_actions_without_help'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/help.rb:19:in `execute_requested_actions'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:33:in `execute!'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:14:in `execute'
    from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/bin/cap:4
    from /usr/bin/cap:19:in `load'
    from /usr/bin/cap:19

passenger_lib location different on some hosts

While bringing up a mixed small/large set of web servers, I ran into an issue with passenger. I base the system image on ubuntu 10.04 with all of the necessary packages installed and not fully configured. In this deploy, we are currently not using ruby enterprise. On i686, rubygems is version 1.3.5 while on x86_64 rubygems is 1.3.7.

On uname -m == i686, passenger_root is /var/lib/gems/1.8/gems/passenger-#{passenger_version}.
On uname -m == x86_64, passenger_root is /usr/lib/ruby/gems/1.8/gems/passenger-#{passenger_version}.

With help from nirvdrum, I was able to work around this issue with some host specific configuration in rubber-passenger.yml. Here it is for reference in case anyone else runs into this problem:

passenger_version: 2.2.15
passenger_root: "/var/lib/gems/1.8/gems/passenger-#{passenger_version}"
hosts:
  x86_64host:
    passenger_root: "/usr/lib/ruby/gems/1.8/gems/passenger-#{passenger_version}"
passenger_lib: "#{passenger_root}/ext/apache2/mod_passenger.so"

Creating new role error mesage

When in rubber.yml i set for host any new role (for example nodejs) i get such message when trying to create instance https://gist.github.com/843988
That fixed when defining at the bottom of rubber.yml this new role:
roles:
nodejs:
packages: [libxslt-dev]
thanks nirvdrum for help !

amazon-ec2 version (latest broken)

When using rubber with the most recent version of amazon-ec2 gem (0.7.5) there is an error due to :group_id being deprecated.

Have tested with the 0.5.x series and rubber works great. Nice work btw!

Cheers,
Alastair

Alias pattern causes security group error

Choosing an alias with the pattern [app_name] _[env]_db_1
is reproducible in freshly retrieved rubygems 1.12.2 gem as well as code cloned from github.
causes the following exception during a cap rubber:create command

gate@tolanna:~/Work/proj-rails/proj$ RUBBER_ENV=staging ALIAS=proj_staging_db_1 ROLES=db:primary=true cap rubber:create
triggering load callbacks

• executing `rubber:init'
• executing `rubber:create'
• Security Group already in cloud, syncing rules: proj_staging_web_tools
• Security Group already in cloud, syncing rules: proj_staging_mysql_master
• Security Group already in cloud, syncing rules: proj_staging_web
• Security Group already in cloud, syncing rules: proj_staging_db_1
• Security Group already in cloud, syncing rules: proj_staging_db
• Security Group already in cloud, syncing rules: proj_staging_default
  ** Creating instance ami-7000f019/m1.small/proj_staging_default,proj_staging_proj_staging_db_1,proj_staging_db,proj_staging_mysql_master/Default
  /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/amazon-ec2-0.9.17/lib/AWS.rb:363:in aws_error?': The security group 'proj_staging_proj_staging_db_1' does not exist (AWS::InvalidGroupNotFound) from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/rubber-1.12.2/lib/rubber/recipes/rubber/instances.rb:226:injoin'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/rubber-1.12.2/lib/rubber/recipes/rubber/instances.rb:226:in create_instances' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/rubber-1.12.2/lib/rubber/recipes/rubber/instances.rb:226:ineach'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/rubber-1.12.2/lib/rubber/recipes/rubber/instances.rb:226:in create_instances' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/rubber-1.12.2/lib/rubber/recipes/rubber/instances.rb:30:inload'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/configuration/execution.rb:139:in instance_eval' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/configuration/execution.rb:139:ininvoke_task_directly_without_callbacks'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/configuration/callbacks.rb:27:in invoke_task_directly' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/configuration/execution.rb:89:inexecute_task'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/configuration/execution.rb:101:in find_and_execute_task' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/execute.rb:46:inexecute_requested_actions_without_help'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/execute.rb:45:in each' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/execute.rb:45:inexecute_requested_actions_without_help'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/help.rb:19:in execute_requested_actions' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/execute.rb:34:inexecute!'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/lib/capistrano/cli/execute.rb:14:in execute' from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/gems/capistrano-2.5.21/bin/cap:4 from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/bin/cap:19:inload'
  from /Users/gate/.rvm/gems/ree-1.8.7-2011.03@proj/bin/cap:19
  gate@tolanna:~/Work/proj-rails/proj

gem_helper problem in newest version (1.10.1)

** /tmp/gem_helper:38: command not found: gem list --local
** /tmp/gem_helper:32: Unable to install versioned gem passenger:3.0.2 (RuntimeError)

I can't seem to get the gem_helper to work when creating a staging server. Somehow the block on 'to_install_ver' is failing. Maybe the gem array is off. I'm new to Rubber so would appreciate some help.

Bootstrapping from an AMI that already has attached volumes

To speed up the process of bootstrapping instances, I've created a base AMI that has all the non-role-specific bootstrapping already done, such as installing RVM and REE, etc. This AMI also happens to have two additional EBS volumes as part of it. However, this causes problems for rubber because if I define these volumes in rubber.yml, it errors out during the bootstrap task because they are already attached. If I take them out of rubber.yml, bootstrapping finishes without error but those volumes don't get added to the local instance configuration file. Is there any way to do this at the moment? And if not, do you have a recommendation on the cleanest way to implement this in rubber?

Add default passenger user

You might want to add this to your passenger.conf template:

PassengerDefaultUser <%= rubber_env.app_user %>

[PATCH] Bumper passenger to 2.2.15

Updated templates to use the most recent passenger-2.2.15

http://github.com/ariejan/rubber/commit/46ff7cd28f219cb7c7c15e4c40e236554de682b8

rake not run through bundle exec

Attempting to cap deploy:cold, cap gets to

* executing "cd /mnt/whathappened-production/releases/20110523111226; rake RAILS_ENV=production  db:migrate"

Then fails with:

** [out :: production...] You have already activated rake 0.9.0, but your Gemfile requires rake 0.8.7. Consider using bundle exec.

My Gemfile does not include rake at all so what I think is happening is that rubber is requiring rake 0.8.7 but installing 0.9.0. I get the problem when I include rubber in the Gemfile (which I need to access the rubber config from the app). I can approach the problem by specifying rake 0.8.7 in the Gemfile and rubber.yml, but it feels artificial and it leads into dependency hell that goes nowhere (i.e. it's not just the rake version).

If I do as rake suggests - i.e. log into the server and run
bundle exec rake RAILS_ENV=production db:migrate
This works fine.

Should rubber be calling rake through bundle exec?

Lock down the version of RubyGems

Each release of RVM grabs whatever the latest version of RubyGems at the time is. In order to have more reproducible deployments, we should lock this down. The rubygems_version value in /usr/local/rvm/config/db contains the setting.

[PATCH] Bumped rvm to 0.1.43

Use rvm-0.1.43, including a fix for setting the rvm_prefix correctly.

http://github.com/ariejan/rubber/commit/616c68ad13724dc2dce4b90af7329f0ba8eeb436

Bad error message if invalid nettica credentials provided

I had the wrong nettica credentials in my rubber.yml file, causing DNS updates to fail. Rubber incorrectly reported the issue as being related to the DNS not existing in nettica. This should be updated to reflect the true error.

/Library/Ruby/Gems/1.8/gems/wr0ngway-rubber-1.0.1/lib/rubber/dns/nettica.rb:21:in `host_exists?': Domain needs to exist in nettica before records can be updated (RuntimeError)

Create staging without write access to /etc/hosts

I'm developing my rails app on Mac OS X with a standard user account, so without direct write access to the /etc/hosts file. Sudo only works if I would su to the admin user.

Unfortunately with this setup rubber can't add the hostnames to /etc/hosts and thus can't connect to the instance because it seems that rubber tries to connect with the hostname. Wouldn't it be possible to connect with the ip-address so that rubber works without a modified /etc/hosts?

Thanks again!

Julian

EC2_URL

It would be nice if there is a way to specify the region (by its EC2_URL, see http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?FAQ_Regions_Availability_Zones.html) in the rubber.yml file too. As far as I have seen the amazon-ec2 gem would support this...

Thanks for your great work on rubber!

(AWS::InvalidGroupNotFound) when adding rules to appname_env_default security group

• Security Group already in cloud, syncing rules: loudcaster_production_mysql_master
• Security Group already in cloud, syncing rules: loudcaster_production_web
• Security Group already in cloud, syncing rules: loudcaster_production_haproxy
• Security Group already in cloud, syncing rules: loudcaster_production_apache
• Security Group already in cloud, syncing rules: loudcaster_production_app
• Security Group already in cloud, syncing rules: loudcaster_production_passenger
• Security Group already in cloud, syncing rules: loudcaster_production_db
• Security Group already in cloud, syncing rules: loudcaster_production_web_tools
• Security Group already in cloud, syncing rules: loudcaster_production_beta
• Security Group already in cloud, syncing rules: loudcaster_production_default
• Missing rule, creating: {"source_group_account"=>"[email protected]", "source_group_name"=>"loudcaster_production_default"}
  /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:282:in aws_error?': The security group 'loudcaster_production_default' does not exist (AWS::InvalidGroupNotFound) from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:220:inmake_request'
  from /usr/lib/ruby/1.8/net/http.rb:543:in start' from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:194:inmake_request'
  from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:245:in response_generator' from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS/EC2/security_groups.rb:122:inauthorize_security_group_ingress'
  from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/cloud/aws.rb:117:in add_security_group_rule' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:154:insync_security_groups'
  from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:149:in each' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:149:insync_security_groups'
  from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:103:in each' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:103:insync_security_groups'
  from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:51:in setup_security_groups' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/instances.rb:158:increate_instance'
  from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/instances.rb:36:in load' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:128:ininstance_eval'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:128:in invoke_task_directly_without_callbacks' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/callbacks.rb:27:ininvoke_task_directly'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:81:in execute_task' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:93:infind_and_execute_task'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:45:in execute_requested_actions_without_help' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:44:ineach'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:44:in execute_requested_actions_without_help' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/help.rb:19:inexecute_requested_actions'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:33:in execute!' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:14:inexecute'
  from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/bin/cap:4
  from /usr/bin/cap:19:in `load'
  from /usr/bin/cap:19
  brandon@dell-desktop:~/projects/rails_apps/loudcaster_new$

deploy-mysql.rb scripts contain syntax error in create_slave_db_from_master

In line 82 of deploy-mysql.rb, a shell script named create_slave_db_from_master is created containing the following:

--password ' + env.db_pass

This causes a syntax error, at least on Ubuntu+MySQL 5.1, because mysqldump expects the --password flag to be appended by an equal sign, e.g: "--password=mypass123". I've updated my deploy-mysql.rb and it works fine. This should be updated in the source as well.

Error during create_staging - You cannot specify the same gem twice with different version requirements. You specified: rubber (>= 0) and rubber (= 1.13.0)

I tried to 'cap rubber:create_staging' but it failed when trying to bundle install because rubber was already specified

executing `rubber:install_bundler_gems'

• executing "sudo -p 'sudo password: ' bash -l -c 'bundle install --gemfile /mnt/pluuck-production/releases/20110424072449/Gemfile --path /mnt/pluuck-production/shared/bundle --deployment --quiet --without development test'"
  servers: ["pluuck.pluuck.com"]
  [pluuck.pluuck.com] executing command
  ** [out :: pluuck.pluuck.com] You cannot specify the same gem twice with different version requirements. You specified: rubber (>= 0) and rubber (= 1.13.0)
  command finished in 2500ms
  failed: "/bin/bash -l -c 'sudo -p '''sudo password: ''' bash -l -c '''bundle install --gemfile /mnt/pluuck-production/releases/20110424072449/Gemfile --path /mnt/pluuck-production/shared/bundle --deployment --quiet --without development test''''" on pluuck.pluuck.com

ruby scripts in crontab should be run in their own bash shell

http://blog.scoutapp.com/articles/2010/09/07/rvm-and-cron-in-production

The various crontab jobs that run as ruby scripts are failing for me (e.g., cron-rake rubber:rotate-logs) because the "require 'open4'" is failing. The cron jobs don't have access to the RVM environment, unless the jobs are forced to run in their own bash shell. There might be a better solution for this, but this seems like the most expedient.

uninitialized constant Rubber

With a fresh installation of rubber 1.5.1 gem, vulcanize gives this error:

./script/generate vulcanize complete_passenger_mysql

uninitialized constant Rubber

Add support for MySQL 5.5

MySQL 5.5 is now out and it'd be nice if rubber supported it out of the box.

Create app user with shell?

I suppose this comes down to a philosophical issue, but I just started running into problems with this after the bundler/rvm changeover.

I run some periodical tasks by having cron call rake tasks in my application. I run these as my app user. This worked fine until bundler/rvm. Since the app user is created without a shell, it doesn't pick up on environment variables that point to the appropriate ruby implementation and associated bundled gems. So doing anything as the app user (except for running the rails stack in passenger, which is explicitly configured) fails when it can't find the gems.

My solution was to change custom_install to create the app user with a shell:
if ! id #{rubber_env.app_user} &> /dev/null; then adduser --system --shell /bin/bash --group #{rubber_env.app_user}; fi

can't convert nil into Array (TypeError)

I have followed the instructions for installing Rubber exactly but I seem to get the following error when I try: cap rubber:create_staging

/home/user/.rvm/gems/ruby-1.9.2-p180/gems/rubber-1.13.1/lib/rubber/instance.rb:161:in `concat': can't convert nil into Array (TypeError)

Stuck on the last DNS setup part

I tried the rubber and it created the ec2 instances. But failed when it was about to change/setup the dns aliases. I was trying with the zerigo. The following is the error:

  * executing `rubber:setup_aliases'
  * executing `rubber:setup_local_aliases'
 ** Writing out aliases into local machines /etc/hosts, sudo access needed
[sudo] password for millisami: 
  * executing `rubber:setup_remote_aliases'
 ** No servers for task setup_remote_aliases, skipping
  * executing `rubber:setup_dns_aliases'
./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:53:in `refresh': undefined method `find' for nil:NilClass (NoMethodError)
    from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:16:in `initialize'
    from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:81:in `new'
    from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:81:in `initialize'
    from ./vendor/plugins/rubber/lib/rubber/dns.rb:9:in `new'
    from ./vendor/plugins/rubber/lib/rubber/dns.rb:9:in `get_provider'
    from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/setup.rb:228:in `destroy_dyndns'
    from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/instances.rb:311:in `destroy_instance'
    from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/instances.rb:59:in `load'
     ... 15 levels...
    from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:14:in `execute'
    from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/capistrano-2.5.8/bin/cap:4
    from /opt/ruby_ee/bin/cap:19:in `load'
    from /opt/ruby_ee/bin/cap:19

use -print0/-0 for find/xargs

From mailing list:

On Jan 5, 2010, at Tue Jan 5, 5:31 PM, Brandon Casci wrote:

I keep getting this error at the end of my deployments. It's not impacting the deployment, and I think it's been going on for a while. I'm just noticing it now. Any ideas?

[staging.loudcity.com] executing command

*** [err :: staging.loudcity.com] xargs:
*** [err :: staging.loudcity.com] unmatched single quote; by default quotes are special to xargs unless you use the -0 option
*** [err :: staging.loudcity.com]
command finished
failed: "sh -c "find /mnt/loudcity-staging/shared -name cached-copy -prune -o -print | xargs chown app:app"" on staging.loudcity.com

---

One of the filenames has a whitespace, quote or something weird in it.
find/xargs normally uses whitespace to delimit between files, but you can change this behavior with -print0 to find and -0 to xargs so that it uses the null char as a delimiter, so your command becomes:

find /mnt/loudcity-staging/shared -name cached-copy -prune -o -print0 | xargs -0 chown app:app

I probably should fix all occurrences of this in rubber, but you can change it manually for now.

Capistrano upgrade problem - uninitialized constant Capistrano::Version::MAJOR

Capistrano's latest version 2.5.16 has removed some constants. I am getting the error uninitialized constant Capistrano::Version::MAJOR.

Cron error missing open4

Using rubber 1.13.0 with complete_passenger_mysql vulcanization

Getting Cron error email with:

internal:lib/rubygems/custom_require:29:in require': no such file to load -- open4 (LoadError) from <internal:lib/rubygems/custom_require>:29:inrequire'
from script/cron-sh:11:in `

'

What to do?

Support for Canonical's Ubuntu Server 9.10 AMIs?

Have you tried using the Ubuntu 9.10 AMIs that Canonical released not too long ago? It'd be nice to not be using a hacked Fedora kernel from 2007, and be using Ubuntu's local mirrors instead of Rightscale's.

Their disabling of root logins trips up rubber early on, though I suppose you could just re-enable it via a user-data script.

Handle binary files in roles

The @path preamble stuff in rubber works great for text-based files. It'd be nice if there were a way to do so for binary files, too. For now I've dealt with it by pulling them down with wget from the rubber module deploy- script, but it'd be nice if I could just store it in the code repository.

The install_rails_gems tasks should not run when bundler is present

The install_rails_gems task is currently run if the Rails version is 2.x. But some of us are moving to bundler early (and an increasing number probably will). The task should not be run if bundler is present.

(It's easy enough to override, but it's an annoyance.)

actionpack requires rack (~> 1.0.0, runtime)

I'm not sure why this is happening now. The situation is another instance as added to the cluster, and rubber:bootstrap was executed.

placing rack before rails in the gem install made the error stop.

** sftp upload #StringIO:0xb767cf84 -> /tmp/gem_helper
[web01.loudcity.com] /tmp/gem_helper
[web01.loudcity.com] done

• sftp upload complete
• executing "sudo -p 'sudo password: ' sh /tmp/gem_helper install $CAPISTRANO:VAR$"
  servers: ["web01.loudcity.com"]
  [web01.loudcity.com] executing command
  ** ERROR: Error installing rails:
  ** actionpack requires rack (~> 1.0.0, runtime)
  ** -:33: Unable to install versioned gem rails:2.3.4 (RuntimeError)
  ** from -:31:in `each'
  ** from -:31
  command finished
  failed: "sh -c "sudo -p 'sudo password: ' sh /tmp/gem_helper install rubber rails:2.3.4 open4 aws-s3 RedCloth hpricot daemons beanstalk-client ruby-hmac amatch hoptoad_notifier memcache-client mysql fastthread rack passenger:2.2.9"" on web01.loudcity.com

uninitialized constant Rubber::Util::RUBBER_ROOT during vulcanize

When going through the quick start guide I am running the command:

$ rails g vulcanize complete_passenger_mysql

and I get the following error spit out after it generates a bunch of config files:

/usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:158:in eval': uninitialized constant Rubber::Util::RUBBER_ROOT (NameError) from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:119:inrails?'
from (eval):1:in block in apply_template' from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:158:ineval'
from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:158:in block in apply_template' from /usr/local/lib/ruby/1.9.1/find.rb:41:inblock in find'
from /usr/local/lib/ruby/1.9.1/find.rb:40:in catch' from /usr/local/lib/ruby/1.9.1/find.rb:40:infind'
from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:148:in apply_template' from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:111:inblock in copy_template_files'
from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:110:in each' from /usr/local/lib/ruby/gems/1.9.1/gems/rubber-1.7.0/lib/generators/vulcanize/vulcanize_generator.rb:110:incopy_template_files'
from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/task.rb:22:in run' from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/invocation.rb:118:ininvoke_task'
from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/invocation.rb:124:in block in invoke_all' from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/invocation.rb:124:ineach'
from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/invocation.rb:124:in map' from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/invocation.rb:124:ininvoke_all'
from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/group.rb:226:in dispatch' from /usr/local/lib/ruby/gems/1.9.1/gems/thor-0.14.0/lib/thor/base.rb:389:instart'
from /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0/lib/rails/generators.rb:163:in invoke' from /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0/lib/rails/commands/generate.rb:10:in<top (required)>'
from /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0/lib/rails/commands.rb:17:in <top (required)>' from script/rails:6:inrequire'
from script/rails:6:in `

'

Rails version is 3.0.0, rubber gem installed via 'gem "rubber"' in Gemfile; appears to be 1.7.0.

Is RUBBER_ROOT a value I'm supposed to define somewhere?

Thanks!

Rubber doesn't handle multiple versions of amazon-ec2 gem

$ gem list | grep amazon-ec2
amazon-ec2 (0.5.0, 0.4.5)

$ RAILS_ENV=nirvdrum cap rubber:create_staging
    triggering load callbacks
  * executing `rubber:init'
/Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems.rb:280:in `activate': can't activate amazon-ec2 (= 0.4.5, runtime) for [], already activated amazon-ec2-0.5.0 for ["rubber-0.9.4"] (Gem::LoadError)
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:35:in `require'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/cloud/aws.rb:2
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/cloud.rb:7:in `get_provider'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/recipes/rubber.rb:51:in `load'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:139:in `instance_eval'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:89:in `execute_task'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/callback.rb:38:in `call'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `trigger'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `each'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `trigger'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:32:in `execute!'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:14:in `execute'
    from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/bin/cap:4
    from /Users/nirvdrum/Gentoo/usr/bin/cap:19:in `load'
    from /Users/nirvdrum/Gentoo/usr/bin/cap:19

Rubber runs rake install:gems at the wrong time

When setting up a staging instance, during the first deploy rubber
tries to run "rake gems:install" before a rubber:config has
transformed and placed all templates, including the database.yml. This
makes gems:install fail.

Does this happen to anyone else? Or is it maybe a problem with our
environment configuration inside the Rails app?