Managing Mobility Unified Reporting System Installation

This chapter describes how to install, upgrade, and uninstall the MUR application.

This chapter describes the following topics:

IMPORTANT:

The procedures for installation, upgrade, and uninstallation of MUR and RDP remain the same.

IMPORTANT:

Please note that the terminologies “starbi”, “inPilot” and “mur” used throughout this guide mean the same.

Installing MUR

This section provides instructions on how to install the MUR application.

IMPORTANT:

Make sure that your system meets the minimum requirements as indicated in the MUR System Requirements section in the MUR Overview chapter of this guide.

The following MUR components are installed by MUR installer.
  • For Solaris platform
    • Apache v2.2.11 with mod_python v3.3.1
    • Python v2.6.4
    • Postgres v 8.2.0
    • Django v1.0.2
    • JRE v1.6.0_12
    • Quartz Scheduler v1.6.4
  • For RHEL platform
    • Apache v2.2.11 with mod_python v3.3.1
    • Python v2.6.1
    • Postgres v 8.3.4
    • Django v1.0.2
    • JRE v1.5.0_11
    • Quartz Scheduler v1.6.4

IMPORTANT:

In RHEL-based deployment of MUR, L-ESS is NOT required as the ECS module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from the chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

IMPORTANT:

It is recommended that you first install the master MUR before proceeding with the RDP installation.

Prior to installing MUR, MUR Administrator user and Group need to be created and activated. MUR Administrator user is the user who will own the MUR installation. Execute the following steps as root user for creating and activating MUR user and group:
  1. Create MUR group using the following command:
    groupadd  -g <groupID> <groupname>
    For example: groupadd -g 500 murgroup
  2. Create MUR user using the following command:
    useradd -u <userID> -c "MUR-administrator"
-g <groupname> -m <username>
    For example: useradd -u 100014 -c "MUR-administrator" -g murgroup -m muradmin
  3. Activate the MUR user using a password:
    passwd <username>
    For example: passwd muradmin
    During installation, provide this user as the Administrator user input.

IMPORTANT:

For High-Availability mode, the user and group creation must be done on both the nodes in the cluster (Active and Passive). Ensure that you provide the same userID, groupID and password on both the nodes. Also, note that High-Availability mode installation is only supported on RHEL platform.

Setting the Database Environment Strings

Prior to installing the MUR components onto the server hardware, there are numerous system environment configuration settings that should be configured. While PostgreSQL will be installed during the installation procedure, these settings must be configured manually.

DANGER:

Failure to configure these settings may cause data loss and will minimally cause errors in the operation.

Settings for Solaris

Add the following values to system file in the /etc/system directory if they are not present and restart the system before continuing with the installation of MUR components.

set msgsys:msginfo_msgmnb=65536 

set msgsys:msginfo_msgtql=1024

set shmsys:shminfo_shmmax=10737418240

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmmni=256

set shmsys:shminfo_shmseg=256

set semsys:seminfo_semmap=256

set semsys:seminfo_semmni=512

set semsys:seminfo_semmns=512

set semsys:seminfo_semmsl=270

Settings for RHEL

Add the following values to system file in the /etc/sysctl.conf if they are not present and restart the system before continuing with the installation of MUR components. 

kernel.shmmax=10737418240

kernel.shmall=4294967296

Pre-installation Checks

Ensure the following checks are made before installing the MUR application.

IMPORTANT:

