Linux Agent

This deals with Linux Agent Architecture Requirements.

Note: The architecture requirements for the Linux Agent are essentially the same as the SolarWinds Platform Agent.  They have been enumerated here with addendum.

Architecture Requirements 

1. Remote deployment. The agent must support remote deployment to Linux/Unix machines given an address and administrative credentials.  The basic unit of deployment is the software package.  Various package managers exist with RPM being chosen as covering the most immediately targeted platforms.  There is a loose standard (LSB) for the RPM package that will allow the transformation to a debian package for Ubuntu, et. al.  AIX supports RPM.  Provided that SSH connectivity exits, the agent package should be installed on a platform with the appropriate dependencies.  The SolarWinds Platform server will need to know what OS is targeted in order to deliver the correct package.  Given that SSH is available, a simple script could return that information.  All Solarwind RPM packages should be signed and a public key used to verify the authenticity.
    
2. Manual deployment. When remote deployment is not feasible, it must be possible to install it manually.  Not much more to add here as it would be the same issues as remote deployment.  Any distribution should have the appropriately targeted package manager available.
    
3. Minimal dependencies for initial deployment. It should be possible to deploy the agent to a typical server or desktop distribution and better yet minimal distribution installs without any missing dependencies.  Given the limited functionality of the agent itself, one expect this to be the case.   Static linking may be used for small additional desired functionality if necessary but should be avoided.  Systems running older C++ libraries will present a problem and will not be supported unless it makes sense to build appropriate packages for them.  Static linking could provide for solutions in some cases.
   1. Plugins may have their own dependencies above this, but the agent service should not.  There should be two ways to deliver the missing dependencies to the agent's host.  Depending upon internet access, the required dependencies can be installed from the internet.  The customer must be notified of the action and have the opportunity to cancel.  A description of the dependencies should be provided such that they may be delivered to the agent and installed by the agent as part of the plugin installation.  The package manager should remove unneeded dependencies on uninstall.
       
4. Small footprint. The agent service must be very frugal with regard to resource utilization. The agent should minimize the impact on the target computer.
    
5. Automatic upgrade. The agent must support receiving unattended upgrades from the SolarWinds Platform server.
    
6. Plugin deployment. The plugins with actual functionality (e.g., SAM, DPI, FIM, etc.) should be automatically deployed and upgraded from the SolarWinds Platform server.  The agent service will receive the plugin package and install it using the appropriate package manager system for the platform.  Package management naturally supports uninstall.  The prospect of missing dependencies is an issue described above.  Plugin packages should be signed and verified with the same public key as the agent package.
   1. Not all plugins should be deployed to all agents. In particular, deploying the DPI plugin to an agent must consume a "DPI probe" license.
   2. If a plugin instance requires a Solarwinds license, the license will be activated, stored, and managed by the SolarWinds Platform server.  The agent will not be responsible for storing or managing Solarwinds licenses on the node that the agent is deployed on.  The SolarWinds Platform server should recognize if it is receiving data from an unlicensed agent and forward message to the agent to shutdown.
       
7. Plugin isolation. The agent service should isolate each plugin into its own process launched by the agent service.  The plugin will be configured as a service (daemon) and controlled with the native control mechanisms of the the platform, i.e. service, systemctl, etc.  In order to support multiple versions of a plugin simultaneously because of multi-server installations, a version designation would be embedded in the package name of the plugin to make it a distinguished package.
    
8. Language/runtime-independent plugin interface. The interface for agent plugins to communicate with agent service should be straightforward to implement in C++, C#, or Java.  Communication will be implemented using named pipes.
    
9. Firewall-friendly messaging system. The agent service should communicate with the SolarWinds Platform server over a single, configurable TCP port. It must support this TCP connection being established in either direction, agent->server (default) or server->agent (to support deployment to a DMZ).
   1. The reason for making agent->server the default direction for initiating the connection is to avoid having to open ports where the agent lives.  Prototype will use SignalR port from DPI Linux probe.
   2. Plugins are expected to use this channel exclusively for communicating with the SolarWinds Platform server.
       
10. Plugin pre-requisite management. The package management system can determine dynamically what the missing dependencies are prior to installation.  There should be a request made to an agent verifying the state and to retrieve this information if there is an issue and allow for resolution.  Either the agent should be allowed to gather the prereqs from the internet or receive the dependencies from the SolarWinds Platform server.  How these are made available to the SolarWinds Platform server is beyond scope here.  However, most packages are available through ftp or http.  A respository of some kind could hold various packages on the server however all packages sent to the agent must be received over the messaging system.
     
11. Development platform. How important is it to have the minimal number of packages representing the same version of the agent to support all platforms?  In general each platform will require a unique package and build to produce it.  It is also possible that different versions of the same OS will require different packages.  An example is CentOS where there is vast differences between the major revisions.  The C++ runtime library presents problems depending upon compiler version and versions of the runtime in the field.  Using a ubiquitous interpreted platform, i.e. python, would simplify the handling of numerous OS platforms.  However, this would only be true if all necessary software facilities are available to satisfy requirements.  SignalR would defeat this as it would be necessary to compile it everywhere and produce a python binding.  All things considered, C/C++ is probably the best way to go and accepting the additional build and release effort.
    
    

See SolarWinds Port Requirements for more information.