• No results found

Side-by-side Migration Guide for Snare Server v7

N/A
N/A
Protected

Academic year: 2021

Share "Side-by-side Migration Guide for Snare Server v7"

Copied!
8
0
0

Loading.... (view fulltext now)

Full text

(1)

Page 1 of 8 © Intersect Alliance International Pty Ltd. All rights reserved worldwide.

Intersect Alliance Pty Ltd shall not be liable for errors contained herein or for direct, or indirect damages in connection with the use of this material. No part of this work may be reproduced or transmitted in any form or by any means except as expressly permitted by Intersect Alliance International Pty Ltd. This does not include those documents and software developed under the terms of the open source General Public Licence, which covers the Snare agents and some other software.

The Intersect Alliance logo and Snare logo are registered trademarks of Intersect Alliance International Pty Ltd. Other trademarks and trade names are marks' and names of their owners as may or may not be indicated. All trademarks are the property of their respective owners and are used here in an editorial context without intent of infringement. Specifications and content are subject to change without notice.

(2)

Table of Contents

1. Migration Overview . . . 3

2. Migration Requirements . . . 4

3. Performing the Migration . . . 5

(3)

© Intersect Alliance International Pty Ltd Page 3 of 8

1. Migration Overview

This guide outlines the steps required to perform a side-by-side migration from an existing Snare Server v6 to a newly installed Snare Server v7 on the same network. It will copy across all event archive data, as well as the application configuration and user data. It can be used to copy event archive data from multiple source servers to a single destination server, although only the application configuration and user data from the last destination server will be kept. This process will remove all existing application configuration and user data from the destination server, so it is highly recommend that it is completed by a fresh install so nothing is lost.

This process is the preferred method of migrating from a Snare Server v6 to v7, and should be attempted in preference to the over-the-top upgrade process if possible.

Other resources that may be useful to read include: Snare Server Installation Guide

Snare Server Upgrade Guide Snare Server User Guide Snare Server Release Notes

IMPORTANT

This document does not cover over-the-top upgrades of an existing Snare Server v6 to v7 on the same server. Please see the Snare Server Upgrade Guide for details of this process.

Any customisations made to the operating system or application code will not be migrated as part of this process. This includes adding and changing components such as FTokens, collection modules, and custom objectives. These will need to be manually migrated over to the destination machine.

These instructions relate to migrating from v6 to v7, and do not support migrating from an older version, such as v4 or v5. To migrate an older Snare Server, migrate it to v6 first, and then to v7.

Looking for something simpler?

(4)

2. Migration Requirements

2.1. What you need

The Source Snare Server v6 must be updated to the latest available version. The Destination Snare Server v7 must be updated to the latest available version. Both the Source and Destination servers will need to be full licensed.

2.2. Hardware Requirements

The Source and Destination servers need to be on the same network and must be able to communicate with each other via port 8730. This port is used for an rsync server (running on the Destination server) that copies the data from the Source to the Destination. If the two servers cannot communicate directly, then the migration is not possible.

2.3. Software Updates

In order to take advantage of the server migration process both the Source Snare Server v6 and the Destination Snare Server v7 will need to be running the latest released versions to ensure the required tools are available. The minimum required versions for each are:

v6: Snare Server v6.4.0 v7: Snare Server v7.0.0

Note: These updates and the ISO image can be downloaded from your Snare Secure Area (if applicable). Please speak to your Snare Support Representative if you are unsure how to access this page.

2.4. Snare Server License

(5)

© Intersect Alliance International Pty Ltd Page 5 of 8

3. Performing the Migration

3.1. Summary

The Side-by-side Migration process involves running steps on both the Source and the Destination server, within a specific time period, and you should prepare the migration environment completely before starting the process. The migration steps are performed by logging into each server as the snare user via SSH. After a successful login each server will present the Snare Server Administration Menu, from which the migration is launched. Before starting the migration, it you should SSH into both servers in two different terminal windows to make sure everything is working as it should be and you can access both at the same time.

Once you have a stable SSH connection to each server, you can begin the migration process.

3.2. Migration Steps

3.2.1. Start the process on each server

Select the Migrate menu option on the Source server, and the Receive menu option on the Destination server.

3.2.2. Enable Receive Files on the Destination