Please note that L-ESS is required ONLY for a Solaris-based deployment of MUR. In the case of RHEL-based deployment of MUR, the ECS module is configured to push the xDRs directly from the chassis to the MUR reporting server via SFTP.

  1. The recommended filesystem for installation is ZFS. If Solaris-based installation is performed on any other filesystem, a warning message appears indicating the recommended filesystem.

    IMPORTANT:

    Please note that the ZFS related recommendations mentioned throughout this guide are specific to SOLARIS ONLY and NOT for RHEL.

  2. MUR must be installed as a root user on the system. Installation with other user privileges is not recommended.
  3. Make sure no other Apache web server is running on the port being used for installation (default port is 8080). If it is, stop it before proceeding with the installation or provide a different port for Apache server. Check if an application is running on a given port by entering the following command: 
    netstat -an | grep <port number>
  4. Make sure no other Postgres server is running on the port being used for installation (default port is 5432). If it is, stop it before proceeding with the installation or provide a different port for Postgres server. Check if an application is running on a given port by entering the following command: 
    netstat -an | grep <port number>
  5. Make sure no other application/process is running on the port being used for pgBouncer (default 'Postgres port + 1'). If it is, stop it before proceeding with the installation or provide a different port for Postgres server so that the installer finds two consecutive ports free (one for Postgres and the other one for pgBouncer). Check if an application is running on a given port by entering the following command: 
    netstat -an | grep <port number>
  6. Make sure no other server is running on the port being used for installation for XML-RPC (default port is 9999). If it is, stop it before proceeding with the installation or provide a different port for XML-RPC server. Check if an application is running on a given port by entering the following command: 
    netstat -an | grep <port number>
  7. MUR installation will ask for the Administrator login and Administrator Primary Group. Administrator login is the OS level administrator of MUR who will own the MUR installation. Administrator Primary Group is the user group of MUR to allow the interaction with external entities like L-ESS.
  8. If the Administrator login provided during MUR installation/upgrade already exists, ensure that it is not an already logged in user.
  9. L-ESS must be stopped before starting MUR installation / upgrade.
  10. If the L-ESS is installed as a root user, the ownership of L-ESS installation should be changed from root to non-root user. This new user must be added to MUR Group. For example, if L-ESS is initially running as root and new user created is essadmin, then perform the following sequence of operations.
    1. Stop L-ESS.
    2. Add the user essadmin to MUR group by entering the following command as root user - usermod -G <MUR Group> essadmin
    3. Verify whether the user is added correctly to MUR group using the command groups essadmin
    4. Change the ownership of L-ESS installation to this new user using the following command - chown -R essadmin <LESS installation directory>
    5. Login as essadmin with the command su essadmin
    6. Start L-ESS again.
  11. If the L-ESS is installed as a non-root user say essadmin, this user should be added to MUR Group.
    1. Stop L-ESS
    2. Add the user essadmin to MUR group by running the following command as root- usermod -G <MUR Group> essadmin
    3. Log off and relogin again as essadmin for the group addition to come into effect.
    4. Start the L-ESS application to continue pulling the EDR files from chassis and forwarding it to MUR.
  12. Perform the following steps only if the user wants to push EDR/UDR files from gateway to MUR server using SFTP mechanism. Otherwise, skip this step.
    1. Change to the /etc/ssh directory.
    2. Open sshd_config file from the directory using vi editor (or any other editor) and observe the default values for the following variables: PasswordAuthentication PAMAuthenticationViaKBDInt (Applicable ONLY for SOLARIS) UsePAM (Applicable ONLY for RHEL)
    3. Change the default values for the following variables as indicated here. PasswordAuthentication = yes PAMAuthenticationViaKBDInt = no (Applicable ONLY for SOLARIS) UsePAM = no (Applicable ONLY for RHEL)
    4. After updating restart SSH daemon using the following command: In the case of SOLARIS: 
      svcadm restart ssh

      IMPORTANT:

      Please note that the above command can be executed only in Solaris 10 environment.

      In the case of RHEL: 
      service sshd restart
  13. The recommended user/group settings for MUR are:
    • NIS-USER<->NIS-GROUP
    • NON-NIS-USER<->NON-NIS-GROUP
    The NIS users should always be associated with NIS Groups. The non NIS users should be associated with Non NIS groups. Also, it is recommended to have separate non NIS users for MUR installation.
  14. For High Availability (HA) mode, please follow the steps described in the section Configuring External Storage Disk on UCS for HA deployment in the Mobility Unified Reporting System Clustering Support for High Availability chapter of this guide to initialize the external storage and create the Disk Groups, Volumes and Mounts required for installing MUR application. MUR application installation can be run from any of the cluster nodes.

MUR Installation

The MUR installation files are distributed as a single compressed file.

IMPORTANT:

In the MUR Software Releases prior to 11.0.100 build, this installation file is distributed with a .tar.gz extension. In the MUR Software Release 11.0.100 and later, this file is distributed in zip format.

IMPORTANT:

The MUR application currently supports UCS Linux platform and Solaris-Sparc/Solaris-x86 platform. The installable tar file names help in identifying the platform. For example, mur.x.x.xx_rhel_x86.zip indicates that this file is for RHEL platform. Similarly, mur.x.x.xx_solaris_sparc.zip indicates that this file is for Solaris-Sparc platform.

