Behind the scenes: How agents earn their living

The inventory software that runs on client machines is not called an agent just by pure coincidence. If we look up the definition of the noun 'agent', we end up with something like this: a representative who acts on behalf of other persons or organizations.

No doubt, the inventory agent fulfils that status quo. The organization for which the agent works is the central management server. Their work is clearly defined; they gather information, and send them back to the central server. They can also act as spies on identifying other hosts that are not inventoried. Network discovery is covered in Chapter 5,Investigating the Process of Gathering Inventory Data.

Besides these tasks, the agent also serves as a key position with regards to package deployment. When this situation occurs, the agent can ask for the file information from the deployment server, request the package, and prepare it for deployment execution.

We have enumerated the tasks of agents in terms of priority. The first and foremost task is sending in the inventory data, if it is required to do so. The task of identifying hosts that are not scanned from the network is the second most useful. It enhances network detection and reduces the bandwidth usage by adding distributed scanning into the mix. The server would otherwise be overwhelmed to scan the entire network, all by itself.

Package deployment is an optional feature of the OCS-NG inventory. In those configurations, where this functionality is not required, agents are not required to execute this task.

In situations that are networked, there is some kind of connectivity between the agents and the central management server; the agents always initiate the contact first. We can imagine this as the agent initiating the communication. This way, we do not need to open a port on the firewall and neither set up port forwarding. If browsing works, then this works too.

Communications happens through the HTTP and HTTPS protocols. On client machines, when the executables are monitored for outgoing traffic (by some kind of firewall), we might need to allow traffic to go back and forth from the OCS inventory agent file.

After the agent contacts the central management server, it replies with the task(s) to do, just like the big boss of an organization for which the agent is secretly working for. There are situations when there's nothing to do for the agent, and in these cases, the central server does not assign any of the tasks. This means that there is no mission available.

The agent always maintains an up-to-date inventory stored in an XML format. This is stored locally. After each communication query is initiated by the agent, the management server checks whether the inventory stored of that client is out of date or not. This is specified with the frequency value and a server-side variable on the OCS-NG server.

The value is specified in days, and it is used to determine how old the inventory is. We will learn about it in the next chapter. The deal is that once the last inventory date gets older than this value, the task of sending in the new inventory data is assigned to the client agent. Once received, the mission is carried out right away and the new inventory is sent in. The other tasks (network discovery and package deployment) are assigned in the same fashion.

There are exceptions to every situation. Inventorying is also possible on those machines that are not connected to the network where the OCS-NG server lies. For example, the client machines might be offline or might initiate a connection on user request. These require offline inventory mechanisms. The agent works in the same way. It gathers and stores the data locally. On hosts, that are not networked, it just won't be able to send them into the server.

In these situations, we need to manually transfer the inventory file (.OCS extension) to the central management server, and then manually import the file via the administration console.