Communicating with Docker contained based BigFix Client & Relay

Usage and Config Platform
1

I have deployed a BigFix Client within a Docker container. This has connected to, and registered with, its parent Relay, and is listed under Computers in the BigFix Console.

The Client is able to post its reports as per the default schedule.

However, if I attempt to deploy an action (or send a Refresh) to this Client, from the Console, the notification does not get through to the Client.

I know this is due to a network issue - since my Client is containerised, it has an internal IP assigned - 172.17.0.2. This is the IP the Client reports when it registers to the parent Relay. Obviously, if the parent relay attempts to communicate to the Client using this IP - the connection will fail.

I would welcome any ideas how to resolve this, if possible. If there is no solution, this will mean the Client can only check for actions as per its schedule. This will reduce the responsiveness of the infrastructure, as compared to normal.

2

With containerized dockers, aren’t you limited by the fact that the docker host controls the networking aspects of it’s containers? In other words, the containers aren’t actually exposed to the network directly.

You could increase reporting frequency by enabling command polling, but I am not aware of a way to enable communication from server to client in a network configuration like this.

1 Like
3

Thanks for the suggestion. I have arrived at the same conclusion that command polling will be our only option. However, upon configuring this - it is not behaving as I expected:

On my container-based Relay I have enabled the following client settings:

_BESClient_Comm_CommandPollEnable=1
_BESClient_Comm_CommandPollIntervalSeconds=900

I can see that the client is now polling for updates. However, the client is polling the local relay service (that is running on the same container instance (client and relay are both installed on the same instance). Since this container-based Relay is not receiving updates from the Parent Relay, it reports that there are no new actions. I had thought it would poll its Parent Relay - but that is not the behavior I am seeing.

So, my issue is that I need to enable polling from the container-based Relay to its Parent Relay. If this can be done, the new actions will flow down and the client will see them. I did find another client setting:

_BESRelay_GatherMirror_UpstreamCheckPeriodMinutes=10

I configured this (as well as the two command polling settings) - but it did not appear to make any difference. The gather request to the Parent Relay was not made (at least I did not see any actions coming down from the Parent Relay).

The only way I could get the container-based Relay to gather from its Parent Relay is:

  1. Manually restart the container-based Relay service - not an acceptable solution
  2. Wait for the default gather interval to arrive on the container-based Relay - this significantly increases the time for the actions to be processed and leads to a slow down in performing actions from the Console - this won’t be acceptable to my customer.

I was trying to determine exactly what the default gather interval for the Relay to reach out to its parent Relay is. From what I read it seems this is only once per day by default? Or is variable depending on whether any attached clients request a site refresh. In my tests I saw a gather after 30 mins. However, if this is variable it could be at any time.

Does anyone have an understanding of the Relay to Relay gather mechanism, the interval behavior, and how we might be able to control this?

4

Related: Relay Behind NAT with no forwarding

I would strongly recommend having the relay on the docker host have port 52311 exposed, in which case it should be able to get updates without the need for this.

You would only be able to expose a single relay per docker host this way.

Command polling would be the right solution for docker container clients so they can get things from their parent relay, but something like _BESRelay_GatherMirror_UpstreamCheckPeriodMinutes=10 is most likely required for an isolated relay to get updates from it’s parent.

I’m not sure why that setting wouldn’t have helped, though it might require relay service restart for that config to get picked up.

I wonder if this setting causes extra messaging in the Relay Log about it doing this?

5

Thanks jgstew - I wasn’t 100% sure whether the _BESRelay_GatherMirror_UpstreamCheckPeriodMinutes setting should go into the besclient.config or besrelay.config. The documentation does suggest besclient.config, but I wasn’t completely sure - given that this is really something that affects the Relay rather than the Client?

6

It is a client setting, which goes in /var/opt/BESClient/besclient.config on Linux, but you should set it using a bigfix action, like this example: https://github.com/jgstew/bigfix-content/blob/master/fixlet/clientsettings/Set%20__BESClient_Comm_CommandPollEnable_%20to%20_1_%20-%20Universal.bes

Actionscript:

setting "_BESRelay_GatherMirror_UpstreamCheckPeriodMinutes"="10" on "{ parameter "action issue date" of action}" for client

Or, you would configure it at install time using a clientsettings.cfg file, like this example: https://gist.github.com/jgstew/51a99ab4b5997efa0318

But, in order to make use of a clientsettings.cfg on linux, you need to use something like this to put the values into /var/opt/BESClient/besclient.config :

Which I use as a basis for creating docker clients in many different ways:

1 Like