"Snapin hash does not exist"

[thopman]

I’m running into a problem after upgrading FOG from 1.2.0: old snapins do not deploy, giving the error that Snapin hash does not exist. This is true; no hash is shown when I look at the Snapin management page. I’ve searched the forums, and the symptoms I’m seeing are different from what others have experienced.
The FOG server is an Ubuntu 14.04 LTS box, fully updated. FOG is 1.3.4, and the client client is 0.11.7; the clients are Windows 7.
Here is a snippet from fog.log:

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 02/02/2017 4:33 PM Client-Info Client Version: 0.11.9
 02/02/2017 4:33 PM Client-Info Client OS:      Windows
 02/02/2017 4:33 PM Client-Info Server Version: 1.3.4
 02/02/2017 4:33 PM Middleware::Response Success
 02/02/2017 4:33 PM SnapinClient Snapin Found:
 02/02/2017 4:33 PM SnapinClient     ID: 8062
 02/02/2017 4:33 PM SnapinClient     Name: Firefox autoconfig
 02/02/2017 4:33 PM SnapinClient     Created: 2017-02-02 09:55:55
 02/02/2017 4:33 PM SnapinClient     Action: 
 02/02/2017 4:33 PM SnapinClient     Pack: False
 02/02/2017 4:33 PM SnapinClient     Hide: False
 02/02/2017 4:33 PM SnapinClient     Server: 
 02/02/2017 4:33 PM SnapinClient     TimeOut: 0
 02/02/2017 4:33 PM SnapinClient     RunWith: 
 02/02/2017 4:33 PM SnapinClient     RunWithArgs: 
 02/02/2017 4:33 PM SnapinClient     Args: 
 02/02/2017 4:33 PM SnapinClient     File: SFX-Firefox-autoconfig.sfx.exe
 02/02/2017 4:33 PM SnapinClient ERROR: Snapin hash does not exist
------------------------------------------------------------------------------

The FOGSnapinHash service is running:

$ service FOGSnapinHash status
 * FOGSnapinHash is running

Its log, however, shows that it thinks there is only one snapin (a snapin pack created after upgrading) when there are actually a couple of dozen:

[02-02-17 3:49:46 pm]  * Starting SnapinHash Service
[02-02-17 3:49:46 pm]  * Checking for new items every 1800 seconds
[02-02-17 3:49:46 pm]  * Starting service loop
[02-02-17 3:49:46 pm]  * Starting Snapin Hashing Service.
[02-02-17 3:49:46 pm]  * We are group ID: 1. We are group name: default
[02-02-17 3:49:46 pm]  * We are node ID: 1. We are node name: DefaultMember
[02-02-17 3:49:46 pm]  * Finding any snapins associated with this group as its primary group
[02-02-17 3:49:46 pm]  * Found 1 snapin to update hash values as needed.
[02-02-17 3:49:46 pm]  | Snapin hash already set
[02-02-17 3:49:46 pm]  * Completed.

What’s going on? How to I get hashes created without having to re-create and re-upload the snapin files? Restarting the FOGSnapinHash service doesn’t do the trick.

[Wayne Workman]

Make sure all your snapins are assiciated to the storage group you have. There’s a menu item on the left of all the snapins called storage group.

[thopman]

All snapins are associated with the “default” storage group, which is the only one I have. Resetting the storage group association for a snapin then restarting the FOGSnapinHash service doesn’t make the service see that snapin.

[Wayne Workman]

@thopman In the log, it says it found 1 snapin to update the hash for, then it says the hash is already set. This is strange. From CLI, take a backup of your fog database with:
mysqldump -B fog > fogdb.sql

And then go into mysql and just blank out the entire sHash column, then restart the hash service and we’ll see what happens. Hopefully it’ll make hashes for everything.

mysql -D fog  #or mysql -D fog -u root -p   if it's password protected
update snapins set sHash = null;
quit
service FOGSnapinHash restart
#You can view the snapin hash log live as it's being written in another ssh/terminal with:
tail -f /opt/fog/log/fogsnapinhash.log
#Or to just output the whole log:
cat /opt/fog/log/fogsnapinhash.log

I did try this on my home fog server and it did cause the service to re-hash my snapins. If that doesn’t work, we will have to ask a developer to look at the issue.

[thopman]

I think I found found a workaround: export snapins, delete the old ones, then re-import. I did this, then "touch"ed one of the snapin files, and restarted the FOGSnapinHash service. Lo and behold, all the hashes were newly calculated. This did not happen if I did not “touch” one of the snapin files.
It’s weird that this should work, because if I re-export and compare the CSV files, I see no difference other than the hashes being added to the CSV.
I would not consider this issue solved: there seems to be some kind of logic flaw in the hash service. I did the delete-and-import process only on the snapins I need immediately, so I can follow up on tracking down the issue.

[Tom Elliott]

@thopman I’m of the mindset that the problem is the “primary group” element.

Snapins need to have a “primary” group associated to it for the hashing to occur (similarly for replicating images and snapins need this too).

It sounds to me like they were not implicitly defined. This would be why the re-import worked, because it knew to associate the snapins with that group as the primary.

I don’t name the snapins apparently (which I can add pretty easily) that are being worked which makes it harder to troubleshoot.(Done in the working 1.3.5 branch now.) It looks, to me, like it was updating the snapins hash, but it only had one snapin with that group as the “primary” group. That snapin was probably NOT the same snapin being sent to the client.

I’ve fixed the code to handle this more properly, but i’m going to guess you’ve been staying “up to date” on fog for a while? (Meaning you were probably previously running a version of trunk or the 1.3.0-RC’s?)

When we initially added the “primary” group elements, the snapins and/or images didn’t automatically adapt to set their primary groups, as they can exist in multiple groups.

[thopman]

@Tom-Elliott Sorry for the delay – new semester started so things got hectic. To answer your question: no, I haven’t used any of the trunks or RC’s. My upgrade path was 1.2.0 -> 1.3.0 -> 1.3.4.

[thopman]

@Wayne-Workman I followed the procedure you suggested, and the hashes were updated – but only for those snapins that I re-imported as outlined in my workaround.

[Wayne Workman]

@thopman 1.3.5 RC 3 was released today, if you wanted to try that out. Otherwise you can wait for the official 1.3.5 release.