Snapin Hash Issue

[UWPVIOLATOR]

@Wayne-Workman I lied its now doing it again.

[UWPVIOLATOR]

@Wayne-Workman Still have not done your update snapins set sHash = null;

but I created a new snapin and its always the same Hash regardless of what is uploaded.

Hash log says it checking and looks like this.

[06-05-17 12:19:23 pm]  * Trying Snapin hash for: Windows_10_and_Office_Activate, ID: 275
[06-05-17 12:19:23 pm]  | Snapin hash already set
[06-05-17 12:19:23 pm]  * Trying Snapin hash for: Windows_7_and_Office_Activate, ID: 71
[06-05-17 12:19:23 pm]  | Snapin hash already set```

[Tom Elliott]

@UWPVIOLATOR How big is the file?

Smaller files should not have this problem.

Is it possible /tmp is set to noexec?

[UWPVIOLATOR]

@Tom-Elliott

Super small .bat files

I have reuploaded, deleted and recreated and it still is not hashing correctly.

[UWPVIOLATOR]

@Tom-Elliott

This was a brand new file and snapin. All it is, is a batfile that says REM This is nothing

Uploaded the snapin. FOG Say it is a93f93076abc51757f22fc9776c5f12fe67b68c25fc3358d244ee75ff83be23a29c19e690d9b6875c7834640c0ba109ad8becf3a1c0df247b488caca98375945

Here is what happens when pushing it out.

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 6/5/2017 12:30 PM Client-Info Client Version: 0.11.12
 6/5/2017 12:30 PM Client-Info Client OS:      Windows
 6/5/2017 12:30 PM Client-Info Server Version: 1.4.1
 6/5/2017 12:30 PM Middleware::Response Success
 6/5/2017 12:30 PM SnapinClient Running snapin Test 2
 6/5/2017 12:30 PM Middleware::Communication Download: http://fogserver/fog/service/snapins.file.php?mac=02:50:41:00:00:01|3C:52:82:4D:86:83|00:28:F8:66:06:A8|02:28:F8:66:06:A7|00:28:F8:66:06:A7|00:28:F8:66:06:AB||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&taskid=133051
 6/5/2017 12:30 PM SnapinClient C:\Program Files (x86)\FOG\tmp\Test.bat
 6/5/2017 12:30 PM SnapinClient ERROR: Hash does not match
 6/5/2017 12:30 PM SnapinClient ERROR: --> Ideal: A93F93076ABC51757F22FC9776C5F12FE67B68C25FC3358D244EE75FF83BE23A29C19E690D9B6875C7834640C0BA109AD8BECF3A1C0DF247B488CACA98375945
 6/5/2017 12:30 PM SnapinClient ERROR: --> Actual: BFBA49E97B70CC6E124CAD15C3775245230B9BCEE4E7641566AC88B812D2822C39C58A3797A2FDE9B5E4721D24DF20A9D66490236688FBD39E7DCE154C51C365
 

[UWPVIOLATOR]

@Tom-Elliott @Wayne-Workman Did the update snapins set sHash = null; and they rehashed but it seems like all the Actual hashes are the same thus FOG client wont run it bc it things its wrong.

[Tom Elliott]

@UWPVIOLATOR Who own’s the /opt/fog/snapins directory?

[UWPVIOLATOR]

@Tom-Elliott fog:www-data

[Tom Elliott]

So all hashes are coming back as 6ADEE03D4…?

[UWPVIOLATOR]

@Tom-Elliott

In the GUI it looks hashed right but on the FOG log of the client. The Actual Hash is BFBA49E97B70CC6E124CAD15C3775245230B9BCEE4E7641566AC88B812D2822C39C58A3797A2FDE9B5E4721D24DF20A9D66490236688FBD39E7DCE154C51C365

That comes up for all snapins now that we reset and rehashed all snapins.

[Tom Elliott]

@UWPVIOLATOR I’m sorry I’m not 100% on the way the client does the hashing. I know we do test things, but it would seem maybe it can’t write to the same point on the client machine and is coming up with a sha512 hash of 0 byte file? (No I don’t expect you to have the answer).

[Wayne Workman]

Let’s re-evaluate where the issue is not.

It’s not the client. Why? Others are not complaining. Joe tests the client functionality throughly. The client’s code for this hasn’t changed in a while.

It’s not the fog server’s Code. Why? Others are not complaining. The fog community uses snapins heavily.

What’s left? Your server, it’s configuration, it’s environment.

Knowing that, we should start digging into what’s different about your server.

First, I would suggest upgrading to 1.4.1. Second, I’d start looking through /var/log/apache2/error_log after uploading a new snapin. I’d look for botched symlinks, misnamed directories, bad permissions, and incorrect configurations.

[Tom Elliott]

@Wayne-Workman We ran through manual hashes and the fog server hash is correct. I haven’t seen a client hash fail except under relatively certain circumstances.

I’m just guessing, but maybe antivirus is quarantining/removing the file before it is able to be checked. Maybe there’s a content blocker not allowing the file to pass to the client?

[UWPVIOLATOR]

@Wayne-Workman

Already updated the other day no affect. This might be a Win 10 thing. I am going to test that theory tomorrow.

[UWPVIOLATOR]

@Wayne-Workman @Tom-Elliott

Tested today. It is only Windows 10. Any snapin works for Windows 7. So what else can I test as to why Windows 10 is messing with the FOG client.

[UWPVIOLATOR]

@Wayne-Workman @Tom-Elliott

What gets me is if we use snapins that were created for a FOG node we gave to a vendor for imaging they work. But if we use any snapin from out master FOG the hash fails. In the temp folder it downloads 1KB

[Wayne Workman]

@UWPVIOLATOR said in Snapin Hash Issue:

But if we use any snapin from out master FOG the hash fails. In the temp folder it downloads 1KB

If the file on the server is whole, but not being downloaded to clients - this has to be some sort of network or security problem. It could be a content filter, a firewall, antivirus, anti-malware. You know your environment better than us - spend time thinking about what could possibly block the download.