CMS Upgrade on VM

LFR and CMS Upgrade

The procedures in this section refresh the LFR and install the required CMS version. To refresh only the required files, follow the steps in Incremental LFR Refresh

1. Execute the below commands to add the required environmental variables:

   sudo bash
   vi /etc/environment

   1. Add the below environmental variables:

      COMPOSE_HTTP_TIMEOUT=400 DOCKER_CLIENT_TIMEOUT=400

2. Execute the below commands to stop and clean previous CMS instance:

   sudo su
   cd /var/cms/docker-compose-files 
   ./stop.sh 
   ./stop.sh -h #to view the help menu
   ./cleanup.sh 
   ./cleanup.sh -h #to view the help menu
   service docker restart

3. For upgrade from existing version, execute the below commands to remove that version
    

   Version 2.5 or Above Version 2.4 or Below

   
   

   Upgrade from Version 2.5 or Above:

   rm -rf /var/kafkavolume
   rm -rf /var/zookeepervolume
   cd /var/cms
   rm *

   
   

   Upgrade from Version 2.4 or Below:

   rm -rf /var/lib/kafkavolume
   rm -rf /var/lib/zookeepervolume
   cd /var/cms
   rm *

   
   
4. Download the tar file vsp-cms-lfr.tar.gz from the Artifactory directory: 
   1. Version 2.8 and Above: vsp > releases > public <Major_Release> > <Minor_Release> > <Patch_Version> > tar_package > cms_lfr  
      Example: vsp > releases > public > 2 > 2.8 > 2.8.0 > tar_package > cms_lfr  
   2. Version 2.7: vsp > releases > public > <Release_Number> > tar_package > cms_lfr 
      Example: vsp > releases > public > 2.7.0 > tar_package > cms_lfr  
5. Execute the below commands to complete the CMS Upgradation:

   tar -xvzf vsp-cms-lfr.tar.gz
   ./vsp_cms_installer.sh
   echo 1 > /proc/sys/vm/drop_caches
   service docker restart 
   ./setup.sh -h  #To view more information about the script usage
   ./setup.sh <CMS_HOST_IP_Adress>

6. The required parameter for the script is:

   Parameter	Description
   HOST_IP	IP Address of the VM where CMS package is installed

   The optional parameters are provided below

   Parameter	Description
   SSL_VERIFY	Provide 0 to disable SSL hostname verification between CMS and Probe. This is useful when a customized domain name is desired for CMS (Default Domain Name: int.cms.virsec.com). Ensure that the option is disabled for ECS Fargate. Provide 1 to enable SSL hostname verification. The option is enabled by default
   -f	Defines the CMS Deployment type. Allowed Values: small: Only the core CMS services are installed. Recommended for POVs only large: The core and optional CMS services are installed. If not specified, the default option is large In the configuration small, the below optional services are not installed: jreports-service – Reports are scheduled and generated in this service licenseserver – This service is the on-prem license server organization-service – Provides communication with the VSP MSSP instance report-service - Provides CMS Reporting functionality ticket-zendesk-service - Provides the ability to configure the ticketing service Zendesk virsec-api-snap-service – Provides the capability to access CMS information through SNAP API vsp-log-manager-service – Responsible for the logging functionality
   -k	Ensure that CMS is not running during usage. Allowed Kafka options: 0: For Unsecure Kafka connection. The option is available only for Version 2.7. By default, the value is set to 0 if not specified 1: For One-way SSL where the Client verifies the Server 2: For Two-way SSL where both the Client and Server verify each other. Version 2.8 and Above: By default, the value is set to 2 if not specified NOTE: If there is a Custom DNS for Kafka listener, then use the option 1 for Kafka. Do not use the option 2 Restart the probe after CMS and/or probe upgrade or when the Kafka mode is modified
   -P	Provide this parameter to select the optional services that need to be started in case of CMS Deployment Type - large. If this option is not provided, all the optional services are started by default. When prompted, provide y/n for optional services [Ticketing Service (Zendesk), Centralized Logging System, MSSP, VSP APIs, Reporting Feature, On-premise License Server]
   -x	Custom advertised listener for Kafka

   NOTE

   If a proxy server with SSL (for internet access) OR LDAP server with SSL (for user management) is configured, ensure that the root certificate information is added to the property file, as described in the Deploy Custom SSL Certificate section of the Maintenance article

   
   

7. In cases where RAM settings for small and large CMS deployment types need modifications, execute the below command before CMS deployment and modify the value as required:
   

   sudo bash
   cd /var/cms/form-factors
   vi ff-ram-size.csv

   NOTE

   The file ff-ram-size.csv contains VSP-recommended RAM values for the available CMS deployment types. Any change in these values may affect CMS functioning

   
   

8. Verification: Execute the below command to verify whether the LFR is up and running

   docker ps | grep lfr

   After a couple of minutes, access the URL: to view the refreshed LFR 
   1. Version 2.8 and Above: https://<VM_IP_Address>:8443
   2. Version 2.7: http://<VM_IP_Address>  

Incremental LFR Refresh

1. Execute the command below to refresh only the required LFR files

   sudo bash
   cd /var/cms 
   ./update_lfr.sh -h  #To view more information about the script usage

2. Example: ./update_lfr.sh -O "rpm" -V "7,8" -S "host"
   When prompted, provide the Artifactory username and password.
   The parameters for the script are:

   Parameter	Description
   -C	Update all the CMS files. Once the script execution is complete, ensure that the script setup.sh is also executed Example: ./update_lfr.sh -C -r releases/public/2.8.0
   -O	Specify the required Operating System (comma separated without spaces)
   -S	Provide the required SKU. Allowed values are web, host, mem. By default, files related to all SKUs are downloaded
   -V	Provide the version numbers for the specified Operating System (comma separated without spaces)
   -r	VSP Release Version. Example: 2.8.0

3. Once the script is executed, LFR has the latest downloaded files
   1. A new directory backup is created in the root directory vsp with a backup of the replaced files
   2. The file changelog.txt under the directory vsp has the log of the refreshed files