I have asked this a few months ago in the BigFix slack but I didn’t get any answer.
We are trying to find a way to let a multiple-action to continue its execution even when downloads have failed.
Our specific case scenario is related to the Chrome Fixlets:
Our SAs team test a baseline with the latest updates in a non-prod environment, once it is tested and validated, the baselines is officially approved to be deployed in production environments(No changes/updates are allowed to the baseline as that would break/violate the QA process).
So often, Google will release updates for Chrome and remove the downloads for the old version of the software hence BigFix is not longer able to download the content from Google.
This has happened right after we deploy the actions containing the previous version of the browser, and during the time it is deployed there is a new version. The action will stay in a Pending Downloads status and won’t move from there.
Is there any way to allow the download to be marked as Failed and let the servers execute the rest of the sub-actions?
At that point we would prefer to miss that single update than miss all the security updates.
I have found multiple similar questions. None of them seem to work:
I’m also aware of the possibility to use an action that installs the latest available version but that would require that we ignore the validation of the sha hashes which could mean a potential security risk.
tl;dr
How to allow a multiple-action to fail a download after an specific amount of retries and let the rest of sub-actions to run.
I have opted to always download a Chrome to a local Bigfix Repo, and update my own fixlet. This way i can choose to keep the entire environment on the same version through a patch cycle as well as avoiding the ‘random’ updates that were occurring throughout the patch night and the ‘hangs’ in the baseline due to download issues.
It also allows me to add a check for a freeze client setting option to keep form updating some systems which are slow to validate against new versions of Edge or Chrome, and if the update goes in could break some custom scripts.
I was going to suggest something close to what @mesee2 is describing but without the need to customize/copy the fixlet. As a part of your test work, just store the Chrome binary somewhere - even if you see that Pending download failure, just copy the binary (rename it to the original sha1 value it carries) to install_path\bes server\wwwrootbes\bfmirror\downloads\sha1 and see if it kicks start it. This should fake situation where the binary was already cached on the root server, so when it attempts to acquire it actually skips the need to download it from the vendor website and just starts distributes it down-chain through the relays and to the clients…
If you created a Baseline with content and deployed it to non-prod machines - the binaries will be cached on the Root Server
If you then take the same baseline and deploy it after some time, some content could be considered as “Superseded” - and would not be relevant for the targets themselves.
If you allow the Evaluation of Superseded content - The Fixlet will then try to fetch the binary from the BigFix Root Server by using the Relay architecture - If the binary is not there - It will try to get it from the specified URL
Let’s take for example the Google Chrome issue (headache )
The URL is the same but the SHA of course is different
If you at first managed to deploy the fixlet to the non-production, the file should be cached on the Root Server - If it is not there after sometime, you should check your Root Server Gather Download sizing and increase it
This will ensure that the BigFix Root Server will keep the binary files for a longer duration.
The way BigFix as I understand it work -
Evaluation - Relevant / Not
Pending Downloads - from Root Server \ Relay \ Internet > to the Client itself
Running - After Downloading the required binaries (it required - prefetch / download) Will run the rest of the Action Script
Completed / Fixed / Failed / Waiting … and so on
If the Action Script requires a binary file and it is not there, there is no reasonable reason to continue with the Action
I’m afraid I still don’t have a good answer for this. I expected to find an idea for it on the Ideas portal, but I couldn’t find one so I submitted a new one. Have a look at https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-373 and see whether that would meet the needs, and if so please give it an upvote.
The only workarounds I see for this today are to ensure the download is already cached on the root server before deploying the action to a wider set of systems, and that your download cache size on the root server is tuned large enough to ensure the download is not removed while it’s still being used in your environment. You could also use the File Precache Wizard to ensure the downloads get cached on the root, in case your test systems are not relevant for every download in the baseline.
)