Great idea, everyone. Sounds a lot more straightforward - I'll go with the alternative migration user.
On Mar 12, 4:41 am, Simone Carletti <[email protected]> wrote: > In this case you might want to create a migration Rails environment pointing > to the production database but with the migration user. Then, ask Capistrano > to execute db:migrate with "migration" environment. > > With this configuration you don't need odd workarounds to switch users in > the same production environment. > > -- Simone > > On Wed, Mar 11, 2009 at 11:27 PM, Lee Hambley <[email protected]> wrote: > > I'm with Sarah, > > Make a "migration" user that is the production database, with a more able > > user defined, use this account to run the migrations, which will still > > affect the production database. > > > = Lee > > > 2009/3/11 Sarah Mei <[email protected]> > > >> One option is to set up another environment (development, test, > >> production, migration) with a separate entry in database.yml, and a db > >> user with increased privileges vs the production user. The capistrano > >> migrate task takes a parameter specifying the Rails environment. > > >> I agree that you should also do IP restriction, though that solves a > >> different problem. The less-privileged production user makes sure a > >> bug *in the app* doesn't do something catastrophic. There are, of > >> course, backups, but downtime costs money. :) > > >> Sarah > > >> On Wed, Mar 11, 2009 at 11:50 AM, Ryan <[email protected]> wrote: > >> > I'm pretty new to Rails and Capistrano and am in the middle or > >> > deploying my first application. I'm wondering about the database > >> > privileges the production user should have. It seems to me that the > >> > db user should be locked down (only read/write to existing tables, no > >> > creating or dropping tables, etc.) when the Rails application is > >> > running. But when the application is being deployed, the user must > >> > have those extended privileges to do the migration. Everywhere I > >> > read, the database scripts create a db user will all privileges > >> > granted - which works for the deployment, but seems too insecure for > >> > everyday use. Am I wrong in thinking this, and should I just grant > >> > all privileges and not worry about it? Or is there something I'm > >> > missing in the Capistrano setup that grants the db user privileges at > >> > the beginning, then removes them at the end? Thanks for any help. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
