How Zero-footprint Collection of Oracle Inventory Works

FlexNet Manager Suite 2023 R1 (On-Premises)
In Zero-footprint inventory collection, the process is initiated by the inventory beacon. However, once the FlexNet inventory agent commences operation, it is running entirely in the context of the target device (the Oracle server). This means that it is functionally equivalent to the local agent-based collection of Oracle inventory, with the only differences being in the methods of initiation.
Tip: In particular, the settings for Oracle inventory that are set in the Actions tab of the Discovery and Inventory Rules page (under Oracle database environments, where there are check boxes for Discover Oracle database environments and Gather Oracle database environment inventory) do not control the behavior of FlexNet inventory agent in this Zero-footprint case, any more than in the local agent-based collection. The Zero-footprint case is controlled only by the setting in the General hardware and software inventory section, and inventory collection is triggered when a rule includes the setting Gather hardware and software inventory from all target devices

The following diagram shows an example scenario for two inventory beacons.



The above diagram shows three database servers, two in Subnet1 and one in Subnet2. The Subnet1 is assigned to Inventory Beacon1 and Subnet2 is assigned to Inventory Beacon2. Each inventory beacon can connect to the Oracle server(s) in its assigned subnet. All the prerequisites outlined in Zero-footprint Collection of Oracle Inventory are satisfied.

