6 Upgrading Oracle Audit Vault and Database Firewall

This chapter provides information on upgrades and Bundle Patch updates and how to upgrade from the previous release of Oracle Audit Vault and Database Firewall.

Note:

Upgrade to Oracle AVDF 20 at the earliest as premier support for release 12.2 ends in March 2021, as specified in the Oracle Lifetime Support Policy Guide. Refer to Oracle AVDF 20 Installation Guide > Chapter 5 Upgrading Oracle Audit Vault and Database Firewall for complete information.

6.1 Upgrading Oracle Audit Vault and Database Firewall

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

Caution:

Oracle Audit Vault and Database Firewall release 12.2.0.11.0 does not support Niagara cards. Do not upgrade to this release if you have Niagara cards in your system.

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

Note:

  • You must first take backup prior to performing any upgrade.

  • Oracle Audit Vault and Database Firewall versions 12.2.0.0.0 and above must first upgrade to 12.2.0.9.0, and then to the latest version in release 12.2.

  • Oracle Audit Vault and Database Firewall versions 12.1.2.7.0 and above in 12.1.x series must first upgrade to 12.2.0.8.0, then to 12.2.0.9.0, and then to the latest version in release 12.2. Follow the instructions in section Mandatory Pre-upgrade Patch for upgrading to 12.2.0.9.0.

  • Oracle Audit Vault and Database Firewall versions prior to 12.1.2.7.0 must first upgrade to 12.2.0.2.0, then to 12.2.0.9.0, and then subsequently to the latest version in release 12.2.

  • 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. The Niagara drivers built for UEK 3 that is shipped with previous versions of Audit Vault and Database Firewall are not compatible with UEK 4 and Audit Vault and Database Firewall 12.2.0.4.0. This leads to failure of the upgrade and subsequent boots of the system.

  • 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 to find the patch.

    The following image is an example only:

    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.

6.2 Pre-upgrade Tasks

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

6.2.1 Host Monitor Migration on Windows

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

Complete the steps in the following sections:

6.2.2 Mandatory Pre-upgrade Patch

Install a mandatory pre-upgrade patch before upgrading to Oracle Audit Vault and Database Firewall (Oracle AVDF) release 12.2.0.9.0.

Before upgrading to Oracle AVDF release 12.2.0.9.0, apply the Mandatory AVDF BP9 Pre-upgrade Patch (Doc ID 2457374.1) (bug_28581135_agentpatch.zip).

Note:

  • This pre-upgrade patch must be executed only if you are upgrading to Oracle Audit Vault and Database Firewall release 12.2.0.9.0 from any release between 12.2.0.0.0 and 12.2.0.8.0.

  • This pre-upgrade patch is not applicable if you are upgrading to Oracle Audit Vault and Database Firewall release 12.2.0.10.0 or above from release 12.2.0.9.0.

  • This patch must be executed only if all the hosts on which your Audit Vault Agents are running, have Java version 1.8. If you have hosts which have Java version 1.6, then update those hosts to Java 1.8 before installing this patch.

  • In case of High Availability configuration of Audit Vault Server this Pre-upgrade Agent Patch has to be applied only on the primary Audit Vault Server.

  • For deploying Audit Vault Agent on IBM AIX, ensure OpenSSL 64-bit version 1.0.1 (or later) is installed.

  • Host Monitor requires OpenSSL 64-bit version 1.0.1 (or later), on the target machine.

Requirements

Note:

  • This patch is located in the zip files extracted in section Instructions To Apply This Bundle Patch.

  • If you do not meet the above mentioned requirements, or in case you are not certain that you meet these requirements, log a Service Request and contact Oracle support.

  • Ensure that all Agents are running when this patch is applied.

  • Stopped Agents are not updated with this patch.

