Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Successfully using:
drush sql-sync @live @dev
But I want to avoid a developer accidentally doing:
drush sql-sync @dev @live
1. Is there a way to specify in drushrc.aliases.inc that a site's database should be read-only.
OR
2. Is there a way to configure a hook in ~/.drush/something.drush.inc
on the remote server, even just for the user that is used to connect, to short-circuit the command that used to sql-load the database there.
Thanks kindly
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedsearch this issue queue for 'policy'. we discussed a policy module which adds validators to the operations it wants to prohibit. validate hook is descriped in api.drush.php
Comment #2
simeCheers Moshe!
Link to related issue #446736: Have drush update be told to ignore a module/theme -- simple solution
Keywords for searching: protect, read-only, lock
Comment #3
greg.1.anderson CreditAttribution: greg.1.anderson commentedThere is another alternative for this. If you add options to your site aliases, @dev and @live, then those options will be applied every time those aliases are used in any context. If you also wrap those options in a 'command-specific' array, then the options will only be applied when a particular command is executed.
Consider, then, the following record:
Now you can't use @live with sql-sync or rsync at all. If you try, it will just print out the commands that it would have done. We can fix this by adjusting our @dev alias too:
Now, when @dev is used as the destination of the rsync or sql-sync command, --simulate=0 will take precedence, but when @live is the destination, then --simulate=1 will take precedence. If you need to override this for some reason, you can add --simulate=0 on the command line, and force a sync to live.
There are other interesting uses for this effect as well; for example, you can specify different 'skip-tables-list' options for dev and live to set up a 'pull data, push configuration' environment.
I was going to explain this at DrupalCon SF, but it didn't really fit into our presentation, in part because it's a little hard to explain. Hopefully the preceding explanation makes sense, though.
Comment #4
simeThis is brilliant!
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedThis is terrific. I didn't know exactly how it worked. Thanks.
This may or may not work as policy enforcement for an organization, since it can be overridden via command line options (by design).
Comment #6
simeHappy to say that I got this working using aliases. I like that it is possible to override the "simulate" option, as I only want to prevent accidents.
I've blogged here:
http://emspace.com.au/article/drush-aliases-primer-live-dev-syncing
Thanks again!
Comment #7
greg.1.anderson CreditAttribution: greg.1.anderson commentedVery nice blog post; thank you for writing that up.
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedI added a link to your blog post to the end of the site alias documentation.
Comment #9
simeHonoured! You have full permission to pinch any for d.o handbook though.
Comment #11
SolomonGifford CreditAttribution: SolomonGifford commentedAs a note, the documentation in #3 (that the simulate in the alias will protect @live but not @dev) is no longer the case in the lastest d7 versions of drush.
Comment #12
greg.1.anderson CreditAttribution: greg.1.anderson commentedYeah, #3 is not the best way to go. See the example policy file for a better method.
Comment #13
Chaulky CreditAttribution: Chaulky commentedIs it possible to override the policy from the command line? Originally using simulate=1 was a way to prevent accidentally writing to production, so that you had to explicitly override the simulate. Is that possible with a policy?
EDIT: I think I see how it would work. That's what the --token=secret would allow you to do right?