Difference between revisions of "Regify provider appliance update guide"
Jump to navigation
Jump to search
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Simple update == | == Simple update == | ||
| − | '''We | + | '''We recommend to make a backup or snapshot as a fall-back option. See next major topic below!''' |
In order to update your regify provider appliance, please follow these steps: | In order to update your regify provider appliance, please follow these steps: | ||
# Login to your regify provider appliance using SSH (PuTTY is the recommended tool). | # Login to your regify provider appliance using SSH (PuTTY is the recommended tool). | ||
| + | ## If you login as ''root'', you need to type "providerConfig" to open the appliance menu. | ||
| + | ## If you login as ''regify'', the appliance menu opens up automatically. | ||
# Select the "Check for updates" option. | # Select the "Check for updates" option. | ||
| − | # Verify the updates found. Select OK to do the update. | + | # Verify the updates found. Select OK or YES to do the update. |
# Select the "Check for updates" option and repeat as long as no more updates are found. | # Select the "Check for updates" option and repeat as long as no more updates are found. | ||
| Line 13: | Line 15: | ||
* The provider will be unreachable for a few minutes during update. | * The provider will be unreachable for a few minutes during update. | ||
* After updating, always login to your provider administration (https://yourUrl/ADMINISTRATION/) and check if there is something to do. | * After updating, always login to your provider administration (https://yourUrl/ADMINISTRATION/) and check if there is something to do. | ||
| − | * It is possible that the error log gets some entries during update. In most cases you can ignore them.<br>If you are unsure about them, please send them to support | + | * It is possible that the error log gets some entries during update. In most cases you can ignore them.<br>If you are unsure about them, please send them to support (at) regify.com and ask for verification. |
== Update with fall-back option == | == Update with fall-back option == | ||
| Line 28: | Line 30: | ||
# Note the notes for "Simple update" in first chapter here. | # Note the notes for "Simple update" in first chapter here. | ||
| − | === How to revert to a previously done VM snapshot === | + | === How to safely revert to a previously done VM snapshot === |
# Enter provider administration (https://yourUrl/ADMINISTRATION/) | # Enter provider administration (https://yourUrl/ADMINISTRATION/) | ||
| − | # Delete all users that have been created | + | # Delete all users that have been created since the last snapshot and respect the following: |
#* If there are unknown users since the update, please note their name and e-mail address! | #* If there are unknown users since the update, please note their name and e-mail address! | ||
#* This allows you to contact them and let them re-register after going back. | #* This allows you to contact them and let them re-register after going back. | ||
#* Please note that transaction history during this period is not able to get restored. | #* Please note that transaction history during this period is not able to get restored. | ||
# Revert your VM to your previous snapshot. | # Revert your VM to your previous snapshot. | ||
| + | # Re-create the users you previously noted. You may invite them or ask them to re-register. | ||
# Contact support@regify.com and tell about your experience. | # Contact support@regify.com and tell about your experience. | ||
| − | == Important notes about | + | == Important notes about restoring VM snapshots and backups == |
| − | In order to understand the complexity of roll-backs, you need to consider the following: | + | In order to understand the complexity of VM roll-backs, you need to consider the following: |
* If someone registers at your regify provider, his email address is registered in the regify clearing service (anonymized as fingerprint). | * If someone registers at your regify provider, his email address is registered in the regify clearing service (anonymized as fingerprint). | ||
* During registration, every regify provider first checks the clearing if the e-mail address is not already registered at any regify provider. If it is, the registration is denied! | * During registration, every regify provider first checks the clearing if the e-mail address is not already registered at any regify provider. If it is, the registration is denied! | ||
| − | * Thus, if you register a new user at a regify provider and reset the database later (eg revert to VM snapshot), the e-mail address is still registered in the clearing. As it is no longer in your provider database you can not even delete this registration. The user is blocked to register forever. | + | * Thus, if you register a new user at a regify provider and reset the database later (eg revert to VM snapshot or a VM backup), the e-mail address is still registered in the clearing. As it is no longer in your provider database you can not even delete this registration. The user is blocked to register forever. |
* If you register transactions, they are registered in the clearing and in the users regify provider. If you revert the provider database later (eg revert to VM snapshot), the transaction entries in your provider are missing. The transactions still can get opened (clearing delivers the key) but your provider is no longer able to assign the notifications to an existing entry in his database. Therefore, the sender will not get a receipt notification at all. The transaction is no longer listed in users history. The provider might trigger an error in his logs because of an unknown transaction ID. | * If you register transactions, they are registered in the clearing and in the users regify provider. If you revert the provider database later (eg revert to VM snapshot), the transaction entries in your provider are missing. The transactions still can get opened (clearing delivers the key) but your provider is no longer able to assign the notifications to an existing entry in his database. Therefore, the sender will not get a receipt notification at all. The transaction is no longer listed in users history. The provider might trigger an error in his logs because of an unknown transaction ID. | ||
Latest revision as of 08:29, 7 December 2020
Contents
Simple update
We recommend to make a backup or snapshot as a fall-back option. See next major topic below!
In order to update your regify provider appliance, please follow these steps:
- Login to your regify provider appliance using SSH (PuTTY is the recommended tool).
- If you login as root, you need to type "providerConfig" to open the appliance menu.
- If you login as regify, the appliance menu opens up automatically.
- Select the "Check for updates" option.
- Verify the updates found. Select OK or YES to do the update.
- Select the "Check for updates" option and repeat as long as no more updates are found.
Notes
- The provider will be unreachable for a few minutes during update.
- After updating, always login to your provider administration (https://yourUrl/ADMINISTRATION/) and check if there is something to do.
- It is possible that the error log gets some entries during update. In most cases you can ignore them.
If you are unsure about them, please send them to support (at) regify.com and ask for verification.
Update with fall-back option
If you do not trust in our update mechanisms, you should follow this scenario:
- Make a snapshot of your VM of the provider appliance.
- Login to your regify provider appliance using SSH (PuTTY is the recommended tool).
- Select the "Check for updates" option.
- Verify the updates found. Select OK to do the update.
- Select the "Check for updates" option and repeat as long as no more updates are found.
- Make your tests!
- If everything is ok, please delete the VM snapshot!
- If you find the need to revert, please follow the steps below.
- Note the notes for "Simple update" in first chapter here.
How to safely revert to a previously done VM snapshot
- Enter provider administration (https://yourUrl/ADMINISTRATION/)
- Delete all users that have been created since the last snapshot and respect the following:
- If there are unknown users since the update, please note their name and e-mail address!
- This allows you to contact them and let them re-register after going back.
- Please note that transaction history during this period is not able to get restored.
- Revert your VM to your previous snapshot.
- Re-create the users you previously noted. You may invite them or ask them to re-register.
- Contact support@regify.com and tell about your experience.
Important notes about restoring VM snapshots and backups
In order to understand the complexity of VM roll-backs, you need to consider the following:
- If someone registers at your regify provider, his email address is registered in the regify clearing service (anonymized as fingerprint).
- During registration, every regify provider first checks the clearing if the e-mail address is not already registered at any regify provider. If it is, the registration is denied!
- Thus, if you register a new user at a regify provider and reset the database later (eg revert to VM snapshot or a VM backup), the e-mail address is still registered in the clearing. As it is no longer in your provider database you can not even delete this registration. The user is blocked to register forever.
- If you register transactions, they are registered in the clearing and in the users regify provider. If you revert the provider database later (eg revert to VM snapshot), the transaction entries in your provider are missing. The transactions still can get opened (clearing delivers the key) but your provider is no longer able to assign the notifications to an existing entry in his database. Therefore, the sender will not get a receipt notification at all. The transaction is no longer listed in users history. The provider might trigger an error in his logs because of an unknown transaction ID.