To apply the patch:

  1. Make sure that all the audit trails are stopped.
    1. Click Secured Targets tab in the Audit Vault Server console.

    2. In the Monitoring menu, click Audit Trails.

    3. Select all the audit trails, and then click Stop.

  2. Log in to the Audit Vault Server as support user.
  3. Switch to root user using the command:

    su root

  4. Copy the patch file bug_28581135_agentpatch.zip to the /var/lib/oracle/dbfw/patch directory of the Audit Vault Server and extract the zip file using the command:

    unzip bug_28581135_agentpatch.zip -d BUG_28581135_AgentPatch

  5. Change directory by executing the following command:

    cd /var/lib/oracle/dbfw/patch/BUG_28581135_AgentPatch

  6. Apply the patch by the using the command:

    ./applyAgentPatch.sh

  7. Once the AgentPatch.sh file is successfully executed, all the running Audit Vault Agents with Java version 1.8 are upgraded automatically with the patch and restarted.
  8. Check for errors in the /var/log/messages file with tag com.oracle.preBP9UpgradeAgentPatch.applyAgentPatch. In case there are any errors, then contact Oracle Support.

    Note:

    • The application of AgentPatch.sh creates a backup of old Agents and plug-ins in the following directories:

      • /var/lib/oracle/dbfw/patch/BUG_28581135_AgentPatch/backup

      • /var/lib/oracle/dbfw/patch/BUG_28581135_AgentPatch/agentjarbackup

    • Preserve this directory in the same location as this is required in case patch needs to be reverted.

    • This pre-upgrade patch is distributed and applied to all running Audit Vault Agents. The user must allow 24 hours for all Agents to update before applying the 12.2.0.9.0 bundle patch upgrade.

    • Check the status of the patch to ensure that all Audit Vault Agents are upgraded before continuing with 12.2.0.9.0 bundle patch upgrade.

6.2.2.1 Checking The Patch Application Status

To check the patch application status, complete an update of the Audit Vault agents.

  1. Log in to the Audit Vault Server as support user.
  2. Switch to root user using the command:
    su root
  3. Change directory by executing the following command:
    cd /var/lib/oracle/dbfw/patch/BUG_28581135_AgentPatch
  4. Execute the following command:
    ./getAgentUpdateStatus.sh
  5. This displays the list of all the Agents that have been updated and that have not been updated with the patch.
  6. The update of all Agents may take up to 24 hours. You can periodically run getAgentUpdateStatus.sh command to get the status update of the Agents.
  7. After 24 hours, you can start the audit trails that were stopped earlier using the Audit Vault Server console as admin user.
  8. Even after 24 hours, there may be some Agents that are not updated. You need to update them manually using steps below.

    Note:

    See Applying The Agent Patch Manually On Individual Agents for complete instructions.
  9. Log in to each non updated host.
  10. Ensure that the Java version on the Agent host is updated to version 1.8.
  11. Follow the instructions in Applying The Agent Patch Manually On Individual Agents. If you have any problems installing this patch, or you are not sure about the inventory setup, then contact Oracle Support.

6.2.2.2 Removing The Pre-upgrade Patch On The Audit Vault Server

Steps to remove the pre-upgrade patch on the Audit Vault Server.

To remove the pre-upgrade patch:

  1. Make sure that all the audit trails are stopped.
  2. Click Secured Targets tab in the Audit Vault Server console.
  3. In the Monitoring menu, click Audit Trails.
  4. Select all the audit trails, and then click Stop.
  5. Log in to the Audit Vault Server as support user.
  6. Switch to root user using the command:

    su root

  7. Change directory by executing the following command:

    cd /var/lib/oracle/dbfw/patch/BUG_28581135_AgentPatch

  8. Execute the following command to revert the patch application:

    ./revertAgentPatch.sh

  9. After successful execution of the revert patch application process, all the running hosts with Java 1.8 are reverted with original binaries and are restarted.
  10. Check for errors in the /var/log/messages file with tag com.oracle.preBP9UpgradeAgentPatch.applyAgentPatch. In case there are any errors, then contact Oracle Support.
  11. After 24 hours, you can start the audit trails that were stopped earlier using the Audit Vault Server console as admin user.

6.2.2.3 Applying The Agent Patch Manually On Individual Agents

