Skip to content
This repository has been archived by the owner on Jul 25, 2018. It is now read-only.

Deploy Migrating to a new Server

Jump to bottom
Michael edited this page Apr 28, 2016 · 10 revisions

The following scenario:

There is an existing machine with sw360 installed. However, the machine requires a new installation from scratch. The contents of the server A should be moved to a new server B. This article will explain what to do.

Getting Data from Server A

There are several section to preserve as special data and configuration.

User Setup

The users can be exported from the current instance using the CSV download from the users pages in the sw360 admin menue. The reason why an export of the users is required is the password: If a user has changed the password, the changed password is unknown and cannot be set to a default value again (would be confusing to the user).

With the CSV export the password that users have set for themselves is exported as hash value. Thus the passwords of the users are preserved for the import to a new server.

Configuration files

The main services that require special configuration file handling are:

  • sw360-portlets: There is the sw360properties and some configuration files. usually, sw360.properties is the most likely changed file (for setting the clearing organizations for example), but it depends what you have set in the files.
  • fossology service: there is the configuration where the fossology server is in the file fossology.properties and the keys for logging in (public / private key).
  • moderation service: There is configuration for the e-mail sending for example, most likely in sw360.properties. Check for yourself if you have changed the other files.

There are configuration files in all services, please check if you have more files to preserve for migration. Usually these are set at deployment of the vagrant in an uniform manner, so no special handling would be required in normally.

As a step you could copy these to some preserving location.

Database: The real data: components, projects, etc.

Th real data should be migrated too. Originally, this part should ave been covered by the CSV Import / Export in the Admin menu of the sw360 (not the liferay admin menue). However, in version 1.2 and 1.3 of sw360, the changes to the data model were considerable intensive that adjustments of the CSV import export have been suspended. In other words, not everything in your database gets exported properly and therefore the subsequent import would be incomplete.

Luckily, the coucdbdb files can be copied, so far without hazzle. In order to copy the couchdb files, consider the following steps:

  1. Stop the sw360 application (shutdown tomcat).
  2. Shutdown couchdb
  3. Change to root.
  4. Copy the following couchdb files out of the machine from /var/lib/couchdb:
sw360attachments.couch
sw360db.couch
sw360fossologykeys.couch

The file sw360users is already by the CSV export (see above). 5. Restart the machine if you prefer.

Setting data on Server B

For the new server, the service should be shut down for moving the files in: the tomcat and the couchdb in this order actually.

Then, copy the files to the same location where they were copied from.

Copying the couchdb files back

  • make sure couchdb is not running.
  • Copy the database files into the /var/lib/couchdb.
  • Adjust the rights and the ownership and the group on the couchdb files (the same as the other *.couch files).
  • start couch db.
Clone this wiki locally