For information on downloading the appropriate MUR package for your requirements, contact your Cisco account representative.

The MUR application and its components can be installed using one of the following two methods.

IMPORTANT:

Please note that the terminologies “starbi”, “inPilot” and “mur” used throughout this guide mean the same.

Installing MUR Using GUI/Console based Installer

IMPORTANT:

To perform the installation procedure explained in this section, you must be logged into the server as a root user.

IMPORTANT:

Fresh installation for backup recovery purpose should be installed on the same path where last backup is stored and also should have the same IP address and port configuration if the MUR is deployed in distributed mode. Make sure that the existing older installation is either removed or moved to a different directory because the metadata recovered from previously installed MUR will have all references as per older installation e.g. archive path, SFTP details, etc.

IMPORTANT:

In the MUR Software Releases prior to 11.0.100 build, this installation file is distributed with a .tar.gz extension. In the MUR Software Release 11.0.100 and later, this file is distributed in zip format.

Follow the instructions below to install MUR using the GUI/Console based installation wizard.

  1. Change to the directory in which the file is stored.
  2. Unzip the file by entering the following command: 
    unzip mur.x.x.xx_os_arch.zip
    x.x.xx is the version of the MUR installation file. os indicates the Operating System on which the MUR application is running. It can be either RHEL or Solaris. arch indicates the architecture either Sparc or x86.

    IMPORTANT:

    To unzip the .gz package file, use tar -xvf <file_name> command.

    Decompressing the installation file results in the following files:
    • inst: A GUI/Console based installer to install the MUR application.
    • setup.bin: The executable used by inst to install MUR application.
  3. Execute the script by entering the following command: 
    ./inst [MODE]
    where [MODE] is optional. Two installation modes are supported namely:
    • gui
    • console
    The command ‘inst/uninst -help' provides usage of the scripts. This script installs the Apache, Postgres and Scheduling servers functionality. The display must be set for running in GUI mode, else the installation will run in Console mode. The MUR Installer dialog appears displaying the MUR version getting installed.
  4. Click Next to proceed.
  5. Respond to the on-screen prompts with the help of inputs given in the following table and configure various parameters as required.
    Parameter Description Default Value
    PostgreSQL System Settings
    .
    This dialog asks the user to check the variable values in system file. If one or more entries are missing, click Cancel to update the system file and restart the system to re-run installer.
    For more information, refer to the Setting the Database Environment Strings section.
    N/A
    MUR Clustering Support
    Veritas Cluster Failover
    If Veritas clustering environment is found, user will be asked whether to install MUR application with clustering support (High Availability mode) or not.
    Yes
    Floating IP
    The Floating IP to be used in Veritas clustering environment.
    N/A
    MUR Installation Directory
    Enter Installation Path
    Enter the base directory path where MUR is to be installed.
    Click Browse to change the installation path.

    IMPORTANT:

    For HA mode installation, the path must be on shared disk.
    <current_directory>
    A Component Type screen appears showing the components for installation. This screen allows you to select either Master MUR or RDP for installation.

    IMPORTANT:

    Make sure that you first install the master MUR and then proceed with the RDP installation.
    MUR Administrator and Group Configuration
    Administrator Login
    Enter an administrator name for the Operating System (OS) level administrator of MUR.

    IMPORTANT:

    Please note that you should not login as a root user.

    IMPORTANT:

    The Administrator user created should be manually activated with a password once the MUR installation is complete. This can be done by entering the following command as root user: passwd <adminusername> Upon executing this command, the user will be asked to enter a suitable administrator password.
    muradmin
    Administrator User ID
    Type the Administrator User ID for the MUR Administrator login.

    IMPORTANT:

    This input will be asked only if the Administrator login name provided does not exist.
    100014
    Administrator Primary Group
    Type the Primary Group name for the Administrator.

    IMPORTANT:

    If the Administrator login name provided already exists, the Primary Group of this login will be considered as the MUR User Group. Otherwise, the user will be asked to enter the Primary Group information.
    murgroup
    PostgreSQL Server Configuration
    Postgres Login
    This is a read-only parameter. The Postgres login name will be the same as the Administrator login name provided earlier.
    muradmin
    Postgres password
    Enter the password for the Postgres database administration.
    N/A
    Postgres Port
    Enter the port number on which PostgreSQL communication will be running.

    IMPORTANT:

    Ensure that no other application/process is running on configured port as well as on next consecutive port (as this port will be used for pgBouncer).

    5432
    Enter data directory path
    Enter the data directory path of postgres being used.
    Click Browse to change the installation path.

    IMPORTANT:

    For HA mode installation, the path must be on shared disk.
    <MUR_install_dir>/starbi/postgres/data
    MUR Port Configuration
    Apache Protocol Type
    Select the Apache protocol type from the available options:
    • HTTP
    • HTTPS
    • Both HTTP and HTTPS
    If both HTTP and HTTPS are required, select the check boxes Apache HTTP Support and Apache HTTPS Support.
    For RDP to MASTER synchronization to take place over RPC, either HTTP or HTTPS will be used. This depends on the user’s selection in this screen.
    HTTP
    Apache HTTP Port Number
    Type the port number over which Apache web server communication will occur with MUR.
    Apache HTTP port should be greater than 1025 and lesser than 65535.

    IMPORTANT:

    This parameter will be enabled only when HTTP option or Both HTTP and HTTPS option is selected.

    IMPORTANT:

    Ensure that no other Apache web server is running on the port being used for installation. If the port is being used, abort the installation.

    For RHEL:
    For RHEL, Apache port provided should be > 1024. RHEL does not allow port 80 to be used by non-root users. However, Apache Web server requests made on port 80 can be redirected to a port >1024 defined by the operator, with the following two commands. For example, to redirect requests made on port 80 to port 8080:
    iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port 8080
    iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port 8080
    For Solaris:
    For using the Apache port < 1024, run the following command as root user once the installation is complete, and restart the Apache server.
    usermod -K defaultpriv=basic,net_privaddr <MUR admin user>
    For example:
    usermod -K defaultpriv=basic,net_privaddr muradmin

    IMPORTANT:

    This poses a major security concern as it will allow muradmin to use all standard ports < 1024.

    8080
    Apache HTTPS Port Number
    Type the port number over which Apache web server communication will occur with MUR.
    Apache HTTPS port should be greater than 1025 and lesser than 65535.

    IMPORTANT:

    This parameter will be enabled only when HTTPS option or Both HTTP and HTTPS option is selected.
    8443
    SSL Certificate Type
    Select the SSL certificate type from the available options:
    • Cisco
    • Custom
    If you select Custom as the option, click Browse to select the path where the SSL certificate file is present. The SSL certificate will be copied to <MUR_install_dir>/starbi directory.
    The installer will allow only .crt file for certificate selection.

    IMPORTANT:

    This parameter will be enabled only when HTTPS option or Both HTTP and HTTPS option is selected.
    Cisco
    SSL Key
    Click Browse to select the path where the SSL key is present. The SSL key will be copied to <MUR_install_dir>/starbi directory.
    The installer will allow only .key file for key selection.

    IMPORTANT:

    This parameter will be enabled only when Custom is selected as the option for the SSL Certificate Type.
    N/A
    Available Port Range for MUR Components (200 Ports)
    Type the port number in the start port text area. Note that the end port text area is a READ-ONLY field.
    End port number will be populated automatically based on the start port number. For example, if the start port number entered is 9001 the end port number will be 9200 (startPort + 199).
    Start port range should be between 1026 and 65335 so that the end port has a range of 1226 to 65535.
    If any of the port/ports in the specified range is/are not available, then the installer throws error and prompts the user to enter a new start port number.
    9001 - 9200
    MUR Archive Directory Configuration
    Enter archive directory path
    Enter the directory path for archiving parsed files.
    Click Browse to change the installation path.

    IMPORTANT:

    For HA mode installation, the path must be on shared disk.
    <MUR_install_dir>/archive
    Pre-installation Summary screen
    The pre-installation screen displays the product name, install location, other product configurations, and disk space information before installing the product.
    Click Cancel to stop installation or Install to continue installation.
    Installing MUR
    The screen shows all the contents being loaded on the machine during installation.
    Click Cancel to stop installation.
    MUR Server Startup
    Start All Servers After Installation
    Select the option to start all servers after installation.
    Click Next to proceed.

    IMPORTANT:

    For HA mode, please ensure that you do not start the MUR processes during the MUR installation. MUR application will be started after the required resources are configured through Veritas Cluster Server (VCS). For information on configuring resources, refer to the Configuring Resources for High Availability section in the Mobility Unified Reporting System Clustering Support for High Availability chapter of this guide.
    Yes
    Install Complete
    The screen shows whether installation is successful or failed.
    Click Done to quit the installer.
    N/A


    When the MUR installation is complete, see the Cisco Mobility Unified Reporting System Online Help documentation for information on how to access and use the GUI. For HA mode, please ensure that you configure the required resources through VCS after the installation of MUR application. For information on configuring resources, refer to the Configuring Resources for High Availability section in the Mobility Unified Reporting System Clustering Support for High Availability chapter of this guide.

