1. Spin up machine

   1. Run ansible scripts

2. Activate maintenance mode on old server

3. Export Fedora data (in sufia 6 instance)

   1. Run audit script (takes 4 or 5 mins)

      1. RAILS_ENV=production bundle exec sufia_survey -v

   2. Make sure you have the latest deployment

   3. Make sure tmp/export is empty

   4. Run json export (takes < 10 mins)

      1. $ RAILS_ENV=production bundle exec sufia_export --models GenericFile=Chf::Export::GenericFileConverter,Collection=Chf::Export::CollectionConverter

   5. Open up fedora port to the other server so it can grab the binaries

   6. Change all the 127.0.0.1 URIs to reflect internal IPs, e.g.

      1. $ find tmp/export -type f -name "*.json" -print0 | xargs -0 sed -i "s/127\.0\.0\.1/[internal_ip_of_prod]/g"

      2. The internal IP of prod is: 172.31.48.168
      3. The internal IP of staging is: 172.31.58.101
   7. Move the resulting directory full of exported data from tmp/export to the new server's tmp/import (or wherever desired; this can be provided to the import script)
      1. $ cd tmp; tar -czf json_export_201611141510.tgz export
   8. Then from your own machine:
      1. $ scp -i ~/test.pem staging:/opt/sufia-project/current/tmp/json_export_201611141510.tgz new_box_ip:/opt/sufia-project/current/tmp/.

4. Migrate postgres

   1. Run the following to generate the export.

      1. pg_dump -U postgres chf_hydra -Fp > chf_hydra_dump.sql

   2. Copy the file to the new machine

      1. scp -3 -i ~/test.pem ubuntu@production_ip:~/chf_hydra_dump.sql ubuntu@new_box_ip:~

   3. Import the file

      1. psql -U postgres chf_hydra < chf_hydra_dump.sql

5. Deploy chf-sufia to new server

6. Create Drives

   1. In the AWS visual interface, go to EC2

   2. Go to Volumes

   3. Select Create Volumes

   4. Make two volumes with the following features:

      1. General Purpose SSD

      2. 150 GB

      3. Availability Zone b

   5. Once each one is made, select it and under Actions choose Attach Volume. Type the name or id of the machine and attach the volume.

   6. ssh into the box

   7. sudo fdisk -l

      1. You should see /dev/vxdg and /dev/xvdh

      2. If not, check if the volumes are attached

   8. Create the filesystem for each disk

      1. sudo mkfs.xfs /dev/xvdg

      2. sudo mkfs.xfs /dev/xvdh

   9. Mount each disk

      1. sudo mount /dev/xvdg /opt/fedora-data

      2. sudo mount /dev/xvdh /opt/sufia-project/releases/XXXX/tmp

   10. Edit the fstab file to retain these mounts

       1. sudo vi /etc/fstab

       2. /dev/xvdg /opt/fedora-data xfs defaults 0 0

       3. /dev/xvdh /opt/sufia-project/releases/XXXX/tmp xfs defaults 0 0

   11. Change the owner of the two mount locations

       1. sudo chown -R tomcat7:tomcat7 /opt/fedora-data

       2. sudo chown -R hydep:deploy /opt/sufia-project/releases/XXXX/tmp

7. Restart Solr

   1. If this is the first time sufia has been deployed, Solr now runs outside of tomcat and needs to be restarted after deployment.

      1. sudo service solr restart

8. Ensure apache is off on new server

   1. We don't want anyone doing stuff before we're ready.

9. Restart Tomcat on new server

   1. sudo service tomcat7 restart

10. Move over minter statefile

    1. On Production
       
       1. sudo cp /var/sufia/minter-state ~
       2. sudo chown ubuntu:ubuntu minter-state
    2. Then copy the file

       1. scp -3 -i ~/test.pem ubuntu@production_ip:~/minter-state ubuntu@new_box_ip:~

    3. On New Box
       1. sudo mv minter-state /var/sufia
       2. sudo chown hydep:deploy /var/sufia/minter-state

11. Import Fedora data (in sufia 7 instance)

    1. Unpack the exported json files

       1. cd /opt/sufia-project/current/tmp/

       2. tar -xzf json_export_201611141510.tgz

       3. mv export import

    2. configure sufia6_user and sufia6_password in config/application

    3. run the import

       1. $ RAILS_ENV=production bundle exec sufia_import -d tmp/import --json_mapping Chf::Import::GenericFileTranslator=generic_file_,Sufia::Import::CollectionTranslator=collection_

12. run (currently nonexistent) verification job

13. migrate dump.rdb

14. Reindex solr

How to check the statefile

There are 3 parts to the state: sequence, counters, and seed. You need the correct combination of all three in order to have the right state. However, if you know you have two valid state files with the same origin you can do a rough comparison of their equivalence just by checking the sequence. To check sequence in our 7.2-based application:

$ cd /opt/sufia-project/current

$ bin/rails c production

> sf = ActiveFedora::Noid::Minter::File.new

> state = sf.read

> state[:seq]

To check in our 6.7-based application:

$ cd /opt/sufia-project/current

$ bin/rails c production

> sm = ActiveFedora::Noid::SynchronizedMinter.new

> state = {}

> ::File.open(sm.statefile, ::File::RDWR|::File::CREAT, 0644) do |f|

>   f.flock(::File::LOCK_EX)

>   state = sm.send(:state_for, f)

> end

> state[:seq]

To check sequence on a file that's not in the default location, pass the template and the filename when you create the object with 'new', e.g:

> sm = ActiveFedora::Noid::SynchronizedMinter.new(".reeddeeddk", "/var/sufia/minter-state")

Misc.

Postgres

You can get a list of all tables and fields with the command:

SELECT * FROM information_schema.columns WHERE table_schema = 'public'

Cleanup

To clean up a server for a new migration test, take the following steps.

1. Stop Tomcat and Solr
2. Remove all the folders in /opt/fedora-data.
3. Remove all the files in /var/solr/data/collection1/data/index/, and /var/sufia/derivatives
4. Remove all the upload files in the tmp directory of the version of sufia used.
5. Enter into postgres (psql -U postgres)
6. Drop the fcrepo database (DROP DATABASE fcrepo;)
7. Build a new fcrepo database (CREATE DATABASE fcrepo;)
8. Grant the fcrepo user (currently tribly until we get a better user) all privileges on fcrepo. (grant all privileges on fcrepo to tribly;)
9. Restart tomcat and sol