Upgrading Oracle Audit Vault and Database Firewall

5 Upgrading Oracle Audit Vault and Database Firewall

This chapter provides information on upgrades from the previous release of Oracle Audit Vault and Database Firewall.

5.1 About Upgrading Oracle Audit Vault and Database Firewall

Learn the steps to upgrade Oracle Audit Vault and Database Firewall.

You can upgrade Oracle Audit Vault and Database Firewall from the previous release.

Note:

You must first take a backup prior to performing any upgrade.
Follow the instructions in section Pre-upgrade Tasks before upgrading to Oracle AVDF 20.
Oracle Audit Vault and Database Firewall versions 12.2.0.0.0 and above must first upgrade to 12.2.0.9.0.
In all the above cases, you may perform a single backup operation prior to performing the first upgrade.
In case you have a Niagara card in your system, then contact Oracle support before performing the upgrade task.
You must keep sufficient disk space if there is huge amount of event data. The amount of disk space required is about 5% of the total event log data size.

Go to My Oracle Support and sign in.
Click the Patches & Updates tab.
Use the Patch Search box.
1. Click the Product or Family (Advanced) link on the left.
2. In the Product field, start typing Audit Vault and Database Firewall, and then select the product name.
3. In the Release field, select the latest patch from the drop-down list.
4. Click Search.
In the search results page, in the Patch Name column, click the number for the latest Bundle Patch.

A corresponding patch page appears.

5.2 Pre-upgrade Tasks

Learn about the pre-upgrade prerequisites before upgrading Oracle Audit Vault and Database Firewall (Oracle AVDF).

Note:

If you have an Audit Vault Agent running on a Windows machine, then ensure to close all the Agent related directories and open files before upgrading Oracle AVDF.

5.2.1 Host Monitor Migration on Windows

If you are using Host Monitoring on Windows platform, then update Npcap and OpenSSL libraries on Windows before upgrading to Oracle AVDF 20.

Complete the steps in the following sections:

Ensure the network_device_name_for_hostmonitor collection attribute is set following the steps mentioned in section Create a Network Audit Trail post installation of Npcap and OpenSSL
Deploying the Agent and Host Monitor on Microsoft Windows Hosts

5.2.2 Back Up The Current Oracle Audit Vault And Database Firewall Installation

Before upgrading Oracle Audit Vault and Database Firewall (Oracle AVDF), you must back up the Audit Vault Server.

See Backing Up and Restoring the Audit Vault Server for complete information.

If your current Audit Vault Server is installed on a virtual machine (for example VM on Oracle VM or VMWare), it is recommended to take a VM snapshot before starting the upgrade process.

5.2.3 Pre-upgrade RPM Legacy Crypto Check Warning

Learn about legacy crypto warning while upgrading to Oracle AVDF 20.4 (or later).

If your current Oracle AVDF 12.2 deployment consists of Host Monitor Agents or Audit Vault Agents on AIX, then follow the instructions in this topic when upgrading to Oracle AVDF 20.4 (or later).

The pre-upgrade RPM performs a check, displays the following warning, and requires your action to proceed with the upgrade.

Upgrading from Oracle AVDF 12.2.0.11.0 and Prior

If you have deployed Host Monitor Agents (or Audit Vault Agents on AIX) in your environment, TLS 1.1 should be used for encryption instead of the default version of TLS 1.2. Else, Host Monitor Agents (or Audit Vault Agents on AIX) will not upgrade automatically. If you wish to use TLS 1.1 for encryption run the below command before proceeding with the upgrade.

ruby /usr/local/dbfw/bin/upgrade/configure_tls_settings.rb 2

Post Audit Vault Server and Agents upgrade, run the following command as root user:

/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level 4

Run the following command post upgrade, if it is only displayed on the prompt:

/usr/local/dbfw/bin/priv/send_agent_update_signal.sh

Refer to Oracle AVDF Installation Guide, sections "Pre-upgrade RPM Legacy Crypto Check Warning" and "Post Upgrade TLS Security Hardening" for more details.

Upgrading from Oracle AVDF 12.2.0.12.0 and Later

If you have deployed Audit Vault Agents on AIX in your environment, TLS 1.1 should be used for encryption instead of the default version of TLS 1.2. Else, the Agents on AIX will not upgrade automatically. If you wish to use TLS 1.1 for encryption run the below command before proceeding with the upgrade.

ruby /usr/local/dbfw/bin/upgrade/configure_tls_settings.rb 2

Post Audit Vault Server and Agents upgrade, run the following command as root user:

/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level 4

Run the following command post upgrade, if it is only displayed on the prompt:

/usr/local/dbfw/bin/priv/send_agent_update_signal.sh

Refer to Oracle AVDF Installation Guide, sections "Pre-upgrade RPM Legacy Crypto Check Warning" and "Post Upgrade TLS Security Hardening" for more details.

See Also:

Post Upgrade TLS Security Hardening

5.2.4 Pre-upgrade RPM Alert Queue Space Check Warning

Learn how to check for insufficient space warning in purge queue before upgrade.

The pre-upgrade RPM performs necessary checks in the alert queue. This ensures the upgrade process does not fail due to lack of space.

The following error is observed when installing the pre-upgrade RPM:

The system does not have sufficient space to purge alert queue. Refer to Installation Guide on how to resolve this.

Follow these steps to resolve this issue:

