Upgrade Moogsoft Onprem RPM v9.0.x or v9.1.x to v9.2.0.1

This topic describes how to patch an RPM-based distribution of Moogsoft Onprem to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x

Important

This process requires the presence of a third Moogsoft Onprem server to act a redundancy server as per : Fully Distributed HA Installation

If this server is not already provisioned and running, it must be provisioned before starting this process, and a clean installation of Moogsoft Onprem v9.2.0 performed on it, with just the RabbitMQ and OpenSearch processes left running

In the process below, Server 1 and Server 2 are existing servers running MoogFarmD, Apache-Tomcat, RabbitMQ etc

In the process below, Server 3 is the Redundancy Server running just RabbitMQ and possibly OpenSearch too

One-time multi-server upgrade step
Update all Percona nodes to the latest version using the instructions here: Percona Cluster 8.4 RPM Minor Version Upgrade
On Server 1 or Server 2
1. IMPORTANT: Make a note of the existing RabbitMQ Events.HA queue name by running this command:
```
rabbitmqctl -p <YOUR_VHOST> list_queues | grep Events.HA | awk '{print $1}' | head -n 1
```
  This queue name is needed later in the upgrade process
On Server 3
1. Stop RabbitMQ
```
service rabbitmq-server stop
```
On Server 1
1. If Server 3 existed before the upgrade and was part of the RabbitMQ cluster, remove the Server 3 RabbitMQ node from the cluster:
```
rabbitmqctl forget_cluster_node rabbit@<SERVER_3_IP_OR_HOSTNAME>
```
2. Comment out any reference to the Server 1 RabbitMQ broker from $MOOGSOFT_HOME/config/system.conf
  The entry under mooms -> brokers should be commented out
3. Comment out any reference to the Server 3 RabbitMQ broker from $MOOGSOFT_HOME/config/system.conf
  The entry under mooms -> brokers should be commented out
4. Stop MoogFarmd to pause event processing
```
service moogfarmd stop
```
5. Restart all other Moogsoft Onprem services (excluding MoogFarmD)
```
service apache-tomcat restart
service restlamd restart
service socketlamd restart
```
On Server 2
1. Comment out any reference to the Server 1 and the Server 3 RabbitMQ brokers from $MOOGSOFT_HOME/config/system.conf
  The entries under mooms -> brokers should be commented out
