Or,
You can condigure passwordless access (tricky?) from the local machine only

GRANT select,delete,update, (anything else you need) ON `` TO
`railsus...@localhost;
FLUSH PRIVILEGES;

(by excluding the IDENTIFIED BY 'passwd' it should be a passwordless
account)

I'm not condoning this practice, work with it in line with your company's
policy on security & passwords!

- Lee

2009/5/21 Simone Carletti <[email protected]>

> I created a standalone recipe months ago.
> You can grab it from gist, save the file in your lib folder and load it
> from deploy.rb.
> http://gist.github.com/2769
>
> It provides a couple of additional options.
>
> -- Simone
>
>
>
> On Thu, May 21, 2009 at 4:42 AM, Glenn Rempe <[email protected]> wrote:
>
>>
>> You might take a look at the Thoughtbot Suspenders template Rails
>> app.  It contains a deploy.rb that prompts you for a db password when
>> you run cap deploy:setup and stores that password in a shared file on
>> the remote DB server.
>>
>> http://bit.ly/QcrOl
>>
>> The database.yml file is then setup to pull the password from this
>> shared file:
>>
>> http://bit.ly/svm27
>>
>> The primary benefit here being that you don't store the password in
>> your SCM.
>>
>> Glenn
>>
>> On May 20, 6:27 pm, "S. Robert James" <[email protected]> wrote:
>> > We have our cap deploy setup to take a new app server from zero to
>> > working, all automatically.
>> >
>> > One issue we're getting stuck with is: Where to store the database
>> > password?
>> >
>> > I'll show you what we thought of, and why we don't like it.  I'm sure
>> > some of the pros here have already grappled with this, so I'd like to
>> > here what you say.
>> >
>> > 1. Store in cap deploy files.
>> > PROBLEM: We don't want every developer who ever had access to cap
>> > deploy source to know the passwords.
>> >
>> > 2. Store in file on each server.
>> > PROBLEM: This would require manual setup of a new server.
>> > PROBLEM: Even if we accept to do it manually, in the course of doing
>> > so, it's quite likely that the password will get emailed around.
>> > "Anyone remember the pw to setup a new server? The box is down and I
>> > need to do a replacement quick."
>> >
>> > 3. Use a nonpassword system
>> > Windows supports authentication via user account on a known machine.
>> > I'm not sure how it works, or how secure it is.  Haven't found any
>> > simple, secure way to do this via Linux.  The ideal would be to tell
>> > the database server "If user rails_app on any of the local machines
>> > wants to connect, they don't need a password."   But I'm not sure if
>> > there is a simple and secure way to do this.
>> >
>> > 4. Use some type of encryption
>> > I'm not sure how to use this to solve problems.  The key needs to go
>> > somewhere, and so we're back to square one, on where to store the key.
>> >
>> > What do you do? Is there a best practice? What do the large
>> > enterprise / J2EE shops do?
>>
>>
>>
>
>
> --
> Simone Carletti
>
> Site & Blog: http://www.simonecarletti.com
> Email: [email protected]
> LinkedIn: http://linkedin.com/in/weppos
> Nick: weppos | Skype: weppos
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---

Reply via email to