Log in to the Audit Vault Server through SSH using the following command:
```
ssh support@<audit_vault_server_ip>
```
In case the deployment is in OCI (Oracle Cloud Infrastructure), then connect through SSH as OPC user.
Switch user to root:
```
su - root
```

Unlock avsys account by running the following commands:

```
su - dvaccountmanager
```
```
sqlplus /
```

alter user avsys identified by <password> account unlock;

```
exit
```
Exit back to root.

Switch user to oracle:
```
su - oracle
```
Connect as avsys user by running the following command:
```
sqlplus avsys/<password>
```

Run the following SQL query:

declare object_exist exception; pragma exception_init(object_exist, -24002); po dbms_aqadm.aq$_purge_options_t;
begin po.block := FALSE; dbms_aqadm.purge_queue_table('AVSYS.AV_ALERT_QT', NULL, po);
exception when object_exist then null; end;/

Exit and lock avsys user account. Refer to MOS note (Doc ID 2117211.1).

5.2.5 Release Existing Tablespaces That Are Retrieved Manually

Learn about releasing tablespaces retrieved manually.

Note:

This procedure is performed automatically if you are upgrading to Oracle AVDF 20.4 (or later).
Follow the steps in this topic if you are upgrading to Oracle AVDF release 20.3 (or earlier).

Release all the existing tablespaces that were retrieved manually before upgrading Oracle AVDF.

If the existing tablespaces are not released, then the pre-upgrade operation may fail resulting in an error. Or the index job creation may fail after upgrade because they cannot allocate space. The new indexes may also not be created after the upgrade.

To manually release the tablespaces follow this procedure:

Log in to the Audit Vault Server console as super administrator.
Navigate to Settings, and then to Archiving.
Click Retrieve.
You will find a list of tablespaces retrieved.
Select and release all the tablespaces.

5.2.6 Preserve File Customizations

Preserve customizations applied to configuration files before upgrade of Oracle AVDF to release 20.

The upgrade will erase all custom changes made to system configuration files. It is advisable to backup any required changes that is required to be transferred to the upgraded system. To preserve such rules:

In case you are upgrading from Oracle AVDF 12.2, there may be differences in configuration between OL6 and OL7 applications that prevent old configuration from working correctly on the upgraded system.
Create your own custom configuration file. See Oracle Linux documentation for details.
Move any rules to a custom configuration file before performing the upgrade process.
Synchronize the time between Database Firewall and Audit Vault Server. In case the system clocks for Database Firewall and the Audit Vault Server are not synchronized, then you may face a certificate error after the upgrade. After the upgrade, check the appliance diagnostics output to ensure that everything is marked OK in green. The diagnostic failures are marked FAILED in red.

See Also:

5.2.7 Pre-upgrade RPM Boot Device Greater than 2 TB

Learn how to address the issue for boot devices greater than 2 TB.

The pre-upgrade RPM performs necessary space checks for the boot device. In case the boot device is greater than 2 TB, then the upgrade process may fail. The boot device should be less than 2 TB before the upgrade process can begin.

Follow these steps in case the boot device is greater than 2 TB when upgrading the Audit Vault Server:

Stop all the trails and monitoring points.
Stop all Audit Vault Agents and shutdown all the Database Firewall servers.
Take a backup of the system.
Choose a server that has at least one hard disk which is less than 2 TB.
Install the same bundle patch version of Audit Vault Server in 12.2 release.
Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
Restore from the backup. Use the same IP and ensure the system is up.
Upgrade Audit Vault Server to release 20 using the documented upgrade process.

Follow these steps in case the boot device is greater than 2 TB when upgrading the Database Firewall added to the Audit Vault Server prior to release 12.2.0.1.0:

Log in to the Audit Vault Server console as administrator.
Click Reset Firewall to update all the settings from Database Firewall Server to the Audit Vault Server. This is applicable for all the Database Firewall instances added to the Audit Vault Server prior to release 12.2.0.1.0.
Choose a server that has at least one hard disk which is less than 2 TB.
Install the same bundle patch version of Database Firewall in 12.2 release.
Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
Configure the Database Firewall instance.
Log in to the Audit Vault Server console as an administrator. Specify the Audit Vault Server certificate and IP address on the new Database Firewall instance.
Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
The Status of the newly installed Database Firewall instance is Down with a red indicator. Click the name of the specific Database Firewall instance. The details of the specific Database Firewall instance is displayed on the main page.
Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
Check the status of this operation by navigating to the Jobs dialog. For this, click the Settings tab, and then click the System tab in the left navigation menu. Click the Jobs link under the Monitoring section.
The Jobs dialog contains a list of ongoing jobs. The Job Type is Reset Firewall. Click the Job Details page icon in the extreme left. The Job Status Details dialog contains current status. If the job has failed, then an appropriate message is displayed. If the job is successful, then it displays the completion time.

Follow these steps in case there is insufficient space in the boot device while upgrading the Database Firewall which is on release 12.2.0.2.0 or later:

Choose a server that has at least one hard disk which is less than 2 TB.
Install the same bundle patch version of Database Firewall in 12.2 release.
Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
Log in to the Audit Vault Server console as administrator.
Configure the Database Firewall instance.
Log in to the Audit Vault Server console as an administrator. Specify the Audit Vault Server certificate and IP address on the new Database Firewall instance.
Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
The Status of the newly installed Database Firewall instance is Down with a red indicator. Click the name of the specific Database Firewall instance. The details of the specific Database Firewall instance is displayed on the main page.
Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
Check the status of this operation by navigating to the Jobs dialog. For this, click the Settings tab, and then click the System tab in the left navigation menu. Click the Jobs link under the Monitoring section.
The Jobs dialog contains a list of ongoing jobs. The Job Type is Reset Firewall. Click the Job Details page icon in the extreme left. The Job Status Details dialog contains current status. If the job has failed, then an appropriate message is displayed. If the job is successful, then it displays the completion time.