Confirming Successful Installation

Verify that the MUR application is running and accessible by entering the following URL in your Web browser:

http://<MUR_installation server
name or IP address>:<apache port>

– or –

https://<MUR_installation
server name or IP address>:<apache port>

For information on logon details, refer to the Launching the MUR GUI section in the Mobility Unified Reporting System Administration and Management chapter of this guide.

For information on using the MUR GUI, see the Cisco Mobility Unified Reporting System Online Help documentation.

For HA mode installation, verify that the MUR application is running and accessible by entering the following URL in your Web browser:

http://<MUR floatingIP
address>:<apache port>

– or –

https://<MUR floatingIP
address>:<apache port>

Upgrading MUR

This section provides instructions on how to upgrade the installed MUR application.

CAUTION:

Please contact your Cisco account representative to ensure compatibility prior to upgrading.

IMPORTANT:

In RHEL-based deployments, L-ESS is NOT required as the Enhanced Charging Services (ECS) module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from the chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

The upgrade procedure ensures that the database content is retained in the new installation. It also ensures that if there are any pending files to be processed in the old installation, then those file are also made available in the new installation.

IMPORTANT:

If MUR is being upgraded from a version in which backup and purging features are not available, to a version in which backup and purging features are supported, then it is recommended that you enable backup feature and take one complete successful snapshot of backup before enabling purging feature. If the backup feature is disabled then enabling purging will cause removal of data without waiting for it to be backed up. If the backup is being taken for the first time after upgrade, then it may take considerable time for first backup.

