I got contacted yesterday about one of our baselines giving the super unhelpful error message “One of the actions in this multiple action group contains an invalid action script”. I found this post later, so I don’t know why this generic error message is still used in the BigFix code. Anyone official know if this message is going to be replaced with the version that actually tells you the name of the offending fixlet?
After figuring out which fixlets were causing the issue, the offending line was “continue if {sha1 of file (parameter “BackupFile”) = (parameter “InstallFileHash”)}” as shown in the example below. The error message is “Hash argument is invalid”.
begin prefetch block
add prefetch item name=2644C9006D74BC27D284ACCA18C579C6AD36B5E2 sha1=2644c9006d74bc27d284acca18c579c6ad36b5e2 size=649 url=SWDProtocol://127.0.0.1:52311/Uploads/2644C9006D74BC27D284ACCA18C579C6AD36B5E2/BackupToRegistersIni.bftemp.bfswd sha256=2e2a1dfd7c9b10e323c8bb6c678b0cc86849528a162e4f4e95cbf4e1d3b06648
end prefetch block
parameter "BackupFile" = "C:\Temp\Backup\test.txt"
parameter "InstallFile" = "C:\Temp\Dest\test.txt"
parameter "BackupFileHash" = "{sha1 of file (parameter "BackupFile") | "BackupFileHash"}"
parameter "InstallFileHash" = "{sha1 of file (parameter "InstallFile") | "InstallFileHash"}"
continue if {sha1 of file (parameter "BackupFile") = (parameter "InstallFileHash")}
continue if {parameter "BackupFileHash" = parameter "InstallFileHash"}
When I was trying to repro the issue it got even more strange. At first I couldn’t get my test fixlet to produce the error. It wasn’t until I added a prefetch command that it refused to run and gave the error. So not only does the error not make sense, it is somehow tied to having a prefetch block?? I’m at a loss.
We recently upgraded our dev environment to v10.0.0.133 so I suspect the issue is caused by something in this version.
I can’t find the details, but I do recall something about the evaluation and execution order being affected by a prefetch block.
I think all of the parameters are evaluated first - so your hash of the downloaded file happens before the file is downloaded.
Hopefully someone from Bigfix will wander by shortly and confirm.
Very tricky to figure this one out. Back in BigFix 7, before the prefetch action command and before prefetch blocks, we had to validate integrity of file downloads with a 2 part action script.
download http://bigfix.com/foo.txt
continue if {sha1 of it = 123123 and size of it = 123} of file "foo.txt" of folder "__download"
It looks to me like Line 11 is incorrectly being incorrectly identified by the action script parser as a pair to a download/continue if statement because of the placement of the sha1 check.
If you swap the arguments around the = you can bypass the issue.
begin prefetch block
add prefetch item name=2644C9006D74BC27D284ACCA18C579C6AD36B5E2 sha1=2644c9006d74bc27d284acca18c579c6ad36b5e2 size=649 url=SWDProtocol://127.0.0.1:52311/Uploads/2644C9006D74BC27D284ACCA18C579C6AD36B5E2/BackupToRegistersIni.bftemp.bfswd sha256=2e2a1dfd7c9b10e323c8bb6c678b0cc86849528a162e4f4e95cbf4e1d3b06648
end prefetch block
parameter "BackupFile" = "C:\Temp\Backup\test.txt"
parameter "InstallFile" = "C:\Temp\Dest\test.txt"
parameter "BackupFileHash" = "{sha1 of file (parameter "BackupFile") | "BackupFileHash"}"
parameter "InstallFileHash" = "{sha1 of file (parameter "InstallFile") | "InstallFileHash"}"
//continue if {sha1 of file (parameter "BackupFile") = (parameter "InstallFileHash")}
continue if { (parameter "InstallFileHash") = sha1 of file (parameter "BackupFile")}
continue if {parameter "BackupFileHash" = parameter "InstallFileHash"}
Thanks Brolly, that makes more sense. I couldn’t fathom why the existence of a prefetch block would have any bearing on my sha1 check. Hoping a BigFix employee here can reproduce the issue and verify this is a v10 bug.
I suspect that this behavior exists on BigFix 9.2 and 9.5, but I don’t have an instance handy to test it.
It does seem bug-like and reproducable with an easy workaround.
If you are looking for a more formal response, I would encourage you to open a trouble ticket with this issue, so it gets properly tracked and fed into BigFix Development. support.bigfix.com
Unfortunate. The problem I have with this is that HCL doesn’t pay me a salary, so I am not inclined to do their work for them. Sorry but I’m going to get on my soapbox for a minute.
I was inconvenienced by this bug. I spent my employer’s time and money to investigate why these fixlets started breaking all of a sudden, tracking down all of the fixlets that now have this issue, spent time creating a detailed forum post which will be helpful to other people if they run into this issue, and the official response I get is “please spend even more of your own time to create a ticket”.
I understand that some issues are complex or tied to certain configurations that may be unique to the customer’s environment. It makes sense to create a support case for those situations so a dedicated tech can get involved and investigate. This is not one of those times.
Existing BigFix customers, especially people who take the time to use these forums to get help and give help, are valuable assets. Take care of us, and you will have more BigFix evangelists. Dismiss us, and we will go away. Here are some examples of what great customer service looks like:
“Thanks for taking the time to let us and others know about this issue. I was able to verify it is a bug and have created a ticket so we can try and fix it for the next release. Sorry for the inconvenience.”
“Thanks for taking the time to let us and others know about this issue. Unfortunately I was not able to reproduce it. I’ve created an internal support ticket and a representative will be contacting you to continue troubleshooting. I’ve sent you a private message so I can get further contact details.”
Thanks for taking the time to let us and others know about this issue
I will review this and will talk to our internal teams to see how we can get this resolved.
I cannot promise I will not want a case opened for future issues as HCL pays me to work cases but I will set it up on my V10 and V9.5 environments next week and will update here with my findings and with what will be done to fix it.
Thank you everyone for your assistance, and apologies for the rant. I strongly believe that the main advantage of the forum is the public discussion and troubleshooting that usually happens when a bug or issue is discovered. Documenting the issue and verifying it here helps benefit everyone. Thanks again.
So I spent some time today and created a 9.5 instance. The behaviour appears to be new in 10.0.
9.5 allows me to use the prefetch block and continueif without modification.
but I will set it up on my V10 and V9.5 environments next week and will update here with my findings and with what will be done to fix it.