The process for Zero-footprint collection of Oracle inventory runs like this:
  1. To control the behavior of the inventory beacon(s), an operator sets an appropriate rule in the web interface at Discovery & Inventory > Discovery and Inventory Rules:
    • Target: One or more target(s) to identify all Oracle servers in your network.
    • Action: These settings:
      • For Action type, choose Discovery and inventory.
      • Under Discovery of devices, select Network scan (and ensure the appropriate ports for your target devices are listed)
      • In the General hardware and software inventory section, select Gather hardware and software inventory from all target devices.
    • Schedule: Set your preferred schedule for execution of the completed rule.
  2. By default, every 15 minutes each inventory beacon checks for any updates to its policy, which also transfers any changed discovery and inventory rules. (To adjust this download schedule, see Inventory Settings Page > Beacon Settings Section in the online help.) Each inventory beacon exercises only those rules that apply to its assigned subnet(s). The only action setting relevant to the Zero-footprint case is Gather hardware and software inventory from all target devices.
  3. When the related schedule triggers an applicable rule, the inventory beacon initiates the process in ways appropriate to the target platform. Full details are available in the Gathering FlexNet Inventory PDF; but in summary:
    • For Windows: The FlexNet Beacon engine logs into the target server, and creates a Windows service that executes ndtrack.exe from the mgsRET$ file share on the inventory beacon. Note that InventorySettings.xml is available to the FlexNet inventory agent so that advanced Oracle inventory capabilities are available; but there is no way to pass device-specific preferences to ndtrack.exe.
    • For UNIX: The FlexNet Beacon engine logs into the target server, elevates its privileges to root level, creates a secure link back to the inventory beacon, and copies ndtrack.sh to the target server and executes it. This script identifies the platform, unzips the appropriate ndtrack executable, and runs it. Note that the ndtrack.ini (which contains any agent preference settings you may have configured there) and InventorySettings.xml are delivered to the target device as well, allowing the functionality described below. However, since these are stored on the inventory beacon, the same values are delivered to each target device managed by an individual inventory beacon.
    Tip: The remaining steps in the process are almost identical to those for local agent-based inventory collection (with the exception of upload retries). The descriptions are repeated here for your convenience.
  4. The tracker (ndtrack executable) runs discovery on the target device, writing results to a .disco file. For Oracle, the discovery process tries to identify one or more paths for $ORACLE_HOME, using all of these platform-dependent methods in order (and combining the resulting dataset):
    UNIX-like platforms — Oracle discovery Windows platforms — Oracle discovery
    1. The tracker scans the file system for any oracle executables.
    • This scan honors the global settings for file system scans in the File Inventory section of the Inventory Settings page of the web interface, which may limit search paths or even disable file scanning entirely.
    • On success, this search returns the file path ($ORACLE_HOME) and the executable ID.

    1. The tracker looks for a registry entry under HKLM\SOFTWARE\Wow6432Node\Oracle\ (or, on 32-bit systems, HKLM\SOFTWARE\Oracle\). On success, this returns the %ORACLE_HOME% path.

    2. The tracker looks for an oratab file (installed in either /etc or /var/opt/oracle during database installation). On success, this provides the $ORACLE_HOME path, the executable ID for the oracle executable, and the System ID (SID) for each database instance listed in the oratab file. (See also note below.)

    2. The tracker interrogates the Windows Service Control Manager. On success, this provides the %ORACLE_HOME% path, the System ID (SID) for the database instance running in that process, and the name of the related Oracle listener.

    3. The tracker examines process listings for matches to ora_smon_*. On success, this provides the $ORACLE_HOME path and/or the executable ID for the oracle executable, as well as the SID for the running database instance and the user account running it. (See also note below.)

    (No step 3 for Windows.)

    4. The tracker examines process listings for tnslsnr. On success, this provides the $ORACLE_HOME path, the executable ID for the oracle executable, the name of the related Oracle listener, and the user account running the listener.

    (No step 4 for Windows.)
    Note: If a symbolic link was used in the $ORACLE_HOME path to start a particular Oracle database instance on a UNIX-like platform, this can 'hide' the database instance from inventory collection by the locally-installed tracker (ndtrack component). To ensure inventory collection from a database instance started with a symbolic link, use either (or both) of the following workarounds:
    • You can ensure that the Oracle home specified in the /etc/oratab file represents the ORACLE_HOME path used to start the database instance.
    • The account running the database instance (say OSUser4Oracle) may set an environment variable within its login profile specifying the ORACLE_HOME path (including the symbolic link) which was used to start the database instance. To test this setting, the following command should display the correct ORACLE_HOME path:
      su -OSUser4Oracle -c "echo \$ORACLE_HOME"
      Tip: If this environment variable is set for any account on the database server, it is applied to all database instances started by the same account on this server. Any mismatch between the (non-empty) environment variable, and the actual path used to start any of these database instances, prevents the collection of database inventory from the mismatched instance by the locally-installed inventory component (ndtrack). Conversely, you can prevent the environment variable option being used for all accounts on the target Oracle server by setting the UserDefinedOracleHome preference (details of this preference are included in Gathering FlexNet Inventory.
  5. Next, the tracker gathers general hardware and software inventory (recorded in an .ndi file) from the local device. This is the standard inventory gathering that the tracker gathers on every device where it is running. If the appropriate preference is set, it also includes gathering evidence for Oracle Fusion Middleware applications (seeSpecial Handling of Oracle Fusion Middleware).
  6. If the tracker discovered one or more Oracle database instance(s) on the device, and all the required settings and account privileges are in place, the tracker also gathers inventory from all accessible Oracle database instances.
    Tip: The definition of "accessible" changed at version 12.4 of the tracker (released with FlexNet Manager Suite 2017 R3):
    • For versions 12.3 and earlier, "accessible" excluded all Oracle database instances that are in standby mode
    • For versions 12.4 and later, the locally-installed tracker also collects inventory from Oracle database instances that are in standby (that is, MOUNTED but not in RUN mode), such as the standby instance in an Active Data Guard configuration.
    The processes for gathering Oracle inventory on different types of platform are as follows.
    • For UNIX-like platforms, the tracker impersonates an appropriate account, determined by the configuration of the preferences shown below.
      Note: On a UNIX-like platform, the tracker attempts to use setuid to impersonate the appropriate account to gather Oracle inventory. If you are using eTrust Access Control on this server, by default it does not permit this impersonation, and inventory gathering fails. The fix is to change the configuration of eTrust to include ndtrack in the LOGINAPPL class. For more information, see the eTrust Access Control Administration Guide (https://supportcontent.ca.com/cadocs/0/g007711e.pdf).
      Each column in this table shows a set of conditions in the first three rows, followed by the resulting behavior in the last two rows. Once a valid user account is determined, the tracker invokes the Oracle-supplied sqlplus utility, giving it either of the command line parameters shown in the last row as appropriate:
      UNIX-like platforms — Conditions Option 1 Option 2 Option 3 Option 4 Option 5

      If the executable runs as

      root

      root

      root

      root

      Any other account

      and OracleInventoryAsSysdba =

      True

      True

      False

      False

      n.a.
      and OracleInventoryUser =

      Valid user

      Not set

      Valid user

      Not set

      n.a.

      Then: Impersonated account is

      That user (see Tip below)

      Process owner

      That user (see Tip below) Not supported n.a.

      Command line parameters for sqlplus

      "/ as sysdba" "/ as sysdba" "/ "

      No inventory

      No inventory

      Tip: If you intend to specify the OracleInventoryUser preference, it must be an exact match for any Oracle user name that:
      • Is also an operating system account
      • Has OS authentication enabled
      • Is a member of oinstall (or equivalent group, granting execute permissions for sqlplus)
      • Is either a current member of the dba group on the UNIX host server (when OracleInventoryAsSysdba=True or is unspecified); or has adequate permissions for inventory gathering (when OracleInventoryAsSysdba=False).
    • For Windows platforms, the tracker normally runs as LocalSystem, but may be run by another account that has administrator privileges (that is, is a member of the Administrators security group). In either case, the same account that is running the ndtrack executable is used to invoke the Oracle-supplied utility sqlplus, using the command line parameter "/ as sysdba". This remains true even if the Oracle database instance is running as a service user, as is possible from Oracle Database 12c; so that binaries controlled by the service account are now executed as LocalSystem (or at least with administrator privileges). It is, of course, best practice to ensure that any service account running a database instance is well secured, so that the binaries it controls are protected.
  7. Where Oracle inventory is collected, the tracker also executes scripts provided by Oracle Global Licensing and Advisory Services (GLAS) to gather software and hardware information about the servers where Oracle Database is installed. (These scripts, as amended from time to time, are downloaded to the tracker from the InventorySettings.xml file. They are used only for the preparation of an Oracle audit report, available to operators who have appropriate access rights in the Discovery & Inventory > Oracle Instances page, with more details available in the help for that page.)
  8. The tracker records the software and hardware results of the Oracle inventory gathering in a separate .ndi file.
  9. Immediately on completion of inventory gathering, the tracker uploads the .disco file and one or two compressed .ndi files to the appropriate inventory beacon.
    Tip: If this upload fails (say, because of a temporary network issue), there is no catch-up retry in the Zero-footprint case.
  10. The inventory beacon uploads all collected discovery and inventory information to the central application server (or, if it is a member of a hierarchy of inventory beacons, uploads the data to its parent in the hierarchy, and the upload is repeated until the data reaches the application server). Data is stored initially in the inventory database.
  11. In due course, the inventory import (to the compliance database) and license reconciliation process runs (typically overnight, although an operator in a role granting the Configure inventory data and reconcile right can also trigger a full import and reconciliation). Progress is visible on the System Tasks page.
  12. The Discovery & Inventory > Oracle Instances page lists the database inventory for all servers discovered and inventoried up to the time of the latest reconciliation calculation.

FlexNet Manager Suite (On-Premises)

2023 R1