Moogsoft Docs

Upgrade - Migrate from RPM to Non-root

This topic describes the upgrade procedure from Moogsoft AIOps v6.4.0 or v6.5.0 (RPM-based) to Moogsoft AIOps v7.0.1 (non-root).

Fundamentally this process involves installing a fresh non-root v7.0.1 deployment of AIOps onto a new server then migrating the v6.5.0 RPM-based database and configuration across.

The following steps outline this workflow:

Before You Begin

Red Hat Enterprise Linux 6/CentOS 6 is not supported for Moogsoft AIOps v7.0.1. See Deprecation Notice: RHEL 6 . If your previous installation runs on RHEL 6, see the Upgrade - Migrate from RHEL6 to RHEL7 guide.

This guide assumes the non-root deployment is on a different host to the RPM-deployment, in order to avoid the need to completely uninstall the existing deployment before verifying the new non-root one.

Back up the Existing System

To back up the existing system:
  1. Back up $MOOGSOFT_HOME .
  2. Take a snapshot (for VMs).
  3. Back up MySQL.

Stop the Existing RPM-based Services

Run the following commands to stop the existing services:

service apache-tomcat stop
service nginx stop
service elasticsearch stop
service moogfarmd stop
service <lam_name> stop
service rabbitmq-server stop

Perform a Database Dump

Run the following commands to perform a database dump:

mysqldump --single-transaction --set-gtid-purged=OFF --routines --triggers moogdb > moogdb.sql
mysqldump --single-transaction --set-gtid-purged=OFF --routines --triggers moog_reference > moog_reference.sql
mysqldump --single-transaction --set-gtid-purged=OFF --routines --triggers historic_moogdb > historic_moogdb.sql

Stop the MySQL Service

Run the following command to stop the RPM-based MySQL service:

service mysqld stop

Install the Non-root Moogsoft AIOps v7.0.1

Choose a deployment scenario for the new non-root Moogsoft AIOps v7.0.1 :

Migrate Data from the RPM Deployment into the New Non-root Deployment

Migrate the configuration files and the database.

Migrate the Configuration Files

The following configuration files/folders should be copied from their current RPM-based location and then manually merged into the new non-root version of each file on the AIOps server. The permissions MUST be set to the same as they were on the original deployment, but the ownership should be changed to the non-root user :

  • $MOOGSOFT_HOME/config/ - You should migrate any customized files in this folder and merge them into the new ones.
  • $MOOGSOFT_HOME/bots/{lambots,moobots} - You should migrate any customized files in these folders and merge them into the new ones.
  • $MOOGSOFT_HOME/contrib/ - You should migrate any files used by LAMs or moolets in this folder.
  • /etc/init.d/apache-tomcat - If the CATALINA_OPTS string was customized in this script, you need to set the altered settings in the new $MOOGSOFT_HOME/bin/utils/process_cntl script on the line starting with export CATALINA_OPTS=... .
  • /etc/init.d/{restlamd,socketlamd,traplamd,...} - For non-root, LAMs are no longer started using service scripts. If multiple LAMs are being used (same type or different), you can start them using process_cntl . For this to work, you need to change the config file names. For example:

    $MOOGSOFT_HOME/bin/utils/process_cntl socket_lam start --service_instance=KINGSTON
  • /etc/nginx/conf.d/moog-ssl.conf - If this file or any other Nginx file has been customized, you must merge it with the new one under $MOOGSOFT_HOME/cots/nginx/config/conf.d/ . You must copy across any certificate files used in the original RPM-based deployment and you must update their paths in the new moog-ssl.conf file.
  • /var/lib/moogsoft/moog-data/ - You must copy across this entire directory contents to the new server into $MOOGSOFT_HOME/moog-data/ . You must set the permissions to the same as they were on the original deployment, but you must change the ownership to the non-root user.
  • $MOOGSOFT_HOME/ui/integrations - You must copy this entire directory contents to the new server into $MOOGSOFT_HOME/ui/integrations . You must set the permissions to the same as they were on the original deployment, but you must change the ownership to the non-root user. An example of a way to copy across old integrations UI files from one folder to the non-root one, which assumes the RPM-based $MOOGSOFT_HOME/ui/integrations folder has been copied to /tmp/integrations/ , is shown below:

    for file in $(diff -qr $MOOGSOFT_HOME/dist/7.0.1/ui/integrations/ \
    ${ROOT_INTEGRATIONS_FOLDER} | egrep -vi 'only in.*7.0.1|differ' \
    | awk '{print $NF}'); do cp -rp "${ROOT_INTEGRATIONS_FOLDER}/$file" \
    $MOOGSOFT_HOME/dist/7.0.1/ui/integrations/; done
  • /etc/my.cnf - You must make any customizations specific to the RPM-based MySQL configuration file to the new non-root MySQL configuration file: ~/.my.cnf .