IMPORTANT:

Upgrade from existing non HA installations to HA installation is not supported.

IMPORTANT:

If the previous installation is MUR then the installation script will cause upgrading the software to MUR and if the previously installed component is RDP then the script will cause upgrading to RDP.

IMPORTANT:

Before performing the upgrade process, ensure that the browser cache is cleared.

IMPORTANT:

To perform the upgrade procedure explained in this section, you must be logged into the server as a root user.

When upgrading to MUR software version 12.2, file parsing configurations are NOT synced automatically at all RDPs. As a result, EDR file parsing does not happen at RDPs.

To overcome this, perform the following steps in the MUR GUI:
  1. After the upgrade, manually attach appropriate RDPs to all relevant gateways.
    1. Create appropriate RDP regions through the System menu.
    2. Attach all RDPs to their respective regions through Edit RDP page viewed by clicking RDP from Admin tab.
    3. Attach appropriate gateways to their corresponding RDPs and regions through Edit Gateway page viewed by clicking GATEWAYS from Admin tab.
  2. Navigate to System > File-Parsing Configs menu and then manually save the file parsing configurations for all the gateways which are attached to RDPs.
The MUR upgrade process is carried out in two steps:
  1. Online Upgrade
  2. Offline Upgrade

The online upgrade is the conventional upgrade process. It will upgrade only last 7 days of available data i.e. it will get the latest date for which data is available and upgrade the last 7 days data only from that date.

Once the online upgrade is complete, offline upgrade starts in the background and it will upgrade all the remaining data older than last 7 days.

During the offline upgrade, there is a possibility of data outage. So, the reports older than last 7 days might be inaccessible from GUI during this period. Once the offline upgrade is over, these reports will be visible again.

Please note the following key points:
  • Once MUR is upgraded and if any schemas support additional counter then you should reconfigure schema for that gateway.
  • After upgrade is over, the previous data and the schemas displayed earlier for the gateway will be shown on the GUI.
  • If you want to perform schema configuration for the gateways which were added prior to upgradation, then you should configure the schemas through the GUI by accessing Bulkstat Schema Configuration screen and disable the earlier file format used on the gateway.

