The RVIA Data Service is an additional component which can be enabled for deployed runners. It is used in connection with RayVentory Inventory Agent (RVIA) clients for legacy inventory support. The technology used in RVIA produces valuable device inventory data in an unusual format for Raynet One. Using the service described in this chapter, the unusual inventory format is converted into modern device inventory objects. Connect your existing RVIA-based device inventory systems to gain strong IT visibility by the user friendly web interface of Raynet One!
RVIA is a program which collects device inventory locally on the device it is executed on. It places inventory files temporarily to be scheduled for upload to a specified HTTP inventory upload endpoint.
HTTP download & upload endpoints
These endpoints are mandatory for the operation of this runner service. They are created on the runner device. Verify the network connectivity between the runner device and the RVIA device. The runner service can be bound to just about any IP address and port, be it IPv4 or IPv6. Another network socket exclusively for runner service operation is created.
Be aware about the complexity of network routing configuration if virtual machines or Docker containers are involved. The network endpoint inside of an encapsulated machine needs to be specified and routed from the viewpoint of the encapsulated machine, not the host machine. It is recommended to be familiar with the topic of general IP networking.
You can use your web browser to verify the proper operation or connectivity to the RVIA runner service. A default web page displayed above is offered at the web site root. In this screenshot, the Firefox web browser is used.
TLS security
In the Windows variant of the runner, there is built-in TLS endpoint communication encryption support by the use of the Windows certificate store. Simply import your certificate through the certificate store MMC snap-in, link the related public certificate and you are good to go. You can find the chapter explaining the process here.
If you are using the Docker variant of the runner, setting up network communication security requires different steps. See the dedicated advanced configuration chapter for the full details.
Configuration parameters (rvia.cfg)
The RVIA configuration file is used to specify the behaviour of the RVIA inventory tool. It is part of the Scan Engine product. Details about the configuration file can be found in the product's documentation.
You can edit the configuration file through the web interface directly.
Incoming files configuration
In this wizard step you can specify runner operational configuration. To save the limited resource called RAM, data received from RVIA clients and furthermore processed is put onto disk. The files are moved around depending on which stage they are in.
•Upload files directory: final location of unknown received files or first target storage directory for data received per HTTP.
•Incoming files directory: actively watched directory for discovery or inventory files (unknown files are moved back to the upload directory).
•Bad format directory: invalid .gz compression file structure, invalid discovery file format (malformed device inventory is deleted instead).
•Import error directory: conversion of discovery or inventory file failed.
An illustration of the entire RVIA Data Service upload endpoint process. It starts by the user building a file and uploading it. It is successfully finished by the interpretation and forwarding into the Raynet One system. Each stage is assigned one of the directories specified in the Incoming files configuration wizard step. Various error directories apply in the Incoming files directory stage. In that stage the file/blob content is inspected in great detail, compatible with the rules set by the Scan Engine product. The Upload files directory is mentioned twice, the first time as temporary tray and the second time as permanent data warehouse.
To prevent clogging up file-system space, the Decompressed file size limit field sets the maximum size of files to decompress. If a compressed file is received and it is bigger or equal to the specified size, it's not processed.