I appreciate the new Chrome fixlet which now wants to download and cache the chrome exe. I noticed it appears to be able to translate the “MANUAL_BES_CACHING_REQUIRED/” to be the Bigfix server’s local repo without any major updates, but is there a similar simple to direct this to the private repo?
I am doing this but wondering if there is an easier way:
rewriting the action to use prefecth block and add prefetch item… etc
begin prefetch block
add prefetch item name = googlechromestandaloneenterprise64.msi sha1=b1bef34124e05acfb6b5ebc36f386ada73bf4063 size=78880768 url={value of setting “_BESClient_AllowCustomRepoDownloads” of client | “https://dl.google.com/MANUAL_BES_CACHING_REQUIRED/”}chrome/googlechromestandaloneenterprise64.msi sha256=0cb73b524004fd03a840e0ee46cfa2498a55ac102bd9737c3f232f7460535768
add prefetch item name = googlechromestandaloneenterprise.msi sha1=a93bcfca5444b12f3dfd6776e4c7568561e727f1 size=76324864 url={value of setting “_BESClient_AllowCustomRepoDownloads” of client | “https://dl.google.com/MANUAL_BES_CACHING_REQUIRED/”}chrome/googlechromestandaloneenterprise.msi sha256=dee48d6bb99dbd2f8de5da2b60dbbb389a57c1ff909b6ff8b83aea9325202e80
end prefetch block
// Check 64bit Chrome
if {x64 of operating system}
Yes – it has manual but does not have reference to the “_BESClient_AllowCustomRepoDownloads” which allows for the system to download from a different server. By default the Manual_Bes_caching looks in the BES primary server webroots, I however prefer to keep these files on a separate server which just hosts these one off files for the systems to reference.
I agree the use of _BESClient_AllowCustomRepoDownloads would be preferred, but I can see that there are some complications to consider on it.
The AllowCustomRepoDownloads option was originally envisioned for things like Java - where every Java binary had a different filename, they could all live side-by-side in the repo folder and every version’s fixlet could find the file it needed. And, they really did need to be manually downloaded, per Oracle licensing and a captive download site.
Every version of Chrome has an identical download URL - Google replaces the binary in-place. Which means the file name beneath the path references at _BESClient_AllowCustomRepoDownloads would also have to be in sync with whichever version of the Chrome fixlet you wish to deploy.
As far as the BES server is concerned, there’s nothing special about the MANUAL_BES_CACHING_REQUIRED string, it’s just there to help out us humans to easily spot the manual download is necessary. For every download the server always checks whether the file is already present at bfmirror/downloads/sha1 before downloading it from the Internet - that’s how the AirgapTool and BESDownloadCacher allow disconnected BigFix servers to work without Internet access.
I’m not sure what the ideal solution / workaround would be for this special-case where the version changes frequently, and every version uses the same download URL.
Is there any plans to allow the BESClient_allowCustom variable to be referenced the same as the manual_BES_Caching and not need to have a 'setting “xxx” of client | xxx type url?
To be clear, this MANUAL_BES_CACHING_REQUIRED url change was to a superseded version of Chrome, which is no longer available for public download in any case. The current versions of Chrome continue to use the public download URL for Google Chrome.
Yes, once the Chrome download has been cached, that version of the fixlet will continue to work even after Google updates the download on their end, at least until the root server removes the file from it’s cache. Check your server cache settings and ensure they are large enough to avoid purging the download too quickly.
Security Updates supersede both security and non-security updates
Non-Security updates supersedes only non-security updates
For chrome also we follow the same rule.
For an instance, Chrome released security update and after that non-security update, so in this case we cannot supersede the security update. When we leave it unsuperseded, it will become applicable to machines and when we try to take action it gives sha mismatch error as the Google releases same download URL for all the updates. So in order to overcome this issue we do add manual caching for the security update.
So we add manual caching to security updates only when the next release is non-security, not for all updates.
This logic makes sense, but only if Chrome allows the download of the older version. After the fact, unless an operator had already manually downloaded the earlier version of Chrome, there’s nothing they can do with that fixlet. Perhaps a better path would be to leave the fixlet non-superseded and change the description to indicate that the proper course of action would be to upgrade Chrome to the latest available version? It’s an all-text fix, but it’d be clearer than the manual caching solution (in my opinion, anyway).