2. Stop MoogFarmD to pause event processing
```
service moogfarmd stop
```
3. Restart all other Moogsoft Onprem Services (excluding MoogFarmD)
```
service apache-tomcat restart
service restlamd restart
service socketlamd restart
```
On Server 3 (Redundancy Server)
1. Stop all services
```
service opensearch stop
```
2. Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the upgrade
```
rm -rf /var/lib/rabbitmq/mnesia/*
```
3. Upgrade the packages on the server
  Upgrade Moogsoft Onprem RPM to v9.2.0.1
  This topic describes how to patch an RPM-based distribution of Moogsoft Onprem to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x
  Ensure the patch RPMs are available to each server being patched:
  For internet-connected hosts, ensure there is a repo file under the /etc/yum.repos.d/ directory pointing to the 'speedy esr' yum repo.
  An example file is below:
  [moogsoft-aiops-9] name=moogsoft-aiops-9 baseurl=https://<username>:<password>@speedy.moogsoft.com/v9/repo/ enabled=1 gpgcheck=0 sslverify=false
  For offline-hosts:
  Download the two offline yum repository files (requires 'speedy' yum credentials):
  https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftBASE8_offline_repo.tar.gz https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftESR_9.2.0.1_offline_repo.tar.gz
  Move the two offline installer bundle files to each server being upgraded as needed
  Create two directories to house the repositories. For example:
  sudo mkdir -p /media/localRPM/BASE/ sudo mkdir -p /media/localRPM/ESR/
  Extract the two Tarball files into separate directories. For example:
  tar xzf *-MoogsoftBASE8_offline_repo.tar.gz -C /media/localRPM/BASE/ tar xzf *-MoogsoftESR_9.2.0.1_offline_repo.tar.gz -C /media/localRPM/ESR/
  Back up the existing /etc/yum.repos.d directory. For example:
  mv /etc/yum.repos.d /etc/yum.repos.d-backup
  Create an empty /etc/yum.repos.d directory. For example:
  mkdir /etc/yum.repos.d
  Create a local.repo file in the /etc/yum.repos.d/ folder ready to contain the local repository details for example:
  [BASE] name=MoogRHE-$releasever - MoogRPM baseurl=file:///media/localRPM/BASE/RHEL gpgcheck=0 enabled=1 [ESR] name=MoogRHEL-$releasever - MoogRPM baseurl=file:///media/localRPM/ESR/RHEL gpgcheck=0 enabled=1
  Clean the Yum cache:
  yum clean all
  Optional GPG key validation of the RPMs to validate the installation files.
  Follow the same instructions for GPG validation on this page: Moogsoft Onprem - Online RPM pre-installation
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Update the NginX yum repo file so it contains the mainline repo:
  rm -f /etc/yum.repos.d/nginx.repo; cat <<END > /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/rhel/8/\$basearch/ gpgcheck=0 enabled=1 module_hotfixes=1 [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/rhel/8/\$basearch/ gpgcheck=0 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=1 END
  FOR ALL VERSIONS
  For online-deployments only: Configure the latest RabbitMQ yum repository:
  curl -s https://packagecloud.io/install/repositories/cloudamqp/rabbitmq/script.rpm.sh | sudo bash
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.1 OR EARLIER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  Remove any 'rpmsave' files present. An rpmsave file will exist if a configuration/bot file was customised post-install/upgrade, and the product was later upgraded to a version which contained a version of the same file with new changes.
  If an rpmsave file is present when the product is upgraded again, and the new version contains additional changes to that file, a new rpmsave file will not be created, so any changes made between the new 'out of the box' version of the file, and the current rpmsave file, will be lost.
  A command to search for rpmsave files is below:
  find ${MOOGSOFT_HOME} -name '*.rpmsave'
  Either move these files to a backup directory, or remove them
  FOR ALL VERSIONS
  On each host where moogsoft packages are installed, install the patch RPMs:
  For internet-connected hosts run the following command:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1/')
  For offline hosts, run the following command in the directory containing the patch RPMs:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1*.rpm/')
  For ALL RPM-based deployments, ensure the Java JDK folder permissions are correct by running the following command as root (or a user with sudo permissions):
  chmod -R 755 /usr/java /usr/lib/jvm
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.1.0 OR NEWER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  FOR ALL VERSIONS
  In the latest release a number of the configuration files are different out of the box. This means after the RPM upgrade, the following configuration files will be replaced with 'rpmsave' versions of those same files.
  $MOOGSOFT_HOME/config/security.conf
  Any customisations made to the pre-upgrade versions of these files (*.rpmsave) should be copied into the non-rpmsave versions of the files. Alternatively, the rpmsave versions of the files can be renamed to replace the new file versions. For example:
  cp $MOOGSOFT_HOME/config/security.conf $MOOGSOFT_HOME/config/911cleansecurity.conf.bak; mv $MOOGSOFT_HOME/config/security.conf.rpmsave $MOOGSOFT_HOME/config/security.conf;
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Upgrade Nginx:
  yum -y upgrade nginx service nginx restart
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0 OR v9.0.0.1 OR v9.0.0.2 OR EARLIER ONLY
  New security enhancements in v9.0.1 require enabling the Sign Response As Required option on the IDP side, if configurable. We kindly request your SAML team to do this for the <PROD/UAT> environment before the upgrade. If you are unsure after communicating with your SAML team whether this option applies to your setup, please contact Moogsoft support.
  If a new IDP is generated after this change, SAML team should provide its metadata file to the team taking care of the upgrade. During the upgrade, the existing IDP file will be replaced with the one provided. In all cases, the SP metadata file will be regenerated and should be shared with SAML team. They may need to import the new SP metadata or configure the relevant fields with the information supplied in the file to complete the trust configuration.
  A fix has been made for SAML authentication around WantAssertionsSigned handling which can impact SAML logins for v9.0.1. Signing is now always required, even when WantAssertionsSigned is disabled. WantAssertionsSigned now requires explicit signing of the assertions, not the response.
  A way to disable this new check (if needed) is to change the WantAssertionsSigned setting in the SP Metadata file from true to false as per the example below (change the file name and path as needed below)
  sed -i 's/WantAssertionsSigned="true"/WantAssertionsSigned="false"/g' ${MOOGSOFT_HOME}/config/keycloak.my_sp_metadata.xml
4. Create the RabbitMQ vhost and Events.HA quorum queue on that node (to allow events to queue here during the upgrade)
```
VHOST=<your_vhost/zone_name>;
$MOOGSOFT_HOME/bin/utils/moog_init_mooms.sh -pz "${VHOST}";
QUEUE_NAME="<YOUR_EVENTS_HA_QUEUE_NAME>";
chmod u+x /usr/lib/rabbitmq/lib/rabbitmq_server-4.*/plugins/rabbitmq_management-4.*/priv/www/cli/rabbitmqadmin;
/usr/lib/rabbitmq/lib/rabbitmq_server-4.*/plugins/rabbitmq_management-4.*/priv/www/cli/rabbitmqadmin -u moogsoft -p m00gs0ft --vhost=${VHOST} declare queue name=${QUEUE_NAME} durable=true arguments='{"x-queue-type":"quorum"}';
/usr/lib/rabbitmq/lib/rabbitmq_server-4.*/plugins/rabbitmq_management-4.*/priv/www/cli/rabbitmqadmin -u moogsoft -p m00gs0ft --vhost=${VHOST} declare exchange name=MOOMS.GENERAL.TOPIC_EXCHANGE type=topic durable=true
/usr/lib/rabbitmq/lib/rabbitmq_server-4.*/plugins/rabbitmq_management-4.*/priv/www/cli/rabbitmqadmin -u moogsoft -p m00gs0ft -V ${VHOST} declare binding source="MOOMS.GENERAL.TOPIC_EXCHANGE" destination_type="queue" destination="${QUEUE_NAME}" routing_key="events"
```

On Server 2

Confirm that the RabbitMQ HA policy is still present on the Events queue:
```
rabbitmqctl list_queues name durable policy -p <YOUR_VHOST> | grep Events.HA
```
This command should return a value. If it does not, the policy should be reapplied with this command:
```
rabbitmqctl set_policy -p <YOUR_ZONE> ha-all ".+.HA" '{"ha-mode":"all"}'
```

Create a RabbitMQ shovel from the existing Events.HA queue to the Server 3 Events.HA queue to buffer events during the upgrade. Update the commands below with accurate variable values for the hostnames, v-hosts, and credentials.

SERVER_2_RABBITMQ_CREDS="moogsoft:m00gs0ft";
SERVER_2_RABBITMQ_VHOST="<YOUR_VHOST_NAME>";
SERVER_2_RABBITMQ_HOST="127.0.0.1";
QUEUE="<YOUR_EVENTS_HA_QUEUE_NAME>";
SERVER_3_RABBITMQ_CREDS="moogsoft:m00gs0ft";
SERVER_3_RABBITMQ_VHOST="<YOUR_VHOST_NAME>";
SERVER_3_RABBITMQ_HOST="<YOUR_SERVER_3_IP_OR_HOSTNAME>";
rabbitmq-plugins enable rabbitmq_shovel;
rabbitmq-plugins enable rabbitmq_shovel_management;
rabbitmqctl -p "${SERVER_2_RABBITMQ_VHOST}" set_parameter shovel my_shovel "$(cat <<EOF
{
   "src-uri": "amqp://${SERVER_2_RABBITMQ_CREDS}@${SERVER_2_RABBITMQ_HOST}/${SERVER_2_RABBITMQ_VHOST}",
   "src-queue": "${QUEUE}",
   "dest-uri": "amqp://${SERVER_3_RABBITMQ_CREDS}@${SERVER_3_RABBITMQ_HOST}/${SERVER_3_RABBITMQ_VHOST}",
   "add-forward-headers": false,
   "dest-exchange": "MOOMS.GENERAL.TOPIC_EXCHANGE",
   "ack-mode": "on-confirm",
   "delete-after": "never"
}
EOF
)"

