Note
This documentation is for the new OMERO 5.3 version. See the latest OMERO 5.2.x version or the previous versions page to find documentation for the OMERO version you are using if you have not upgraded yet.
The OME team is committed to providing frequent, project-wide upgrades both with bug fixes and new functionality. We try to make the schedule for these releases as public as possible. You may want to take a look at the roadmap for exactly what will go into a release. We always inform our mailing lists of the development status.
See the full details of OMERO 5.3.3 features in the Announcements forum.
This guide aims to be as definitive as possible so please do not be put off by the level of detail; upgrading should be a straightforward process.
Before starting the upgrade, please ensure that you have reviewed and satisfied all the system requirements with correct versions for installation. In particular, ensure that you are running a suitable version of PostgreSQL to enable successful upgrading of the database, otherwise the upgrade script aborts with a message saying that your database server version is less than the OMERO prerequisite. If you are upgrading from a version earlier than OMERO 5.0 then first review the 5.0 upgrade notes regarding previous changes in OMERO.
You may wish to review the open file limits. Please consult the Too many open file descriptors section for further details.
The passwords and logins used here are examples. Please consult the Which user account and password do I use where? section for explanation. In particular, be sure to replace the values of db_user and omero_database with the actual database user and database name for your installation.
Since OMERO 5.3, OMERO.web can be deployed separately from OMERO.server. This is the recommended installation set-up as they perform best under different circumstances and require a different set of dependencies. Please check Deployment for the latest advice on how to deploy OMERO.web.
If you generated configuration stanzas using omero web config which enables OMERO.web via Nginx, they will include hard-coded links to your previous version of OMERO. Therefore, you should regenerate your config files when upgrading, remembering to merge in any of your own modifications if necessary. You should carry out this step even for minor version upgrades as there may be fixes which require it.
Note
Since OMERO 5.2, the OMERO.web framework no longer bundles a copy of the Django package, instead manual installation of the Django dependency is required. It is highly recommended to use Django 1.8 (LTS) which requires Python 2.7. For more information see Python on the Version requirements page.
Also note that support for Apache deployment has been dropped in 5.3.0.
While upgrading the server you should keep OMERO.web dependencies up to date to ensure that security updates are applied:
$ pip install --upgrade -r share/web/requirements-py27-all.txt
Warning
Missing this step can result in OMERO.web failing to start after upgrading.
OMERO.web plugins are very closely integrated into the webclient. For this reason, it is possible that an update of OMERO will cause issues with an older version of a plugin. It is best when updating the server to also install any available plugin updates according to their own documentation.
Since 5.3, all official OMERO.web plugins can be installed from Python Package Index. You should remove all previously installed plugins and install the latest versions using pip.
Also introduced in 5.3, the Open with configuration allows users to open data in other web applications e.g. open images in a custom viewer or open images in a new figure with OMERO.figure. After installing OMERO.figure (or any other app), run the following command to add it to the Open with options, so that the app is available from the context menu on the webclient tree:
$ bin/omero config append omero.web.open_with '["omero_figure", "new_figure",
{"supported_objects":["images"], "target": "_blank", "label": "OMERO.figure"}]'
If you have configured omero.web.open_with prior to OMERO 5.3.3 and also set the default viewer with omero.web.viewer.view, for example as described for OMERO.iviewer then you will find that Open with > Image Viewer also opens the OMERO.iviewer instead of the webgateway viewer.
To fix this, you need to update the Image Viewer option within your omero.web.open_with config.
The best way to do this without changing the ordering of the options is to get the complete current config, edit the Image Viewer option, replacing "webindex" with "webgateway" and then set this as the updated config:
$ bin/omero config get omero.web.open_with
[["Image viewer", "webindex", {"supported_objects": ["image"], "script_url": "we....
# Replace "webindex" with "webgateway" and paste everything back to set, within single quotes
$ bin/omero config set omero.web.open_with '[["Image viewer", "webgateway", {"supported_objects": ["image"], "scr....'
All cached Bio-Formats memoization files created at import time will be invalidated by the server upgrade. This means the very first loading of each image after upgrade will be slower. After re-initialization, a new memoization file will be automatically generated and OMERO will be able to load images in a performant manner again.
These files are stored under BioFormatsCache in the OMERO data directory, e.g. /OMERO/BioFormatsCache. You may see error messages in your log files when an old memoization file is found; to avoid these messages delete everything under this directory before starting the upgraded server.
If you encounter errors during an OMERO upgrade, database upgrade, etc., you should retain as much log information as possible and notify the OMERO.server team via the mailing lists available on the community page.
All OMERO products check themselves with the OmeroRegistry for update notifications on startup. If you wish to disable this functionality you should do so now as outlined on the OMERO upgrade checks page.
For all users, the basic workflow for upgrading your OMERO.server is listed below. Please refer to each section for additional details.
There is a precheck SQL script provided that performs various database checks to verify readiness for upgrade. The precheck script works even with the OMERO server running so it may be used before downtime for the actual upgrade is scheduled. Issues that the script reports will need to be resolved before the upgrade may proceed. The precheck script will not make any changes to the database: it merely performs various precautionary checks also done by the actual upgrade script.
$ cd OMERO.server
$ psql -h localhost -U db_user omero_database < sql/psql/OMERO5.3__0/OMERO5.2__0-precheck.sql
Password for user db_user:
...
...
status
---------------------------------------------------------------------
+
+
+
YOUR DATABASE IS READY FOR UPGRADE TO VERSION OMERO5.3__0 +
+
+
(1 row)
The first thing to do before any upgrade activity is to backup your database.
$ pg_dump -h localhost -U db_user -Fc -f before_upgrade.db.dump omero_database
Before copying the new binaries, stop the existing server:
$ cd OMERO.server
$ bin/omero web stop
$ bin/omero admin stop
Your OMERO configuration is stored using config.xml in the etc/grid directory under your OMERO.server directory. Assuming you have not made any file changes within your OMERO.server distribution directory, you are safe to follow the following upgrade procedure:
$ cd .. $ mv OMERO.server OMERO.server-old $ unzip OMERO.server-5.3.3-ice3x-byy.zip $ ln -s OMERO.server-5.3.3-ice3x-byy OMERO.server $ cp OMERO.server-old/etc/grid/config.xml OMERO.server/etc/grid
Note
ice3x and byy need to be replaced by the appropriate Ice version and build number of OMERO.server.
Warning
This section only concerns users upgrading from a 5.2 or earlier server. If upgrading from a server, you do not need to upgrade the database.
Versions of OMERO from 5.1.0 onwards require a Unicode-encoded database; without it, the upgrade script aborts with a message warning how the OMERO database character encoding must be UTF8. From psql:
# SELECT datname, pg_encoding_to_char(encoding) FROM pg_database;
datname | pg_encoding_to_char
------------+---------------------
template1 | UTF8
template0 | UTF8
postgres | UTF8
omero | UTF8
(4 rows)
Alternatively, simply run psql -l and check the output. If your OMERO database is not Unicode-encoded with UTF8 then it must be re-encoded.
If you have the pg_upgradecluster command available then its --locale option can effect the change in encoding. Otherwise, create a Unicode-encoded dump of your database: dump it as before but to a different dump file and with an additional -E UTF8 option. Then, create a Unicode-encoded database for OMERO and restore that dump into it with pg_restore, similarly to effecting a rollback. If required to achieve this, the -E UTF8 option is accepted by both initdb and createdb.
You must use the same username and password you have defined during OMERO.server installation overview. For a large production system you should plan for the fact that the upgrade script may take several hours to run.
$ cd OMERO.server
$ psql -h localhost -U db_user omero_database < sql/psql/OMERO5.3__0/OMERO5.2__0.sql
Password for user db_user:
...
...
status
---------------------------------------------------------------------
+
+
+
YOU HAVE SUCCESSFULLY UPGRADED YOUR DATABASE TO VERSION OMERO5.3__0 +
+
+
(1 row)
If you are upgrading from a server earlier than 5.2 then it suffices to run the earlier upgrade scripts in sequence before the one above. There is no need to download and run the server from an intermediate major release.
Note
If you perform the database upgrade using SQL shell, make sure you are connected to the database using db_user before running the script. See this forum thread for more information.
For various reasons, production databases may accumulate non-sharable annotations that are orphaned. These are structured annotations that are ‘basic’ (Boolean, Timestamp, Term), ‘numeric’ (Double, Long), or Comment, and that are not annotating an object. An illustrative example is that deleting a rating in OMERO.insight 5.2 may have left behind the corresponding Long annotation that captured the rating’s number of stars. Non-sharable annotations, like comments and ratings, cannot be viewed from OMERO.insight or OMERO.web after they have been orphaned because they are no longer associated with any model object such as an image. The deletion script does not delete annotations that have a custom/non-OME namespace (ns) set.
$ cd OMERO.server $ psql -h localhost -U db_user omero_database < sql/psql/OMERO5.3__0/delete-ns-orphans.sql
This script may be used during some maintenance window subsequent to the actual upgrade as long as it runs on a OMERO5.3__0 database. If at upgrade time you have questions about the script then you may perform further research before backing up the database again then running the script. There is no requirement to ever use it.
After you have run the upgrade script, you may want to optimize your database which can both save disk space and speed up access times.
$ psql -h localhost -U db_user omero_database -c 'VACUUM FULL VERBOSE ANALYZE;'
Regions of interest generated using OMERO.insight did not follow the OME model specification. The color of shapes is now handled according to the data model, using RGBA rather than ARGB format. A script is provided to upgrade the color settings of shapes created using OMERO.insight or a different client that saved them in the ARGB format. If you only wish to apply the changes to a subset of ROIs, edit the TRUE in the script below before running it:
$ psql -h localhost -U db_user omero_database < sql/psql/OMERO5.3__0/shape_color_argb_to_rgba.sql
If you need to roll back the changes, a reverse script reverse_shape_color_argb_to_rgba.sql is also available in the same folder. Edit the TRUE if you wish to roll back the changes to a subset of ROIs.
Since 5.3, users can annotate Wells in both OMERO.web and OMERO.insight. Previously they could only annotate Images linked to WellSamples. The official script Move_Annotations.py can be run by users to move annotations from Images to Wells but an administrator can run the script on any user’s data.
If any new official scripts have been added under lib/scripts or if you have modified any of the existing ones, then you will need to backup your modifications. Doing this, however, is not as simple as copying the directory over since the core developers will have also improved these scripts. In order to facilitate saving your work, we have turned the scripts into a Git submodule which can be found at https://github.com/ome/scripts.
For further information on managing your scripts, refer to OMERO.scripts. If you require help, please contact the OME developers.
If you changed the directory name where the 5.3.3 server code resides, make sure to update any system environment variables. Before restarting the server, make sure your PATH and PYTHONPATH system environment variables are pointing to the new locations.
Your memory settings should be copied along with etc/grid/config.xml, but you can check the current settings by running omero admin jvmcfg. See Memory configuration for more information.
FastCGI support was removed in OMERO 5.2 and OMERO.web can be deployed using WSGI (see Deployment for more details). If you have already deployed OMERO.web using WSGI you should regenerate your config files, remembering to merge in any of your own modifications if necessary. Due to the nature of OMERO.web development for the 5.2.x line, you should carry out this step even for minor version upgrades as there may be fixes which require it.
If necessary ensure you have set up a regular task to clear out any stale OMERO.web session files as described in OMERO.web maintenance.
Support for Apache and mod_wsgi deployment was deprecated in OMERO 5.2.6 and dropped in 5.3.0. It is recommended to use OMERO.web WSGI deployment.
Following a successful database upgrade, you can start the server.
$ cd OMERO.server
$ bin/omero admin start
If anything goes wrong, please send the output of omero admin diagnostics to ome-users@lists.openmicroscopy.org.uk.
Start OMERO.web with the following command:
$ bin/omero web start
If the upgraded database or the new server version do not work for you, or you otherwise need to rollback to a previous database backup, you may want to restore a database backup. To do so, create a new database,
$ createdb -h localhost -U postgres -E UTF8 -O db_user omero_from_backup
restore the previous archive into this new database,
$ pg_restore -Fc -d omero_from_backup before_upgrade.db.dump
and configure your server to use it.
$ bin/omero config set omero.db.name omero_from_backup
See also