RC10 Broken Items on upgrade

[Thiago]

@adukes40
To solve “Snapin hash does not exist”, i updated all my snapins to generate the hash.
When i opened a snapin to edit, the hash field (that is read only) was empty. I clicked the update button and the field was filled.
After this, snapin was installed.
edit. some I had to delete and recreate the snap in, by uploading the file again.

[adukes40]

@Thiago Hopefully your “edit” isnt what I need to do lol. I have 746 snapins.

It does appear clicking on UPDATE is filling in the hash. I will test this ina few minutes. But is there a way to “update” them all at once?

[Tom Elliott]

@adukes40 By resetting with update snapins set sHash='' it should make all snapins force update when they are next checked in. The create date is coming from when the snapin tasking was createsd I think.

[adukes40]

@Tom-Elliott This morning before I manually hit Update, The boxes were blank as @Thiago mentioned.

I just started an image and I am at the snapin install part. Still complaining about Snapin Hash does not exist, even tho:

[adukes40]

While looking at the thread about the failing to add snapins, I went and looked at my ownership. It looks like it is now set to Fog:www-data Is this right?

Because a few months ago I had to run this:

chown -R fog:root /opt/fog/snapins

I don’t know where this www-data came from

This is what I mean:

drwxr-xr-x 2 root root 4096 Sep 15 09:32 log/
drwxr-xr-x 9 root root 4096 May 24 13:50 service/
drwxrwxr-x 3 fog www-data 20480 Aug 25 14:42 snapins/

[Tom Elliott]

@adukes40 this is correct. So long as the first part is fog you will be fine. The www-data is the Apache user on debian based systems. Permissions as set with that because it’s typically accessed using web calls. It’s just to ensure we can do what we need.

[adukes40]

@Tom-Elliott Ok, just making sure something didn’t go haywire. Not sure what else to do about my snapins tho. I have a snapshot of my server from Aug 29 I can revert to, but I do not have any snapshots of my nodes Which I assume would cause issues. Just incase we needed t explore that route.

[adukes40]

Wait, so after I update the hash, does this need to replicate out to the nodes, because we still have the replication turned off from the other day. If it does, this might be why my remote site (where I am) still isn’t working.

[Tom Elliott]

@adukes40 the problem with just updating is the hash is coming from the file. Because you’re not uploading a file the hash returned is likely the same for all snapins.

[adukes40]

@Tom-Elliott It appears the 3 snapins I “updated” all have the same hash number, at a quick glance.

[Tom Elliott]

@adukes40 And that’s because it’s got the hash of an empty file.

[adukes40]

@Tom-Elliott So will need to go back in the snapin mgmt, and repoint to the file? or do I need to recreate 750 snapins?

[adukes40]

Any other ideas, pretty much dead in the water at the moment. Im down for remote control if needed.

[adukes40]

This is what I was talking about earlier. This show up before the image kicks off:

[Tom Elliott]

@adukes40 Those messages are fine. For snapins you don’t need to reupload them. I have to fix updating a snapin so the hash isnt erroneously overwritten but for now please just set the snapin hashes back to an empty string

[adukes40]

@Tom-Elliott Is that the sHash=‘’ command?

[Tom Elliott]

@adukes40 Yes. Now because th snapins have all failed, you won’t see them manually update their hashes. To update the hashes you will need to re deploy the snapins like any other tasking.

[Tom Elliott]

@Tom-Elliott for simplicity and if possible I’d say set all snapins to one host and run an all snapins task. This way you don’t have 50 systems just sitting around waiting for hashes to catch back up

[adukes40]

@Tom-Elliott I set all snapins to one machine, Told it to install all, and still yells about the hash.

[Tom Elliott]

@adukes40 Can you post a fog.log for us?