5.2.8 Pre-upgrade RPM Boot Partition Space Check Warning

Learn how to address boot partition space check warning.

The pre-upgrade RPM performs necessary space checks in the boot partition. In case there is not enough space in the boot partition, the upgrade process may fail. The boot partition should have at least 500 MB before the upgrade process can begin.

Follow these steps in case there is insufficient space in the boot partition while upgrading the Audit Vault Server:

Stop all the trails and monitoring points.
Stop all Audit Vault Agents and shutdown all the Database Firewall servers.
Take a backup of the system.
Install the same bundle patch version of Audit Vault Server in 12.2 release. This creates the /boot partition with 500 MB.
Restore from the backup. Use the same IP and ensure system is up.
Upgrade Audit Vault Server to release 20 using the documented upgrade process.

Follow these steps in case there is insufficient space in the boot partition while upgrading the Database Firewall instances added to the Audit Vault Server prior to release 12.2.0.1.0:

Log in to the Audit Vault Server console as administrator.
Click Reset Database Firewall to update all the settings on the Audit Vault Server.
Continue the upgrade process using the steps in the following block.

Follow these steps in case there is insufficient space in the boot partition while upgrading the Database Firewall:

Install the same bundle patch version of Database Firewall in 12.2 release. This creates the /boot partition with 500 MB.
Log in to the Audit Vault Server console as administrator.
Configure the Database Firewall instance.
Log in to the Audit Vault Server console as an administrator. Specify the Audit Vault Server certificate and IP address on the new Database Firewall instance.
Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
The Status of the newly installed Database Firewall instance is Down with a red indicator. Click the name of the specific Database Firewall instance. The details of the specific Database Firewall instance is displayed on the main page.
Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
Check the status of this operation by navigating to the Jobs dialog. For this, click the Settings tab, and then click the System tab in the left navigation menu. Click the Jobs link under the Monitoring section.
The Jobs dialog contains a list of ongoing jobs. The Job Type is Reset Firewall. Click the Job Details page icon in the extreme left. The Job Status Details dialog contains current status. If the job has failed, then an appropriate message is displayed. If the job is successful, then it displays the completion time.
Check the overall health status of the Database Firewall instance. Navigate back to the Database Firewalls tab, and click on the specific instance. Click Health Indicators link, under Diagnostics section.
Expand the Certificates block. There is a message pertaining to certificate validation failure in the list, and take appropriate action.
Expand the Database Firewall Monitoring section and ensure everything is green. Click the Close button in the bottom right corner of the dialog.

5.2.9 Tasks to be Noted When Upgrading the Target Database

Learn about tasks to be performed or noted when upgrading the target database.

Make a note of the following points when upgrading the target database:

In case the Database Firewall is deployed in Monitoring / Blocking (Proxy) mode, then stop the monitoring point of the target.
Ensure there is no change to the database listener ports.
If there is no change to the target database details like the IP address or host name, then upon completion of the target database upgrade, the traffic flows through the monitoring point as before. However, the monitoring point must be enabled.
Ensure to run the privilege script on the target database to grant privileges, after the database upgrade.

See Also:

5.3 Upgrade Tasks

Tasks for upgrading Oracle Audit Vault and Database Firewall.

5.3.1 Upgrade the Audit Vault Servers

You must upgrade the Audit Vault Server before you upgrade the Audit Vault Agents and Database Firewall.

Note:

If you have set up a high availability environment, upgrade both primary and standby Audit Vault Servers. Upgrade the standby Audit Vault Server first, then the primary instance.

5.3.1.1 Upgrading An Audit Vault Server

This procedure is for updating an Audit Vault Server that is not part of a pair of Audit Vault Servers configured for high availability (a resilient pair).

To upgrade an Audit Vault Server:

Make sure that all audit trails are stopped.
1. Click the Targets tab in the Audit Vault Server console.
2. Click Audit Trails tab in the left navigation menu.
3. Select all audit trails, and then click Stop.
Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the Audit Vault Server.

Upgrade Notes

If you have existing targets for which you ran Oracle Audit Vault and Database Firewall setup scripts to set user privileges (for example, for stored procedure auditing), no further action is required to update those privileges.
Password hashing has been upgraded to a more secure standard. This change affects the operating system passwords (support and root). Change your passwords after upgrade to take advantage of the more secure hash.

5.3.1.2 Upgrading A Pair Of Audit Vault Servers Configured For High Availability

Learn to upgrade a pair of Audit Vault Servers configured for high availability.

Note:

Do not change the primary and standby roles before completing the upgrade on both Audit Vault Servers.

Upgrade the standby Audit Vault Server first.

Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the standby (secondary).
After the standby Audit Vault Server is rebooted, ensure that it is up and running before proceeding to upgrade the primary Audit Vault Server.
Stop the audit trails before upgrading the primary Audit Vault Server.
1. Click the Targets tab in the Audit Vault Server console.
2. Click Audit Trails in the left navigation menu.
3. Select all audit trails, and then click Stop.
Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the primary.

Note:

After the primary Audit Vault Server is rebooted and is running, no additional reboot is needed. It is fully functional at this point.

