Hello!
This post specifically covers BigFix Download Plugins and how they work. You likely use download plugins if you are patching RHEL, AIX, Solaris, or using Software Distribution. You may already know that Download Plugins allow BigFix to download content that is behind some sort of download restriction (like requiring a subscription).
I am not an IBM Employee and, as there is little documentation on this matter, the information in this post is based entirely on my hands-on experience writing and using Download Plugins.
Download Plug-in Installation Overview
Installation
Download Plug-ins are typically installed into the BES Server\DownloadPlugins directory on the root server.
Alongside the Plug-in typically sits a configuration file where the plug-in stores certain configuration information like logging verbosity.
Registration
For the server to know a plug-in exists, it must be registered with the server.
Download Plug-ins are registered by dropping a JSON file into BES Server\Mirror Server\Inbox. The JSON file looks like this:
{
"message" : "add",
"protocol" : "MYProtocol",
"location" : "C:\PathToMyDownloadPlugin\Plugin.exe"
}
The Mirror Server will gobble this up and register the download plugin. The registration process adds a row to the DownloadPlugins.db SQLite database located in BES Server\Mirror Server\Config directory.
The database has two columns:
- Protocol Identifier (“MYProtocol”)
- Plugin Location (“C:\PathToMyDownloadPlugin\Plugin.exe”)
Download Plug-in Runtime Overview
A Download Plug-in operates like many other server components in that they are invoked by the BESRootServer service and they take command line arguments and pass information back and forth using mailboxes.
Invocation
A Download Plug-in is invoked when an action is created that has a prefetch starting with the protocol we registered our Download Plug-in with. If our Download Plug-in uses MYProtocol then our download plugin will be invoked whenever a prefetch has a URL of MYProtocol://anywebsite/anyfile.exe
When the Plug-in is invoked it is passed a single command line argument:
--download=C:\Windows\temp\bes123124.tmp
The --download parameter points to a .tmp file which has in it a small amount of JSON that looks like this:
{
"id": 1476622591,
"inbox": "F:\\Program Files (x86)\\BigFix Enterprise\\BES Server\\Mirror Server\\inbox",
"downloads": [
{
"id": 116,
"file": "F:\\Program Files (x86)\\BigFix Enterprise\\BES Server\\wwwrootbes\\bfmirror\\downloads\\ActiveDownloads\\indexed_9343_1",
"url": "MYProtocol:\/\/myWebsite\/myApp.exe",
"sha1": {
"algorithm": "sha1",
"value": "850f643bb715782f120edb8eee982b0f3543a332"
},
"size": null
}
]
}
This provides an ID for the download, where status messages should be placed (inbox) the location to place the download (file) and the URL to obtain it from (URL)
Processing
The Plug-in then processes the download by translating the URL into something usable (Removing the protocol definition and replacing it with HTTP, HTTPS, FTP, etc).
The Plug-in writes the file as it downloads to the location specified by “file” in the case of the above json file, the plugin would write the downloaded file to "F:\\Program Files (x86)\\BigFix Enterprise\\BES Server\\wwwrootbes\\bfmirror\\downloads\\ActiveDownloads\\indexed_9343_1"
Because we are saving it in a location the server is watching as the file downloads the operator is notified of the progress:
Completion
Once the download has finished the Plug-in provides a completion notification to the mirror server at the location provided in the provided JSON above (in this case, “inbox”). The notification is a JSON file with a name of plugin_<download id>_0 and contains the following:
{
"status": [
{
"error": "",
"id": 14,
"success": true
}
],
"message": "status",
"id": 1476764753
}
This is the ID and DownloadID from before along with whether we were successful or not. Any text provided in the error item here will be displayed to the console operator if there is a failure:
In this case i’m reporting up the message from a powershell exception into the BigFix console:
Use-Case
In my situation there is a very popular open-source repository called FossHub.com which hosts a large number of Open Source projects a number of projects use only FossHub.com to host their binaries.
This is an issue because FossHub.com prevents hotlinking directly to files (which is what we need to form prefetches). It does this by only attaching time bombs to their URLs so that they stop working within minutes to hours after obtaining them.
It makes perfect sense for them to prevent hotlinking from strangers as they don’t want people mass-consuming their bandwidth. Unfortunately this model doesn’t take into account that, in our case, BigFix will only download the file once from fosshub.com even if it installs on tens of thousands of machines (Because the root server and relays cache the installer).
In the case of FossHub we can use a download plug-in to get around this restriction and allow the download to proceed.
I’m hoping to finalize this download plug-in and make it available as part of C3-Patch in the coming weeks so that the content we provide that uses FossHub will no longer require manual caching.
Summary
Like most other things I write about if you’re thinking about writing a download plug-in it’s probably not the right answer to your problem but if have any thoughts or questions please don’t hesitate to reach out 
Thanks!
Bill