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 -~----------~----~----~----~------~----~------~--~---
