It would be great if the storage node to use for imaging / snapins could automatically be determined based on the subnet of the requesting client.

This would be useful in a situation where computers are physically roaming between locations. If e.g. a snapin/image for that host is queued, it would make sense to download the snapin/image from the storage node that is in the current subnet.

In RC5, when you deploy a single snapin to a host, and deploy a second single snapin directly afterwards to the same host (before the first one is processed by the client), Active Snapin Tasks only shows the last deployed snapin as a task.

The following happens step by step:

1. Deploy single snapin A to host 1
2. Snapin A shows up in both Active Tasks and Active Snapin Tasks
3. Deploy snapin B to host 1
4. Snapin B shows up alongside snapin A in Active tasks, but replaced Snapin A in Active tasks
5. The client will install Snapin B and remove it from Active Snapin Tasks
6. Snapin A remains indefinitely queued in Active Tasks, never appears in Active Snapin tasks and never gets installed by the client (client logs no snapins found in c:\fog.log)

@Tom-Elliott Great!

@Tom-Elliott

Main server sha512sum:

cb872de2b8d2509c54344435ce9cb43b4faa27f97d486ff4de35af03e4919fb4ec53267caf8def06ef177d69fe0abab3c12fbdc2f267d895fd07c36a62bff4bf

Storage node(s) sha512sum:

b16ed7d24b3ecbd4164dcdad374e08c0ab7518aa07f9d3683f34c2b3c67a15830268cb4a56c1ff6f54c8e54a795f5b87c08668b51f82d0093f7baee7d2981181

@Wayne-Workman said in RC8 - Snapin not replicating after edit:

lftp -e ‘set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; mirror -c -R -i test.cmd --ignore-time -vvv --exclude ‘dev/’ --exclude ‘ssl/’ --exclude ‘CA/’ --delete-first /opt/fog/snapins /opt/fog/snapins; exit’ -u fog,[Protected] 172.18.0.5

The only output is:

Total: 1 directory, 2 files, 0 symlinks 

And the file does not get updated at 172.18.0.5

This is after updating a snapin with a new file that has the same name as the old one and restarting the FOGSnapinReplicator service:

[08-13-16 11:30:45 am]  * Found Snapin to transfer to 3 node(s)
[08-13-16 11:30:45 am]  | Snapin name: testsnapin
[08-13-16 11:30:46 am]  * Starting Sync Actions
[08-13-16 11:30:46 am]  | CMD:
                        lftp -e 'set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; set net:limit-rate 0:1280000; mirror -c -R -i test.cmd --ignore-time -vvv --exclude 'dev/' --exclude 'ssl/' --exclude 'CA/' --delete-first /opt/fog/snapins /opt/fog/snapins; exit' -u fog,[Protected] 172.17.0.5
[08-13-16 11:30:46 am]  * Started sync for Snapin testsnapin
[08-13-16 11:30:47 am]  | CMD:
                        lftp -e 'set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c -R -i test.cmd --ignore-time -vvv --exclude 'dev/' --exclude 'ssl/' --exclude 'CA/' --delete-first /opt/fog/snapins /opt/fog/snapins; exit' -u fog,[Protected] 172.18.0.5
[08-13-16 11:30:47 am]  * Started sync for Snapin testsnapin

I should have been more clear. Replication works fine once a new snapin file is uploaded (existing snapin with new filename, or new snapin), just not when replacing a file with another file that has the same name.

After editing a snapin by uploading a new snapin file with the same name as the old file , the new file does not get replicated to the other storage nodes. They keep the old file, which will no longer deploy since the hashes differ.

Updating a snapin with a file that has the same name as the previous one happens a lot with e.g. altered cmd scripts or newer versions of msi installers.

Since upgrading to RC6, snapins no longer deploy.

When sending a single snapin to a host, the status of the task changes to checked in after a while, but stays on that status indefinitely.

fog.log on the client:

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 4-8-2016 10:03 Client-Info Client Version: 0.11.4
 4-8-2016 10:03 Client-Info Client OS:      Windows
 4-8-2016 10:03 Client-Info Server Version: 1.3.0-RC-6
 4-8-2016 10:03 Middleware::Response Success
 4-8-2016 10:03 SnapinClient Snapin Found:
 4-8-2016 10:03 SnapinClient     ID: -1
 4-8-2016 10:03 SnapinClient     Name: 
 4-8-2016 10:03 SnapinClient     Created: -1
 4-8-2016 10:03 SnapinClient     Action: 
 4-8-2016 10:03 SnapinClient     Pack: False
 4-8-2016 10:03 SnapinClient     Hide: False
 4-8-2016 10:03 SnapinClient     Server: 
 4-8-2016 10:03 SnapinClient     TimeOut: -1
 4-8-2016 10:03 SnapinClient     RunWith: 
 4-8-2016 10:03 SnapinClient     RunWithArgs: 
 4-8-2016 10:03 SnapinClient     Args: 
 4-8-2016 10:03 SnapinClient     File: 
 4-8-2016 10:03 SnapinClient ERROR: Snapin hash does not exist
------------------------------------------------------------------------------

Great! Compliments for the super quick response and fix. That’s what makes Fog stand out!

@Tom-Elliott I understand that there may be a difference between Active Tasks & Active Snapin Tasks, but there are two strange things: 1. The last sent snapin gets executed first, 2. The other snapin never gets executed at all.

In RC5, when you deploy a single snapin to a host, and deploy a second single snapin directly afterwards to the same host (before the first one is processed by the client), Active Snapin Tasks only shows the last deployed snapin as a task.

The following happens step by step:

1. Deploy single snapin A to host 1
2. Snapin A shows up in both Active Tasks and Active Snapin Tasks
3. Deploy snapin B to host 1
4. Snapin B shows up alongside snapin A in Active tasks, but replaced Snapin A in Active tasks
5. The client will install Snapin B and remove it from Active Snapin Tasks
6. Snapin A remains indefinitely queued in Active Tasks, never appears in Active Snapin tasks and never gets installed by the client (client logs no snapins found in c:\fog.log)