Using private repo for caching?

[mesee2]

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}

  wait msiexec.exe /q /I “__Download\googlechromestandaloneenterprise64.msi”

  action may require restart “d4f8ff6483db4cfdab5ec972b2c14647cda4b279”

  // Otherwise should be 32bit
  else

  wait msiexec.exe /q /I “__Download\googlechromestandaloneenterprise.msi”

==
this is the fixlet that was published to cache on the BES server:

if {x64 of operating system}
prefetch googlechromestandaloneenterprise64.msi sha1:d4f8ff6483db4cfdab5ec972b2c14647cda4b279 size:78856192 https://dl.google.com/MANUAL_BES_CACHING_REQUIRED/googlechromestandaloneenterprise64.msi sha256:ce096f99178621dbb7be66737f61675f2c78861bee3b8e36cdb9738e4362df7f

wait msiexec.exe /q /I "__Download\googlechromestandaloneenterprise64.msi"

[D.Dean]

Fixlet ID 14011275?

My Fixlet does have the Manual Caching Required Language…

But we have not had any issues deploying. Need to look into this.

[D.Dean]

success

Odd, the deployment does not have the manual caching needed language

[mesee2]

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.

[JasonWalker]

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.

[mesee2]

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?

[JasonWalker]

I don’t think there are any plans around this.

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.

[D.Dean]

I noticed this yesterday and it makes sense to do it this way.

[mesee2]

Will ‘caching’ on the BES root server prevent issues when Google releases updates in the middle of the night during my patch cycle?

Since the signatures and size match from fixlet to cache, it should never know the backend Google site changed?

[JasonWalker]

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.

[Meghana]

Hello

We usually follow a rule in Patches:

1. Security Updates supersede both security and non-security updates
2. 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.

[JasonWalker]

Thank you for the explanation, I didn’t realize there was a non-Security update for Chrome and this really helps clear it up.

[straffin]

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).