Side-by-side Migration Guide for Snare Server v7 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. Page 1 of 8
Table of Contents 1. Migration Overview.................................................. 3 2. Migration Requirements............................................... 4 3. Performing the Migration.............................................. 5 4. Migration Notes..................................................... 8 Page 2 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? If you are looking for something simpler that will copy Snare Event Archive data from a Source server to a Destination server without needing to copy configuration and user data, there is also small helper script on the Snare Server that provides this functionality. See the Manual Event Archive Importer section at the end of this guide in the Migration Notes section for more information. Intersect Alliance International Pty Ltd Page 3 of 8
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 The Destination Server will need a valid license installed and working before the migration can be completed. A new license for your v7 server can be obtained from your Snare Account Representative. It is recommended to use a time-limited hardware unlocked trial license initially to confirm the Destination Server works correctly on the hardware. Once everything is working as expected, and the data has been migrated successfully, a full license can be provided. Intersect Alliance International Pty Ltd Page 4 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. In the screenshots in this section, the screen on the left in blue is the Source (v6), and the screen on the right in purple is Destination (v7). 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. Intersect Alliance International Pty Ltd Page 5 of 8
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 The Source server will send all of the required data to the Destination server automatically. This process may take some time to complete. Intersect Alliance International Pty Ltd Page 6 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. Note: There may be a small delay in the new event data being accessible after this process as the metadata system processes the new data. Intersect Alliance International Pty Ltd Page 7 of 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 only Snare Event Archive data from a Source server to a Destination server. This script uses SSH from the 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. Once the script has completed, it will perform several tasks to integrate the newly acquired data into the destination server. This process may take several hours, depending on the volume of data received. The script will output a period/full stop (.) to your screen, for every 30 days of data that it processes. Note that the audit collection service on the destination machine will be disabled during this process, in order to preserve data integrity. Intersect Alliance International Pty Ltd Page 8 of 8