Migrate the Database

Copy the three database dump files from the original server onto the non-root server. Then import the database dumps into the new database. Replace the database names below as appropriate if they are not the default names.

mysql -u root moogdb < moogdb.sql
mysql -u root moog_reference < moog_reference.sql
mysql -u root historic_moogdb < historic_moogdb.sql

Upgrade the Moogsoft AIOps Schema

To upgrade the Moogsoft AIOps database, you need to provide the moog_db_auto_upgrader utility with the credentials of a database user with super privileges. For single-host installs where MySQL was installed as part of the Moogsoft AIOps deployment, you can use the default 'root' user.

  1. Run the following command after substituting the <MySQL-SuperUsername> argument:

    bash $MOOGSOFT_HOME/bin/utils/moog_db_auto_upgrader -t 7.0.0 -u <MySQL-SuperUsername>
  2. Enter the password for that user. You can provide the password to the utility using the -p flag but this is not recommended in non-test deployments for security reasons.
  3. Run the following commands to fix some indexing issues:

    mysql -u root -e "use moogdb; alter table alert_filters_access drop key \`filter_id\`"
    mysql -u root -e "use moogdb; alter table situation_filters_access drop key \`filter_id\`"
    mysql -u root -e "use moogdb; alter table enrichment_static_mappings drop key \`enrichment_static_mappings_ibfk_1\`"
    mysql -u root -e "use moogdb; alter table sig_stats_cache drop key \`sig_id\`"

Restart All Processes

To restart all processes:

  1. Run the following commands to restart the processes:

    $MOOGSOFT_HOME/bin/utils/process_cntl apache-tomcat restart
    $MOOGSOFT_HOME/bin/utils/process_cntl moog_farmd restart
    $MOOGSOFT_HOME/bin/utils/process_cntl nginx restart
    $MOOGSOFT_HOME/bin/utils/process_cntl elasticsearch restart
  2. To restart LAMs or moog_farmd instances using specific configuration files, you can use the following example commands:

    $MOOGSOFT_HOME/bin/utils/process_cntl socket_lam start --service_instance=KINGSTON
    $MOOGSOFT_HOME/bin/utils/process_cntl moog_farmd start --service_instance=SURBITON
  3. Run the following command to restart any previously running UI-based Integrations:

    bash $MOOGSOFT_HOME/bin/utils/startup_cntl;

Install the Integrations

Run the following command to install the UI integrations for Moogsoft AIOps v7.0.1, if required:

bash $MOOGSOFT_HOME/bin/utils/integration_installer -a -l WARN;

Elasticsearch Re-index

Run the following command to re-index the alerts and Situations in moogfarmd. This command requires moogfarmd to be running.

$MOOGSOFT_HOME/bin/utils/moog_indexer --now

The re-index occurs in the background and may take a while to complete. This depends on the number of alerts and Situations in your system.

Migrate the Java Keystore

The upgrade includes a new version of the Java Runtime so you need to migrate any certificates stored in the old Java keystore into the new keystore, which is now the JRE under $MOOGSOFT_HOME/cots/jre/ .

If you did not manually add any certificates, you can skip this step.

Verify the Upgrade

Run the following automatic utilities to ensure that the upgrade was successful:

  1. Validate upgrade of AIOps core binary files

  2. Validate upgrade of apache-tomcat webapps and configuration

  3. Validate that the database schema has been upgraded successfully

  4. If there are some schema differences, they may be valid (e.g. custom_info related). If there are more substantial differences, you should investigate further to check if all the pre-requisite upgrade scripts have been applied in the right order:

    mysql -u root <moogdb_database_name> -e "select * from schema_upgrades;"
    mysql -u root <moog_reference_database_name> -e "select * from schema_upgrades;"

Remove the RPM-based Moogsoft AIOps

Once the migration and upgrade have been completed successfully, you can remove the Moogsoft AIOps packages and dependencies from the original RPM-based server, if required.

Please Please refer to the Uninstalling Moogsoft AIOps guide for instructions on how to do this.


If you have any issues, refer to Troubleshooting .