You will …
Upgrade a SeisComP system
Migrate a SeisComP3 system to a newer SeisComP version
Pre-requisites for this tutorial:
Tutorial on installation and SeisComP previously installed
Time range estimate:
SeisComP has developed over time. The versions can be distinguished:
SeisComP since version 4.0.0 uses release version numbers
SeisComP3 uses release versions, names, numbers and patch numbers:
Release version: major changes in module groups, functionality, concepts, data model. Example: SeisComp3 is SeisComP in version 3.0 in comparison to version 2.5 the GUIs were introduced.
Release name: major changes in functionality, concepts, data model. Example: with SeisComP3-Seattle the new user friendly configuration GUI scconfig was introduced.
Release number: changes in data model version and/or major changes in applications and optimizations. The numbers include the year and the day of the year of the software release. Example: Jakarta-2018.327
Patch number: optimizations of applications without changes in the data model version.
Upgrade SeisComP on multiple machines¶
Applications can only connect to a messaging system that runs with a database in an equal or lower data model version. Therefore, the SeisComP system which operates the messaging system is always updated last.
Example: A distributed system includes a processing system with the messaging system and database and a GUI work station connected to the processing system:
Upgrade the GUI work station
Upgrade the processing system, take actions to upgrade the database version.
Always stop all SeisComP modules before upgrading:
Documentation of changes¶
The important novelties, optimizations and changes that are available after upgrading are documented in the change log. It is recommend to read the change log before taking further actions. The details can be found in the file
Upgrade to a higher release number¶
Installing a new SeisComP release or version is simple. More actions are required when upgrading from SeisComP3 to SeisComP in version 4. The normal upgrade takes only a few steps:
Download the SeisComP package
Stop all SeisComP modules:
Install the new packages
Users of external, e.g. gempa modules must ensure that the gempa modules match the SeisComP release version if they depend on SeisComP libraries.
When installing a new SeisComP release, upgrading the database may be required. The database version will be tested and the required actions will be shown when executing:
or when pressing the Update Configuration button in scconfig. An upgrade from version SeisComP3 jakarta-2017.334 to SeisComP in version 4.1.0 will give, e.g.:
seiscomp update-config * starting kernel modules starting scmaster * configure kernel * configure scmaster INFO: checking DB schema version of queue: production * check database write access ... OK * database schema version is 0.10 * last migration version is 0.11 * migration to the current version is required. apply the following scripts in exactly the given order: * /home/sysop/seiscomp/share/db/migrations/mysql/0_10_to_0_11.sql error: updating configuration for scmaster failed
The shown migration scripts can be used directly with the database command for upgrading:
MySQL / MariaDB:
mysql -u sysop -p -D seiscomp -e 'source /home/sysop/seiscomp/share/db/migrations/mysql/0_10_to_0_11.sql;'
psql -U sysop -d seiscomp -h localhost -W \i'seiscomp/share/db/migrations/postgresql/0_10_to_0_11.sql'
Using the migration scripts provides a more user friendly way than copying the lines of MySQL code from the changelog. In future versions we might add the option to automatically run the migrations.
Upgrading the database make take some time. Do no interrupt the process! During this time, the SeisComP messaging system is unavailable causing a downtime of the system.
After applying the migration scripts the database should be at the correct version. Test again with:
After a successful upgrade, start all modules again and observe the status:
seiscomp start seiscomp status
Migrate from SeisComP3 to version 4¶
Files and directories¶
With SeisComP3 all the default installation typically required all modules and configurations in the directories
seiscomp3/ , typically $HOME/seiscomp3 or /opt/seiscomp3/
As of SeisComP in version 4 the directories are:
seiscomp/ , typically $HOME/seiscomp/ or /opt/seiscomp/
All configuration files must be migrated to the new structures. This includes:
Configurations and inventory in seiscomp3/:
Configurations in $HOME/.seiscomp3/
Logs in $HOME/.seiscomp3/log (optional)
All user-defined files and directories in seiscomp3/share/
All user-defined seedlink and other templates in seiscomp3/share/templates/
The waveform archive and other archives typically in seiscomp3/var/lib/
User-defined files and directories in other places.
Some configuration default and description files have changed. Spread, arclink and arclinkproxy are not part of SeisComP anymore. Therefore, do not migrate:
any default configuration, description and init files. Better enable the desired daemon modules again.
seiscomp/bin/seiscomp enable [module]
any file related to spread or the arclink and arclinkproxy servers.
Configurations containing absolute paths, e.g.
must be adjusted. Better use internal SeisComP variables
such as @DATADIR@ instead of seiscomp3/share or seiscomp/share.
The system environment variables must be updated, e.g. in
Remove or uncomment the lines
$HOME/.bashrc referring to the depreciated SeisComP3
version. Then execute
seiscomp/bin/seiscomp print env >> $HOME/.bashrc source $HOME/.bashrc
When using pipelines or alias modules, create and enable the alias module names again, e.g.
seiscomp alias create [alias] [module] seiscomp enable [alias]
Migrate the module and bindings configurations of the alias modules including all related additional files which are referred to in the configurations.
One of the main changes SeisComP3 to SeisComP in version 4.0 is the messaging system. Spread does not exist anymore and only scmaster is started initially for the messaging system. scmaster allows to operate several queues in parallel with different databases. This flexibility comes with additional parameters which require configuration. Migrate the legacy database parameters and configure the new one:
Set up the messaging queues in the configuration of scmaster in
Remove or comment the obsolete dbplugin plugin manually from
#plugins = dbplugin
Add new queue or stay with the default queues.
The default queue is production used by default by all modules connected to the messaging system. When removing this queue, another queue must exist and the queue name must be configured for all modules in the connection parameters. See below for an example.
Add the required plugins, currently only dbstore is supported. Example for a queue named production:
queues.production.plugins = dbstore
Add non-default message groups to the list of default groups in
defaultGroups, e.g. for adding the groups L1PICK and L1LOCATION set
defaultGroups = L1PICK, L1LOCATION, AMPLITUDE,PICK,LOCATION,MAGNITUDE,FOCMECH,EVENT,QC,PUBLICATION,GUI,INVENTORY,ROUTING,CONFIG,LOGGING,SERVICE_REQUEST,SERVICE_PROVIDE
or use the configuration of queues, e.g.
queues.production.groups = L1PICK, L1LOCATION, AMPLITUDE,PICK,LOCATION,MAGNITUDE,FOCMECH,EVENT,QC,PUBLICATION,GUI,INVENTORY,ROUTING,CONFIG,LOGGING,SERVICE_REQUEST,SERVICE_PROVIDE
The configured groups will be available for all other connected modules in this queue in addition to the default groups.
Add the interface name, currently only dbstore is supported. Example for a queue names production
queues.production.processors.messages = dbstore
Add the database parameters which can be used from the legacy configuration. E.g.
queues.production.processors.messages.dbstore.driver = mysql queues.production.processors.messages.dbstore.read = sysop:sysop@localhost/seiscomp3 queues.production.processors.messages.dbstore.write = sysop:sysop@localhost/seiscomp3
The name of the database can be freely chosen. The example assumes that the database named seiscomp3 exists already and that it shall be continued to be used with the new SeisComP.
Add the names of the queues to the
Configure the connection parameters of all modules connecting to the messaging system in the global configuration, e.g. in
global.cfg. As in SeisComP3 the connection server is localhost. The queue is added to the host by “/”. The default queue is production, e.g.
connection.server = localhost/production
If production shall be used, then no additional configuration is required.
After adjusting the structure, variables and configuration parameters, check if the database requires an upgrade as well.
Automatic module check¶
If applied, adjust the settings for automatic module status check, e.g. crontab entries. For crontab use:
If SeisComP is controlled by the system daemon, e.g. to start SeisComP automatically during computer startup, then the startup script must be adjusted.