1. Installation Guide
  2. 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 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.

  1. Go to My Oracle Support and sign in.

  2. Click the Patches & Updates tab.

  3. 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.

  4. In the search results page, in the Patch Name column, click the number for the latest Bundle Patch.

    A corresponding patch page appears.

  5. Click Readme to access the README file, which has the upgrade instructions.

  6. Follow the instructions in the README file to complete the upgrade.

Parent topic: Upgrading Oracle Audit Vault and Database Firewall

5.2 Pre-upgrade Tasks

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

Parent topic: Upgrading Oracle Audit Vault and Database Firewall

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 20.1.

Complete the steps in the following sections:

Parent topic: Pre-upgrade Tasks

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.

Parent topic: Pre-upgrade Tasks

5.2.3 Release Existing Tablespaces That Are Retrieved Manually

Learn about releasing tablespaces retrieved manually.

Release all the existing tablespaces that were retrieved manually before upgrading Oracle Audit Vault and Database Firewall.

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 release the tablespaces follow this procedure:

  1. Log in to the Audit Vault Server console as super administrator.

  2. Navigate to Settings, and then to Archiving.

  3. Click Retrieve.

  4. You will find a list of tablespaces retrieved.

  5. Select and release all the tablespaces.

Parent topic: Pre-upgrade Tasks

5.2.4 Preserve File Customizations

Preserve customizations applied to configuration files before upgrade of Oracle Audit Vault and Database Firewall to 20.1.

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:

  • 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:

Parent topic: Pre-upgrade Tasks

5.2.5 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:

  1. Stop all the trails and monitoring points.
  2. Stop all Audit Vault Agents and shutdown all the Database Firewall servers.
  3. Take a backup of the system.
  4. Choose a server that has at least one hard disk which is less than 2 TB.
  5. Install the same bundle patch version of Audit Vault Server in 12.2 release.
  6. Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
  7. Restore from the backup. Use the same IP and ensure the system is up.
  8. Upgrade Audit Vault Server to release 20.1 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:

  1. Log in to the Audit Vault Server console as administrator.
  2. Click Reset Database 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.
  3. Choose a server that has at least one hard disk which is less than 2 TB.
  4. Install the same bundle patch version of Database Firewall in 12.2 release.
  5. Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
  6. Configure the Database Firewall instance.
  7. 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.
  8. Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
  9. 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.
  10. Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
  11. Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
  12. 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.
  13. 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:

  1. Choose a server that has at least one hard disk which is less than 2 TB.
  2. Install the same bundle patch version of Database Firewall in 12.2 release.
  3. Configure the system to boot in BIOS mode. For most of the servers this is the default setting.
  4. Log in to the Audit Vault Server console as administrator.
  5. Configure the Database Firewall instance.
  6. 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.
  7. Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
  8. 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.
  9. Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
  10. Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
  11. 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.
  12. 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.

Parent topic: Pre-upgrade Tasks

5.2.6 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:

  1. Stop all the trails and monitoring points.
  2. Stop all Audit Vault Agents and shutdown all the Database Firewall servers.
  3. Take a backup of the system.
  4. Install the same bundle patch version of Audit Vault Server in 12.2 release. This creates the /boot partition with 500 MB.
  5. Restore from the backup. Use the same IP and ensure system is up.
  6. Upgrade Audit Vault Server to release 20.1 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:

  1. Log in to the Audit Vault Server console as administrator.
  2. Click Reset Database Firewall to update all the settings on the Audit Vault Server.
  3. 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:

  1. Install the same bundle patch version of Database Firewall in 12.2 release. This creates the /boot partition with 500 MB.
  2. Log in to the Audit Vault Server console as administrator.
  3. Configure the Database Firewall instance.
  4. 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.
  5. Click on Database Firewalls tab. A list of Database Firewall instances configured are displayed on the main page.
  6. 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.
  7. Click Update Certificate button, and wait for the page to load. The status of the Database Firewall instance is Up or green.
  8. Click Reset Firewall button. Confirm the operation by selecting OK in the dialog.
  9. 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.
  10. 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.
  11. 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.
  12. Expand the Certificates block. There is a message pertaining to certificate validation failure in the list, and take appropriate action.
  13. Expand the Database Firewall Monitoring section and ensure everything is green. Click the Close button in the bottom right corner of the dialog.

Parent topic: Pre-upgrade Tasks

5.3 Upgrade Tasks

Tasks for upgrading Oracle Audit Vault and Database Firewall.

Parent topic: 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.

If you have set up a high availability environment, upgrade both your primary and standby Audit Vault Server.

