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

moshe weitzman’s picture

Status: Active » Fixed

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

sime’s picture

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

greg.1.anderson’s picture

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.

sime’s picture

This is brilliant!

moshe weitzman’s picture

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).

sime’s picture

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!

greg.1.anderson’s picture

Very nice blog post; thank you for writing that up.

greg.1.anderson’s picture

I added a link to your blog post to the end of the site alias documentation.

sime’s picture

Honoured! You have full permission to pinch any for d.o handbook though.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

SolomonGifford’s picture

As 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.

greg.1.anderson’s picture

Yeah, #3 is not the best way to go. See the example policy file for a better method.

Chaulky’s picture

Is 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?