Move content downloading to a Relay

In his post at Dynamic Download for Firefox Fixlets, @jgstew mentions using a Relay to handle the content downloading tasks.

Can the BES Server be configured to not do file downloads itself, but have a Relay do that instead? What settings would need to be configured on a BES Server to operate that way?

1 Like

I believe you would set these values (to 0) to get the relay to download directly (after asking the server for it):
_BESGather_Download_CheckInternetFlag

and change this one to not check the server for any files:
_BESGather_Download_CheckParentFlag

This will allow the client to do the same:
_BESClient_Download_Direct

Taken from:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli+Endpoint+Manager/page/Configuration+Settings

Yes, the root server should be able to be configured so that it does not download files from the internet and the top level relay would do that instead. I have never done this, but as far as I know it should work.

You want to configure the following on the top level relay:

_BESClient_Download_Direct=1
_BESGather_Download_CheckParentFlag=0
_BESGather_Download_CheckInternetFlag=1
_BESGather_Download_CacheLimitMB=SOMETHING_LARGE

This should allow the top level relay to handle the storage and downloads of internet files, which will take that load off of the root server. This is nice because it is much easier to swap out a relay as needed than to do so with the root server. It also allows the root server to not have internet access but still allow internet facing downloads to function.

If your installation is large enough, then it makes sense to have what I would call a “Super Top Level Relay” which is designed to take as much load off of the root server as possible, including internet downloads, message level decryption, etc…

The root server could be configured to use a proxy with very limited access, and the top level relay could also use a proxy if needed, but with broader access.

You can go a step further and have this super top level relay masquerade as the root server in a configuration called “hidden root”.

3 Likes

I’d love to hear more about the hidden root configuration. Right now I’m running with two servers in a DSA configuration, one on either side of an isolation firewall. This allows the Internet-facing DSA to handle downloads, which I then copy to the private DSA server using wget. The DSA replication (database + sites) allows for all client reports to be seen from either server, and actions can be taken on either server, but the configurations you describe sound superior.

1 Like

Assuming these are Windows Root Servers, you could have the webcache on a separate DFS volume that is automatically replicated between the 2 servers in DSA configuration. This should remove the need for WGET or a manual process to get the downloads onto both servers.

Also, if essentially everything is replicated to both servers, then what is the advantage of having one internet facing while the other is not?

I don’t deny that the primary advantage is to provide an appearance of security for inquiring minds.

Operationally, we do have an ability to sever the links between the Public-facing and our Private environments’ DSA servers, and then to manage both sides independently; while in a nominal configuration we get replicated baselines, fixlets, and client reports that are available on both sides.

Because the two DSA servers are on separate Forests, using DFS replication is not an option. What I have is a script that runs nightly on the Public-facing DSA server, builds a list of all of the files under bfsites/downloads/sha1, and saves that to a text file. The Private-side DSA server downloads this file, and uses wget to retrieve any files that are missing from the Private side.

We use the Airgap tool to provide the Gather function, downloading updated copies of the BES Sites for the Private DSA server, and the Download Cachers to precache downloads on the Public-facing DSA (which then get picked up on the Private DSA using the wget script).

1 Like

@jgstew are referring to the practice of having the FQND in the masthead resolve to a top level relay instead of the root server ?

1 Like

Yes. I haven’t done it myself, but it is something in active use by some organizations. It has many benefits.

@JasonWalker - there’s a brief description of Fake Root in the @sbl’s presentation

1 Like

Thanks, I ran through the Prezi version today. It’s difficult sometimes to take a step back and put the Big Picture all in one place, so I can appreciate the effort it must have taken to put this together.

1 Like