Installation/Appliance/Migration
| Migration to current appliances
|
 | This document refer to the appliance based on Ubuntu 20.04.
The migration guide for the old version 18.04 published in 2019 can be found here. |
Contents
|
Introduction
| | Always test the migration in testing servers, before doing the real migration. |
A good idea is, if possible, to keep the old system around for a time. This way if something goes very wrong during or shortly after this migration it is possible to revert to the initial system.
Migrate to appliance 20.04
Currently, it is supported to migrate to the Appliance 20.04 from:
- Openbravo Appliance 18.04
It is NOT possible to directly migrate from the following very old options:
- Openbravo Appliance 14.04
- Openbravo Appliance 12.04
- Old appliance based on rPath
- Ubuntu package: Openbravo installed with the Openbravo package for Ubuntu (sudo apt-get install openbravo-3)
Before the migration, it is highly recommended to have a running instance in a consistent state. This means that no local changes should be present in the database and that the application should compile without any issues.
This is recommended as it allows for clear and easy separation of any potential issue during the migration.
Check compatibility of Openbravo version
Openbravo recommends to use the latest Confirmed Stable (CS) release if possible.
Recommended version
To migrate to the new appliance 20.04 it is recommended to have at least the following Openbravo version (or higher):
- 20Q1
This version has been fully tested in our CI system against the Appliance 20.04 stack.
Minimum version (extra testing needed)
- 19Q3
The older version 19Q3 already includes the last code changes known to be required.
If you cannot upgrade to 20Q1 or higher 19Q3 should work however you should plan to do more extensive testing in that case.
Additional fix for some versions
Additionally versions between 20Q4 and 22Q4 (both included) should apply this fix as well: Issue 51718
Without it running install.source will fail with the error ERROR: DROP DATABASE cannot be executed within a pipeline
Read usage differences section for changes 18.04 to 20.04
Please read the entire Usage difference in Appliance 20.04 compared to 18.04 section.
It contain several important differences to be aware of.
attachment folder must exist
One side-effect of the new security configuration on restricting writing files is that tomcat cannot create the attachment folder itself if it should be missing.
The folder pointed to by the attach.path entry must be created before starting tomcat.
This folder is NOT just used by the attachment system but also for some other temporary files.
Check compatibility of modules used in your Installation
As the new Appliance 20.04 updates some stack components it maybe required to update modules to be compatible with it.
Any modules not created by you
In this case please ask the module owner to verify/test if the module is compatible.
Note: Any standard modules from Openbravo itself have been updated and should work with the new Appliance. Should you notice any problem please raise a support ticket/issue with Openbravo.
Modules created by you as a developer
This section is for developers to give some help on how to check compatibility for the new stack.
The main stack change comparing the older Appliance 18.04 with the new Appliance 20.04 is PostgreSQL 10 -> 12
Apart from module compiling and functionality testing the following gives some extra information on specific things to test:
The PostgreSQL project maintains a list of changes and known incompatibilities for each major release. Most of the time those are transparent to most modules. However to check in more detail please check:
Preparation checklist for migration
- Prepare new server, configure the timezone, install updates, reboot
- Check the tomcat and postgres config and migrate to the new server
- /etc/profile.d/tomcat.sh # check if you have changed the xmx of tomcat, etc
- /etc/postgresql/10/main/conf.d/91-local-custom.conf # Any custom changes done therein
- Note: Ensure that the change is still needed, since maybe the new default value is equal or greater than old one.
- Check that you don't have any other databases different that the Openbravo standard one, the backup will ignore it and you need to copy manually in case that you still need it.
- Copy the needed keys of the /home/openbravo/.ssh/authorized_keys.
- Move the backups config
- /etc/openbravo-backup.conf
- crontab -l # as openbravo user will show the backups schedule
- Do a migration test to ensure that everything continues working in the new system
- When you do the final migration, remember that the first step is stop the production tomcat.
From Openbravo appliance 18.04
Attachments, check that you have the backups in the usual path, if not you need to manually copy to new instance, for appliance: /opt/OpenbravoERP/attachments
Appliance 20.04 has PostgreSQL 12 and in appliance 18.04 is PostgreSQL 10, the migration process will update the database, usually there are no problems in this migration but if you have custom developments, remember to check that they continue working.
Backup for migration from appliance 18.04:
- Create a backup in the appliance.
If the new server is configured with public key, then you can follow this process.
Connect to the new server using a private key that is also valid for the old server:
ssh -A openbravo@<ip_new_server>
The '-A' option kind of exports the private key so allows to connect from the new serer to the old one using it. Care should be taken when using the '-A' option as to only use it when connecting to trusted servers.
Then copy the backup from there to the new server:
sudo mkdir -p /backups/manual # create folder to store manual backups sudo chown -R openbravo:openbravo /backups # fix owner of backups folder recursively scp openbravo@<ip_old_server>:/backups/manual/backup-xxx.tar /backups/manual/ # copy the backup from the old machine into the manual backups dir of the new instance. # Note: Change backup-xxx.tar with the name of the backup just created.
Restore
Then you can connect by ssh to the new server and the backup will be in /backups/manual/ folder.
| | On restoring a backup created with PostgreSQL10 / Appliance 18.04 a single error message "ERROR: schema "public" already exists" will be shown on restore.
This specific error is harmless but not easily avoidable. It can be safely ignored. |
From this point you can follow the normal restore process.
Things to do after the migration
After the migration, a good practice is take a look regularly to the system to check that everything continues fine:
- Check all the logs for errors.
- Check that the backups are done in the configured schedule.