Parent topic: Upgrade Tasks

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:

  1. 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.

  2. 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.

  1. 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).

  2. After the standby Audit Vault Server is rebooted, ensure that it is up and running before proceeding to upgrade the primary Audit Vault Server.

  3. 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.

  4. 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 The Audit Vault Agents And Host Monitors

The Agents and Host Monitors 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.

    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.

Parent topic: Upgrade Tasks

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.

Parent topic: Upgrade Tasks

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:

  1. 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.

  2. 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.

  1. Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to first upgrade the standby (secondary) Database Firewall.

  2. Ensure that the standby Database Firewall has been restarted.

  3. 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.

  4. Follow the steps in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the original primary Database Firewall.

  5. 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.

Parent topic: Upgrade Tasks

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.1.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:

  1. Log in to the primary Audit Vault Server console as oracle user.

  2. Run the following command:

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

  3. Check the failover status in the output.

Run Pre-Upgrade RPM

Follow these steps to run the pre-upgrade RPM:

  1. Verify the download at this point by using a shasum of the avdf-pre-upgrade-20.1.0.0.0.zip file.

  2. Unzip the bundle using the command:

    unzip avdf-pre-upgrade-20.1.0.0.0.zip

  3. Log in to the appliance through SSH as user support, and then 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

  4. Change directory using the command:

    cd /root

  5. 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.1.0.0.0-0_200707.2000.x86_64.rpm /root

  6. Run the following command to install the avdf-pre-upgrade-20.1.0.0.0-0_200707.2000.x86_64.rpm: 

    rpm -i /root/avdf-pre-upgrade-20.1.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:

  1. Run commands lsof(8) or fuser(1) to determine the processes using the device.
  2. Stop these processes.
  3. Confirm the volumes are released.
  4. Attempt to uninstall and reinstall the pre-upgrade RPM.
5.3.4.2 Transfer The ISO File To The Appliance

Steps to transfer the ISO file to the appliance.

The avdf-upgrade-20.1.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.

  1. Log in to the appliance as user support.

  2. Copy the avdf-upgrade-20.1.0.0.0.iso file as follows:

    scp remote_host:/path/to/avdf-upgrade-20.1.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 user root. Using the screen command prevents network disconnections interrupting the upgrade. If the session terminates, resume as follows:

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

  1. Log in to the appliance through SSH as user support, and then 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.

  2. Execute the following command to perform appropriate checks before the upgrade:

    /usr/bin/avdf-upgrade

  3. 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.1.0.0.0.iso
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.1.0.0.0.iso
Mounting /var/dbfw/upgrade/avdf-upgrade-20.1.0.0.0.iso on /images
mount: /var/dbfw/upgrade/avdf-upgrade-20.1.0.0.0.iso is write-protected, mounting read-only
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.1.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.

This upgrade will erase /root and /images.

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 ab
ort. [y/n]?

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

    
Verifying upgrade preconditions
1/27: Allocating space for upgrade (simulation)
2/27: Ensuring sufficient space on oracle filesystem (simulation)
3/27: Applying LVM adjustments (simulation)
4/27: Mounting filesystems (1)
5/27: Allocating space for upgrade
  Rounding up size to full physical extent 6.22 GiB
  Logical volume "lv_ol7root" created.