5.3.2 Automatic Upgrade of Audit Vault Agents and Host Monitor Agents

The Audit Vault Agents and Host Monitor Agents are automatically upgraded when you upgrade the Audit Vault Server.

Note:

During the Audit Vault Agent auto-update process, its status will be UNREACHABLE for a while. It may take as much as 45 minutes to return to RUNNING state.
On Windows hosts, the Audit Vault Agent gets updated automatically only if you have registered it as a Windows service, and you have set this service to use the credentials of the OS user that originally installed the agent. See preinstall.html#GUID-5731D531-7846-44B8-B528-907ABC951098__GUID-492FA70C-002F-45D6-B37F-0552A8133DD0 for more information.

When you start the Agent from the command line, the Audit Vault Agent will not auto-update. In this case, update the Agent manually. For example:

<agent_home>\bin\agentctl.bat stop

Download the new agent.jar from the Audit Vault Server Console and extract it using java -jar agent.jar from agent_home of the existing agent. Then run:

<agent_home>\bin\agentctl.bat start

Do not delete the existing agent_home directory.
In a high availability environment if the Audit Vault Agents are deployed on the secondary Audit Vault Server before pairing, then manually update the previously deployed Audit Vault Agents pertaining to the secondary Audit Vault Server after pairing is complete.

5.3.3 Upgrade The Database Firewalls

You must first upgrade the Audit Vault Server (or high availability pair of servers), before following these instructions to upgrade all Database Firewalls.

When updating Database Firewalls configured for high availability (a resilient pair), upgrade both the primary and secondary Database Firewall.

Note:

After upgrading to Oracle AVDF 20.3 or later, the status of some of the Database Firewall monitoring points may be Down. The Database Firewall policies created before the upgrade are undergoing migration to the new format. This may take few minutes. Navigate to the Jobs dialog in the Audit Vault Server console and check the status of the job Firewall post-upgrade actions. In case the background job fails, then deploy the Database Firewall policy using the Audit Vault Server console only. Check if the status of the Database Firewall monitoring points has changed to Up. Else, start the monitoring point.

5.3.3.1 Upgrading A Database Firewall

This procedure is for updating a Database Firewall that is not part of a pair of Database Firewalls configured for high availability (a resilient pair).

To upgrade a Database Firewall:

Stop all the Database Firewall monitoring points.
1. Click Database Firewalls tab in the Audit Vault Server console.
2. Click Database Firewall Monitoring tab.
3. In the Database Firewall Monitoring section, select all the monitoring points.
4. Click Stop.
Follow the procedures in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the Database Firewall.

5.3.3.2 Upgrading A Pair Of Database Firewalls Configured For High Availability

Learn to upgrade a pair of Database Firewalls configured for high availability.

Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to first upgrade the standby (secondary) Database Firewall.
Ensure that the standby Database Firewall has been restarted.
After the standby Database Firewall has fully started up after the reboot, swap this Database Firewall so that it now becomes the primary Database Firewall. To do this:
1. In the Audit Vault Server console, click the Database Firewalls tab.
2. Click High Availability tab in the left navigation menu.
3. Select this resilient pair of Database Firewall instances, and click Swap.
  
  The Database Firewall you just upgraded is now the primary Database Firewall.
Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the original primary Database Firewall.
After the original primary Database Firewall has fully started up after the reboot, swap this Database Firewall so that it now becomes the primary Database Firewall. This is an optional step.

5.3.4 Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances

The steps to upgrade an Audit Vault Server appliance or a Database Firewall appliance are similar.

In the following steps, the term appliance refers to Audit Vault Server or Database Firewall depending on the one you are upgrading. Make sure you upgrade all the appliances as described in the sections above.

5.3.4.1 Install Oracle AVDF Pre-Upgrade RPM

Steps to install Oracle AVDF pre-upgrade RPM.

You must install the pre-upgrade RPM. It puts the system into a state that can be safely upgraded after it checks for suitable space on the file system. When the pre-upgrade RPM is installed, it re-arranges free space on the appliance so that there is enough room to copy the upgrade files to the appliance and start the installation. After the upgrade, the space for the upgrade files is given back to the file system.

The avdf-pre-upgrade-20.7.0.0.0.zip executable includes the upgrade prerequisites and also checks that the platform conditions are met prior to the upgrade.

The pre-upgrade RPM prepares the system for upgrade by creating the /var/dbfw/upgrade directory with enough space to hold the main upgrade ISO file.

Prerequisite

In case of high availability environment, before running the pre-upgrade RPM, check the failover status on the primary Audit Vault Server. The failover status should not be STALLED. If the failover status is STALLED, then wait for a while and check the status again. If the status is not changing, then contact Oracle Support.

Follow these steps to check the failover status on the primary Audit Vault Server:

Run the following command:

/usr/local/dbfw/bin/setup_ha.rb --status

Check the failover status in the output.

Run Pre-Upgrade RPM

Follow these steps to run the pre-upgrade RPM:

Verify the download at this point by using a shasum of the avdf-pre-upgrade-20.7.0.0.0.zip file.
Unzip the bundle using the command:
```
unzip avdf-pre-upgrade-20.7.0.0.0.zip
```
Log in to the appliance through SSH as support user.

In case the deployment is in OCI (Oracle Cloud Infrastructure), then connect through SSH as OPC user.
Switch user to root.
```
su - root
```
Run the screen command as user root.
Note:

