Survol needs to run one agent per machine: A plain HTTP server running Common Gateway Interface (CGI) Python scripts. This agent and its port number define the identity of each object of this machine, that Survol is able to provide information about. This is the same concept as in WMI and WBEM, and both interoperate completely. Therefore, Survol is able to get information with another machine with no Survol agent: See OpenLMI, WMI etc...
If your browser runs ActiveX, it is also possible to use Survol web pages with no agent.
Survol is based on a tree of Python scripts, all of them display information of the system the agent is running on. Some scripts do not need parameters: They will return information with no context: For example, all available databases, all detected machines on the network, all installed Python modules etc... Other scripts need parameters, as they display information about a specific object. For example; Files opened by a specific process. Columns of a SQL Server™ table. Processes connected to an Oracle™ database.
As a benefit of a CGI-based architecture, it is also possible to run any Python scripts as command-line programs. This allows to test them in isolation with full control on ther environment and input, and full visibility on the output. This greatly helps when creating and testing scripts.
The internal data model built by Survol, is based on RDF, a standard model for data interchange in the Web. The data representation of Survol is a RDF graph: a set of triples: Subject, relation, object, and is also the core data type found in the Semantic web. It is successfully used in Artificial Intelligence applications. This abstract representation is independent of the display mode. The same set of data, extracted from an information system, is shown several ways:
There are also two output modes, used internally:
To start with, some acronyms. WBEM™ stands for Web-Based Enterprise Management, an industry initiative to develop a standard technology for accessing management information in an enterprise environment. This standard is governed by DMTF, Distributed Management Task Force. WMI is the Microsoft implementation of WBEM. In the Linux world, a common implementation of WBEM is OpenLMI. It is based on an open-source implementation named OpenPegasus™. WBEM standard information is delivered with CIM (Common Information Model).The CIM schema is the model for delivering this standard information.
To summarize, WBEM define classes of computer-related objects: Processes, files, network cards etc... have a valid and detailed definition in CIM. Here are some examples:
|CIM_Process||This is the base class of a process, which is derived into Win32_Process|
|CIM_Datafile||A normal file: The concept and its implementation are similar in Windows and Linux.|
|Win32_UserAccount||A Windows user account. Linux has a specific definition, unrelated to this one.|
One of the core aspects of Survol is its data model which attempts to take the best of the worlds it is working in. A first approach is WBEM. However, the data description offered by WBEM suffers from several drawbacks:
Despite this, building a software on an industrial standard is invaluably convenient. Therefore, Survol attempts to combine the best of both worlds:
Survol library is made of packages and subpackages which represents its classes model. A class is a module where the function
EntityOntology() is present, whether it is defined by the module or one of its parents modules. The return value of
EntityOntology() is a list of string, each representing an attribute of the class. If a module nor none of its parent modules define the function
EntityOntology(), it is a domain.
A class or a domain can define other functions in its
__init__.py file. All of them are optional:
|Function||What it does|
returns an array of strings which are the name of the attributes of an
object of this class. This does not apply to domains.
returns a RBG colour coded as a hexadecimal string. This colour is used
by any UI mode, for this class/domain, unless it is superseded by a
subclass or subdomain.
|EntityName||This returns a
display name for
this object, given its attributes passed as an array, in the order
specified by the ontology. The hostname is also passed as an argument. The resulting
name does have to be unique, but must be printable. This applies to
|AddInfo||When displaying an
object, adds some extra information related to it.
||This tells if the
module or the
script, is usable in this context, given the platform, available
packages etc... It can be defined for any module or any script.
Survol is designed to run in a harsh environment, uncertain platforms, broken libraries, incompatible interfaces, and return as much information as possible about unknown applications. It has to be robust and adapt to any situation. Therefore, it is built, at all stages, on the concept of redundancy.
Redundancy of data display:
Survol can display its results in:
Redundancy of information sources:
The core information might come from any source: win32 Python library, any Linux package, WMI and WBEM select statements.
Redundancy of Web hosting:
Scripts can be hosted by Apache, IIS™, the dedicated ad hoc CGI server. Any reasonable HTTP server with CGI or WSGI capabilities should suffice.
Redundancy of Python interpreter and libraries:
Survol scripts access many software resources, some of them being protected with credentials, typically a username and a password. These credentials are made available to Survol with a JSON file, SurvolCredentials.json, residing in the users' home directory. Depending on the user running the HTTP server (Apache, IIS etc...), this home directory may vary. This file can be edited with the "Credentials" page link.
It contains several types of credentials, depending on the type of access: Database software, middleware library etc... For each of this access type, it is possible to add, delete, update any credentials. On the other hand, it is not possible, without extra development, to add new types of credentials as these need specific software to use them.
A typical content of this file might be:
|Visual Studio Professional||8532-42f4-a66a-c5da7acd|
It is absolutely mandatory to ensure that this file is protected, for security reasons.
Some subcategories of the credentials file are used for static services discovery:
A Survol setup can run on several machines, each agent providing a facet of the overall multi-hosted application being investigated. To get an overall vision of this application, it is necessary to discover all the Survol agents available, in order to merge their outputs into a single result, whether this result is a SVG document, a HTML page etc...
There are several mechanisms allowing to discover other Survol agents available in the same network.