Survol needs to run one agent per machine: a plain HTTP server runs 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 with WMI and WBEM, both inter-operate 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 their 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 and object. It 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 another mode, 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 defines classes of computer-related objects: processes, files, network cards etc... have a valid and detailed definition in CIM. Here are some examples:
|This is the base class of a process, which is derived into Win32_Process
|A normal file: the concept and its implementation are similar in Windows and Linux.
|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:
The ontologies describing the data model of WMI and WBEM are automatically created and completed by the Survol'specific classes. Primhill Computers freely rovides these ontologies which can be used by any ontology editor. Being created automatically, they are the most accurate semantic model of the internal architecture of the operating system.
Survol library is made of packages and
subpackages which represents its classes model. A class is a
module where the function
is present, whether it is defined by the module or one of its
parents modules. The return value of
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
__init__.py file. All of
them are optional:
|What it does
|This returns an array of strings which are the name of
the attributes of an object of this class. This does not
apply to domains.
|This 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.
|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 classes only.
|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
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.