Disable snapin hashing
-
@JJ-Fullmer I found some time to dive into this and figured that I am still missing the initial question/answer. What is actually causing an issue for you here? Sorry if this sounds like a dumb question but I am still not sure how to try and replicate the issue you see as I can’t see the exact error it is causing for you!?
Do you see a message in the fog-client log like this?
Hash does not match --> Ideal: ... --> Actual: ...
Or is it the snapin replication that causes you grief?
Testing the script you posted I ran into an error:
... Write-Verbose "Updating hases for all snapins"; $snapinScript = Get-Item Get-Item "path\to\chocoPkgSnapin.ps1";
Get-Item
called onGet-Item
fails for me. I suppose this was just a copy&paste thin.While I understand that your
chocoPkgSnapin.ps1
script has not changed in some time I still wonder if you are aware of your script code seems to not actually upload the file contents. While it does create a snapin definition it does not update thechocoPkgSnapin.ps1
on the server at all. I might be wrong with that. You know I am more a Linux shell than MS Powershell guy. But I am sure we’ll figure this out.Disabling hashing is not something I want to rule out. Don’t get me wrong on this. I am just trying to get my head around this before I can see what we are heading for with this.
-
-
@Sebastian-Roth That is a internal function in that script. I’m pretty sure that it is the same as the Invoke-FogApi function I have in the published powershell module, so you could find it here https://github.com/FOGProject/fog-community-scripts/blob/master/PowershellModules/FogApi/FogApi.psm1
It’s renamed here to avoid clobberring I think as I may have written the code I pasted as an example here before I made the uninversal module. -
@Sebastian-Roth That is the general idea of what happens in the fog log yes. I get a hash doesn’t match error.
I took out the paths when I copied pasted the script, I think that duplicate get-item is just a typo.
I beleive I am trying to not update the file on the server here, instead of trying to re-upload the file everytime I am just getting the correct information about the file (name, size, hash) and trying to force every snapin database entry to match the file’s details correctly. Somehow though I end up with different hash’s during deployment. If I export the snapins, they all look the same in the exported csv as they should. It’s like something happens when the snapin is deployed where it changes. -
function Invoke-FogApiChocoSnapin { <# .SYNOPSIS a cmdlet function for making fogAPI calls via powershell .DESCRIPTION takes a few parameters with a default that will get all hosts Makes a call to the api of a fog server and returns the results of the call The returned value is an object that can then be easily filtered, processed, and otherwise manipulated in poweshell. i.e. you could take the return value of the default all hosts and run $(invoke-fogapiChocoSnapin).hosts | where name -match "$(hostname)" to get the host information for the current computer .PARAMETER fogApiToken a string of your fogApiToken gotten from the fog web ui. Can be set in the function as a default or passed to the function .PARAMETER fogUserToken a string of your fog user token gotten from the fog web ui in the user section. Can be set in the function as a default or passed to the function .PARAMETER fogServer The hostname or ip address of your fogserver, defaults to the default fog-server .PARAMETER uriPath Put in the path of the apicall that would follow http://fog-server/fog/ i.e. 'host/1234' would access the host with an id of 1234 .PARAMETER Method Defaults to 'Get' can also be .PARAMETER jsonData The jsondata string for including data in the body of a request .EXAMPLE #if you had the api tokens set as default values and wanted to get all hosts and info you could run this, assuming your fogserver is accessible on http://fog-server Invoke-FogApiChocoSnapin; .Example #if your fogserver was named rawr and you wanted to put rename host 123 to meow Invoke-FogApiChocoSnapin -fogServer "rawr" -uriPath "host/123" -Method "Put" -jsonData "{ `"name`": meow }"; .Link https://news.fogproject.org/simplified-api-documentation/ .NOTES The online version of this help takes you to the fog project api help page #> [CmdletBinding()] param ( [string]$fogApiToken = '', [string]$fogUserToken = '', [string]$fogServer = "fog-server", [string]$uriPath = "host", #default to get all hosts [string]$Method = "Get", [string]$jsonData #default to empty ) begin { # Create headers Write-Verbose "Building Headers..."; $headers = @{}; $headers.Add('fog-api-token', $fogApiToken); $headers.Add('fog-user-token', $fogUserToken); # Set the baseUri Write-Verbose "Building api call URI..."; $baseUri = "http://$fogServer/fog"; $uri = "$baseUri/$uriPath"; } process { Write-Verbose "$Method`ing $jsonData to/from $uri"; if ($Method -eq "Get") { $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -ContentType "application/json"; } else { $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -Body $jsonData -ContentType "application/json"; } } end { Write-Verbose "finished api call"; return $result; } }
-
@JJ-Fullmer said in Disable snapin hashing:
That is the general idea of what happens in the fog log yes. I get a hash doesn’t match error.
Ok, in this case we’d need to provide a new patched fog-client installer binary for you that doesn’t do the hash sum checking or has an option to select if it should check or not. But you’d need to deploy the new client installer to all your hosts. I am wondering if that’s all worth it. Probably easier to figure out why the hash mismatch is being caused while it shouldn’t be?!
First let’s try to gather some more information. Leave the snapin as is for now and only schedule snapin tasks for clients and let those run.
- Does it randomly fail on the same host? So if you schedule the same task on one host ten times in a row, does it run through all the time if it is fine on the first run?
- When it magically fails on a host can you please grab that host and take a look at
C:\Program Files (x86)\FOG\tmp
. I have not checked the code yet but I would hope the fog-client leaves a copy of that file there on failure. Now check if that file is zero size or truncated or anything like that. - On snapin failure as well pay attention to the apache and PHP-FPM log files to see if there is an HTTP/PHP error on snapin download (see my signature).
- Please post the full fog-client log here in case of a failure so we can have a look. Sometimes there is something we see that leads us to the real problem.
If that doesn’t help we can go ahead an try monitor the database for changes of the hash. FOG has a deamon running that updates the snapin hashes from time to time. Unlikely but maybe this is causing an issue. You can take a look in that log file (webUI -> logs -> snapin log) and even disable that in another step just to see if it interferes.
-
First let’s try to gather some more information. Leave the snapin as is for now and only schedule snapin tasks for clients and let those run.
- Does it randomly fail on the same host? So if you schedule the same task on one host ten times in a row, does it run through all the time if it is fine on the first run?
I don’t typically try it more than once maybe twice, if it fails I just run the command manually. But I will give that a try. See if I can’t recreate it on my computer.
- When it magically fails on a host can you please grab that host and take a look at
C:\Program Files (x86)\FOG\tmp
. I have not checked the code yet but I would hope the fog-client leaves a copy of that file there on failure. Now check if that file is zero size or truncated or anything like that.
It does not leave a copy, it does put a copy there and if you’re watching it you can copy it real quick or you can stop the fogservice before the hash check if you’re lucky. I think I did that once when I first discovered the issue but don’t recall the result, I remember it being confusing, I guess I’ll have to try this again too.
- On snapin failure as well pay attention to the apache and PHP-FPM log files to see if there is an HTTP/PHP error on snapin download (see my signature).
Good thought will give those a post.
- Please post the full fog-client log here in case of a failure so we can have a look. Sometimes there is something we see that leads us to the real problem.
Standby
If that doesn’t help we can go ahead an try monitor the database for changes of the hash. FOG has a deamon running that updates the snapin hashes from time to time. Unlikely but maybe this is causing an issue. You can take a look in that log file (webUI -> logs -> snapin log) and even disable that in another step just to see if it interferes.
I was hoping there is a way to disable it on the server, maybe something in the database or something, because I didn’t want to go through the trouble of recompiling the fog client. The other trick is that I really only use snapins during provisioning right after I image a computer. But I guess if I want it fixed I oughta suck it up.
The only other thing that may be a factor is I also add the snapins to the host and initiate the task from the api during provisioning. So It’s possible that it being queued from api causes this too, we’ll see if that’s the case though since I’ll be testing by deploying through the gui.
-
Ok so it appears to be working when I queued the tasks from the gui. I did grab the file while something was deploying and the hash was the same this time.
So maybe this only happens when the snapin is queued from the api, doesn’t make a ton of sense, but maybe.Could also be related to when a host is new perhaps. I will try to be more vigilante in logging the next time it happens if I can’t recreated it by queuing the snapins from the api
ps this would be how I am queuing a all snapins task in powershell
function Start-FogSnapins { [CmdletBinding()] param ( $hostid = ((Get-FogHost).id), $taskTypeid = 12 ) begin { Write-Verbose "Stopping any queued snapin tasks"; $tasks = Invoke-FogApi -Method GET -uriPath "task/active"; $taskID = (($tasks | Where-Object hostID -match $hostid).id); Write-Verbose "Found $($taskID.count) tasks deleting them now"; $taskID | ForEach-Object{ Invoke-FogApi -Method DELETE -uriPath "task/$_/cancel"; } # $snapAssocs = Invoke-FogApi -uriPath snapinassociation -Method Get; # $snaps = $snapAssocs.snapinassociations | ? hostid -eq $hostid; } process { Write-Verbose "starting all snapin task for host"; $json = (@{ "taskTypeID"=$taskTypeid; "deploySnapins"=-1; } | ConvertTo-Json); Invoke-FogApi -Method POST -uriPath "host/$hostid/task" -jsonData $json; } end { Write-Verbose "Snapin tasks have been queued on the server"; return; } } function Get-FogHost { [CmdletBinding()] param ( [string]$uuid, [string]$hostName, [string]$macAddr ) begin { [bool]$found = $false; Write-Verbose 'Checking for passed variables' if (!$uuid -and !$hostName -and !$macAddr) { Write-Verbose 'no params given, getting current computer variables'; $uuid = (Get-WmiObject Win32_ComputerSystemProduct).UUID; $macAddr = ((Get-NetAdapter | Select-Object MacAddress)[0].MacAddress).Replace('-',':'); $hostName = $(hostname); } Write-Verbose 'getting all hosts to search...'; $hosts = (Invoke-FogApi).hosts; Write-Verbose "search terms: uuid is $uuid, macAddr is $macAddr, hostname is $hostName"; } process { Write-Verbose 'finding host in hosts'; [bool]$found = $false; $hostObj = $hosts | Where-Object { ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) -OR ` ($hostName -ne "" -AND $_.name -eq $hostName) -OR ` ($macAddr -ne "" -AND $_.macs -contains $macAddr); if ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) { Write-Verbose "$($_.inventory.sysuuid) matches the uuid $uuid`! host found"; $found = $true; } if ($macAddr -ne "" -AND $_.macs -contains $macAddr) { Write-Verbose "$($_.macs) matches the macaddress $macAddr`! host found"; $found = $true; } if ($hostName -ne "" -AND $_.name -eq $hostName) { Write-Verbose "$($_.name) matches the hostname $hostName`! host found"; $found = $true; } } } end { if ($found){ return $hostObj; } return $found; #return false if host not found } }
-
I can’t seem to recreate it, but I know it’s broken whenever I deploy a new computer. So next time I have to image a computer I’ll come on back
-
@JJ-Fullmer @Sebastian-Roth I would really like some help in this area as well. I am creating snapins and just got stuck in the same spot.
---------------------------------SnapinClient---------------------------------
4/23/2019 12:39 PM Client-Info Client Version: 0.11.16
4/23/2019 12:39 PM Client-Info Client OS: Windows
4/23/2019 12:39 PM Client-Info Server Version: 1.5.4
4/23/2019 12:39 PM Middleware::Response Success
4/23/2019 12:39 PM SnapinClient Running snapin test
4/23/2019 12:39 PM SnapinClient ERROR: Snapin hash does not exist@JJ-Fullmer check it out using your stuff
$dataSet = @{“name” = “test4”
“description” = “test4”
“file” = “MA-Redirect.ps1”
“args” = “747EPO.CDA.BEA.LAB”
“runWith” = “powershell.exe”
“isEnabled” = “1”
“runWithArgs” = “-ExecutionPolicy Bypass -NoProfile -File”}
$dataToSend = ($dataSet | ConvertTo-JSON)
New-FogObject -type object -coreObject snapin -jsonData $dataToSend
-
@mparlette said in Disable snapin hashing:
SnapinClient ERROR: Snapin hash does not exist
Is the
FOGSnapinHash
service running on your FOG server? How long did you wait after clearing the snapin? -
@Sebastian-Roth Yes.
My setup is almost exact to @JJ-Fullmer except I am on 1.5.4
[root@localhost snapins]# systemctl status FOGSnapinHash
● FOGSnapinHash.service - FOGSnapinHash
Loaded: loaded (/usr/lib/systemd/system/FOGSnapinHash.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2019-02-05 16:19:42 PST; 2 months 15 days ago
Main PID: 2447 (FOGSnapinHash)
CGroup: /system.slice/FOGSnapinHash.service
├─2447 /usr/bin/php -q /opt/fog/service/FOGSnapinHash/FOGSnapinHash &
└─2475 /usr/bin/php -q /opt/fog/service/FOGSnapinHash/FOGSnapinHash &Feb 05 16:19:42 localhost systemd[1]: Started FOGSnapinHash.
Feb 05 16:19:42 localhost systemd[1]: Starting FOGSnapinHash… -
@Sebastian-Roth OK. I just didn’t wait long enough sorry to rattle your cage. Thanks for the help it did the hash just waited a while and it’s working now.