Disable snapin hashing

  • Testers

    Would like to disable snapin hashing

    The way I use snapins, I have one script that takes arguments. The script essentially makes either a interactive or background scheduled task to install a chocolatey package given in the parameters to the script. The script is simple and it works, and really I don’t even need it included with the snapins because I have it installable from an internal powershell repo and could just have the snapin tool run a powershell command. But a snapin currently requires a file, and that file has a hash, and checking it seems to be required. Somehow my hash keeps changing, so I want to disable the hash checking.

    The scenario in more detail

    So all my snapins use the same powershell script. This script hasn’t changed in some time. However, somehow the hash keeps changing when I try to deploy snapins. I have some automations in place using the api that make my snapins for me and I’ve tried many things to try and ensure the hash is right. However I have found that if I try to create a new snapin with a ‘snapin file exists’ setting it gets the wrong hash. Or if I do it with the api, the has doesn’t match. I even make it so every time I push a snapin through the api it re-uploads the powershell script, grabs the hash of the uploaded script and updates the hash value in the database for every snapin. But it still doesn’t stick 100%.

    Easiest solution

    While it is possible that there’s something I’m doing somewhere that keeps causing the hash to change. I would find it much easier for my environment to disable the hashing. The hash check is a cool feature, and I remember when it was being added for cases where people have large files they’re sending in a snapin and want to make sure the whole file downloaded. But I’m sending one tiny script file of a few kb that doesn’t change. Since it’s somehow changing, I’d like the option to just disable that feature for my purposes. So I’m wondering if there’s any easy way that’s built in that I don’t know about. Or if I have to go into the database and change something, or some setting file on the server or if I have to recompile the client installer to have a custom client that doesn’t do snapin hashes. I’m willing to do what it takes, just need a little help.


    Fog Server 1.5.5
    Cent OS 7 x64
    Client version 0.11.16

    Please and thank you =)

  • Developer

    @JJ-Fullmer said in Disable snapin hashing:


    Where is this defined?

  • Developer

    @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 on Get-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 the chocoPkgSnapin.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.

  • Testers

    Here is the code I use to create a snapin after publishing a chocolatey package to my repo.
    I added the hashes after the problem started and it sometimes helps but it seems the behavior is slightly unpredictable and the hash record on fog still changes somehow.

    end {
            Write-Verbose "making sure package $global:packageName exists as fog snapin";
            if ( (Invoke-FogApi -uriPath "snapin/search/$global:packageName" -Method GET).count -eq 0){
                Write-Verbose "snapin does not exist, creating new snapin";
                $snapinScript = Get-Item "path\to\chocoPkgSnapin.ps1";
                $hash = ($snapinScript | Get-FileHash -Algorithm SHA512).Hash;
                $fileSize = $snapinScript.Length;
                $json = @{
                    "args"="-pkgname $global:packageName"
                    "runwithArgs"="-ExecutionPolicy Bypass -NoProfile -File"
                } | ConvertTo-Json;
                Invoke-FogApiChocoSnapin -uriPath 'snapin/new' -Method POST -jsonData $json -verbose;
            else {
                Write-Verbose "Snapin already exists";
            Write-Verbose "Updating hases for all snapins";
            $snapinScript = Get-Item Get-Item "path\to\chocoPkgSnapin.ps1";
            $hash = ($snapinScript | Get-FileHash -Algorithm SHA512).Hash;
            $fileSize = $snapinScript.Length;
            $snapins = Get-FogObject -type object -coreObject snapin;
            $snapins.snapins | Where-Object file -match 'choco' | ForEach-Object { $data = @{
                "id" = "$($_.id)";
                "name" = "$($_.name)";
                "file" = "$($_.file)";
                "runwithArgs"="-ExecutionPolicy Bypass -NoProfile -File";
                "args" = "$($_.args)";
                "hash" = "$hash";
            } | convertto-json; 
            Update-FogObject -type object -coreObject 'snapin' -IDofObject $_.id  -jsonData $data -uri "snapin/$($_.ID)/
            Write-Verbose 'Done!';

    Some of the snapins return 500 errors when I attempt to loop through them all and update their hash records.
    Since that isn’t working I’m really hoping there’s some way to disable the hashing function, even if it’s some hackish way in the database or something.

Log in to reply