Our Bigfix is in an isolated environment and patches are manually loaded into …\wwwrootbes\uploads<specific folder> by hand. I have noticed that those uploaded patches are automatically converted to sha files and placed in the \bfmirror\downloads\sha1 folder.
Question: Is there a default folder that BigFix knows to look in when it does this sha conversion work?
The default folder that the BigFix root BES server will interrogate prior to performing a download is \bfmirror\downloads\sha1, which you can manually inject files/objects into the cache.
The problem would come if the cache size is small enough that the sha1 converted files/objects are overwritten because of the FIFO (based on last date/time used) cache rules.
On a related note, while storing some files under \wwwrootbes\Uploads<etc> can be useful, it’s important to note that the FillDB service catalogs all files under \wwwrootbes… so if you happen to mount a NFS share (or similar) it can cause unintended issues with FillDB and specific tables in the BFEnterprise or BFENT databases (depending on if your MSSQL or DB2).
In the above case, it would be recommended to utilize a file repository like Artifactory, GitHub, etc. to house your payloads to be prefetched in custom content so that only a single instance of the file/object exists under \bfmirror\downloads\sha1.
Thank you for the reply. The folks I work with claim that there is a hidden process that moves files from the Upload directory into the SHA1 directory but I have not found that to be accurate. Am I correct or is there some process that does that?
It’s the process of clients/relays requesting the files from a defined website (i.e. MS updates, etc.) or under \wwwrootbes\Uploads via prefetch or similar Action Script method that implements the caching mechanism that places the files/objects under \bfmirror\downloads\sha1 cache folder.
It’s the prefetch that does it then…we have a fixlet that prestages the updates on the local client. I assume it is that fixlet that caches the updates. Thank you for the insight. It was most helpful.
They might be talking about the Custom Repository feature. On Windows clients we can specify a Client Setting for a custom repository. Check this task in Patching Support site for the settings that get applied:
43 Set or Update Custom Repository Setting (Windows)
That only works though for the Fixlets that are specifically written to use the Custom Repository setting. We provide that for sites (like Oracle) who do not allow us to directly download the patches (for Java) and instead require you, as an end user, to manually download and stage the patch files. We’ve crafted the download URL on those fixlets so you can keep a stable copy in another location, and not have to worry about the download cache cleanup purging your manual copy out of the downloads/sha1 folder.
A look at one of the Java updates for Windows illustrates how the download link is used:
add prefetch item name = jre-8u281-windows-x64.exe sha1=5835e46596fe9f4dfe48fd5dd3947dc650d196ec size=83548808 url={value of setting "_BESClient_AllowCustomRepoDownloads" of client | "http://download.oracle.com/MANUAL_BES_CACHING_REQUIRED/"}jre-8u281-windows-x64.exe sha256=27fd9a85f2b49ae6a11b15e36ab28c0493d5572357edf2990a65a2b56f1e1157
If your client computer has specified a value for _BESClient_AllowCustomRepoDownloads it will request the download from the URL you specify. That URL very well could be https://bigfix-root-server:52311/Uploads/MyCustomRepo
If you specify an AllowCustomRepoDownloads value, you can download the Java update and copy it to your repo (without needing to rename it or calculate sha1 value). If you don’t specify the value, you need to download the update, rename it to match its sha1, and copy it to your downloads/sha1 folder on the root server.
…but this AllowCustomRepoDownloads process is only used in the fixlets that are crafted to reference it.
thanks for the reply. I checked this and I did not see a custom repo configured but I will double check.