Page History

...

* it does not work with a domain name here!

...

How to get yourself set up to use the scripts

• do this on each machine (victoria01, victoria02, victoria03)

      cd ~
      git clone git@github.com:cul-it/drupal-site-moves.git
  

How to change the modules and themes

• if the drush.make file is in git
  • it will likely be in github in cul-it in a repository named after the site
    • eg. www-library-cornell-edu corresponds to www.library.cornell.edu
  • clone the repo to your local machine to do the updates, then check back in on the master branch
• if the drush.make file is in subversion
  
  • do a subversion checkout of https://svn.library.cornell.edu/cul-drupal
• • find your make file under cul-drupal/[drupal_6 or drupal_7]/make/[your site name]/[your site name].make
• add lines or modify the version of the module listed according to the drush make file format (use other sites for examples)
• check in the changed version

...

• go to victoria02 and cd /libweb/sites/[your site name]/make
• sudo dr-make.sh @[your site name]

• Panel
  Note: the alias argument @[your site name] is no longer necessary for dr-make.sh

• a few sites on victoria02 use drush.make files stored in git
  • use ~/drupal-site-moves/dr-make-git.sh for these
  • main1.test.library.cornell.edu

How to update your theme/module code on the site

...

• You need to have ssh keys set up so you can get to the other machine without a password prompt
• one easy way to do this is set up the drush command 'pushkey'
  
  • read all about it: https://www.drupal.org/project/drush_extras

  • PUSHKEY
    
        drush pushkey user@host.domain.com
    
    	Creates an ssh public/private key pair in $HOME/.ssh, if
    	one does not already exist, and then pushes the public
    	key to the specified remote account.  The password for the
    	destination account must be entered once to push the
    	key over; after the key has been stored on the remote
    	system, subsequent ssh and remote drush commands may be
    	executed using the public/private key pair for authentication.
    
    	IN DRUSH EXTRAS because is is Linux / openssl-specific.
            

  • install it in your user's drush
    • log in to victoria02

    • drush dl drush_extras

  • use it

    • log in to victoria02
    • drush pushkey nid123@victoria01.library.cornell.edu
    • prompts for password on victoria01 one time
    • now try
      • ssh nid123@victoria01.library.cornell.edu
      • no password prompt, right?

once the ssh keys are set up, you can avoid lots of extra 

Enter passphrase for key '/home/user/.ssh/id_rsa'

prompts by using this command:

ssh-add

How to move from production to test

See this: http://blog.joncairns.com/2013/12/understanding-ssh-agent-and-ssh-add/

How to get the latest versions of the scripts

• log in to victoria02
• grab the new scripts from github

  • cd ~

  • git clone git@github.com:cul-it/drupal-site-moves.git

  • cd ~/drupal-site-moves

  • git pull

How to set permissions on a site

• log in to the server where the site is via ssh
• get the latest versions of the scripts

• ~/drupal-site-moves/set_permissions.sh <site name>

How to move from production to test

• Set permissions for the production site on the production machine
• Set permissions on test site on the test machine
• while logged in to the test machine:

  • ~/drupal-site-moves/pull_site_from_production.sh <production site name> <test site name>

• you are prompted for your password
• you are asked to confirm the site move
• you are asked to inform the site users that you are working on the site on the test server
  • put up the 'Site Under Maintenance' block
• script continues on without requiring any input from you
  • backs up the database
  • moves the site files to the target server
  • installs the backed up database on the target server
• done

• Log on to the production  Drupal site and configure the 'Site under maintenance' block
  • Under 'Page specific visibility settings' select 'Show on every page except the listed pages.'
• Make a backup of the production site to the Manual Backups Directory (using Backup and Migrate module)Log on to the test Drupal site
  • Drupal 6: http://$productiondomain/admin/content/backup_migrate/export
  • Drupal 7: http://$productiondomain/admin/config/system/backup_migrate
• Put the test site into maintenance modego to victoria02 and cd /libweb/sites/[your site name]/make
  • Drupal 6: http://$testdomain/admin/settings/site-maintenance
  • Drupal 7: http://$testdomain/admin/config/development/maintenance
• Determine what machine the production site is onLog on to the test Drupal site
  • victoria03 - www.library.cornell.edu, beta.library.cornell.edu
    • sudo update_test_from_victoria03.sh [your production site domain] [your test site domain]
  • victoria02 - all the others
    • sudo update_test_from_production.sh [your production site domain] [your test site domain]
  • the script will ask you if you completed each of the steps above and give you all the real paths to the pages you need to use
  • the script moves the site with rsync
• Restore the latest backuptake the test site out of maintenance mode
  • Drupal 6: http://$testdomain/admin/content/backup_migrate/destination/list/files/manual
  • Drupal 7: http://$testdomain/admin/config/system/backup_migrate/destination/list/files/manual
  • click 'restore' next to the latest version of the file (hint: sort by file name!)

How to move from test to production

How to move from test to production

• Set permissions for the test site on the test machine
• Set permissions on production site on the production machine
• while logged in to the production machine:

  • ~/drupal-site-moves/pull_site

• log in to victoria01 or victoria03
• grab the new scripts from github
  • cd ~
  • git clone git@github.com:cul-it/drupal-site-moves.git
  • cd ~/drupal-site-moves
  • git pull
• ~/drupal-site-moves/pull

  • _from_test.sh <test site name> <production site name>

• you are prompted for your password

• you are asked to confirm the site move
• you are asked to confirm again
  • you can take down the 'Site Under Maintenance' block while the site is still on the test server
• script continues on without requiring any input from you
  • backs up the database
  • moves the site files to the target server
  • installs the backed up database on the target server
• done

...

• victoria03 - www.library.cornell.edu, beta.library.cornell.edu
  • ssh to the production machine victoria03 and cd /libweb/sites/[your site name]/make 
  • sudo update_victoria03_from_test.sh [your test domain] [your production domain]
• victoria01 - all the others
  • ssh to the production machine victoria01 and cd /libweb/sites/[your site name]/make 
  • sudo update_production_from_test.sh [your test domain] [your production domain]

...