Steps to download and manually apply the Agent patch on individual Agents.

Steps To Download The Patch

In case the Mandatory Pre-upgrade Patch has failed to upgrade one or more Audit Vault Agents, then use this procedure to apply the Agent patch manually on each Audit Vault Agent.

  1. Go to https://support.oracle.com, sign in, and click the Patches & Updates tab.

  2. In the Patch Search box type bug 28581683.

  3. From the search results, choose PRE BP9 PATCH FOR MANUALLY UPDATING AGENT (Patch 28581683).

  4. Click README and follow the instructions in the file.

Steps To Apply The Patch

  1. Log in to the Audit Vault Agent host.
  2. Stop the Agent using the command:

    <AGENT_HOME>/bin/agentctl stop -force

  3. Copy the patch file p28581683_122000_Generic.zip and extract the zip file using the command:

    unzip p28581683_122000_Generic.zip -d BUG_28581683_ManualAgentPatch

  4. Create a backup of the file <AGENT_HOME>/bin/agentctl using the command:

    mv <AGENT_HOME>/bin/agentctl <BACKUP_LOCATION>/agentctl

  5. Create a backup of the file <AGENT_HOME>/bin/agentctl.bat using the command:

    mv <AGENT_HOME>/bin/agentctl.bat <BACKUP_LOCATION>/agentctl.bat

  6. Create a backup of the file <AGENT_HOME>/av/jlib/dep_jre7/ojdbc7.jar using the command:

    mv <AGENT_HOME>/av/jlib/dep_jre7/ojdbc7.jar <BACKUP_LOCATION>/ojdbc7.jar

  7. Copy the patch agentctl file to <AGENT_HOME>/bin using the command:

    cp -f BUG_28581683_ManualAgentPatch/agentctl <AGENT_HOME>/bin

  8. Copy the patch agentctl.bat to <AGENT_HOME>/bin using the command:

    cp -f BUG_28581683_ManualAgentPatch/agentctl.bat <AGENT_HOME>/bin

  9. Copy the patch ojdbc7.jar to <AGENT_HOME>/bin using the command:

    cp -f BUG_28581683_ManualAgentPatch/ojdbc7.jar <AGENT_HOME>/av/jlib/dep_jre7

  10. Start the Agent using the command:

    <AGENT_HOME>/bin/agentctl start

  11. Log in to the Audit Vault Server console as admin user and check the status of audit trails running on this Agent machine. If the audit trail is not running, then contact Oracle Support.

6.2.2.4 Undo Manual Application Of The Agent Patch

Steps to undo the manual application of the Agent patch.

  1. Log in to the Audit Vault Agent host.
  2. Stop the Agent using the command:

    <AGENT_HOME>/bin/agentctl stop -force

  3. Copy agentctl from the backup location to <AGENT_HOME>/bin using the command:

    cp -f <BACKUP_LOCATION>/agentctl <AGENT_HOME>/bin

  4. Copy agentctl.bat from the backup location to <AGENT_HOME>/bin using the command:

    cp -f <BACKUP_LOCATION>/agentctl.bat <AGENT_HOME>/bin

  5. Copy ojdbc7.jar from the backup location to <AGENT_HOME>/av/jlib/dep_jre7 using the command:

    cp -f <BACKUP_LOCATION>/ojdbc7.jar <AGENT_HOME>/av/jlib/dep_jre7

  6. Start the Agent using the command:
    <AGENT_HOME>/bin/agentctl start

    Note:

    If you have any problems executing these instructions, then contact Oracle Support.

6.2.3 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 some Audit Vault Server and Audit Vault Agent components.

You must back up the following components:

  • The Audit Vault Server database

  • The Audit Vault Server appliance

  • The Audit Vault Agent home directory

Note:

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.

6.2.4 Release Existing Tablespaces That Are Retrieved Manually

Learn about releasing tablespaces retrieved manually.

Release all the existing tablespaces that were retrieved manually before performing the Oracle Audit Vault and Database Firewall (Oracle AVDF) upgrade process. Else, 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.

