Drupal site administration - Library servers

The scripts we use assume a directory layout like this

• libweb
  • sites
    • [domain name]
      • htdocs
        • [ Drupal site is here ]
        • sites
          • default *
            • settings.php
            • files [for Drupal 6 and 'public files' for Drupal 7 ]
              • backup_migrate
      • make (this is only on the test server)
        • [domain name]
          • [domain name].make
      • drupal_files [private files for Drupal 7 ]
        • backup_migrate

and assume there is a drush alias set up for the site called @[domain name] .

* it does not work with a domain name here!

How to change the modules and themes

• 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

How to rebuild your site

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

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

How to update your theme/module code on the site

• make changes on your copy and check them in to svn
• go to victoria02 and cd /libweb/sites/[your site name]/htdocs/sites/all/[modules or themes]/[your code's name]
• svn up

How to work with your custom themes/modules

• check out svn copies on your machine
• edit/whatever the copies
• check in changes

Moving sites between machines

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

How to get the latest versions of the scripts

• 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

• 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_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

• Log on to the test  Drupal site
• Make a backup of the test site to the Manual Backups Directory (using Backup and Migrate module)
• Log on to the production Drupal site
• Put the production site into maintenance mode
• Determine which machine the production site is onthe script will ask you if you've done each step and give you all the proper paths
  • 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]
• restore the latest backup
• configure the 'site under maintenance' block
  • Under 'Page specific visibility settings' select 'Show on only the listed pages'