The following steps describe how to upgrade the MUR application:

  1. Stop the L-ESS by running the following command from the <LESS_install_dir>/ess directory: 
    ./serv stop
  2. Stop the MUR application using the following command from the <MUR_install_dir>/starbi/bin directory: 
    ./serv stop

    IMPORTANT:

    For all MUR software versions 9.0.16 and later, use the serv stop command.

    or 
    ./shutdown.sh

    IMPORTANT:

    For all MUR software versions 9.0.15 and lower, use the shutdown command.

    Then, check the status of processes using the following command: 
    ./serv status

    IMPORTANT:

    For all MUR software versions 9.0.16 and later, use the serv status command.

    or 
    ./status.sh

    IMPORTANT:

    For all MUR software versions 9.0.15 and lower, use the status command.

    IMPORTANT:

    Make sure that none of the processes is running.

  3. Install the new release of MUR. MUR is upgradable from:
    • Earlier script installer based version to newer script installer based version
    • Earlier script installer based version to GUI/Console installer based version
    • Earlier GUI/Console installer based version to subsequent GUI/Console installer based version
    For instructions on different MUR installers, refer to the MUR Installation section. In case of the first two upgrade options mentioned above, make sure that you enter the old installation path (<install_dir>) for upgrade when prompted for the 'MUR Installation directory'. In case of the third upgrade option, it automatically detects the old installation path through registry information. The installation automatically detects earlier setup and reads required configuration for Apache, Postgres and RPC port, etc. You will be prompted with a confirmation message before proceeding with the upgrade process. After upgrade, the log files are generated at /starbi/logs/ directory.

    IMPORTANT:

    The installation script will check if the Administrator user and Primary Group information is already present in database. If it does not exist, it will ask the user to enter this information and then continue with the upgrade.

  4. After the installation is done, start all the MUR related processes using the following command from the <MUR_install_dir>/star/bin directory: 
    ./serv start
    Then, start the L-ESS using the following command from the <LESS_install_dir>/ess directory: 
    ./serv start
  5. Modify the L-ESS configuration or HDD configuration to reflect the changes in the MUR installation path.
  6. Restart the EDR file generation or HDD file push as needed.

    IMPORTANT:

    The RDP should be upgraded manually. If the version of the RDP is not compatible with the MUR, then MUR may ignore the data sent by RDP. Thus, RDP should always be upgraded if it is not in sync with the MUR. For change in mode from RDP to MUR or vice-versa, re-installation is required.

Upgrade from Standalone Deployment to Scalable Model

This section provides instructions on how to upgrade from the standalone deployment of MUR application to scalable model.

IMPORTANT:

Whenever an MUR is upgraded from an older version to 12.2, the logical regions for the MUR gets void and the user will not be able to see any gateways under the DPI/Bulkstats/CF/KPI tab. In this scenario, the user should add that gateway under NOC.

It is expected that the user must first upgrade the MUR application to a hierarchical model before deploying MUR in scalable model.

  1. Consider the current standalone node as a master. Then, upgrade the software to latest MUR version.
  2. Install two or more RDPs in scalable mode, as mentioned in the Scalability Setup for New Deployments of MUR section.
  3. Retain the existing gateway as it is (attached to Master) if you are interested in viewing existing gateway reports. Else, remove the gateway through the Gateway Configuration screen on the GUI.
  4. Configure the same gateway (with different name and IP address) through master for one of the RDPs and mark as pseudo to another RDP. Rest of the configuration remains the same as mentioned in the Scalability Setup for New Deployments of MUR section.
  5. Reconfigure the gateway to push data to one of the RDPs. In the earlier configuration, the gateway pushed the files to the standalone server (now it is master MUR).

Example

If user is interested in viewing data for the earlier configured gateway, the gateway should remain in the configuration. After upgrading to scalable model, the following procedure should be performed:
  • Invoke MUR GUI. On the home page, even if there were gateways configured earlier, the following message will be displayed “no gateways added”.
  • Click GATEWAY from Admin menu, and then edit each of the gateways to have the region as NOC.

All the reports will now be available to users.

Upgrade From Hierarchical Deployment to Scalable Model