6.2.5 Preserve Customization In Log Rotate File

Preserve customizations applied to the log rotate configuration files during upgrade of Oracle Audit Vault and Database Firewall (Oracle AVDF).

Any customization applied to the log rotate configuration files may be lost during upgrade. To preserve such rules:

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

6.2.6 Check For Busy Devices Before Starting The Upgrade Process

Check for any busy devices before starting the Oracle Audit Vault and Database Firewall (Oracle AVDF) upgrade process.

The upgrade may not check for busy volumes and may result in an error later.

Run lsof against /tmp and /usr/local/dbfw/tmp to discover any open temporary files. Ensure that no logs are open when starting the upgrade process.

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.

6.3 Upgrade Tasks

Tasks for upgrading Oracle Audit Vault and Database Firewall.

6.3.1 Upgrade The Audit Vault Server (Standalone) Or Server Pair (High Availability)

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.

6.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 Secured Targets tab in the Audit Vault Server console.

    2. In the Monitoring menu, click Audit Trails.

    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 secured 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 in versions 12.1.2.x and later. This change affects the operating system passwords (support and root). Change your passwords after upgrade to take advantage of the more secure hash.

6.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 Secured Targets tab in the Audit Vault Server console.

    2. In the Monitoring menu, click Audit Trails.

    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.

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

  • If any Agent is using Java 1.6, then upgrade the Java version to 1.8. This action ensures the following:

    • Establishes communication between the Audit Vault Server and the Agents.

    • Auto upgrade of Agents to release 12.2.0.9.0.

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

6.3.3 Upgrade The Database Firewall Or Firewall Pair

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.

6.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 enforcement points.

    1. Click Secured Targets tab in the Audit Vault Server console.

    2. In the Monitoring menu, click Enforcement Points.

    3. Select all the enforcement points, and then click Stop.

  2. Follow the procedures in Steps To Upgrade Oracle Audit Vault And Database Firewall Appliances to upgrade the Database Firewall.

6.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 Firewalls tab.

    2. Click Resilient Pairs.

    3. Select this resilient pair of firewalls, and click Swap.

      The Database Firewall you just upgraded is now the primary 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.

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

6.3.4.1 Install The Oracle Audit Vault And Database Firewall Pre-Upgrade RPM

