Ensure the PRA of a ServiceNav Box

Purpose of this documentation

We have identified 2 scenarios in which a ServiceNav Box (SNB or supervisory box) can be replaced:

• A ServiceNav Box becomes unstable and exhibits unpredictable behavior. It can be migrated to a new : Migration of a ServiceNav Box
• A ServiceNav Box becomes completely unusable. After rebooting, it is no longer possible to connect to it either via the network or via a local console.

This documentation will deal with this second case and will present the 2 solutions available to customers to set up a Disaster Recovery Plan.
The following actions can be performed entirely by customers without the intervention of ServiceNav support.

Backup of local configuration files

If all the configuration of the boxes is stored at the central platform, some configuration files are only present locally on the box. It is therefore very important to keep a copy on an external storage in case the access to the box storage is not possible anymore.

Here are the files in question:

• The file iptablesThis is the SNB firewall rule set. To be saved if custom rules have been set up. -> /etc/init.d/iptables.sh
• The file freetds containing the configuration for monitoring MSSQL databases. -> /etc/freetds.conf
• The file tnsnames containing the configuration for Oracle database monitoring. -> /usr/lib/oracle/12.2/client64/network/admin/tnsnames.ora OR/usr/lib/oracle/11.2/client64/network/admin/tnsnames.ora

It will be mandatory to place them in the correct location on the new SNB.

Complete replacement of a ServiceNav Box

If no backup of the box is available, it is possible to replace the SerivceNav Box HS by a new one.

Actions to be taken :

1. Provision a new ServiceNav Box from the image on our FTP site. It must have exactly the same characteristics that the SNB HS: CPU, RAM, disk space.
   Note: to gain in reactivity, it is advisable to carry out this provisioning in advance.
2. Turn off the defective box completely and start the new one.
3. Connect to the machine, become root and launch the box initialization script.
   
4. Follow this documentation to answer the different steps: Installation of an SNBPart 3 "Configuring the ServiceNav Box".
   For the "Network settings" part: put the same LAN IP and the same Hostname that the box is out of order.
   For the "Configuration upload" part: generate a token and an ID for the SNB in question.
   -> At the interface level, the SNB is not deleted/re-created. The new SNB will have the same name, ID and VPN IP address as the defective one.
   Linking with the platform and configuring emails.
5. Copy all local configuration files to the new SNB.
6. Push back the configuration on the new SNB. It will take the same supervision configuration as on the faulty SNB.

This new SNB takes the place of the SNB HS and recovers all its configuration.

Supervision is back in operation.

Rollback from a ServiceNav Box backup

When the ServiceNav Boxes are in the form of a virtual machine, it is very important to make regular backups (via the hypervisor directly or via a backup solution). It will then be very quick to restore a backup.

Actions to be taken :

1. Turn off the defective box completely.
2. Deploy the last available backup of the box on the hypervisor.
3. Start the new box from the backup.
4. Verify that the VPN tunnel is mounted properly -> ifconfig tun0
   If the interface is present, the tunnel is operational:
   
5. If one of the files listed in the chapter "Backup of local configuration files" has been modified since the last backup of the box, it must be copied to the new box from the backup.
6. In order to update this new box from the backup with the new configuration: connect to the ServiceNav web interface and push the configuration to the box.

Supervision is back in operation.