This page is to walk through the execution of the upgrade script, explaining what it does at each step and providing information (links to other documentation) that describes it in more detail. PurposeThe server file, tf_upgrade.sh is an upgrade configuration script, run on the command-line, which runs through some basic Q and A for the user to answer about specific configurations for redbox or mint. As the script steps through prompts for the user, it backs up the current configuration files affected by the script to another directory (e.g, <fascinator-home>/pre-upgrade-backup). The questions are either yes/no or short answers for the user to provide. Running the upgradeThe upgrade script is executed in a similar manner to tf_restore.sh: Change into the server directory in your redbox installation. e.g., cd /opt/redbox/server Ensure that your redbox installation is shutdown (and afterwards check that the server is no longer running): sudo -u redbox ./tf_server stop Find and execute the script, tf_upgrade.sh, as the redbox installation user: sudo -u redbox ./tf_upgrade.sh In the example, above the redbox user is redbox
If the script is executed correctly, you should now see some command line prompts for you to enter details about your installation upgrade. Redbox upgrade processCurrently, the redbox upgrade configuration script will step through the following prompts: Verifies correct upgrade version- The script checks that the server library version matches the version named in the upgrade script (e.g, redbox-1.9-SNAPSHOT.pom).
- If there is no match, the script will display a message that the library version is incorrect and the script will exit.
- The script will also prompt to upgrade the version recorded by the server - ensure this is also matched.
Checks if changes have been made to the dataset configuration templates- If so, no updates are made to the configuration, with a simple message that these should be reviewed.
- If not, the upgrade script proceeds to update the configuration, which currently checks:
Curation relations which should be excluded- (see Curation exclude conditions for details of the new configuration)
- Previously, identifiers could only be excluded individually. From the 1.9 upgrade, redbox can now also exclude all relations except for that identifer which is nominated.
- The script steps here are:
- exclusion conditions for the parties/groups relation identifier prefix that start with are found (e.g., nla identifier prefixes)
- the user is prompted for the mint identifier prefix
- the exclusion conditions identified are replaced such that any identifier that doesn't start with the mint identifier prefix are excluded from curation. In this way, redbox will ignore other parties/groups identifiers such as NLA and ORCID, during curation.
Record as location- The user can choose to have a record's URL included as a rif-cs location, using the template named in the upgrade script (e.g, ${urlBase}published/detail/${oid} ) (see recordAsLocationDefault collection form field)
Configure the new rifcs transformer- The user can choose to use:to write the rifcs records.
- By answering yes, the script will set up the configuration required to use the new rifcs transformer, over the rifcs template.
- The script will also enable harvest remapping on restore, to ensure that the rifcs transformer is applied when running the restore/migration process, following this upgrade script.
Note: At the 1.9 release, both the rifcs velocity template and the rifcs groovy script are compatible with rif-cs version 1.6.1. However, in the future (TBA), the rifcs velocity template will become deprecated, with revisions made only to the groovy script.
Create the api user configuration- If it doesn't already exist, the upgrade process adds empty api keys config, for user to add their api keys later. Andrew to link
ExitMint upgrade processCurrently, the mint upgrade configuration script will step through the following prompts: Verifies correct upgrade version- The script checks that the server library version matches the version named in the upgrade script (e.g, redbox-1.9-SNAPSHOT.pom).
- If there is no match, the script will display a message that the library version is incorrect and the script will exit.
- The script will also prompt to upgrade the version recorded by the server - ensure this is also matched.
Technical DetailsIt is not necessary to understand the high-level technical detail by which the upgrade process runs. It is provided here merely as a quick technical reference for those who wish to modify the upgrade according to their institutional requirements. - In running the upgrade, in a similar manner to tf_restore.sh. That is, the tf_upgrade.sh does not execute any upgrade logic directly, but rather looks for (on the java classpath) and executes the fascinator java class, UpgradeClient.class. To find this class, the script must be executed within the redbox installation server folder in order to find the correct class within server/lib.
- The UpgradeClient class then binds itself (for use of any utility methods) to a groovy script, upgrade.groovy. It is this groovy script that contains the explicit upgrade instructions and can be found under home/upgrade/upgrade.groovy
- As a groovy script, upgrade.groovy does not require explicit compilation - it can be modified, and the tf_upgrade.sh script executed immediately from the server folder, in order to process the changes
- (for those new to working with groovy, check the redbox installation version number of the groovy-all java archive and find the correct groovy version documentation here).
Troubleshooting |