Steps to install the Oracle Audit Vault and Database Firewall (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-12.2.0.10.0-1.x86_64.rpm executable includes the upgrade prerequisites and also checks that the platform conditions are met prior to the installation.

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

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

    If you are upgrading from release 12.2.0.5.0 or later, then 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 support.

    • Switch to user root.

    • Run command screen -r

  2. Run the following command to copy the avdf-pre-upgrade-12.2.0.10.0-1.x86_64.rpm executable from the download location to this appliance:

    scp remote_host:/path/to/avdf-pre-upgrade-12.2.0.10.0-1.x86_64.rpm /root

  3. Run the following command to install the avdf-pre-upgrade-12.2.0.10.0-1.x86_64.rpm executable:

    rpm -i /root/avdf-pre-upgrade-12.2.0.10.0-1.x86_64.rpm

    The following message should appear:

    SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.
    
    The upgrade can then be started by running:  /usr/bin/avdf-upgrade

Note:

In case the installation of the pre-upgrade RPM fails, take the remedial action described in the error message displayed. The appliance may not be ready for installation or the pre-upgrade RPM may have detected a problem. Upon taking the necessary measures, remove the pre-upgrade RPM and attempt installation again.

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

rpm -e avdf-pre-upgrade

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

rpm -e avdf-pre-upgrade --noscripts

6.3.4.2 Transfer The ISO File To The Appliance

Steps to transfer the ISO file to the appliance.

The avdf-upgrade-12.2.0.10.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-12.2.0.10.0.iso file as follows:

    scp remote_host:/path/to/avdf-upgrade-12.2.0.10.0.iso /var/dbfw/upgrade

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

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

    Note:

    If you are upgrading from release 12.2.0.5.0 or later, then 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.

    Note:

    • For upgrade from Oracle Audit Vault and Database Firewall releases prior to 12.2, a data encryption keystore password is prompted as follows. This password prompt appears on primary and standalone systems, but not on standby systems.

      In Oracle Audit Vault and Database Firewall release 12.2, the repository is encrypted using Oracle Database Transparent Database Encryption (TDE). This password protects the master encryption key wallet for TDE. After the upgrade, you may choose to integrate Oracle Audit Vault and Database Firewall with Oracle Key Vault to further protect your encryption key.

    • The password must contain at least 8 characters and at most 30 bytes. It cannot have a leading or trailing space. It must not contain control characters, delete character, non-spacebar white space, or a double-quote (") character. An ASCII only password must have at least one uppercase letter, one lowercase letter, one digit (0-9), and one special character from the following: (.,+:_!).

    Output similar to the following appears:

    Enter Keystore Password: ********
    
    Re-Enter Keystore Password:
    
    WARNING: power loss during upgrade may cause data loss. Do not power off during upgrade.
    
    Verifying upgrade preconditions
    1/7: Mounting filesystems (1)
    2/7: Cleaning yum configuration
    3/7: Cleaning old packages and files
    4/7: Upgrading kernel
    5/7: Upgrading system
    6/7: Installing database bundle patch resources
    7/7: Setting final system status
    Remove media and reboot now to fully apply changes.
    Unmounted /var/dbfw/upgrade/avdf-upgrade-12.2.0.10.0.iso on /images

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

Upgrading the Appliance

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:

If you are upgrading from release 12.2.0.5.0 or later, then 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

6.3.4.4 Restart The Appliance

Steps to reboot the appliance and continue the upgrade process.

To reboot the appliance, 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

    The restart process completes the upgrade. When the appliance restarts, the pre-database and post-database migrations are run automatically. This process also removes the pre-upgrade avdf-pre-upgrade-12.2.0.10.0-1.x86_64.rpm executable, 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.

    3. If the upgraded Database Firewall indicates a certificate error, click on its name, and then click Re-Register Firewall.

Note:

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

  1. Upgrade The Audit Vault Server (Standalone) Or Server Pair (High Availability)

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

  3. Upgrade The Database Firewall Or Firewall Pair

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

6.4 Post Upgrade Tasks

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

Note:

Apply the deprecated ciphers patch (Deprecated-Cipher-Removal.zip) to remove old ciphers, post AVS install or upgrade. Apply this patch on Audit Vault Server after installation or upgrade to 12.2.0.13.0 (or later). Before applying the patch, make sure that all the Audit Vault Agents and Host Monitor Agents are upgraded to 12.2.0.13.0.

The following topics describe some important post upgrade changes:

6.4.1 Confirmation Of The Upgrade Process

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

Symptoms when the upgrade is successful:

  • The Audit Vault Server console can be launched without issues

  • The home page on the Audit Vault Server console displays the actual version on the top right corner

  • SSH connection to the Audit Vault Server is successful without any errors

Symptoms when the upgrade has failed:

  • Unable to launch the Audit Vault Server console

  • SSH connection to the Audit Vault Server displays an error that the upgrade has failed

6.4.2 Upon Successful Upgrade, Data Encryption Is Automatically Enabled

After upgrade, the newly created tablespaces are automatically encrypted.

However, tablespaces created before the system was upgraded to 12.2 continue to be in clear text.

See Also:

Data Encryption on Upgraded Instances in the Oracle Audit Vault and Database Firewall Administrator's Guide for detailed steps to encrypt existing tablespaces.

6.4.3 Changes Required To 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;

6.4.4 Enable Archiving Functionality Post Upgrade From BP11 to Later Releases

Learn how to fix disabled archiving functionality post upgrade from Oracle AVDF 12.2.0.11.0 to later releases (12.2.0.12.0 or 12.2.0.13.0).

Problem

Archiving functionality may be disabled after upgrading from Oracle AVDF 12.2.0.11.0 or 12.2.0.12.0, to 12.2.0.12.0 or 12.2.0.13.0.

Archiving functionality for high availability environment is supported starting Oracle AVDF release 12.2.0.11.0. This problem arises when you are upgrading from older releases where archiving functionality is supported only on the primary Audit Vault Server. Execute the steps only if you are upgrading from Oracle AVDF 12.2.0.11.0 to later releases.

Note:

If you are upgrading from any release prior to Oracle AVDF 12.2.0.11.0, then follow the steps documented in section Enable Archiving Functionality Post Upgrade.

Solution

If archive locations were present before upgrading to 12.2.0.13.0, execute the following steps to enable archiving functionality. These steps must be executed post upgrade process.

  1. Create a new archive location using the Audit Vault Server console. While creating this new archive location enter the details of both the primary and standby location. This will mount the new archive location on the primary or standby Audit Vault Server and update the fstab with both archive locations.

  2. SSH to the primary Audit Vault Server as support user and then unlock the avsys user by executing the following commands:

    su root
    su dvaccountmgr
    sqlplus /
    alter user avsys identified by <new password for avsys user> account unlock;
    exit;
    exit;
  3. Execute the following commands as avsys user:

    su oracle
    sqlplus avsys
  4. Enter the avsys password when prompted. Execute the following SQL commands:

    delete from avsys.system_configuration where property = '_ILM_ARCHIVING_DISABLED';
    COMMIT;
    insert into avsys.system_configuration values ('_ILM_HA_UPGRADE_COMPLETED', 'Y');
    COMMIT;
    exit;
    exit;
  5. Execute the following command to lock the avsys user:

    su dvaccountmgr
    sqlplus /
    alter user avsys account lock;
  6. Delete the new archive location that was created in the initial step. Navigate to Settings tab, then click Manage Archive Locations in the left navigation menu. Delete the specific archive location.

6.4.5 Enable Archiving Functionality Post Upgrade From Release BP10 and Prior

Enable archiving functionality post upgrade from release 12.2.0.10.0 and prior. This is required only if the Audit Vault Server is deployed in a high availability environment.

Archiving functionality for high availability environment is supported starting Oracle AVDF release 12.2.0.11.0. This problem arises when you are upgrading from older releases where archiving functionality is supported only on the primary Audit Vault Server. Execute the steps only if you are upgrading from Oracle AVDF 12.2.0.10.0 or prior releases to later releases where archiving functionality is supported for both primary and standby Audit Vault Servers.

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.

  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. Enter the SQL*Plus credentials as follows:

    sqlplus <super-admin>/<password>

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

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

6.4.6 Recommended Post Upgrade Steps For Setting TLS Levels

After upgrading all of the appliances and Agents, Oracle recommends that you set the TLS level to Level-4.

Set the TLS level to Level-4 by executing the following command:

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

Note:

  • In case any single instance of an Agent is running on IBM AIX, then use --agent-tls-cipher-level 3 instead of --agent-tls-cipher-level 4 in the above command.

  • If any Agent is using Java 1.6, then upgrade the Java version to 1.8.

Then, perform the following procedure to propagate cipher level change to all Agents:

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

  2. Change the directory by using the command:

    cd /usr/local/dbfw/bin/priv

  3. Execute the following script using the command:

    ./send_agent_update_signal.sh

Note:

  • This command must not be executed more than once in a period of one hour.

  • This will break communication with external systems if they do not support the strict TLS setting. See About Setting TLS Levels in the Oracle Audit Vault and Database Firewall Administrator's Guide for the appropriate level.

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

6.4.8 Scheduling Maintenance Job

There are some jobs on the Audit Vault Server that need to be scheduled for proper and effective functioning of the system.

These jobs should run during a period when the Audit Vault server usage is low, such as night.

The user can schedule these jobs as per their time zone, through these procedures:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click Settings tab, and then Manage.
  3. 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.
  4. 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.
  5. 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.

    See Also:

    Monitoring Jobs in the Oracle Audit Vault and Database Firewall Administrator's Guide to check the status of the job scheduled.

6.4.9 Resolve Missing Log Rotate File Post Upgrade

After upgrading Oracle Audit Vault and Database Firewall (Oracle AVDF), you will need to resolve a missing log rotate file.

This scenario is encountered while upgrading from Oracle Audit Vault and Database Firewall release 12.2.0.4.0 or prior, to release 12.2.0.5.0 and above. The /etc/logrotate.d/dbfw-db file may be missing after the upgrade.

To fix this issue, execute the following commands as root user:

install -o root -g root -m 0400 \
  /usr/local/dbfw/templates/template-logrotate.d_dbfw-db \
  /etc/logrotate.d/dbfw-db

Upgrade to Oracle Audit Vault and Database Firewall release 12.2.0.10.0 or later, to fix the following error:

error: /etc/logrotate.d/dbfw-db:10 duplicate log entry for /var/lib/oracle/dbfw/av/log/apex_perf_patch.log

6.5 Migration of Expired Audit Records

Releases prior to Oracle Audit Vault and Database Firewall 12.2 did not automatically archive expired audit records (records that were older than the months online period specified in the data retention/archiving policy).

Expired audit records were stored in the AVSPACE schema of the Audit Vault Server.

After you upgrade to Oracle Audit Vault and Database Firewall 12.2, a migration job automatically kicks off to migrate expired audit data, and either archive it or delete it according to retention policies set for your secured targets. You can see the status of this migration job in the Jobs page (Settings tab, System menu, Jobs). In the event of an error (for example, not enough space for migration), the error appears in the job status. The expired records migration job runs every six hours until errors are fixed and the migration is complete.

Note:

Upon successfully upgrading to release 12.2.0.4.0 from 12.2.0.3.0, the user must run the encryption script prior to executing archive jobs.

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide for more information on archiving.

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

6.7 Uninstalling Audit Vault Agents Deployed on Target Host Machines

Uninstall the Audit Vault Server and the Database Firewall appliances, and the Audit Vault Agents, that are deployed on target host machines.

To remove the Audit Vault Agent from secured target host machines:

  1. In the Audit Vault Server, stop all audit trails for the secured target host.
  2. If the secured target host has a host monitor running, stop it.
  3. In the Audit Vault Server, deactivate the Audit Vault Agent for the secured target host.
  4. In the Audit Vault Server, delete the secured target host.
  5. In the secured target host, delete the Audit Vault Agent install directory.

To uninstall the Audit Vault Server or Database Firewall(s), turn off the computers on which they are installed, and follow the procedures for safely decomissioning the hardware.

6.8 Reimage Oracle Database Firewall and Restore from Audit Vault Server

About reimaging Oracle Database Firewall and to restore from Audit Vault Server.

Use this procedure to reimage the Oracle Database Firewall appliance and restore the configuration from the Audit Vault Server console.

  1. Reinstall Database Firewall.
  2. Complete the configuration steps for the Database Firewall instance. The configuration includes the IP address, proxy ports, bridges, and other settings similar to the previous Database Firewall instance.
  3. Specify the Audit Vault Server certificate and IP address on the new Database Firewall instance.
  4. Log in to the Audit Vault Server console as an administrator.
  5. Click on Database Firewalls tab. The Database Firewalls tab on the left navigation menu is selected by default and a list of Database Firewall instances configured are displayed on the main page.
  6. The newly installed Database Firewall displays red in the Status column.
  7. Click on the name of the specific Database Firewall instance.
  8. In the Status section on the main page, click on Show details against the Status field.
  9. The Diagnostic Status section is displayed on the main page. There is a Certificate Validation Failed message displayed in the list.
  10. Click on the Back button in the top right corner.
  11. In the main page, click Update Certificate and wait for the page to load.
  12. Check the status of the Database Firewall instance.
  13. Click Reset button under Reset Database Firewall section and confirm the operation.
  14. Verify the status of the Database Firewall is Primary and the status of the Enforcement Point is Up.