cap deploy:cold no pg_hba.conf entry

[Shaun Thompson]

Hello,

I'm currently trying to deploy a Rails/Postgres application to EC2 using rubber.

When I run cap deploy:cold, I get the following error

* executing "cd /mnt/xx/releases/20130517175524 && bundle exec rake RAILS_ENV=production  db:migrate"

    servers: ["db01.foo.com"]

    [db01.foo.com] executing command

 ** [out :: db01.foo.com] rake aborted!

 ** [out :: db01.foo.com] FATAL:  no pg_hba.conf entry for host "xx.xx.xxx", user "xx", database "xx_production", SSL off

I've added several entries to the /rubber/role/postgresql/pg_hba.conf file and can't get passed this error.

[Kevin Menard]

Hi Shaun,

I don't know why it's trying to do a DB migration as part of deploy:cold.

Can you do a:

cap deploy

cap deploy:migrations

in that order and see if it fixes the problem for you?

Thanks,

Kevin

--
You received this message because you are subscribed to the Google Groups "rubber" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubber-ec2+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shaun Thompson]

cap deploy works but cap deploy:migrations fails with the same error.

[Kevin Menard]

Did you restart PostgreSQL after your change?  The default rubber config sets up pg_hba.conf correctly before the server starts, so it's not a problem.  But pg_hba.conf entries can't be picked up via SIGHUP and so require a full server restart.  As awesome as rubber is, we don't trust automated DB server restarts, so you'd have to manually restart it on your own after the modified file has been deployed.

cap rubber:postgresql:restart should do the trick.

-- 

Kevin

[Shaun Thompson]

All right that worked.

Now I'm also using unicorn and when I run cap rubber:unicorn:start it throws an error no servers for task start.

[Kevin Menard]

Do your servers have the "unicorn" role?  As you can see in the task definition, it will only run on the servers with that definition:

https://github.com/rubber/rubber/blob/master/templates/unicorn/config/rubber/deploy-unicorn.rb#L18

--
Kevin

Shaun Thompson

Saturday, May 18, 2013 10:15 PM

All right that worked.

Now I'm also using unicorn and when I run cap rubber:unicorn:start it throws an error no servers for task start.

On Friday, May 17, 2013 3:34:23 PM UTC-5, Kevin Menard wrote:

--
You received this message because you are subscribed to the Google Groups "rubber" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubber-ec2+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Kevin Menard

Friday, May 17, 2013 4:34 PM

Did you restart PostgreSQL after your change?  The default rubber config sets up pg_hba.conf correctly before the server starts, so it's not a problem.  But pg_hba.conf entries can't be picked up via SIGHUP and so require a full server restart.  As awesome as rubber is, we don't trust automated DB server restarts, so you'd have to manually restart it on your own after the modified file has been deployed.

cap rubber:postgresql:restart should do the trick.

-- 

Kevin

On Friday, May 17, 2013 at 4:31 PM, Shaun Thompson wrote:

Shaun Thompson

Friday, May 17, 2013 4:31 PM

cap deploy works but cap deploy:migrations fails with the same error.

On Friday, May 17, 2013 2:34:05 PM UTC-5, Kevin Menard wrote: --

You received this message because you are subscribed to the Google Groups "rubber" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubber-ec2+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Kevin Menard

Friday, May 17, 2013 3:34 PM

Hi Shaun,

I don't know why it's trying to do a DB migration as part of deploy:cold.

Can you do a:

cap deploy

cap deploy:migrations

in that order and see if it fixes the problem for you?

Thanks,

Kevin

On Friday, May 17, 2013 at 3:31 PM, Shaun Thompson wrote:

Shaun Thompson

Friday, May 17, 2013 3:31 PM

[Shaun Thompson]

They did but I had to apply the roles to the instance after they were created.

When creating the instance with automatic security groups, it first fails if there are the default icmp,udp,tcp rules defined - something to the effect that no group_id was defined.  

Once removing the roles, the instance creation will continue if auto-security groups is off as the number of roles assigned to my instances exceeds the VPC limit.

https://forums.aws.amazon.com/thread.jspa?messageID=453269&#453269

Here's what I currently have for roles on my instances.

http://awesomescreenshot.com/0e81auw136

Now when I go to app.foo.com, I get "We're sorry, but something went wrong."

Checking the nginx logs shows this.

2013/05/21 00:17:46 [error] 1635#0: *15 connect() to unix:/var/run/unicorn.sock failed (111: Connection refused) while connecting to upstream, client: XX.XX.XX.XX, server: foo.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/run/unicorn.sock:/", host: "app01.foo.com"

[Kevin Menard]

Hi Shaun,

Thanks for sticking with this.  I have no idea how well Rubber works with VPC currently.  We don't do any special handling for it, so things like security groups and elastic IPs likely aren't being applied to the VPC.

If you could start filing issues for VPC related things, that'd be helpful.  I'd like to get to adding VPC support, but as it stands you're traveling in uncharted waters.

-- 

Kevin