...
- The system.id is retrieved, along with the timestamp of the previous audit submission and the "status" column.
- For each entry in the hard_drive audit result, the database is queried.
- It checks for hard drive model, serial, index and size.
- These values vary according to the item being processed - see the relevant model PHP pages (in PHP page at /code_igniter/application/models/)m_devices_components.php
- If it gets a match on the above values, combined with component.status = 'y' and the system_id, the current timestamp OR the previous timestamp, .id and a system.status of "production", then an existing entry exists for this piece of equipment.
- In the case of hard drives, it simply updates the timestamp current flag to 'y' to reflect the component is still current audit timestamp.
- If it does not get a match, it does an insert of the relevant details.
So, we can determine if something is currently installed - the timestamps match (on the system table and the relevant item table)current column is 'y'.
We can determine when something was detected - the "first_timestampseen".
We can determine if something was installed after the initial audit - first timestamps seen will be different.
We can determine if something is not currently installed, but previously was - the timestamp on the item is less than the timestamp on the systemcurrent = 'n'.
We can determine the last time we detected an item - the timestamp on the item, when the timestamp is less than the current system timestamplast_seen.
At any given point, we can determine what was on a system - by using the oa_ audit_log table and selecting the relevant components based on timestampsfirst_seen and last_seen.
So, that's how we determine what's on or has been on a system.
How do we
...
determine device uniqueness?
When we receive data about a device we check the following columns for matches. If we get a match and the existing entry has a status of 'production', we update this device.
The code for this currently resides in code_igniter/application/models/m_system.php.
Devices are considered the same if they have the following attributes in common: UUID & hostname, dbus_identifier*, FQDN, serial & device type, MAC address and config item**, ip address and config item**, hostname and config item**.
* In 1.12.8 we use the dbus_uuid in Linux to determine uniqueness. This is being reverted in 1.12.8.1 because ESX does not recreate this identifier upon cloning a mchine, hence possibly causing false positive matching.
** In the configuration of Open-AudIT you can select discovery_hostname_match (and mac, ip) to enable this matching.
The order of creating a key to define a device as unique is below. When importing you MUST have one of the following (in order of preference): fqdn (which is the hostname and domain columns seperately - PHP will combine them), the IP Address or the Serial Number. If a computer is audited with an audit script, it will use a concatenation of the UUID and the hostname. If a computer is audited via Active Directory, it will use the FQDN in preference but if that is not available it will use the IP Address. Where possible, the first option will be chosen and where possible on subsequent audits, will be changed to the first option.
NOTE - We now have configuration options for some fields that we use. In the config section (menu -> Admin -> Configuration) you will see options for discovery_ip_match, discovery_name_match and discovery_mac_match. If ip is set to 'y', the system key will include it (where relevant). If discovery_name_match is set to 'y', the system key will include it where relevant. If discovery_mac_match is set to 'y', all mac addresses will be checked to determine a match.
NOTE #2 - This is changing for 1.12.8 and we will update this document when it happens.
| computer | network printer | local printer | network device | non-network device | |
| audit script | uuid + hostname | fqdn, ip address | hostname + deviceID | - | - |
| active directory | fqdn, ip address | fqdn, ip address | - | - | - |
| nmap | fqdn, ip address | fqdn, ip address | - | fqdn, ip address | - |
| snmp | fqdn, ip address, type + serial | fqdn, ip address, type + serial | - | fqdn, ip address, type + serial | - |
| spreadsheet | fqdn, ip address, type + serial | fqdn, ip address, type + serial | - | fqdn, ip address, type + serial | type + serial |
| html form | fqdn, ip address, type + serial | fqdn, ip address, type + serial | - | fqdn, ip address, type + serial | type + serial |
How do we match a system key?
The order of preference to match one system against another is as follows: Obviously if we have the system_id, we simply match on that first. If we don't have the system_id, in the model m_system.php is a function called find_system. This will attempt to:
- Create a system key using UUID & hostname if possible and match
- Create a system key using the fqdn if it exists and match
- Create a system key using the hostname concatenated with the domain (to make a fqdn) and match
- Create a system key using the ip address and match
- Create a system key using serial number and match
- Check if the MAC Address exists in the sys_hw_network_card_ip table and match
- Check if the IP Address exists in the sys_hw_network_card_ip table and match
- Check if the serial exists in the system table and match
- Check if the serial exists in the man_serial field in the system table and match
- Check if the hostname is in the system table and match
What do we use for a name?
...
Where possible, the first option will be chosen and where possible on subsequent audits, will be changed to the first option.
...
: hostname, dns_hostname, sysName.