Confirm that the Shovel was created successfully by running the command below.
The "state" must show "running" in this output. If the Shovel is not running at this stage, events may be lost depending on the overall process being carried out.
```
rabbitmqctl -p <YOUR_VHOST> shovel_status
```
Assuming events are being ingested via LAMs and UI Integrations, the count for the Events.HA queue on the Server 3 node should now be increasing.
You can check this using the CLI command below:
```
rabbitmqctl -p <YOUR_VHOST> list_queues
```

On Server 1

Confirm that the RabbitMQ HA policy is still present on the Events queue:

VHOST=$(${MOOGSOFT_HOME}/bin/utils/moog_config_reader -k mooms.zone)
rabbitmqctl list_queues name durable policy -p "${VHOST}" | grep Events.HA

This command should return a value. If it does not, the policy should be reapplied with this command:

rabbitmqctl set_policy -p "${VHOST}" ha-all ".+.HA" '{"ha-mode":"all"}'

Stop RabbitMQ
```
service rabbitmq-server stop
```

On Server 2

Remove the Server 1 RabbitMQ node from the cluster:

rabbitmqctl forget_cluster_node rabbit@<SERVER_1_IP_OR_HOSTNAME>

On Server 1
1. Stop all services (update the commands below as needed)
```
service apache-tomcat stop
service opensearch stop
service restlamd stop
service socketlamd stop
kill -9 $(ps -ef | grep java | grep Broker | awk '{print $2}') 2>/dev/null;
```
2. Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the upgrade
```
rm -rf /var/lib/rabbitmq/mnesia/*
```
3. Upgrade the packages on the server
  Upgrade Moogsoft Onprem RPM to v9.2.0.1
  This topic describes how to patch an RPM-based distribution of Moogsoft Onprem to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x
  Ensure the patch RPMs are available to each server being patched:
  For internet-connected hosts, ensure there is a repo file under the /etc/yum.repos.d/ directory pointing to the 'speedy esr' yum repo.
  An example file is below:
  [moogsoft-aiops-9] name=moogsoft-aiops-9 baseurl=https://<username>:<password>@speedy.moogsoft.com/v9/repo/ enabled=1 gpgcheck=0 sslverify=false
  For offline-hosts:
  Download the two offline yum repository files (requires 'speedy' yum credentials):
  https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftBASE8_offline_repo.tar.gz https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftESR_9.2.0.1_offline_repo.tar.gz
  Move the two offline installer bundle files to each server being upgraded as needed
  Create two directories to house the repositories. For example:
  sudo mkdir -p /media/localRPM/BASE/ sudo mkdir -p /media/localRPM/ESR/
  Extract the two Tarball files into separate directories. For example:
  tar xzf *-MoogsoftBASE8_offline_repo.tar.gz -C /media/localRPM/BASE/ tar xzf *-MoogsoftESR_9.2.0.1_offline_repo.tar.gz -C /media/localRPM/ESR/
  Back up the existing /etc/yum.repos.d directory. For example:
  mv /etc/yum.repos.d /etc/yum.repos.d-backup
  Create an empty /etc/yum.repos.d directory. For example:
  mkdir /etc/yum.repos.d
  Create a local.repo file in the /etc/yum.repos.d/ folder ready to contain the local repository details for example:
  [BASE] name=MoogRHE-$releasever - MoogRPM baseurl=file:///media/localRPM/BASE/RHEL gpgcheck=0 enabled=1 [ESR] name=MoogRHEL-$releasever - MoogRPM baseurl=file:///media/localRPM/ESR/RHEL gpgcheck=0 enabled=1
  Clean the Yum cache:
  yum clean all
  Optional GPG key validation of the RPMs to validate the installation files.
  Follow the same instructions for GPG validation on this page: Moogsoft Onprem - Online RPM pre-installation
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Update the NginX yum repo file so it contains the mainline repo:
  rm -f /etc/yum.repos.d/nginx.repo; cat <<END > /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/rhel/8/\$basearch/ gpgcheck=0 enabled=1 module_hotfixes=1 [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/rhel/8/\$basearch/ gpgcheck=0 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=1 END
  FOR ALL VERSIONS
  For online-deployments only: Configure the latest RabbitMQ yum repository:
  curl -s https://packagecloud.io/install/repositories/cloudamqp/rabbitmq/script.rpm.sh | sudo bash
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.1 OR EARLIER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  Remove any 'rpmsave' files present. An rpmsave file will exist if a configuration/bot file was customised post-install/upgrade, and the product was later upgraded to a version which contained a version of the same file with new changes.
  If an rpmsave file is present when the product is upgraded again, and the new version contains additional changes to that file, a new rpmsave file will not be created, so any changes made between the new 'out of the box' version of the file, and the current rpmsave file, will be lost.
  A command to search for rpmsave files is below:
  find ${MOOGSOFT_HOME} -name '*.rpmsave'
  Either move these files to a backup directory, or remove them
  FOR ALL VERSIONS
  On each host where moogsoft packages are installed, install the patch RPMs:
  For internet-connected hosts run the following command:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1/')
  For offline hosts, run the following command in the directory containing the patch RPMs:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1*.rpm/')
  For ALL RPM-based deployments, ensure the Java JDK folder permissions are correct by running the following command as root (or a user with sudo permissions):
  chmod -R 755 /usr/java /usr/lib/jvm
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.1.0 OR NEWER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  FOR ALL VERSIONS
  In the latest release a number of the configuration files are different out of the box. This means after the RPM upgrade, the following configuration files will be replaced with 'rpmsave' versions of those same files.
  $MOOGSOFT_HOME/config/security.conf
  Any customisations made to the pre-upgrade versions of these files (*.rpmsave) should be copied into the non-rpmsave versions of the files. Alternatively, the rpmsave versions of the files can be renamed to replace the new file versions. For example:
  cp $MOOGSOFT_HOME/config/security.conf $MOOGSOFT_HOME/config/911cleansecurity.conf.bak; mv $MOOGSOFT_HOME/config/security.conf.rpmsave $MOOGSOFT_HOME/config/security.conf;
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Upgrade Nginx:
  yum -y upgrade nginx service nginx restart
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0 OR v9.0.0.1 OR v9.0.0.2 OR EARLIER ONLY
  New security enhancements in v9.0.1 require enabling the Sign Response As Required option on the IDP side, if configurable. We kindly request your SAML team to do this for the <PROD/UAT> environment before the upgrade. If you are unsure after communicating with your SAML team whether this option applies to your setup, please contact Moogsoft support.
  If a new IDP is generated after this change, SAML team should provide its metadata file to the team taking care of the upgrade. During the upgrade, the existing IDP file will be replaced with the one provided. In all cases, the SP metadata file will be regenerated and should be shared with SAML team. They may need to import the new SP metadata or configure the relevant fields with the information supplied in the file to complete the trust configuration.
  A fix has been made for SAML authentication around WantAssertionsSigned handling which can impact SAML logins for v9.0.1. Signing is now always required, even when WantAssertionsSigned is disabled. WantAssertionsSigned now requires explicit signing of the assertions, not the response.
  A way to disable this new check (if needed) is to change the WantAssertionsSigned setting in the SP Metadata file from true to false as per the example below (change the file name and path as needed below)
  sed -i 's/WantAssertionsSigned="true"/WantAssertionsSigned="false"/g' ${MOOGSOFT_HOME}/config/keycloak.my_sp_metadata.xml
4. Upgrade the database schema
  Upgrade the database schema
  Upgrade the database schema and refresh all stored procedures (provide the 'ermintrude' DB user password when prompted):
```
$MOOGSOFT_HOME/bin/utils/moog_db_auto_upgrader -t 9.2.0 -u ermintrude
```
5. If the Enrichment Database (Create the Enrichment API Data Store) is being used, ensure the schema is updated using the schema update command on that page.
6. Cluster RabbitMQ with the Node 3 RabbitMQ
  Join the RabbitMQ v4 cluster (RPM)
  The primary erlang cookie is located at /var/lib/rabbitmq/.erlang.cookie on whichever RabbitMQ node has been upgraded first.
  The erlang cookie must be the same for all RabbitMQ nodes. Replace the erlang cookie on all other RabbitMQ nodes with primary erlang cookie
  Make the cookies on non-primary nodes read-only:
```
chmod 400 /var/lib/rabbitmq/.erlang.cookie
```
  You may need to change the file permissions on the existing erlang cookies first to allow those files to be overwritten. For example:
  chmod 600 /var/lib/rabbitmq/.erlang.cookie
  Restart RabbitMQ on nodes where the erlang cookie has been replaced
```
service rabbitmq-server restart
```
  To join a RabbitMQ node to a cluster, run these commands on the servers needing to join the cluster, but first substitute the short hostname of the RabbitMQ server you wish to cluster with. The short hostname is the full hostname excluding the DNS domain name. For example, if the hostname is ip-172-31-82-78.ec2.internal, the short hostname is ip-172-31-82-78. To find out the short hostname, run rabbitmqctl cluster_status on the appropriate server.
```
systemctl restart rabbitmq-server
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@<NODE_3_SHORTNAME>
rabbitmqctl start_app
```
  Run rabbitmqctl cluster_status to get the cluster status. Example output is as follows:
```
Cluster status of node rabbit@ip-172-31-93-201 Basics Cluster name rabbit@ip-172-31-93-201.ec2.internal Disk Nodes rabbit@ip-172-31-93-201
rabbit@ip-172-31-85-42
rabbit@ip-172-31-93-201 Running Nodes rabbit@ip-172-31-93-201
rabbit@ip-172-31-85-42
rabbit@ip-172-31-93-201 Versions
...
```
7. Update the RabbitMQ brokers in $MOOGSOFT_HOME/config/system.conf to include Server 1 and Server 3
  The entries under mooms -> brokers should be added or uncommented as needed
8. Upgrade Apache-Tomcat
  Upgrade Apache-Tomcat (RPM)
  Warning
  This process will completely remove and re-deploy Apache-Tomcat. If the Apache-Tomcat logs need to be kept, a copy should be made before proceeding.
  Deploy the new version of Apache Tomcat and the latest webapps:
```
$MOOGSOFT_HOME/bin/utils/moog_init_ui.sh -twf
```
  If you made any changes to the original Apache Tomcat service script (such as the Xmx value), apply the same changes to the new version. This will require a restart of the apache-tomcat service
9. Update the NginX configuration file to ensure the UI Integrations tab is accessible:
```
sed -i 's;location ^~ /integrations {;location ^~ /integrations/ {;' /etc/nginx/conf.d/moog-ssl.conf
```
  Then reload NginX:
```
service nginx reload
```
10. Perform final checks
  Final upgrade steps (RPM)
  Validate the patch:
  $MOOGSOFT_HOME/bin/utils/moog_install_validator.sh $MOOGSOFT_HOME/bin/utils/tomcat_install_validator.sh $MOOGSOFT_HOME/bin/utils/moog_db_validator.sh
  If there are any errors from the validators, contact Moogsoft Support
  Important
  Re-install the latest 'Addons' pack: Install Moogsoft Add-ons
  The OpenSearch Cluster now needs to be recreated: Opensearch Clustering Guide - RPM
  Restart any event feeds if they were stopped
11. Start the LAMs (update the commands below as needed)
```
service restlamd restart
service socketlamd restart
```
On Server 2
1. Stop Tomcat and LAMs (update the commands below as needed)
```
service apache-tomcat stop
service restlamd stop
service socketlamd stop
kill -9 $(ps -ef | grep java | grep Broker | awk '{print $2}') 2>/dev/null;
```
2. Wait for the old Events.HA RabbitMQ queue to drain via the shovel to the new nodes. The command below needs to return a value of 0 before proceeding:
```
VHOST=$(${MOOGSOFT_HOME}/bin/utils/moog_config_reader -k mooms.zone)
rabbitmqctl -p "${VHOST}" list_queues name messages | grep Events.HA
```
3. Stop RabbitMQ
```
service rabbitmq-server stop
```
4. Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the upgrade
```
rm -rf /var/lib/rabbitmq/mnesia/*
```
5. Upgrade the packages on the server
  Upgrade Moogsoft Onprem RPM to v9.2.0.1
  This topic describes how to patch an RPM-based distribution of Moogsoft Onprem to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x
  Ensure the patch RPMs are available to each server being patched:
  For internet-connected hosts, ensure there is a repo file under the /etc/yum.repos.d/ directory pointing to the 'speedy esr' yum repo.
  An example file is below:
  [moogsoft-aiops-9] name=moogsoft-aiops-9 baseurl=https://<username>:<password>@speedy.moogsoft.com/v9/repo/ enabled=1 gpgcheck=0 sslverify=false
  For offline-hosts:
  Download the two offline yum repository files (requires 'speedy' yum credentials):
  https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftBASE8_offline_repo.tar.gz https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftESR_9.2.0.1_offline_repo.tar.gz
  Move the two offline installer bundle files to each server being upgraded as needed
  Create two directories to house the repositories. For example:
  sudo mkdir -p /media/localRPM/BASE/ sudo mkdir -p /media/localRPM/ESR/
  Extract the two Tarball files into separate directories. For example:
  tar xzf *-MoogsoftBASE8_offline_repo.tar.gz -C /media/localRPM/BASE/ tar xzf *-MoogsoftESR_9.2.0.1_offline_repo.tar.gz -C /media/localRPM/ESR/
  Back up the existing /etc/yum.repos.d directory. For example:
  mv /etc/yum.repos.d /etc/yum.repos.d-backup
  Create an empty /etc/yum.repos.d directory. For example:
  mkdir /etc/yum.repos.d
  Create a local.repo file in the /etc/yum.repos.d/ folder ready to contain the local repository details for example:
  [BASE] name=MoogRHE-$releasever - MoogRPM baseurl=file:///media/localRPM/BASE/RHEL gpgcheck=0 enabled=1 [ESR] name=MoogRHEL-$releasever - MoogRPM baseurl=file:///media/localRPM/ESR/RHEL gpgcheck=0 enabled=1
  Clean the Yum cache:
  yum clean all
  Optional GPG key validation of the RPMs to validate the installation files.
  Follow the same instructions for GPG validation on this page: Moogsoft Onprem - Online RPM pre-installation
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Update the NginX yum repo file so it contains the mainline repo:
  rm -f /etc/yum.repos.d/nginx.repo; cat <<END > /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/rhel/8/\$basearch/ gpgcheck=0 enabled=1 module_hotfixes=1 [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/rhel/8/\$basearch/ gpgcheck=0 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=1 END
  FOR ALL VERSIONS
  For online-deployments only: Configure the latest RabbitMQ yum repository:
  curl -s https://packagecloud.io/install/repositories/cloudamqp/rabbitmq/script.rpm.sh | sudo bash
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.1 OR EARLIER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  Remove any 'rpmsave' files present. An rpmsave file will exist if a configuration/bot file was customised post-install/upgrade, and the product was later upgraded to a version which contained a version of the same file with new changes.
  If an rpmsave file is present when the product is upgraded again, and the new version contains additional changes to that file, a new rpmsave file will not be created, so any changes made between the new 'out of the box' version of the file, and the current rpmsave file, will be lost.
  A command to search for rpmsave files is below:
  find ${MOOGSOFT_HOME} -name '*.rpmsave'
  Either move these files to a backup directory, or remove them
  FOR ALL VERSIONS
  On each host where moogsoft packages are installed, install the patch RPMs:
  For internet-connected hosts run the following command:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1/')
  For offline hosts, run the following command in the directory containing the patch RPMs:
  yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1*.rpm/')
  For ALL RPM-based deployments, ensure the Java JDK folder permissions are correct by running the following command as root (or a user with sudo permissions):
  chmod -R 755 /usr/java /usr/lib/jvm
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.1.0 OR NEWER ONLY
  Important
  Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
  Upgrade Erlang (required for the new version of RabbitMQ):
  Online RPM erlang upgrade command:
  yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
  Offline RPM erlang upgrade command:
  yum upgrade erlang-27.3.4.13
  FOR ALL VERSIONS
  In the latest release a number of the configuration files are different out of the box. This means after the RPM upgrade, the following configuration files will be replaced with 'rpmsave' versions of those same files.
  $MOOGSOFT_HOME/config/security.conf
  Any customisations made to the pre-upgrade versions of these files (*.rpmsave) should be copied into the non-rpmsave versions of the files. Alternatively, the rpmsave versions of the files can be renamed to replace the new file versions. For example:
  cp $MOOGSOFT_HOME/config/security.conf $MOOGSOFT_HOME/config/911cleansecurity.conf.bak; mv $MOOGSOFT_HOME/config/security.conf.rpmsave $MOOGSOFT_HOME/config/security.conf;
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0.x OR EARLIER ONLY
  Upgrade Nginx:
  yum -y upgrade nginx service nginx restart
  FOR DEPLOYMENTS BEING UPGRADED FROM v9.0.0 OR v9.0.0.1 OR v9.0.0.2 OR EARLIER ONLY
  New security enhancements in v9.0.1 require enabling the Sign Response As Required option on the IDP side, if configurable. We kindly request your SAML team to do this for the <PROD/UAT> environment before the upgrade. If you are unsure after communicating with your SAML team whether this option applies to your setup, please contact Moogsoft support.
  If a new IDP is generated after this change, SAML team should provide its metadata file to the team taking care of the upgrade. During the upgrade, the existing IDP file will be replaced with the one provided. In all cases, the SP metadata file will be regenerated and should be shared with SAML team. They may need to import the new SP metadata or configure the relevant fields with the information supplied in the file to complete the trust configuration.
  A fix has been made for SAML authentication around WantAssertionsSigned handling which can impact SAML logins for v9.0.1. Signing is now always required, even when WantAssertionsSigned is disabled. WantAssertionsSigned now requires explicit signing of the assertions, not the response.
  A way to disable this new check (if needed) is to change the WantAssertionsSigned setting in the SP Metadata file from true to false as per the example below (change the file name and path as needed below)
  sed -i 's/WantAssertionsSigned="true"/WantAssertionsSigned="false"/g' ${MOOGSOFT_HOME}/config/keycloak.my_sp_metadata.xml
6. Cluster RabbitMQ with Node 3 RabbitMQ
  Join the RabbitMQ v4 cluster (RPM)
  The primary erlang cookie is located at /var/lib/rabbitmq/.erlang.cookie on whichever RabbitMQ node has been upgraded first.
  The erlang cookie must be the same for all RabbitMQ nodes. Replace the erlang cookie on all other RabbitMQ nodes with primary erlang cookie
  Make the cookies on non-primary nodes read-only:
```
chmod 400 /var/lib/rabbitmq/.erlang.cookie
```
  You may need to change the file permissions on the existing erlang cookies first to allow those files to be overwritten. For example:
  chmod 600 /var/lib/rabbitmq/.erlang.cookie
  Restart RabbitMQ on nodes where the erlang cookie has been replaced
```
service rabbitmq-server restart
```
  To join a RabbitMQ node to a cluster, run these commands on the servers needing to join the cluster, but first substitute the short hostname of the RabbitMQ server you wish to cluster with. The short hostname is the full hostname excluding the DNS domain name. For example, if the hostname is ip-172-31-82-78.ec2.internal, the short hostname is ip-172-31-82-78. To find out the short hostname, run rabbitmqctl cluster_status on the appropriate server.
```
systemctl restart rabbitmq-server
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@<NODE_3_SHORTNAME>
rabbitmqctl start_app
```
  Run rabbitmqctl cluster_status to get the cluster status. Example output is as follows:
```
Cluster status of node rabbit@ip-172-31-93-201 Basics Cluster name rabbit@ip-172-31-93-201.ec2.internal Disk Nodes rabbit@ip-172-31-93-201
rabbit@ip-172-31-85-42
rabbit@ip-172-31-93-201 Running Nodes rabbit@ip-172-31-93-201
rabbit@ip-172-31-85-42
rabbit@ip-172-31-93-201 Versions
...
```
7. Update the RabbitMQ brokers in $MOOGSOFT_HOME/config/system.conf to include Server 1 and Server 2, and Server 3
  The entries under mooms -> brokers should be added or uncommented as needed
8. Upgrade Apache-Tomcat
  Upgrade Apache-Tomcat (RPM)
  Warning
  This process will completely remove and re-deploy Apache-Tomcat. If the Apache-Tomcat logs need to be kept, a copy should be made before proceeding.
  Deploy the new version of Apache Tomcat and the latest webapps:
```
$MOOGSOFT_HOME/bin/utils/moog_init_ui.sh -twf
```
  If you made any changes to the original Apache Tomcat service script (such as the Xmx value), apply the same changes to the new version. This will require a restart of the apache-tomcat service
9. Update the NginX configuration file to ensure the UI Integrations tab is accessible:
```
sed -i 's;location ^~ /integrations {;location ^~ /integrations/ {;' /etc/nginx/conf.d/moog-ssl.conf
```
  Then reload NginX:
```
service nginx reload
```
10. Perform final checks
  Final upgrade steps (RPM)
  Validate the patch:
  $MOOGSOFT_HOME/bin/utils/moog_install_validator.sh $MOOGSOFT_HOME/bin/utils/tomcat_install_validator.sh $MOOGSOFT_HOME/bin/utils/moog_db_validator.sh
  If there are any errors from the validators, contact Moogsoft Support
  Important
  Re-install the latest 'Addons' pack: Install Moogsoft Add-ons
  The OpenSearch Cluster now needs to be recreated: Opensearch Clustering Guide - RPM
  Restart any event feeds if they were stopped
11. Start the LAMs (update the commands below as needed)
```
service restlamd restart
service socketlamd restart
```
On Server 1
1. Ensure all RabbitMQ quorum queues are updated to have the right number of replicas:
```
rabbitmq-queues grow rabbit@<SERVER1_HOSTNAME_OR_IP> all;
rabbitmq-queues grow rabbit@<SERVER2_HOSTNAME_OR_IP> all;
rabbitmq-queues grow rabbit@<SERVER3_HOSTNAME_OR_IP> all;
```
2. Update the RabbitMQ brokers in $MOOGSOFT_HOME/config/system.conf to include Server 1 and Server 2, and Server 3
  The entries under mooms -> brokers should be added or uncommented as needed
3. Start MoogFarmD
```
service moogfarmd restart
```
4. Restart Apache-Tomcat
```
service apache-tomcat restart
```
On Server 2
1. Start MoogFarmD
```
service moogfarmd restart
```
Upgrade the Moogsoft Bridge Servers
Upgrade the Moogsoft bridge packages to v9.2.0.1
This topic describes how to patch an RPM-based distribution of Moogsoft Onprem Bridge to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x
Upgrade Moogsoft Onprem Bridge RPM to v9.2.0.1
Important
While a Moogsoft Onprem Bridge environment can run with one or two RabbitMQ nodes, as of Moogsoft v9.2.0 / RabbitMQ v4, the new Quorum queues require at least three nodes to provide full protection to events in the queues in the case of a cluster node failure.
For example, three RabbitMQ v4 nodes will protect against a single node failing, and five RabbitMQ v4 nodes will protect against two nodes failing etc
So while the Moogsoft Onprem Bridge can run against a single RabbitMQ node, events will potentially be lost during this upgrade process. Events will be saved if there are two nodes, but there will be no protection on the queue should one of the nodes go down in the future. Hence it is recommended to provision a third RabbitMQ node for the Bridge to communicate with.
Documentation for creating a three node setup is available here: Fully Distributed HA Installation
Ensure that the main Moogsoft Onprem servers have been upgraded before performing the Bridge upgrades
For Bridge deployments with a single RabbitMQ node
Warning
Events may be lost during the upgrade process in this deployment type - it is recommended to upgrade to a three node RabbitMQ cluster to protect against event loss
Stop all services (ensure that all LAMs are stopped - REST LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^$.*moogsoft_bridge.*$$/#\1/') | crontab - kill -9 $(ps -ef | grep java | grep moogsoft_bridge | awk '{print $2}') 2>/dev/null service restlamd stop service socketlamd stop service rabbitmq-server stop
Upgrade the Moogsoft Onprem packages on the server using the instructions in the section below. Refer to Upgrade the Moogsoft bridge packages to v9.2.0.1
Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the queue upgrade
rm -rf /var/lib/rabbitmq/mnesia/*
Re-create the RabbitMQ vhost
$MOOGSOFT_HOME/bin/utils/moog_init_mooms.sh -pz ${YOUR_VHOST};
Restart all services (ensure that all LAMs are started - Rest LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^\#\+$.*moogsoft_bridge.*$/\1/') | crontab - service restlamd start service socketlamd start
For Bridge deployments with two RabbitMQ nodes
Warning
Having only two nodes will not provide protection against event loss in RabbitMQ v4 - if one node fails, the cluster will fail. It is recommended to upgrade to a three node RabbitMQ cluster which can be done after this upgrade if needed.
On Server 1
Stop all services (ensure that all LAMs are stopped - REST LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^$.*moogsoft_bridge.*$$/#\1/') | crontab - kill -9 $(ps -ef | grep java | grep moogsoft_bridge | awk '{print $2}') 2>/dev/null service restlamd stop service socketlamd stop service rabbitmq-server stop
Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the upgrade
rm -rf /var/lib/rabbitmq/mnesia/*
Upgrade the Moogsoft Onprem packages on the server using the instructions in the section below. Refer to Upgrade the Moogsoft bridge packages to v9.2.0.1
Create the RabbitMQ vhost
$MOOGSOFT_HOME/bin/utils/moog_init_mooms.sh -pz ${YOUR_VHOST};
Restart all services (ensure that all LAMs are started - Rest LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^\#\+$.*moogsoft_bridge.*$/\1/') | crontab - service restlamd start service socketlamd start
On Server 2
Stop all services (ensure that all LAMs are stopped - REST LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^$.*moogsoft_bridge.*$$/#\1/') | crontab - kill -9 $(ps -ef | grep java | grep moogsoft_bridge | awk '{print $2}') 2>/dev/null service restlamd stop service socketlamd stop service rabbitmq-server stop
Delete the RabbitMQ mnesia dir to reset RabbitMQ to prepare for the upgrade
rm -rf /var/lib/rabbitmq/mnesia/*
Upgrade the Moogsoft Onprem packages on the server using the instructions in the section below. Refer to Upgrade the Moogsoft bridge packages to v9.2.0.1
Cluster the Rabbit Nodes together
Join the RabbitMQ v4 cluster (RPM)
The primary erlang cookie is located at /var/lib/rabbitmq/.erlang.cookie on whichever RabbitMQ node has been upgraded first.
The erlang cookie must be the same for all RabbitMQ nodes. Replace the erlang cookie on all other RabbitMQ nodes with primary erlang cookie
Make the cookies on non-primary nodes read-only:
chmod 400 /var/lib/rabbitmq/.erlang.cookie
You may need to change the file permissions on the existing erlang cookies first to allow those files to be overwritten. For example:
chmod 600 /var/lib/rabbitmq/.erlang.cookie
Restart RabbitMQ on nodes where the erlang cookie has been replaced
service rabbitmq-server restart
To join a RabbitMQ node to a cluster, run these commands on the servers needing to join the cluster, but first substitute the short hostname of the RabbitMQ server you wish to cluster with. The short hostname is the full hostname excluding the DNS domain name. For example, if the hostname is ip-172-31-82-78.ec2.internal, the short hostname is ip-172-31-82-78. To find out the short hostname, run rabbitmqctl cluster_status on the appropriate server.
systemctl restart rabbitmq-server rabbitmqctl stop_app rabbitmqctl join_cluster rabbit@<NODE_3_SHORTNAME> rabbitmqctl start_app
Run rabbitmqctl cluster_status to get the cluster status. Example output is as follows:
Cluster status of node rabbit@ip-172-31-93-201 Basics Cluster name rabbit@ip-172-31-93-201.ec2.internal Disk Nodes rabbit@ip-172-31-93-201 rabbit@ip-172-31-85-42 rabbit@ip-172-31-93-201 Running Nodes rabbit@ip-172-31-93-201 rabbit@ip-172-31-85-42 rabbit@ip-172-31-93-201 Versions ...
Restart all services (ensure that all LAMs are started - Rest LAM and Socket LAM are included below as examples but these should be replaced with the LAMs running in your deployment)
(crontab -l | sed -e 's/^\#\+$.*moogsoft_bridge.*$/\1/') | crontab - service restlamd start service socketlamd start
For Bridge deployments with more than two RabbitMQ nodes
For deployments with three or more RabbitMQ nodes, the same process as for two nodes can be followed - upgrade one server fully to start, then select the next server, upgrade the applications, join it to the first RabbitMQ node cluster, before restarting all services, and repeating for the remaining servers
Upgrade the Moogsoft bridge packages to v9.2.0.1
This topic describes how to patch an RPM-based distribution of Moogsoft Onprem to v9.2.0.1 from v9.0.0 or 9.0.0.x or 9.0.1.x, 9.1.0.x, or 9.1.1.x
Ensure the patch RPMs are available to each server being patched:
For internet-connected hosts, ensure there is a repo file under the /etc/yum.repos.d/ directory pointing to the 'speedy esr' yum repo.
An example file is below:
[moogsoft-aiops-90] name=moogsoft-aiops-90 baseurl=https://<username>:<password>@speedy.moogsoft.com/v9/repo/ enabled=1 gpgcheck=0 sslverify=false
For offline-hosts:
Download the two offline yum repository files (requires 'speedy' yum credentials):
https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftBASE8_offline_repo.tar.gz https://speedy.moogsoft.com/v9/offline/2026-07-29-1785381987-MoogsoftESR_9.2.0.1_offline_repo.tar.gz
Move the two offline installer bundle files to each server being upgraded as needed
Create two directories to house the repositories. For example:
sudo mkdir -p /media/localRPM/BASE/ sudo mkdir -p /media/localRPM/ESR/
Extract the two Tarball files into separate directories. For example:
tar xzf *-MoogsoftBASE8_offline_repo.tar.gz -C /media/localRPM/BASE/ tar xzf *-MoogsoftESR_9.2.0.1_offline_repo.tar.gz -C /media/localRPM/ESR/
Back up the existing /etc/yum.repos.d directory. For example:
mv /etc/yum.repos.d /etc/yum.repos.d-backup
Create an empty /etc/yum.repos.d directory. For example:
mkdir /etc/yum.repos.d
Create a local.repo file in the /etc/yum.repos.d/ folder ready to contain the local repository details for example:
[BASE] name=MoogRHE-$releasever - MoogRPM baseurl=file:///media/localRPM/BASE/RHEL gpgcheck=0 enabled=1 [ESR] name=MoogRHEL-$releasever - MoogRPM baseurl=file:///media/localRPM/ESR/RHEL gpgcheck=0 enabled=1
Clean the Yum cache:
yum clean all
Optional GPG key validation of the RPMs to validate the installation files.
Follow the same instructions for GPG validation on this page: Moogsoft Onprem - Online RPM pre-installation
FOR ALL VERSIONS
For online-deployments only: Configure the latest RabbitMQ yum repository:
curl -s https://packagecloud.io/install/repositories/cloudamqp/rabbitmq/script.rpm.sh | sudo bash
FOR ALL VERSIONS
On each host where moogsoft packages are installed, install the patch RPMs:
For internet-connected hosts run the following command:
yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1/')
For offline hosts, run the following command in the directory containing the patch RPMs:
yum -y upgrade $(rpm -qa --qf '%{NAME}\n' | grep moogsoft | sed 's/$/-9.2.0.1*.rpm/')
For ALL RPM-based deployments, ensure the Java JDK folder permissions are correct by running the following command as root (or a user with sudo permissions):
chmod -R 755 /usr/java /usr/lib/jvm
FOR ALL VERSIONS
Important
Ensure the RabbitMQ feature flags have been enabled before proceeding. See the start of this document for the required command.
Upgrade Erlang (required for the new version of RabbitMQ):
Online RPM erlang upgrade command:
yum upgrade https://github.com/rabbitmq/erlang-rpm/releases/download/v27.3.4.13/erlang-27.3.4.13-1.el8.x86_64.rpm
Offline RPM erlang upgrade command:
yum upgrade erlang-27.3.4.13
FOR ALL VERSIONS
In the latest release a number of the configuration files are different out of the box. This means after the RPM upgrade, the following configuration files will be replaced with 'rpmsave' versions of those same files.
$MOOGSOFT_HOME/config/security.conf
Any customisations made to the pre-upgrade versions of these files (*.rpmsave) should be copied into the non-rpmsave versions of the files. Alternatively, the rpmsave versions of the files can be renamed to replace the new file versions. For example:
cp $MOOGSOFT_HOME/config/security.conf $MOOGSOFT_HOME/config/911cleansecurity.conf.bak; mv $MOOGSOFT_HOME/config/security.conf.rpmsave $MOOGSOFT_HOME/config/security.conf;

‌

In this section:

Upgrade Moogsoft Onprem RPM v9.0.x or v9.1.x to v9.2.0.1

Important

Important

Important

Important

Important

Warning

Important

Important

Important

Warning

Important

Upgrade Moogsoft Onprem Bridge RPM to v9.2.0.1

Important

Warning

Warning

Upgrade the Moogsoft bridge packages to v9.2.0.1

Important

Search results