This section provides instructions on how to upgrade from the hierarchical deployment of MUR application to scalable model.

IMPORTANT:

Whenever an MUR is upgraded from an older version to 12.2, the logical regions for the MUR gets void and the user will not be able to see any gateways under the DPI/Bulkstats/CF/KPI tab. In this scenario, the user should add that gateway under NOC.

It is assumed that there is at least one RDP attached to the master. Follow the steps as described here.

  1. Stop the MUR on both master and RDP-1.
  2. Upgrade MUR on both of them independently to the latest version.
  3. Create appropriate regions if required. Then, update RDP-1 and gateway configuration appropriately from master MUR.
  4. Setup a new node as RDP-2 and configure it in cluster mode, attached to a shared storage. While configuring new node [RDP-2] make sure that you specify the id of the node-1 (older RDP) during cluster installation so that cluster will get installed on node-1 also. Make sure that node-1 and node-2 are physically interconnected to have cluster functionality. Also, make sure the share disk is created and mounted as described in the Basic Scalability Model section.
  5. Install the latest MUR on RDP-2. Make sure that the parameters for user id, and user name are the same as that of MUR on RDP-1.
  6. Reconfigure the gateway to push traffic through this new node RDP-2 on the shared disk.
  7. Add this gateway as pseudo gateway on RDP-2 through master. This would be a pseudo to the gateway on RDP-1. Initially, configure the gateway to pick up all the files without setting any filters. Files will keep on getting processed on this RDP-2.
  8. On the old RDP-1, check if all the files have been parsed. If yes, check if there are any files pending in the <starbi home>/server/ sql_export_data directory. When there are no files, and you have waited for 20 minutes after the files have been parsed, take a backup of all the metadata so that RDP can be restored later, and stop this RDP.
  9. Now uninstall the MUR on this server (RDP-1). Bring the node RDP-1 in cluster, and re-install RDP on it with the same parameters with which it was installed (installation path, user id, postgres id, postgres port, postgres password, apache port, RPC port, etc.).
  10. Perform RDP recovery procedure and then reconfigure the gateway from master on the RDPs to take the files from appropriate path with required filters.
  11. If there are more than one RDP, repeat the above procedure for other RDPs. Then, edit the earlier gateway configuration to pick up only odd (or as desired) numbered files on RDP-2.
  12. Add another gateway, but as a pseudo to earlier one, on RDP-2. Configure it to pick up only even numbered files (or as desired) so that the gateway traffic is evenly distributed across the RDPs.
  13. Repeat the above procedure for other RDPs.

    IMPORTANT:

    The same RDP can be restored if they are reinstalled with the same parameters.

Uninstalling MUR

This section provides instructions on how to uninstall the MUR application.

IMPORTANT:

It is recommended that you manually perform a backup of all critical and historical data files before proceeding with this procedure. Failure to do this causes removal of all the directories, files and database. However, in the case of scalability setup, the shared directory will remain intact and can be removed manually using the command rm -rf <gateway-directory-path> only when all the RDPs configured for a gateway are uninstalled.

The MUR application and its components can be uninstalled using one of the following two methods:

IMPORTANT:

The Administrator user and Primary Group configured during installation / upgrade will not be deleted during uninstallation. These have to be deleted manually by entering the following commands as root user: userdel <ADMINUSER> and groupdel <ADMINGROUP>

Note:

Before deleting the Group, ensure that NO other users are attached to the same group by entering the following command: logins -g <ADMINGROUP>

Uninstallation Using GUI/Console-based Uninstaller

This method must be used if installation has been done using GUI/Console based installer (using inst).

IMPORTANT:

To perform the uninstallation procedure explained in this section, you must be logged into the server as a root user.

  1. Change to the <MUR_install_dir>/starbi directory and enter the following command: 
    ./uninst [MODE]
    where [MODE] is optional. Two modes are supported namely:
    • gui
    • console
    The display must be set for running in GUI mode, else the uninstallation will run in Console mode. The MUR Uninstaller dialog appears.
  2. Click Uninstall to proceed. This uninstall script stops all the servers if it is running and all the data is wiped off.

    IMPORTANT:

    The uninstall script does not cleanup the archive directory. You must take a backup of archive directory and manually delete the user <muradmin> and group <murgroup> using the commands <userdel muradmin> and <groupdel murgroup>.