Using the screen command prevents network disconnections interrupting the upgrade. If the session terminates, resume as follows:
- Connect as user support.
- Switch to user root.
- Run command
```
screen -r
```
Change directory using the command:
```
cd /root
```
Run the following command to copy only the pre-upgrade RPM file from the downloaded location to this appliance:
```
scp remote_host:/path/to/avdf-pre-upgrade-20.x.0.0.0-0_200707.2000.x86_64.rpm /root
```
Run the following command to install the avdf-pre-upgrade-20.x.0.0.0-0_200707.2000.x86_64.rpm:
```
rpm -i /root/avdf-pre-upgrade-20.x.0.0.0-0_200707.2000.x86_64.rpm
```
The following message appears:

SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.

The upgrade can then be started by running: /usr/bin/avdf-upgrade

To remove the RPM execute the following command as root user:

rpm -e avdf-pre-upgrade

Run the following command if there is an issue with uninstalling the pre-upgrade RPM:

rpm -e avdf-pre-upgrade --noscripts

Note:

In case the installation of the pre-upgrade RPM identifies any problem in your environment, then make a note of the remedial action displayed in the message. First, remove the pre-upgrade RPM by running the command rpm -e avdf-pre-upgrade as root user. After uninstalling the pre-upgrade RPM, perform the remedial action that was noted earlier from the message displayed. Upon taking the necessary measures, attempt the upgrade process again.

The following error may be observed while installing the pre-upgrade RPM:


BUSY:
The pre-upgrade process cannot continue because the following logical volumes are busy:
Volume: lv_tmp
Process: java
File(s): /tmp/XXX
Please stop the processes listed here before retrying:
java

Follow these steps to resolve this issue:

Run commands lsof(8) or fuser(1) to determine the processes using the device.
Stop these processes.
Confirm the volumes are released.
Attempt to uninstall and reinstall the pre-upgrade RPM.

5.3.4.2 Transfer the ISO File to the Appliance

Learn how to transfer the ISO file to the appliance.

The avdf-upgrade-20.7.0.0.0.iso file is the main upgrade ISO that you generated earlier by combining the three ISO files downloaded from My Oracle Support.

Log in to the appliance as support user.
Copy the avdf-upgrade-20.x.0.0.0.iso file as follows:

scp remote_host:/path/to/avdf-upgrade-20.x.0.0.0.iso /var/dbfw/upgrade

5.3.4.3 Start the Upgrade Script

The upgrade script mounts the ISO, changes to the correct working directory, executes the upgrade process, and then after the upgrade process is complete, unmounts the ISO.

Points to note before starting the upgrade

The system may take some time to complete the commands. Do not interrupt the upgrade, otherwise the system may be left in an inconsistent state.

For this reason it is important to use a reliable and uninterruptible shell, for example, a direct console login (or iLOM equivalent).

If you use a network (ssh) connection to upgrade the appliance, ensure the connection is reliable. You may also need to set the connection to keepalive. If you are using ssh from the Oracle Linux command line, you can use the ServerAliveInterval option, for example as follows:

# ssh -o ServerAliveInterval=20 [other ssh options]

Note:

Run the screen command as root user. Using the screen command prevents network disconnections interrupting the upgrade. If the session terminates, resume as follows:

Connect as support user.
Switch to root user.
Run command screen -r

Log in to the appliance through SSH as support user.

In case the deployment is in OCI (Oracle Cloud Infrastructure), then connect through SSH as OPC user.
Switch user (su) to root.

Note:
Run the screen command as user root. Using the screen command prevents network disconnections interrupting the upgrade. If the session terminates, resume by switching to user root and then run command screen -r.
Execute the following command to perform appropriate checks before the upgrade:

/usr/bin/avdf-upgrade

Follow the system prompt, warning, and instruction to proceed with the upgrade accordingly.

Output similar to the following appears:


Please wait while validating SHA256 checksum for /var/dbfw/upgrade/avdf-upgrade-20.7.0.0.0.iso
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.7.0.0.0.iso
Mounting /var/dbfw/upgrade/avdf-upgrade-20.7.0.0.0.iso on /images
mount: /dev/loop0 is write-protected, mounting read-only
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.7.0.0.0.iso on /images

The following messages have important information about the upgrade process.

Power loss during upgrade may cause data loss. Do not power
off during upgrade.

Please review Note ID 2235931.1 for a current list of known issues.

The upgrade process is irreversible, please confirm 'y' to continue or 'n' to abort. [y/N]?

Enter y to proceed. Output similar to the following is displayed:


The Oracle base has been set to /var/lib/oracle
Error: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Additional information: 4475
Additional information: 1990413931
The Oracle base has been set to /var/lib/oracle
Error: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Additional information: 4475
Additional information: 1990413931
Verifying upgrade preconditions
1/11: Mounting filesystems (1)
2/11: Cleaning yum configuration
3/11: Cleaning old packages and files
4/11: Upgrading kernel
5/11: Upgrading system
6/11: Cleaning platform packages repo
7/11: Adding required platform packages
8/11: Cleaning AVDF packages repo
9/11: Installing AVDF packages
10/11: Setting boot title
11/11: Setting final system status
Reboot now to continue the upgrade process.
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.7.0.0.0.iso on /images

Note:

The output above varies depending on the base installation level, the appliance type, and the configuration.

5.3.4.4 Restart the Appliance

Steps to reboot the appliance and continue the upgrade process.

To restart, perform the following steps:

Log in to the appliance through SSH as support user.