On the Destination server, read through the dialog regarding the Receive Files step, and then select Yes when you are ready to continue to the next step.

You will be asked to provide the sudo password for the snare user to authenticate the request before the process will begin.

In the screenshots in this section, the screen on the left in blue is the Source (v6), and the screen on the in purple is Destination (v7).

(6)

3.2.3. Provide the Destination address or hostname

Now that the Destination server is waiting for the Source to send files at it, the next step is to tell the Source server where to send the files. Provide the IP Address or Hostname of the Destination server to the Source server and select Ok.

Note: This needs to be done within 60 seconds of the Destination server starting to wait, or the Destination server listener will timeout and stop waiting.

3.2.4. Waiting for the transfer to complete

(7)

© Intersect Alliance International Pty Ltd Page 7 of 8

3.2.5. Finalising the Migration

Once it has finished the Source server will let you know the results of the transfer. Only once it has completed at the Source should the Ok button be pressed on the Destination server.

The Destination server will run various upgrade scripts to make the required changes to the migrated data, and will finish back on the Administrative Menu.

3.2.6. Finished

Once the Destination process goes back to the Administration Menu, the migration has been completed. You should now be able to login to the user interface using the user credentials from the Source server. All Objectives and user data will have been migrated across, as well as the Event Archive data.

(8)

4. Migration Notes

4.1. Network Compatibility

The migration process involves starting an rsync server on the Destination server listening on port 8730 that the Source server connects to, to transfer the required files across. As part of this process the port is opened in the UFW firewall on the Destination server for the duration of the migration process.

The recommended network layout is for the Source and Destination servers to be connected to the same network with no firewalls or proxies between them. This allows the communications between the two servers to work without any problems. If it is not possible for the servers to exist on the same network and a firewall or proxy must be used, then problems may be experienced during the migration process. At a minimum the Source server needs to be able to directly connect to the Destination server on port 8730.

For help troubleshooting complex network configurations and issues with the migration process, please contact your Snare Support Representative.

4.2. Manual Event Archive Importer

4.2.1. Summary

In addition to the Migration process, there is also a helper script on the Snare Server which allows you to import Snare Event Archive data from a Source server to a Destination server. This script uses SSH from the

only

Destination server to login to the Source server and rsync the files across. It then wipes out the metadata to force a full regeneration with the new data. Since it uses rsync to copy the data, it can be run multiple times with the same Source with no negative impacts and minimal time spend on repeated imports. It can also be run against multiple Source servers to import data into a single Destination.

It does not copy any of the objective configuration or user data from the Source server. If this information is required, then the Migration process outlined in this document should be followed instead of this script.

The only requirement for this script is that the Destination server needs to be able to SSH into the Source server. Once this is working, the script can be run. Authentication can be done either via SSH Keys, or via a password which will be prompted for as part of the process.

4.2.2. How to run the script

SSH into the Destination server, and exit the Administration Menu. Run this command to launch the script:

sudo /data/Snare/Supporting/System/ImportSnareArchives.php

Follow the prompts provided, and the script will update you with its progress. You can interrupt the script at any point using the key combination CTRL-C (hold control, and hit the C button). The script will resume from where it terminated, the next time it is executed.

References

Related documents

Leveraging Biomarkers in Early Clinical Drug Development for Metabolic Disease Therapies.. Mallé Jurima-Romet, PhD August

This phase aims to identifiy cloud services to recommend to user. We exploit user’s and service’s Clusters, matrix of useand the cloud labels structure produced in the

High- deductible CDHP enrollees reported the lowest increase in three of the five motivation items (thinking about cost, awareness of cost, and awareness of quality differences

This suggests that as firms use more internal funds relative to external equity, their costs of equity capital will fall and the rate the market uses to discount unexpected earnings

List some of the resources you think Silk Flora will need to acquire to fulfil its business plan.. Find the business plan developed by

It provided us with datasets on all admissions of maternity patients who had contact with the Tayside Substance Misuse Service, some details of their illicit substance use and

The objective of this study was to analyse the changes in species composition, stand structure, and above- ground biomass of the woody plants of an undisturbed forest of the

The fact that now dependants cannot work unless they secure their own work permit under the same conditions as any other applicant acts as a means to discourage family