Connector Internals


This document discusses the internal design of the connector process. 
It does not discuss the sandbox or container design.


The connector (also known as the "vlink") is the main process of the of intigua end-point agent. The connector is deployed by the core-server or deployed manually by a user and communicates with a core-server configured during installation.
Some of the roles the connector performs when it runs:

  • Receive commands from the core server and sends back status updates
  • Install, start, stop, remove virtual vAgents
  • Monitors vAgent processes
  • Serves as the services manager for agents with windows services (emulation for services.exe)
  • Manages the sandbox registry and sandbox file-system per-agent
  • Serves as DComLauncher for agents which use DCOM
  • Samples agent resources and throttles them when needed
  • Upgrades itself and removes itself on command
  • Manages injections to system processes like services.exe


For installing a connector on an end-point, the core server copies the installer executable to the machine and executes it remotely. 
This can be performed by the core-server in one of several ways

For a windows end-point, using SMB/CIFS protocol

  • copy the file "one_time_service.exe" and the connector installer file to the machine.
  • remotely create a windows service on the remote machine with this executable, the service name is "IntiguaOTS"
  • remotely start the service with the arguments to run the installer

For a linux end-point, using SSH

  • copy to the machine the connector installer and the script ""
  • run bash with the needed installer arguments. This is done to avoid having to chmod remotely and to take care of any sudoers errors

For machines that only have VIX connectivity

  • copy the installer to the machine using guest operation
  • run the installer using VIX guest operation
  • circumvent UAC issue using DubStep.exe

The installer executable is a standalone executable which does not depend on anything else.

This executable uses Intigua's C++ framework to extract the connector files from itself and start the connector run. Embedded inside the installer executable as a resource is a zip file which is the connector upgrade package.
The C++ installer operation:

  • Parse the command line arguments given to it
  • Create the directory structure where the connector should be installed
    • by default this is C:\Program Files\Intigua in windows and /usr/local/intigua in linux. Call this INTIGUA_ROOT
  • Extract the files needed for this version of the connector to function from the embedded zip file
    • the connector package is deployed to INTIGUA_ROOT/vAgentManager/PackageManager/vlink/vlink_1.2.3.4/
  • Setup the loader configuration for the watchdog to know which connector executable to runInstall the watchdog service (windows service or init.d service)
    • This is the INTIGUA_ROOT/loader.cfg
    • set to true the field that means that this is a new installation, this tells the starting connector to do some extra initialization work when it starts.
  • start the watchdog service
  • wait for the connector to start and initialize, sampling the connector status folder periodically
  • save a short status file in the same directory where the installer itself was saved indicating the status of the installation (failed or succeeded). The core server checks for this file to discover the connector installation status

When the core-server detects the finished installation it deletes the installer executable and saved status.

On linux up untill 2.8.0, this procedure is performed not by C++ code but by a bash script called and the connector is extracted from a tar file, not the upgrade zip. The linux and windows logic are unified in 2.9 and above.