In case the deployment is in OCI (Oracle Cloud Infrastructure), then connect through SSH as OPC user.
Switch user (su) to root.
Restart the appliance. For example:

reboot

When the appliance restarts, the pre-database and post-database migrations are run automatically. This process also removes the avdf-pre-upgrade RPM, so you do not need to manually remove this file.

Note:
After restarting, the migration process can take several hours to complete. Please be patient. Do not restart the system while this is in progress.
If you have upgraded a Database Firewall, it may have regenerated the appliance certificate. In this scenario, you need to re-register the Database Firewall. To check this:
1. Log in to the Audit Vault Server console as an administrator.
2. Click the Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default. A list of configured Database Firewall instances is displayed on the page.
3. Select the specific Database Firewall instance that indicates a certificate error after the upgrade.
4. Click Reset Firewall button.

Note:

Make sure that you upgrade all the components as mentioned in these sections:

Once the upgrade is complete, perform the post-upgrade changes.

5.4 Post Upgrade Tasks

Post upgrade tasks for Oracle Audit Vault and Database Firewall (Oracle AVDF).

Note:

If you are upgrading Audit Vault Server to releases 20.1 to 20.3, then apply the patch (Deprecated-Cipher-Removal.zip) after upgrade.
If you are upgrading Audit Vault Server to release 20.4 and later, then apply the patch (Deprecated-Cipher-Removal.zip) only if you reduce the TLS level during upgrade.

These topics describe some important post upgrade changes:

5.4.1 Confirmation Of The Upgrade Process

Here are the symptoms that validate whether the upgrade was successful or not.

Use these symptoms to verify a successful upgrade.

Successful Upgrade of Audit Vault Server

The Audit Vault Server console can be launched without any issues.
Successful log in to Audit Vault Server console as administrator and auditor without any issues.
The home page of the Audit Vault Server console displays the correct version (Oracle Audit Vault and Database Firewall 20).
SSH connection to the Audit Vault Server is successful without any errors.
Check the following items:
1. Log in to the Audit Vault Server console as administrator.
2. Click Settings tab, and then click System in the left navigation menu.
3. Check the Uptime on the main page.
4. Check the status of Database Firewall log collection is up (green arrow pointing upwards).
5. Check the status of Background Job is up (green arrow pointing upwards).
6. Check the High Availability Status.

Successful Upgrade of Audit Vault Agents

Log in to the Audit Vault Server console as administrator.
Click Agents tab.
The main page contains a list of Audit Vault Agents. The status of the Agents must be RUNNING.
Check the version in the Agent Details column. It should indicate release 20.

Successful Upgrade of Database Firewall

Log in to the Audit Vault Server console as administrator.
Click Database Firewalls tab.
The main page contains a list of Database Firewall instances. The status must be Up.
The Version should indicate release 20.
Click on a specific Database Firewall instance under the Name field.
Click Health Indicators under the Diagnostics section. All the health indicators must have a green mark.
Exit the dialog. Click Database Firewall Monitoring tab in the left navigation menu.
Check the Status of all the monitoring points is Up.

Unsuccessful Upgrade

Symptoms when the upgrade has failed:

Unable to launch the Audit Vault Server console
SSH connection or the terminal to the Audit Vault Server displays an error that the upgrade has failed

5.4.2 Post Upgrade TLS Security Hardening

Learn how to manage TLS security hardening after upgrading to Oracle AVDF 20.4 (or later).

While upgrading to Oracle AVDF releases 20.4 (or later), if you had run the following command, then the upgrade process does not automatically set to Level-4. After the upgrade process is complete (including Agents), it is strongly advisable to set to Level-4.

ruby /usr/local/dbfw/bin/upgrade/configure_tls_settings.rb 2

Refer to the following sections for complete information:

5.4.3 Unable to Add Pre-upgrade SQL Clusters to New Cluster Sets After Upgrading to Oracle AVDF 20.1

Learn how to fix SQL cluster issue post upgrade to Oracle AVDF 20.1.

After upgrading to Oracle AVDF 20.1, the pre-existing SQL clusters from release 12.2 cannot be added to new cluster sets. This is encountered while create a new Database Firewall policy and when attempting to create a new SQL cluster set in release 20.1. To resolve this issue, run the populate_cluster_job.sql script immediately after upgrading to Oracle AVDF 20.1. This script resolves the issue in the event log table and the user can create cluster sets based on the clusters that were generated prior to 20.1 upgrade.

Note:

This issue is observed in Oracle AVDF 20.1 only. It is resolved in Oracle AVDF 20.2 (20 RU2).

Follow these steps to run the populate_cluster_job.sql script:

Download the populate_cluster_job.sql script from ARU or My Oracle Support.
The Database Firewall monitoring points or traffic need not be stopped. However, if the monitoring points and other traffic is stopped, then the script execution is faster.
The path is executed on the Audit Vault Server. Connect to the Audit Vault Server through SSH as support user.
Switch user to root:
```
su - root
```
Unlock the avsys user by following these steps:
1. You are connected to the Audit Vault Server through SSH as root user now.
2. Switch user to dvaccountmgr:
```
su - dvaccountmgr
```
3. Run SQL*Plus as:
```
sqlplus /nolog
```
4. Run the command:
```
alter user avsys identified by <passwd> account unlock;
```
5. Quit SQL*Plus:
```
exit
```
Run exit to connect back as root user.
Switch user to oracle:
```
su - oracle
```
Connect to the Audit Vault Server database as avsys user using SQL*Plus as follows:

