Page tree
Skip to end of metadata
Go to start of metadata

This Guide is for copying an entire installation of Agiloft from one server to another.

This guide is written specifically for transferring a server from AWS to vX, but the process for vX to vX etc would be similar.


These steps should be taken ahead of time, hopefully the day before the planned move.

  1. Update Agiloft on the source server to the latest version

  2. Instruct Client to ensure that no uploads will occur during the maintenance window, specifically automated scheduled SFTP uploads

  3. Create destination server at vX using AWS KB

    1. Install Agiloft automatically, but once fully installed, stop Agiloft

    2. Destination server should have slave configured too

    3. Remove lost+found directories in /backups/ , /opt/data/ and /opt/server/

    4. Regenerate licenses for Agiloft instance using the IP and hostnames of the newly created server, these should be installed on the source server now to reduce time taken for the move process later.

  4. Review Support KB records for any special notes on the source server.

    1. In the server record, customers on server tab, you can see relevant information by selecting view in servers for migration

  5. In Agiloft admin console under Communications -> SMTP Check SMTP server is set to

  6. Run find / -type d | grep "\s" on source server to identify any directories with whitespace that might cause rsync to have issues. You might need to rename these to not have whitespace, if you do, make a complete list of what the original name was and what you renamed it.


These steps can be done leading up to the move as they do not affect the current instance of Agiloft on the source server at AWS.

  1. On both destination and source server, add ‘s key to the root users on each

    1. Edit /etc/ssh/sshd_config on both servers to allow root to login using keys

      1. Copy any special rules from the source server’s sshd config such as rules for SFTP users

    2. Comment out entire requiretty line on the source server if it exists in /etc/sudoers using visudo

    3. Test that root@jump can login to root on both servers and accept both server’s fingerprints

      1. To stop constant prompts for key passphrase use:

        1. ssh-agent bash

        2. ssh-add

  2. Copy any additional users and groups to the destination server, specifically SFTP users, also copy their entry in /etc/shadow to maintain their password

  3. Send broadcast on source server warning of downtime.

    1. echo "The server will be going down for scheduled maintenance in 15 minutes, it will be available no later than 8:00am PST Monday, August 13th, 2018" > /opt/server/Agiloft/tmp/message2broadcast

  4. Set source server to planned downtime, this does not stop Agiloft; it stops monitoring notifications on the server


The script itself will stop Agiloft on the source server, these steps should take place once the deadline you sent in the broadcast above has been reached.

  1. Run the script on jump as root:
    python2.7 ./ -f <Source server FQDN> <Destination server FQDN>

    1. Should be run from within the /root/keys directory to keep other directories being spammed with the keys the script generates.

  2. If licenses keys generated in Pre-preparation stage 4 were not already installed on the source server, go to the Agiloft admin console of the destination server and install them.

  3. If any directories were renamed for whitespace reasons, restore the original names now.

  4. Update firewall, see document “Firewall Quick Guide” for specific steps

    1. Add target server to https_servers

    2. Make sure slave server is in mysql_slaves

  5. Copy any custom crontab entries from source to destination server

    1. /var/spool/cron/root

  6. Change DNS entries to point to new server in AWS KB

  7. Update support KB records to link customers to target server

  8. Update AWS KB admin console passwords of target server to match source server

    1. With the transfer complete, the admin password is now that of the source server.

  9. Restart the server to check that it comes up without issues.

    1. Screenshot the login page for the server to show it is working at it’s direct server URL, upload to #vxvplans channel on slack

  10. Once you have confirmed that the target server is now working correctly, update it’s record in the AWS KB from created to active

  11. Remove ‘s key from destination server

    1. Remove the key files created by the script on jump

  12. Add server to nagios and grafana

    1. You will need to add a subnet address

      1. Add Address=172.20.1.X/24 to /etc/systemd/network/

      2. Run systemctl restart systemd-networkd

  • No labels