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:
- Ensure that Splunk UBA has access to RHEL repositories.
- 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.See Check system status before and after installation for more information about the script./opt/caspida/bin/utils/uba_health_check.sh
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:
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.
id 1010
- 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 thegroup_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 a single node AMI or OVA installation of Splunk UBA
- Upgrade a single node RHEL installation of Splunk UBA
- Upgrade a single node OEL installation of Splunk UBA
- Upgrade a distributed AMI or OVA installation of Splunk UBA
- Upgrade a distributed RHEL installation of Splunk UBA
- Upgrade a distributed OEL installation of Splunk UBA
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.
Secure the default account after installing Splunk UBA | Upgrade a single node AMI or OVA installation of Splunk UBA |
This documentation applies to the following versions of Splunk® User Behavior Analytics: 5.2.1
Feedback submitted, thanks!