mke2fs 1.43-WIP (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
408000 inodes, 1630208 blocks
81510 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1669332992
50 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

6/27: Mounting new install root
7/27: Extracting minimal root filesystem
8/27: Mounting required filesystems (2)
9/27: Mounting required filesystems (3)
10/27: Creating mountpoints for ASM
11/27: Populating new root filesystem
12/27: Adding required platform packages
13/27: Upgrading packages in new root filesystem
14/27: Ensuring sufficient space on oracle filesystem
15/27: Migrating system history
16/27: Installing AVDF packages
17/27: Migrating configuration
18/27: Creating mountpoints for NFS
19/27: Installing systemd upgrade units
20/27: Applying LVM adjustments
21/27: Disable SELinux
22/27: Migrating fstab
23/27: Migrating grub
24/27: Migrating old root log files
25/27: Setting final system status
26/27: Unmounting
27/27: Migrating old network log files
Reboot now to continue the upgrade process.
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.1.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:

  1. Log in to the appliance through SSH as user support, and then switch user (su) to root.

  2. 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.

  3. 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 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.

See Also:

Registering a Database Firewall in the Audit Vault Server

Note:

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

  1. Upgrade The Audit Vault Servers

  2. Automatic Upgrade Of The Audit Vault Agents And Host Monitors

  3. Upgrade The Database Firewalls

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:

Apply the patch to remove deprecated ciphers post AVS install or upgrade: Deprecated-Cipher-Removal.zip. Apply this patch on Oracle Audit Vault Server 20.1 after install or upgrade. In case of upgrade, before applying the patch, make sure that all Audit vault Agents are upgraded to 20.1 and Host Monitor Agents are in Installed state.

See Also:

Unable to Log in to the Oracle AVDF Appliance through SSH

These topics describe some important post upgrade changes:

Parent topic: Upgrading Oracle Audit Vault and Database Firewall

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

  1. The Audit Vault Server console can be launched without any issues.
  2. Successful log in to Audit Vault Server console as administrator and auditor without any issues.
  3. The home page of the Audit Vault Server console displays the correct version (Oracle Audit Vault and Database Firewall 20).
  4. SSH connection to the Audit Vault Server is successful without any errors.

  5. 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

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

Successful Upgrade of Database Firewall

  1. Log in to the Audit Vault Server console as administrator.
  2. Click Database Firewalls tab.
  3. The main page contains a list of Database Firewall instances. The status must be Up.
  4. The Version should indicate release 20.
  5. Click on a specific Database Firewall instance under the Name field.
  6. Click Health Indicators under the Diagnostics section. All the health indicators must have a green mark.
  7. Exit the dialog. Click Database Firewall Monitoring tab in the left navigation menu.
  8. 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

Parent topic: Post Upgrade Tasks

5.4.2 Unable to Add Pre-upgrade SQL Clusters to New Cluster Sets After Upgrading to 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:

  1. Download the populate_cluster_job.sql script from ARU or My Oracle Support.
  2. 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.
  3. The path is executed on the Audit Vault Server. Connect to the Audit Vault Server through SSH as support user.
  4. Switch user to root: su - root
  5. 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 sqlplus /
    4. Execute the command: alter user avsys identified by <passwd> account unlock;
    5. Run exit to quit SQL*Plus.
  6. Run exit to connect back as root user.
  7. Switch user to oracle: su - oracle
  8. Connect to the Audit Vault Server database as avsys user using SQL*Plus as follows:

    sqlplus /nolog

    connect avsys

  9. Enter the password when prompted.
  10. Execute the script using the following command:

    @<file path of the populate_cluster_job.sql script>

  11. 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.

Parent topic: Post Upgrade Tasks

5.4.3 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.
  1. After upgrade to 20, the network interface cards used have the original bridge configuration.
  2. Log in to the Audit Vault Server console to check the current status of the Database Firewall network configuration.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Assuming that there are no other network changes made, the network mask remains the same.
  9. 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}}}"
  10. 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

  11. Run the following command to apply all the settings:
    configure-networking
  12. Test the client connectivity with the database.

Parent topic: Post Upgrade Tasks

5.4.4 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:

    Log in to Audit Vault Server as root OS user, then perform the following commands: 

    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;

Parent topic: Post Upgrade Tasks

5.4.5 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 Network File System (NFS) versions v3 and v4 for archive or retrieve functionality.

  • NFS v3 only is not supported.

  • 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 user to oracle: su - oracle
    3. Start SQL*Plus connection as sqlplus /nolog without the username or password.
    4. In SQL*Plus execute the command: connect <super administrator>
    5. Enter the password when prompted. Alternatively, execute the command: connect <super administrator/password>
    6. Execute the command: exec avsys.adm.add_config_param('_SHOWMOUNT_DISABLED','TRUE');
  1. Connect to the primary Audit Vault Server using SSH.
  2. Switch to root user and then to oracle user by executing the following commands:

    su - root

    su - oracle

  3. 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.
  4. Start SQL*Plus connection as sqlplus /nolog without the username or password.
  5. In SQL*Plus execute the command: connect super administrator
  6. Enter the password when prompted. Alternatively, execute the command: connect super administrator/password
  7. Enable the archiving functionality by executing the following command:

    exec management.ar.run_hailm_job('<NFS location name defined>');

    This command triggers a back ground job. The status can be viewed under the Jobs page. The name of the job is HAILM POST UPGRADE JOB.

  8. Once this functionality is enabled, all the archived data files are moved to the new NFS location. Archiving is enabled once this job completes successfully.

Parent topic: Post Upgrade Tasks

5.4.6 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).

Parent topic: Post Upgrade Tasks

5.4.7 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.
  1. Log in to the Audit Vault Server as an administrator.
  2. Click Settings tab.
  3. Click System tab in the left navigation menu.
  4. In the Configuration section:
  5. 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.
  6. 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.
  7. 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.
  8. Click Save.

Parent topic: Post Upgrade Tasks

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:

Parent topic: Upgrading Oracle Audit Vault and Database Firewall