sqlplus /nolog

connect avsys
Enter the password when prompted.

Execute the script using the following command:

@<file path of the populate_cluster_job.sql script>

The script runs in the background. The duration of the script execution is based on the traffic, and sometimes may take longer. Check the status of the job in the Audit Vault Server console as follows:
1. Log in to the Audit Vault Server console as administrator.
2. Click Settings tab, and then click the System tab in the left navigation menu.
3. Click Jobs.
4. Check the status of the job type Retrieve_clusters. In case the script has failed, repeat the steps and execute the script again.

5.4.4 Changing Bridge to Equivalent Proxy Configuration Post Upgrade to 20

Steps to be taken after upgrading to Oracle AVDF 20, if you have Database Firewall In-line Bridge mode deployed in release 12.2.

Database Firewall In-line bridge deployment mode is de-supported in Oracle AVDF 20. The deprecation notice was issued in 12.2. Follow these steps, after upgrading to 20, if you have Database Firewall In-line Bridge mode deployed in release 12.2.

Oracle Audit Vault and Database Firewall 20 requires configuration changes to maintain network separation originally provided by a traffic source (bridge). The order of the Network Interface Cards (NIC) and the components connected cannot be determined. If your current installation is 12.2, and has Database Firewall In-line bridge mode deployed, then certain measures have to be taken after upgrading to release 20.

Note:

A single proxy port is required for every target. A single proxy port cannot service multiple target databases. Add more traffic proxy ports as required.

This topic contains the necessary steps to change the configuration to an equivalent proxy mode.

Upgrade Prerequisites

Current Database Firewall is on 12.2 version
Database Firewall is currently deployed in monitoring (DAM) or blocking (DPE) mode with 1 or more traffic sources configured as a bridge

Execute the following steps after upgrading to release 20 in the following scenarios:

Only if you wish to maintain your existing network segmentation.
The interfaces are used for monitoring only.
The default bridge device is created or repurposed to create the monitoring point services.

After upgrade to 20, the network interface cards used have the original bridge configuration.
Log in to the Audit Vault Server console to check the current status of the Database Firewall network configuration.
From the available Database Firewall configuration information, the network connections of the two interfaces used by the traffic source are not known. Determine the information of the network segment and the interfaces plugged in, by using tools such as ping.
Find out the client side NIC among the two NICs and make a note. Ensure the device has a valid IP address and is up.

Note:
Ensure to add a valid proxy port for this interface. A default port number is created automatically.
Find out the database facing NIC among the two NICs and make a note. Ensure the device has a valid IP address and is up.
After collecting the required data and gaining fair amount of knowledge on the Database Firewall configuration, ping the target addresses from the database facing device.
Enable 1 NIC device at a time and attempt to the ping the target addresses from the appliance. If you cannot find any information on the first interface, then check on the second one. If the target addresses are not available, then try pinging the local gateway. This approach usually directs towards the clients.
Assuming that there are no other network changes made, the network mask remains the same.
After the NICs are enabled and the changes incorporated, the settings in the NET_SERVICE_MAP within the dbfw.conf file file is similar to the following:
```
NET_SERVICE_MAP="{"enp0s9":{"ip4":{"address":"192.0.2.21/24","gateway":"","enabled":true}},"enp0s10":{"ip4":{"address":"192.0.2.20/24","gateway":"","enabled":true}}}"
```
Routes are required so that the proxy can send the traffic between the clients and the database. Add the routes to the NET_SERVICE_MAP as follows:
```
NET_SERVICE_MAP="{"enp0s9":{"ip4":{"address":"192.0.2.21/24","gateway":"","enabled":true},'route':{'ip4route':['192.0.2.4/22 192.0.2.21',...]}},...}
```
The routing requires a general range for the clients as follows:
```
ip route add 192.0.2.21/24 via 192.0.2.20 dev enp0s10
```
The routing range for the targets is as follows:
```
ip route add 192.0.2.4 via 192.0.2.21 dev enp0s9
```
Run the following command to apply all the settings:
```
configure-networking
```
Test the client connectivity with the database.

See Also:
Configuring Oracle Database Firewall as a Traffic Proxy

5.4.5 Possible Changes Required for Existing Archive Locations

Learn about possible changes that may be required for existing archive locations.

After the upgrade, new behavior is enforced on archive locations. New archive locations are owned by the user with administrator role who created them.
The user with super administrator role can view all archive locations.

Existing archive locations can only be accessed by the user with super administrator role. In order for the regular user with administrator role to access these locations, you must do the following task for each archive location:

su - dvaccountmgr
sqlplus /
alter user avsys identified by <password> account unlock;
exit;
exit;
su - oracle
sqlplus avsys/<password>
update avsys.archive_host set created_by=<adminuser> where name=<archive location name>;
commit;
exit;
exit;
su - dvaccountmgr
sqlplus /
alter user avsys account lock;
exit;
exit;

5.4.6 Enable Archiving Functionality Post Upgrade

Enable archiving functionality post upgrade is required only if the Audit Vault Server is deployed in a high availability environment.

In case there are NFS locations and archived data files, ensure all the data files are available in the respective NFS locations. Upon completion of the upgrade process, archiving is disabled. User must follow the below steps to enable archiving.

Note:

