Proposed Directory Structure.

The above can be achieved by ensuring that new and old installations are held in separate directories. Consider the following typical Linux installation 

/usr/local/VyoptaCollector
├── .cache
├── .drivers
├── .jre
├── .libs
├── License.txt
├── .logs
├── .patches
├── .resources
├── .shadow
├── vyoptacollector.sh
└── vyoptacollector.xml

Here the collector is installed under /usr/local/VyoptaCollector, with all of the files present under the same directory.

What is proposed is that the installation directory structure should have an extra level that corresponds to the version being installed:-

/usr/local/VyoptaCollector
├── 4.7
│   ├── .cache
│   ├── .drivers
│   ├── .jre
│   ├── .libs
│   ├── License.txt
│   ├── .logs
│   ├── .patches
│   ├── .resources
│   ├── .shadow
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml

Installing to the new structure

If the structure above is already present on your system, then performing the upgrade in the safest way can be achieved by the following steps 

• Create a new directory (in this case 4.8) under the existing tree

mkdir 4.8

• Copy the vyoptacollector.xml file into the 4.8 directory

cp 4.7/vyoptacollector.xml 4.8

• Place the new installer into the 4.8 directory and ensure the installer is executable (from the 4.8 folder)

chmod +x vyoptacollector.sh

Your directory tree will now resemble

/usr/local/VyoptaCollector
├── 4.7
│   ├── .cache
│   ├── .drivers
│   ├── .jre
│   ├── .libs
│   ├── License.txt
│   ├── .logs
│   ├── .patches
│   ├── .resources
│   ├── .shadow
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml
├── 4.8
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml

You are now ready to perform the upgrade:

• Stop the Vyopta CPM Data Collector service

sudo systemctl stop VyoptaCPMDataCollectorService

• Go back to the old installation directories (4.7 in the above) and run the following

vyoptacollector.sh -uninstall

• Now head to the new installation directories (4.8 in the above) and run the following

vyoptacollector.sh -install

The roll-back is a matter of performing the same steps with the installation and uninstallation reversed. 

If the structure is not already present on your system, then please proceed as follows

Create a 4.7 directory under your current installation. Into this directory place the vyoptacollector.xml and the new collector executable. 

Create a directory for your old version (assuming 4.7 in this example)

/usr/local/VyoptaCollector
├── .cache
├── .drivers
├── .jre
├── .libs
├── License.txt
├── .logs
├── .patches
├── .resources
├── .shadow
├── vyoptacollector.exe
└── vyoptacollector.xml
├── 4.7
├── 4.8
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml

• Stop the Vyopta CPM Data Collector service

sudo systemctl stop VyoptaCPMDataCollectorService

• At an administrative command prompt in the old installation directories (/usr/local/VyoptaCollector in the above example) run the command

vyoptacollector.sh -uninstall

• At an administrative command prompt in the new installation directories (4.8 in the above) run the command

vyoptacollector.sh -install

• Move all remaining files and directories (except the new folder (4.8) into the old (4.7) folder

The rollback procedure will be to uninstall from the new folder and install from the old with the service stopped. 

Cleaning up

Once the upgrade has taken place the folders highlighted in the the old (4.7) file tree can safely  be removed without hindering rollback.

/usr/local/VyoptaCollector
├── 4.7
│   ├── .cache
│   ├── .drivers
│   ├── .jre
│   ├── .libs
│   ├── License.txt
│   ├── .logs
│   ├── .patches
│   ├── .resources
│   ├── .shadow
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml
├── 4.8
│   ├── .cache
│   ├── .drivers
│   ├── .jre
│   ├── .libs
│   ├── License.txt
│   ├── .logs
│   ├── .resources
│   ├── .shadow
│   ├── vyoptacollector.exe
│   └── vyoptacollector.xml

When it is certain that the previous version is no longer required, the entire tree for the release may be deleted, leaving only the new version. 

Notes for Linux Users:

Throughout the directory trees will be depicted as a Windows tree - the same structure, however, will be assumed for a Linux installation, and commands to perform the equivalent Linux actions will be given following the Windows instructions.

Concerning the Linux Firewall

If a Linux installation should fail because there is no firewall control executable (such as firewall-cmd) found, take the following actions:

Using an editor of your choice, create a file called firewall-cmd in /usr/local/bin. The content of this file is 

#!/bin/bash
exit 0

And ensure that it is executable: chmod +x /usr/local/bin/firewall-cmd