Parameter substitution in relevance and action script questions

(imported topic written by JohnJ91)

What about using variables in prefetch statements? For example I have a fixlet that I constantly have to change the filename and sha1 values for. Is it possible to do variable substitution and if so is it excluded from prefetch? This way I don’t have to change every reference in the action script or relevance each time I get new files to send I can just change the parameter values in one spot?

Such as:

parameter “file1name” = “firstfilename”

paramater “file1sha1” = “abcdefg123456789”

parameter “file1size” = “1234”

prefetch “(parameter “file1name”)” sha1:"(parameter “file1sha1”)" size:"(parameter “file1size”)" http://mywebserver/"(parameter “file1name”)"

if {exists file “c:\mydir”(parameter “file1name”)""}

delete “c:\mydir”(parameter “file1name”)""}


copy “__Download”(parameter “file1name”)"" “c:\mydir”(parameter “file1name”)""

Would something like this work? Or does anyone have a way to make maintaining frequently changing fixlets easier?



(imported comment written by BenKus)

Hey JohnJ,

This won’t work in the normal prefetch command because this is an example of what we call a “dynamic download”… Dynamic downloads have a different (and more complex) syntax and are only available with BigFix 7.2+ agents. What version are you running?


(imported comment written by JohnJ91)

We are running the latest and greatest. on Windows clients, and on Linux.

(imported comment written by jessewk)

If you enclose the arguments to a prefetch statement in curly braces {} , the client will treat the arguments to the prefetch statement as a relevance expression and evaluate them before using the results to make a URL request to the server. Prior to a client making such a request, no files are downloaded on the server side.

If you don’t enclose any of the arguments to the prefetch statement in curly braces, the prefetch request is evaluated by the server at the time the action is issued and the files will be downloaded on the server immediately after issuing the action.

In the first instance you are able to use parameters because the client knows how to evaluate the relevance for itself in the local context. In the second instance, you cannot use parameters because the server cannot guarantee that the result for the parameter expressions will be the same on all clients.

Dynamic downloads (i.e., those that use relevance expressions) also require that you use the 7.2+ syntax for prefetch items. That is, you must specify a prefetch block and you must use the ‘add prefetch item’ command.

You also have a lot of syntax errors in the action script you posted.

Therefore, try something like this:

begin prefetch block
parameter “file1name” = “testfile.txt"
parameter “file1sha1” = “a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"
parameter “file1size” = “4"
add prefetch item {“name=” & parameter “file1name” & " sha1=” & parameter “file1sha1” & " size=” & parameter “file1size” & " url=” & parameter “file1name”}
end prefetch block

if {exists file (“c:\mydir” & parameter “file1name”)}
delete "c:\mydir{parameter “file1name”}"

copy “__Download{parameter “file1name”}” “c:\mydir{parameter “file1name”}”

Additionally, you will need to create a whitelist for the URLs. The whitelist is simply a file that is manually placed on the server at:

“\Mirror Server\Config\DownloadWhitelist.txt”

The file should be a newline separated list of regular expressions using the perl regex format. For a URL to pass the whitelist, it must match one of the regular expressions.

If a requested URL does not match any entry in the whitelist, the download will immediately fail and you will see an error in the action document, “The requested URL does not pass this deployment’s download whitelist”

The default whitelist (if the whitelist file does not exist, or is empty) fails all URLs.

You must restart the BES Root Server service for whitelist modifications to take effect.

Here is an example whitelist:**