Liongard

Roar Users Guide & Documentation

Welcome! You'll find comprehensive guides and documentation to help MSPs start working with Liongard's Roar as quickly as possible, as well as support if you get stuck. Let's go #MakeITRoar!

Get Started    

Agents Overview

📘

Exciting Agent Updates are Coming!

In the coming months, lots of exciting Agent updates are headed your way. To take advantage, make sure your On-Premises and Self-Hosted Agents are on the latest version (2.0.2 or newer).

For more information, please review our documentation.

Agents Overview

What is a Liongard Agent?

Liongard gathers information about your Environments and customer networks via Agents that are installed in the cloud and on customer networks.

Agents run Inspectors, which are the individual queriers that gather information about various systems (the Active Directory Inspector, the SonicWall Inspector, and so forth).

📘

Key Concept

Inspectors are run by Agents.

Agent Types

Liongard comes with a managed On-Demand Agent. This is baked into your Liongard instance, so its setup and maintenance are completely managed by us. This Agent is used to run inspections that do not require any privileged access to your customers' networks.

📘

Partners Prior to April 2021

For those partners who joined before April 2021, you have a managed Cloud-Linux Agent. This Agent functions in the same manner as Liongard's On-Demand Agent. For more information, please reach out to Liongard Support.

In Liongard, you also have the ability to deploy On-Premise Agents into your customers' network Environments. These Agents are installed on Windows servers "inside the firewall" (preferably on a Domain Controller) to perform inspections that do require access to servers and services that are not available from the public internet.

For each Environment you manage, only ONE On-premise Agent is required per network; thus, an Agent will be required per VLAN in order to communicate directly with the system it needs to inspect.

Typically, Agents are installed on the domain controller. From there, the Agent will automatically inspect the Windows Server and Active Directory. The Agent will also automatically deploy a Network Discovery Inspector. As you deploy additional Inspectors for on-premise systems, you will select this On-premise Agent to perform the inspections.

For Environments that have no on-premise server, and therefore no way to deploy an On-Premise Agent to inspect edge devices such as Firewalls, you should deploy a Self-Hosted Agent.

Like our On-Demand Agents, Self-Hosted Agents can handle inspections across multiple Liongard Environments and are hosted from your own infrastructure, without the need to allow cloud IP addresses through firewalls.

Instructions on deploying a Self-Hosted Agent can be found here.

Once you have deployed a single Self-Hosted Agent, it can be used for all Environments that do not have the ability to deploy an On-Premise Agent.

Agent Type

Use Case

On-Demand/Cloud-Linux

Cloud Inspectors

On-Premise

Behind the firewall

Self-Hosted

Serverless Environments

Privileged Network - Hosted in the MSP's data-center - Can access multiple Environments to inspect edge devices

The Admin > Agents screen segregates Agents by Self-Managed (including Self-Hosted Agents and On-Premise Agents) or Liongard-Managed Agents (including On-Demand and Cloud-Linux Agents). Ensure you are selecting the appropriate tab when looking for deployed Agents.

Local vs. Remote Inspections

Remember: Every Inspector is run by an Agent.

When you deploy an On-Premise Agent, it can run inspection jobs aimed at the machine that it's actually installed on (a "local inspection") or aimed at other servers/network devices on the same local network (a "remote inspection".)

This is good to understand for a couple of reasons:

  • You don't need to install an Agent on every Windows server in your customer Environments. One (or in certain cases, a couple) of Agents running remote inspections against other servers and devices will do.
  • Agents need appropriate permissions on the network to inspect target systems, sometimes via credentials put into the Liongard web application and sometimes via the user account executing the Liongard Agent service.

See the Permissions & Authentication page for a deeper dive into how permissions to complete inspections are handled.

📘

Key Concept

Local inspections are when an Inspector is aimed at the server on which the Agent is installed. For example, an Agent installed on an Active Directory domain controller and running an Active Directory inspection against that domain is a "local inspection."

Remote inspections are when an Inspector is aimed at a server or device other than where the Agent is installed. In the Active Directory scenario above, if the Agent is installed on a member server in the domain and using the local network to inspect the domain controller, that's a "remote inspection".

Windows vs. Linux Agent

There are two versions of the Liongard Agent, one that runs on Windows and the other that runs on Linux.

The Linux Agent is provided as one of the "Managed Cloud Agents" discussed above, and often facilitates API and CLI-based Inspectors. It typically is not deployed on-premise. Our documentation discussing the deployment and use of On-premise Agents focuses on the Windows Agent.

Rolling out On-Premise Agents

You can deploy Windows On-Premise Agents via MSI Installer or via an RMM Script.

You can deploy a Linux On-Premise Agent via our Linux Agent installation process.

❗️

Traffic to your Network/Websites

Please note that by enabling inspections, you will see new traffic from Agent machines depending on the inspection type. In order to verify traffic you see in your network or against an external facing entity is coming from Liongard, check the IP of a specific Agent via the Admin > Agents screen on your Liongard dashboard.

More details about finding the IP address of a specific Agent in Liongard can be found here.

Updated 28 days ago


Agents Overview


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.