Posts made by bluenix

@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)

Great! Thank you!

In FOG 1.3.0 RC2, when a new snapin is being created, the filename of the file that is uploaded is being changed: The . (dot) is being replaced by _ (underscore). See the attached screenshot showing the result of uploading the file “test.cmd”. Is there some php configuration change I need to make to resolve this, or could this be a bug that needs squashing?

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.

You’re a star! I’ll try this out tomorrow!

Hi jbsclm. If you could put one together for 0.33 that would be great! I was thinking about running a simple tftp server on the lan to enable clients to pxeboot and load ipxe. The then loaded ipxe could then chain load the fog server over WAN. Basically it is what you describe you did with a cd/usb, but instead of putting the cd/usb into the client, starting such a cd over pxe.

Since you’re now using iPXE, I would think it is also possible to boot a pc over WAN by using a local iPXE installation which chains to the FOG server over internet… Am I correct?

Tom,
Just wanted to say you are doing an amazing job and it is really good to see fog getting developed. I hope that once I have some more time, I can eventually contribute in some way to the development as well. Keep up the good work, much appreciated!