Posted by sime on July 15, 2010 at 4:36am
5 followers
Jump to:
| Project: | Drush |
| Version: | All-versions-3.x-dev |
| Component: | Documentation |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Successfully using:
drush sql-sync @live @devBut I want to avoid a developer accidentally doing:
drush sql-sync @dev @live1. 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
#1
search 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
#2
Cheers 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
#3
There 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:
$aliases['live'] = array ('remote-host' => 'servername.com',
'remote-user' => 'publisher',
'uri' => 'http://drupalsite.org',
'root' => '/srv/www/drupal',
'command-specific' => array (
'sql-sync' => array (
'simulate' => '1',
),
'rsync' => array (
'simulate' => '1',
),
),
);
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:
$aliases['dev'] = array ('uri' => 'http://drupalsite.org',
'root' => '/srv/www/dev.drupalsite.org',
'command-specific' => array (
'sql-sync' => array (
'simulate' => '0',
),
'rsync' => array (
'simulate' => '0',
),
),
);
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.
#4
This is brilliant!
#5
This 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).
#6
Happy 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!
#7
Very nice blog post; thank you for writing that up.
#8
I added a link to your blog post to the end of the site alias documentation.
#9
Honoured! You have full permission to pinch any for d.o handbook though.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.