The document discusses discovery scripts used by Atrium Discovery to gather information from devices. It explains that scripts are organized by platform and method, and may require different access types. It provides examples of Unix and Windows discovery scripts, noting Windows scripts typically use multiple access types like WMI and require a Windows slave host.
Note that Discovery treats all the linux distributions as one Platform.
For instance the same Script can run on SSH as Telnet as it makes no difference. But a completely different Script needs to run on WMI compared to SNMP as the commands are very different.
For all the Linux distributions there is a SINGLE set of scripts (under the Linux platform) and for the minor differences between distributions the script itself can run alternative commands as there is a rich control set in shell scripting. For SNMP access there is a fixed set of SNMP queries against standard MIBs that will get a basic set of infrastructure information. SNMP will be used against any device that appears to have an SNMP port open, but it will be used last as it is the most limited. There are some platforms where the only supported access is via SNMP. Of these some will form Host nodes and have full discovery and some will simply be identified. This area of out of the box discovery is fixed and is not end user editable.
For SNMP access there is a fixed set of SNMP queries against standard MIBs that will get a basic set of infrastructure information. SNMP will be used against any device that appears to have an SNMP port open, but it will be used last as it is the most limited. There are some platforms where the only supported access is via SNMP. Of these some will form Host nodes and have full discovery and some will simply be identified. This area of out of the box discovery is fixed and is not end user editable.
The Windows Slave is a Discovery Proxy Service that runs on a Windows host external to Tideway Foundation. This is for 2 core reasons High quality Windows Access is via proprietary protocols (mostly WMI) and needs to be done from a Windows system For Windows protocols to authenticate successfully they need to be connected to a To install and manage Windows Slaves see the separate module.
Neither approach is better or worse; this is not some which Platform is better flamewar! But the discovery scripts have evolved in different ways on the two major collections of platforms and so while they have similarities there are differences.
This is why the UNIX Scripts are required to be editable whereas the Windows Scripts are fixed.
Important: getDeviceinfo, getHostinfo, and getInterfaceList must all success in order to infer a host
Some, but not all, scripts have notes attached. Usually where elevated privilege is required in the script there will be short notes explaining this. Elevated privilege will be discussed shortly but note that commands that require it are highlighted in red and prefixed with a PRIV_<NAME> function. To edit the script click on the edit button. A useful tip is that if you want to review *all* the scripts from a platform, maybe you have to send them around for authorisation review, then you can click on the “Download host script” link at the top of the page. This will merge all the scripts into one. This is also useful if you want to try how the scripts behave on Hosts that you are not yt allowed to scan directly.
The out of the box scripts are designed to degrade gracefully if root privilege is not available and will still return as much data as they can.
Remember that this script will be run *every* time a session is established for this platform. It has to work on *every* machine in your environment. You should have a sound knowlegde of your local UNIX environment or enlist the support of those that do.
As the same script is used for every host on this platform you may find that you need to test a number of paths, and maybe even different tools, to find which one is installed on a praticular host and it’s path. It’s best to do this by writing a small search before the PRIV_ commands and setting the command and path to a shell variable. This means this is done just once rather than in every function which is more efficient and easier to maintain.
For ease of display the WMI queries are summarised on their own page – “WMI Support” “ Shell Scripts” are used by discovery in the rare case that the Windows host supports unix shell sessions and is rarely used.
Some important differences to the UNIX Scripts getDeviceInfo AND getHostInfo will both be handled by scripts in the getHostInfo Method and will only be run once Many more Scripts per Method than UNIX to the create variety of Access types and the lack of a common scripting shell between them The Scripts are fixed – you cannot edit them or disable them. This is because the configuration is held local to the slave and this area of the UI is simply a summary of the standard slave configuration. WMI Query Scripts are attempted first for most Methods but not some important Methods, notably getNetworkConnectionList, have no information in WMI and have to use other Scripts
Note that it is not possible to reorder the Scripts used by a Method, in Windows or UNIX platforms. They are in a fixed order ranked according to the quality of data provided.
Wikipedia says: Windows Management Instrumentation ( WMI ) is a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).
The important detail here is that the first query in the getHostInfo WMI Script must succeed. If it does not then the slave executing the query will take this as an indication that it does not have access to WMI and will use other Scripts and Access types for the rest of the session. In general any query that fails will cause the method to fail for WMI and the slave will use other scripts, the only exception being queries marked as “Option, This query may fail” which are used for additional information or potentially will only work on newer versions of Windows.
Optionally you may wish to complete the labs that have been prepared to accompany this module. Please download the lab zip file that should be available where you accessed this module. Make sure you have access to a running appliance before attempting the labs. It is best to use the training demo VA provided as it is set up to work with the labs. You may need to review tutorial material in order to work out the solutions.
RemCom is used as the PsTools toolset is no longer maintained reliably, in particular v1.94 of psexec must never be installed as it will consistently cause the slave to fail. Additionally our license agreement to distribute PsTools was made with Sysinternals prior to the merger with Microsoft; Microsoft have honoured the original agreement to distribute to XP/2003 hosts but have declined to extend this to Vista/2008 hosts. RemCom, as an open source tool, does not suffer from these restrictions. RCMD is included for discovery of older systems and relies on the RCMDSRV.EXE to be running. Frequently it is not in most environments. RCMD is no longer distributed with the slave so customers will need to download and install the appropriate Windows Resource Kit for the OS that the slave is running on, and copy the files into the slave installation directory. Other tools that are no longer distributed are srvinfo, pulist and tlist. These tools are also in the Windows Resource Kit and can be downloaded if needed. From Sourceforge: RemCom is RAT [Remote Administration Tool] that lets you execute processes on remote windows systems, copy files, process there output and stream it back. It allows execution of remote shell commands directly with full interactive console.