Oracle AVDF 20.1 and later supports archive and retrieve functionality with Network File System (NFS) server which support both versions v3 and v4.
Only NFS version v3 is not supported for releases 20.3 and prior. It is supported starting Oracle AVDF release 20.4.
If your NFS server supports and permits both v3 and v4 for archive or retrieve, then no action is required.
In case you have NFS v4 only in your environment for archive or retrieve, then set the _SHOWMOUNT_DISABLED parameter to TRUE using the following steps:
1. Log in to the Audit Vault Server as root.
2. Switch to oracle user:
```
su - oracle
```
3. Start SQL*Plus connection as follows without the username or password:
```
sqlplus /nolog
```
4. In SQL*Plus run the command:
```
connect <super administrator>
```
5. Enter the password when prompted. Alternatively, run the command:
```
connect <super administrator/password>
```
6. Run the command:
```
exec avsys.adm.add_config_param('_SHOWMOUNT_DISABLED','TRUE');
```

Connect to the primary Audit Vault Server using SSH.
Switch to root user and then to oracle user by running the following commands:
```
su - root
```
```
su - oracle
```
Create new NFS locations using the Audit Vault Server console. These new locations created consider the newly mounted NFS points for both the primary and secondary Audit Vault Servers. Ensure there is sufficient space in the newly created NFS locations to store all the necessary data files archived.
Start SQL*Plus connection as follows without the username or password.
```
sqlplus /nolog
```
In SQL*Plus run the command:
```
connect super administrator
```
Enter the password when prompted. Alternatively, run the command:
```
connect super administrator/password
```
Enable the archiving functionality by running the following command:
```
exec management.ar.run_hailm_job('<NFS location name defined>');
```
This command initiates a background job. The status can be viewed under the Jobs page. The name of the job is HAILM POST UPGRADE JOB.
After this functionality is enabled, all the archived datafiles are moved to the new NFS location. Archiving is enabled after this job completes successfully.

5.4.7 Post Upgrade Actions to Clear Unused Kernels From Oracle Audit Vault and Database Firewall

See MOS note (Doc ID 2458154.1) for complete instructions to clear unused kernels from Oracle Audit Vault and Database Firewall (Oracle AVDF).

5.4.8 Check Observer Status After Upgrading to Oracle AVDF 20.7

Learn how to fix observer issue in a high availability environment after upgrading to Oracle AVDF release 20.7.

There is an issue observed in high availability environment after upgrading to Oracle AVDF release 20.7 (or later) from previous releases 20.5 and 20.6. Audit Vault Server internally uses Oracle Data Guard for managing high availability.

Follow these steps to check the status of Oracle Data Guard observer:

Connect to the standby Audit Vault Server through SSH as support user.

In case the deployment is in OCI (Oracle Cloud Infrastructure), then connect through SSH as OPC user.
Switch user to root:
```
su - root
```
Switch user to oracle:
```
su - oracle
```
Run the following commands:
```
dgmgrl /
```
```
show observer
```
The output displays the status and the last ping interval of both the observers running on the primary and standby Audit Vault Servers. In case output is similar to the following, then run the steps provided as resolution:
```
Host Name:                   <host name>
Last Ping to Primary:        (unknown)
Last Ping to Target:         (unknown)
```

Follow these steps to resolve this issue:

Connect to the standby Audit Vault Server through SSH as support user.
Switch user to root user:
```
su - root
```
Switch user to oracle user:
```
su - oracle
```
Run the following command:
```
/usr/local/dbfw/bin/observerctl --stop
```
Wait for a minute.
Run the following commands:
```
dgmgrl /
```
```
show observer
```
Check the output displayed. The last ping interval of both the observers must have a specific duration in seconds.

5.4.9 Configure Audit Vault Server Backup

Learn how to manage Audit Vault Server backup post upgrade.

Audit Vault Server backup configuration file is release specific. It works on the same release. It is advisable to run the avbackup config command and create a new configuration file before performing the backup operation after Oracle AVDF upgrade.

5.4.10 Scheduling Maintenance Jobs

Oracle AVDF runs some jobs on the Audit Vault Server for proper and effective functioning of the system.

Oracle recommends that you run these jobs during a period when the Audit Vault server usage is low, such as night. You can schedule these jobs as per your time zone.

Log in to the Audit Vault Server as an administrator.
Click Settings tab.
Click System tab in the left navigation menu.

In the Configuration section:

For Oracle AVDF Release

Click

20.1 and 20.2

Manage

20.3 and later

Maintenance

To schedule a new maintenance job, select Start Time. Enter the time in hours and minutes for the maintenance job to start at a specific time. The time specified here is the time on the browser.
In the Time Out (In hours) field, enter the duration of the maintenance job in hours.

Note:
In case the job does not complete within the duration specified, it is timed out.
In the Repeat Frequency field, select the frequency of the maintenance job to be repeated.

Note:
This field cannot be edited, and by default the value remains Daily. The job runs at the specified start time daily.
Click Save.

5.5 Recovering the Database in the Event of a Failed Upgrade

Always take back up Oracle Audit Vault and Database Firewall before upgrading in case the upgrade fails for an unforeseen reason.

If there is enough space in the Audit Vault Server's flash recovery area, you may be able to recover the database after a failed upgrade under the guidance of Oracle Support.

As a rule of thumb, to make recovery of the database possible, you should have the following amount of free space in the flash recovery area:

20 GB or 150% of the amount of data stored in the Audit Vault Server database, whichever is larger.

See Also:

Back Up The Current Oracle Audit Vault And Database Firewall Installation
Oracle Audit Vault and Database Firewall Administrator's Guide for information on monitoring the flash recovery area.