Migrating data from versions prior to 3.9
This document describes the process of manually migrating data from version prior to 3.9 to the latest version of CloudShark.
Please contact email@example.com before beginning the migration for assistance and to ensure your new CloudShark system has a valid license.
The general procedure is to stop CloudShark on the existing system, and then save the database contents and user data to a new location. This data can then be copied and imported onto the new CloudShark system.
In the commands below, the /backups directory is used to store the data. After the data has been exported the directory can be copied to a new CloudShark system. This could instead be a remote NFS service or another storage mechanism.
A note about older versions
CloudShark prior to 2.6 tracked a hash for each capture file using MD5. The latest version requires the SHA-1 hash and CloudShark will not open any files imported without it. In some migrations from earlier than CloudShark 3.0 the SHA-1 was not transferred to every capture. If you may be in this situation, you will need to run the following commands to generate this before exporting the database:
sudo -u cloudshark bin/run CloudShark::Utils.update_missing_sha1
On the existing CloudShark system, the following commands will gather and export the data to migrate to the new CloudShark system.
In step 2 the ‘cloudshark.activities table has been excluded from the database export. This table can be quite big, especially on long-running systems Excluding this table will result in an empty activity log available to an admin user. If you need to keep that data, please leave that part of the command out.
systemctl stop cloudshark
mysqldump -uroot -pqacafe123 --ignore-table=cloudshark.activities cloudshark > /backups/cloudshark.sql
mysqldump -uroot -pqacafe123 mysql > /backups/mysql.sql
cd /var/www/cloudshark/shared/uploads/ && tar -czpf /backups/cloudshark_data.tar.gz
cd /var/www/cloudshark/shared/ && tar -czpf /backups/cloudshark_private.tar.gz private/
cp /var/www/cloudshark/shared/config/cloudshark.conf /backups/
systemctl start cloudshark
If you have added a custom TLS certificate and private key to the existing CloudShark system you would like to use on the new CloudShark system they can be copied to the following locations:
The default configuration on the new CloudShark system will use the TLS certificate and private key in these locations.
If you have connected CloudShark to an external database or other shared services, or have modified the default nginx configuration, please also review this section for some required steps to replicate those changes on your new system.
If you have modified the default ‘services.conf’ file on the existing CloudShark system to point to an external service such as the database, this file will have to be copied to the new ‘services.conf’ location manually.
On the existing CloudShark system this file is located at:
On the new CloudShark system edit the following file to configure CloudShark to use the same external services:
Any custom configuration changes made to nginx on the existing CloudShark system
in the following files should be rewritten into a single
/usr/cloudshark/etc/nginx.conf file on the new CloudShark system manually:
Once the data from the existing CloudShark system has been copied to the new CloudShark system, the cloudshark-full service must be stopped to ensure that the data is imported correctly. The following commands will stop cloudshark, import the data, and start cloudshark again:
systemctl stop cloudshark-full
tar -pxzf /backups/cloudshark_data.tar.gz -C /usr/cloudshark/data/
tar -pxzf /backups/cloudshark_private.tar.gz -C /usr/cloudshark/data/
cp /backups/cloudshark.conf /usr/cloudshark/etc/
mysql -uroot mysql < /backups/mysql.sql
mysql -uroot cloudshark < /backups/cloudshark.sql
./cloudshark-installer-<VERSION>.<DIST>.run --keep --noexec
systemctl start cloudshark-full