Upgrade Splunk UBA prerequisites

Upgrading to Splunk UBA 5.2.1 requires Splunk UBA 5.2.0. See How to install or upgrade to this release of Splunk UBA for upgrade path information.

If you are running a version lower than 5.0.5, you must first upgrade to version 5.0.5 to upgrade to version 5.2.0 and then to version 5.2.1.
If you are running a version lower than 5.0.0, you must first upgrade to version 5.0.0, then upgrade to version 5.0.5, then upgrade to version 5.2.0, and then to version 5.2.1.

Before you upgrade, perform the following tasks:

Hadoop ports changed for Splunk UBA version 5.1.0 and higher. See Networking requirements to verify Hadoop port information before upgrading.

In RHEL Linux environments:
1. Ensure that Splunk UBA has access to RHEL repositories.
2. When installed on RHEL 8.x operating systems, Splunk UBA uses a 2048 bit RSA encryption key. The Splunk platform that communicates with Splunk UBA must also use a 2048 bit encryption key. See Red Hat Enterprise Linux 8.x cryptographic policies.
Review the Known issues for this release in the Release Notes manual.
The software update contains two archive files approximately 849MB and 4.7GB in size. The total extracted size is approximately 6.4GB. Verify that you have enough free space in /home/caspida to store the extracted installer files.
Backup your system. See Prepare to backup Splunk UBA in Administer Splunk User Behavior Analytics.
Make sure your system is running normally by using the uba_health_check.sh shell script.
```
/opt/caspida/bin/utils/uba_health_check.sh
```
See Check system status before and after installation for more information about the script.

Verify availability of a specific system ID for Impala

Perform the following steps to check if a UBA user is occupying UID 1010 and GID 1010. And if there is a user occupying 1010, migrate the user to another ID.

SSH to the host as caspida user.
Verify if any user or group other than "impala" has occupied id 1010. Run the following command:
```
id 1010
```
If the id is already assigned to a user or group, the command will output information about that user or group, including their name, group memberships, and more. If the UID is not assigned to any user or group, the command will return an error message indicating that the ID is not found.
If the id is assigned to any user, follow the steps to migrate that user to an ID other than 1010.

Create a backup of the user's home directory and any other files or directories that are owned by the user. Find the files/directories by following command:
```
sudo find / -uid 1010 -print
```
Run the following command replacing new_uid to a different value than 1010 and replacing the username placeholder to the value retrieved in step 2.
Changing the UID of a user can have unintended consequences if the user has ownership of system files or directories. Make a backup of the system before performing this operation.
```
sudo usermod -u <new_uid> <username>
```
Verify that the user's files and directories have been updated. Run the following command to find any files or directories associated with the old UID:
```
sudo find / -uid 1010 -print
```
If any files or directories are found with the old UID, update their ownership to the new UID using the following command:
```
sudo chown -R <username>:<username> /path/to/directory
```

If the ID is assigned to any group, follow the steps to migrate that group to an ID other than 1010.

Create a backup of any files or directories that are owned by the group. Find the files/directories by following command:
```
sudo find / -gid 1010 -print
```
Run the following command replacing new_gid to a different value than 1010 and replacing the group_name placeholder to the value retrieved step 2.
Changing the GID of a group can have unintended consequences if the group has ownership of system files or directories. Make a backup of the system before performing this operation.
```
sudo groupmod -g <new_gid> <group_name>
```
Verify that any files and directories owned by group have been updated. Run the following command to find any files or directories associated with old GID:
```
sudo find / -gid 1010 -print
```
If any files or directories are found with the GID 1010, update their group ownership to the new GID using the following command:
```
sudo chgrp -R <group_name> /path/to/directory
```

Validate the UMASK value

Ensure the UMASK value of the root user is set to 0002 or 0022, or grant read permissions for newly created files and directories to the caspida user.

Complete the following steps to validate the UMASK value:

Check the UMASK value of the root user by running the following command. The value must be 0002 or 0022:
```
umask
```
Verify the UMASK value in the /etc/login.defs file:
```
grep -i "^UMASK" /etc/login.defs
```
The umask value specified in /etc/login.defs applies as the default for all users.
Validate the permissions for new files and directories:

As the caspida user, create a new file or directory using sudo to observe the permissions:
```
sudo touch testfile.txt 
sudo mkdir testdirectory
```
Next, check the permissions of the created files and directories. The read permission for caspida(other) users is required:
```
ls -l testfile.txt 
ls -ld testdirectory
```

To set the required umask value, edit the /etc/login.defs file and set the UMASK value to 022.

If the caspida user does not have read permissions, update the UMASK value accordingly. Failure to provide the required permission to the caspida user will result in a UBA installation or upgrade failure.

Instructions to upgrade your Splunk UBA deployment

After satisfying the prerequisite requirements, go to one of the following:

Upgrade multiple Splunk UBA clusters that are using warm standby

If you have two Splunk UBA clusters running in a warm standby configuration, perform the following tasks to upgrade both clusters. Links to documentation in the Administer Splunk User Behavior Analytics manual are provided. In this example, the original primary system is called System A and the standby system is called System B.

Verify that both the System A and System B are configured for warm standby and are running as expected. See Verify that the primary and standby systems are synchronized .
Manually trigger a sync between System A and System B. See Synchronize the primary and standby systems on-demand.
Perform a failover from System A to System B. See Failover to a standby Splunk UBA system.
Switch the roles of both systems to reflect the failover. See Change the role of both systems to switch the primary and standby systems.
Failover from System B back to System A. See Failover to a standby Splunk UBA system.
Switch the roles of both system again to reflect the second failover operation. See Change the role of both systems to switch the primary and standby systems.
Run the uba_health_check.sh script. See Check system status before and after installation in the Install and Upgrade Splunk User Behavior Analytics manual.
Use the health monitor to verify that both Splunk UBA systems are up and running.
Upgrade the primary system (System A) to this release. Follow the upgrade instructions for your operating system.
Upgrade the standby system (System B) to this release. Follow the upgrade instructions for your operating system.
Check /var/log/caspida/UpgradeStatus-<release>.properties on both systems to verify that the upgrade succeeded. See Verify a successful upgrade of Splunk UBA in the Install and Upgrade Splunk User Behavior Analytics manual.

Upgrade Splunk UBA prerequisites

Verify availability of a specific system ID for Impala

Validate the UMASK value

Instructions to upgrade your Splunk UBA deployment

Upgrade multiple Splunk UBA clusters that are using warm standby

Comments

Upgrade Splunk UBA prerequisites

Was this topic useful?