Page Comparison

...

• Migrate production to LibraryHost

  • Preparation:

    • Purchase a production LibraryHost plan

    • Ensure the PUI is accessible. (see https ://shi-staging.libraryhost.com)

    • Ensure the new server’s API is accessible via HTTPS (see https://sciencehistory-api.libraryhost.com/)

    • Ensure the new server’s API is inaccessible via HTTP. (see http://shi-stagingarchives.libraryhostsciencehistory.comorg:8089/ )

  • Migration proper (this needs to take place within a short period: ideally, 2 or 3 business days).

    • Preparation

      • Send out a notice to users reminding them of the migration and warning them to make any final metadata changes before the end of the business day

      • Create an IAM policy and user that gives LibraryHost write access to the backup directory in S3, and to nothing else.

      • Users can make their final edits to the old ArchivesSpace metadata before the migration.

      • Move the latest backup of the old ArchivesSpace DB out of the regular backup directory and move it into another directory where it won’t get overwritten.

      • Create a dump of the database that can be sent to LibraryHost

      • Run the mapping script and send updated collection description links to to Gabriela and Caroline

      • Prevent users from logging in to the old site by turning off the ArchivesSpace daemon.

      • Turn off the EAD export

    • Migration

      • Eddie sends database over from EC2 ArchivesSpace to Manny.

      • Create an issue and PR to change the data in the digital collections to the new URLS. (These URLs won’t work until archives.sciencehistory.org is pointing at the new server).

      • Wait until our wildcard certificate is installed at the new server and it can accept connections from our domain.

      • Point archives.sciencehistory.org at the new LibraryHost server (with help from Chuck).

      • Update the OPAC and the digital collections to point at the new production URLS in the production PUI.

        💡 Note that external links to our HTML finding aids are rare. There should be no need to provide redirects from the old URLS to the PUI when we discontinue the HTML finding aids.

      • Spin down the ec2 servers - leave them around, inactive, for a month or so.

        • 💡 For forensic purposes it can be turned back on as needed; it will come up at https://50.16.132.240/.

    • Exports and backups

      • Update our EAD export to point at the LibraryHost API instead of our ArchivesSpace server.

        Part of this task is re-adding the scheduled Heroku task, disabled during the migration. Add a task to run the following every week: bin/proximo bundle exec ruby run.rb && curl https://api.honeybadger.io/v1/check_in/OaIlNl &> /dev/null

        

      • Ensure backups are going to our s3 backup bucket as planned.

  • Cleanup (no deadline.)

    • Retire the Ansible codebase

    • Retire AWS services that existed only to support ArchivesSpace (such as our single remaining elastic IP address)

    • Make sure the EAD export is running weekly, instead of daily

    • Go back to a development ($5 / month) Proximo plan. We temporarily moved to the Development plan on May 23rd. See https://github.com/sciencehistory/export_archivesspace_xml/issues/18 for details and instructions.Permanently remove old production ArchivesSpace EC2 server

    • Since we will now have secure access to the API, possibly remove Proximo from export_archivesspace_xml altogether and run the export (over https) using plain username/password authentication. Decide whether we still want to back up the database on Dubnium; `/home/ubuntu/archivesspace_scripts/mysql-backup.sh`, which dumped the database to a location where it was harvested by the Dubnium backup scripts, will have stopped running.

    • Retire the Ansible codebase

    • Make sure Chuck’s backup pipeline is getting nightly backups

    • Retire AWS services that existed only to support ArchivesSpace (such as our single remaining elastic IP address)