Upgrading From Earlier Versions

ExaVault is excited to announce the version 16.10 update to the ExaVault On-Premise software.

Version 16.10 includes many critical security and performance updates. It is critical that customers using earlier versions of ExaVault (also known as SmartFile) accomplish the 16.10 update as soon as possible.

The steps for performing this upgrade are detailed below.

In contrast to previous version updates, the 16.10 upgrade process involves completely replacing the VM image, rather than updating Docker containers inside the VM image.

The new VM image contains critical security updates to the base operating system. Additionally, by completely replacing the VM image we ensure that your ExaVault environment does not contain any unauthorized modifications. We do not support any modifications that you may have made to your previous ExaVault VM. All subsequent updates will be delivered as a full VM image.

This upgrade will require downtime for your current production system. You need to power down your existing installation VM long enough to copy the data to the new VM.

Prerequisites

ExaVault requires that your VM is configured with both a primary disk (for the VM image we provide) and secondary disk (to hold your data).

If you do not have a secondary disk configured, please contact our Support Team for help adding and configuring a secondary data disk prior to the upgrade.

All of the Linux commands in this guide should be performed with root privileges, using sudo.

Preparation

Prior to the upgrade, please perform the following steps:

Make a backup first of the entire production VM including primary and secondary disks. While we've never seen anyone experience a failure following these upgrade instructions, taking a backup first provides a safeguard against the unforeseen interrupting a step that can't be recovered.

Save a copy of the network configuration locally. This will be needed to build a new netplan file. This configuration is likely found in the file /etc/network/interfaces

Confirm that the secondary data disk is mounted at /data. This is the only supported mount location for the secondary data disk. If the data disk is mounted anywhere else, you will need to perform the following additional steps to fix the mount location of the secondary data disk.

You can view where the data disk is mounted with the following command:

df -h

Migrate Data Folder Mapping (if needed)

If your secondary disk is mounted at /data, then you do not need to perform the steps in this section, and you can move on to creating your new VM.

If your secondary disk is mounted to /data/smartfile/files, you will need to move folders on your secondary disk.

This process is done on your existing ExaVault server, prior to installing the update.

Before you start this process, need to make sure that you have enough disk space free on your secondary disk. Check the size of /data/veristack and /data/smartfile/ excluding the /data/smartfile/files folder. You must verify that you have enough space before trying to move the files in the following steps.

As you run each of the commands below, observe the output and be on the lookout for errors.

Stop the docker processes that are reading and writing to the data files:

veridocker -o stop

Make a new subfolder structure to move your files into:

mkdir -p /data/smartfile/files/smartfile/files

Move the contents of the data folders:

mv /data/smartfile/files/data /data/smartfile/files/smartfile/files/
mv /data/smartfile/files/scratch /data/smartfile/files/smartfile/files/

Move the contents of the configuration files, and databases.:

mv /data/veristack /data/smartfile/files/
cd /data/smartfile 
mv $(ls -I files) /data/smartfile/files/smartfile/

At this point there should be no files in /data/ except for the smartfile directory.

Next, we will unmount the data disk:

cd / && verimount -o remove --destination /data/smartfile/files 

We will now clean up the existing path and remount the disk to the /data folder:

mv data data.old
mkdir -p /data
verimount -o remount --destination /data --source /dev/sdb1 --type xfs

At this point, you can restart the ExaVault appliance using the veridocker command:

veridocker -o start

Launching The New VM Instance

We support two environments for launching the ExaVault VM: VMWare and EC2.

EC2 Instructions

To obtain access to the AMI image, contact support with your AWS Account ID and Region.

Launch a new EC2 instance using the appropriate ExaVault 16.10 AMI for your region. We recommend using a c5n.xlarge instance type.

VMWare Instructions

Launch a new VM instance in VMware using the ExaVault 16.10 OVA file. For best results, we recommend that you deploy the image from your Content Libraries in vSphere.

Once the new VM is created, select the new Virtual Machine and choose Edit Settings.

Change the CPU and Memory settings to match the previous configuration. Normally this is 4 vCPU and 16 GB of memory.

Confirm that the VM Options settings are set correctly. The Guest OS Family must be set to Linux, and the Guest OS Version to Debian GNU/Linux 6 (64bit).

Expand the root disk for your new VM to match the size of the root disk from the previous VM.

Copy or restore your secondary disk into this new VM instance. If you are copying, first power off the source VM to prevent changes to the source data disk.

Power on the virtual machine and login as admin with the password DefaultPassChangeMe1! .

Change the hostname to match your current hostname using the command:

hostnamectl set-hostname <existing_hostname>

Use the passwd command to change the password for the admin user.

Create and apply the appropriate netplan configuration in /etc/netplan/.

Netplan example configuration

Use the example template below to create a network configuration for your environment.

network:
  version: 2
  ethernets:
    ens192:
      dhcp4: no
      addresses:
      - 192.168.0.5/24
      nameservers:
        addresses: [8.8.8.8, 4.2.2.2]
      routes:
      - to: 0.0.0.0/0
        via: 192.168.0.1
      routing-policy:
      - from: 192.168.0.1/24

After the network configuration has been set, apply the changes:

netplan apply

Configuring and Finalizing the Upgrade

Execute the following commands in a shell to configure and finalize the upgrade to 16.10:

Create the /data dir:

mkdir -p /data

Remount the existing disk:

verimount -o remount --destination /data --source /dev/sdb1 --type xfs

Start the application:

veridocker -o start

Upgrade the MariaDB database tables, first connect to the docker container running MariaDB. The default password will be: smartfile

docker exec -it filehub-mariadb-1 mysql_upgrade -u root -p

After the MariaDB table upgrade, stop the application:

veridocker -o stop

Wait for all containers to fully stop, then start the application:

veridocker -o start

Confirm that the migrations all applied successfully by tailing the container instance and confirming that there are no errors in the log:

docker logs -n 10 -f filehub_api_1

Troubleshooting After Upgrade

A small number of upgrades have resulted in CSS corruption causing the application to render awkwardly in a web browser. When this happens, there's an easy fix.

To resolve this, we will delete the assets and restart the application.

First, stop the application:

veridocker -o stop

Next, remove the asset files:

rm -rf /data/smartfile/.static/*

Then start the application again, and it will automatically recompute assets.

veridocker -o start