FOG::SnapinClient Download Failed; Zero size file.
-
Hi ch3i
No snapins currently work - I’ve tested with 2 known ones which did work on earlier versions of fog - I’m using the same .msi or .exe files and same switches but they (the 2 different one I’ve tried so far) both fail with the same error as previously.
I have the location plugin installed as well as WOL plugin and Pushbullet in case any of them have an impact on snapins - don’t see how.
I’m trying to deploy from main fog server to a client in the same location/subnet as main server too.
regards Kiweegie.
-
@Kiweegie Don’t know wich protocol is used to transfer snapins from server to client. But “Download Failed” seem to be a service that not running or a right problem.
-
I thought it might be permissions or ownership - my propblem is I don’t know who the owner should be or what acces rights are needed.
the snapins directory shows as
drwxrwxr-x 4 fog apache 4096 Jun 11 13:41 snapinsand the snapins therein
-rw-r--r-- 1 fog fog 27684864 Jun 1 19:12 LogMeIn_Pro.msiIf anyone has a working snapin system could you check what ownership and perms you have set?
ta
-
You could temporarily set permissions to 777 recursively on those directories for troubleshooting purposes. With perms set to 777, the owner no longer matters.
[CODE]chmod -R 777 /path/to/your/snapins/directory[/CODE]
-
@Wayne-Workman Thanks Wayne, I had actually tried that, sorry I should have mentioned that. I’ll do some more digging on that when I get back to the office tomorrow.
As a side note I did try deploying a snapin to my own machine but as that one was imaged with the old server its using an old Fog client it didn’t work and gave me a completely different error.
14/06/2015 12:53 FOG::SnapinClient Attempting to connect to fog server... 14/06/2015 12:53 FOG::SnapinClient Unknown error, module will exitI’ve seen reference in these forums to legacy vs new fog client and I’m presuming the new one pulls through on any machine imaged with new (1.2.0?) version of Fog. Can anyone point me to a definitive explanation of this? There has been a lot of change in the new Fog version seemingly and finding information in this forum is not always as straight forward as it should be.
thanks all, Kiweegie.
-
Is the firewall enabled on the target hosts?
I wonder if that would make a difference. Try turning the firewall off (all three options) and see.
-
@Wayne-Workman no rest for you on a Sunday either I see
We disable client side firewalls via GPO so that’s not blocking it. I think the issue is fog-server side rather than the end clients. I had hoped the error in fog.log may have been encountered before or documented somewhere to give me an idea of where it was going wrong.
Unsure if it has any bearing on things but I have multiple storage nodes set up at remote locations and I’m trying to get the WOL and snapins replication working there too. Currently image replication is working on a few but not all storage nodes (3 out of 7) though this may just be bandwidth related as I’ve dialled transfers down to 500Kbps.
regards Kiweegie
-
Well then… let’s approach this from just a general troubleshooting standpoint, never mind FOG for the moment.
On one of the hosts that’s failing to get the snap-ins, can you ping the proper FOG server?
Can you use wget or FTP to try to get one of the snapins from one of the hosts?
-
@Wayne-Workman Hi Wayne, good plan. I have been able to FTP from client machine to the main fog server using the username fog and password which sits in FOG_TFTP_FTP_PASSWORD field
Default path it hits is /home/fog but I can navigate ok to the snapins directory at /opt/fog/snapins just fine.
So it doesn’t look like a permissions issue - I did also amend to 777 perms per your earlier suggestion but this I don’t think is necessary. I’ve amended back to original permissions and checked access via FTP again to be sure and it works fine. I can also pull file across to client via FTP not just view contents of fog directories.
regards, Kiweegie
-
@Wayne-Workman Hi again Wayne, searching forum seems to be working a little better today and i’ve found this post which had same error mesage:
https://forums.fogproject.org/topic/3362/active-snapins/4
On that Tom Elliott had advised to ensure the snapin file name showed as file name only not the full path. It shows file name only.
The OP (BUdgester) on that call as workaround edited the /var/www/fog/service/snapins.file.php file line 31 (in my case on Centos path is /var/www/html/fog/service/snapins.file.php and lines 31 shows as:
$SnapinFile = "ftp://".$StorageNode->get('user').":".$StorageNode->get('pass')."@".$FOGCore->resolveHostname($StorageNode->get('ip')).'/'.ltrim(rtrim($StorageNode->get('snapinpath'),'/'),'/').'/'.$Snapin->get('file');Do I need to look at manually editing some part of this file perhaps?
Unlike Budgesters issue this is a clean install of the SVN version of Fog and not an upgrade.
regards Kiweegie
-
Is your $StorageNode set with an IP or a netBIOS name? If it’s set by name, perhaps it’s a DNS resolution issue?
-
@Wayne-Workman Hi Wayne
all storage nodes are set using IP - I’m sure I read somewhere there was an issue adding DNS name here.
Just thinking out loud now…
I have 2 storage groups, default and Storage.
The main server (storage node = DefaultMember) uses the default storage group as do all my remote storage nodes. I have one more storage node at head office which uses the storage group - this is to hold images which I don’t want to sync to my remote nodes.I’m guessing that there might be something funky with how I’ve set this up or with the location plugin or something (though fully prepared to accept I’m barking up the wrong tree). As a test i tried adding the snapin to the storage group but kept getting error:
Failed to add snapin, unable to locate snapin directory.
Does the other storage group “storage” need to be set as master even though its not replicating to other nodes?
I should also point out that I’ve edited the php file for max upload etc of snapin files.
regards Kiweegie
-
The location plugin can be funky…
Could you try to remove those remote nodes from the location plugin, and then re-add them?
In the past, people have had issues with ‘orphaned’ settings… it’s weird, I don’t really get it, but they solved it by removing and re-adding.
-
@Wayne-Workman Thanks for all your help so far Wayne.
I think the way I had set this up locations orignally wasn’t quite right anyway. I’m likely overthinking this or making more compllicated than it needs to be. I went with the SVN version based on Toms recommendations as I wanted specifically to make use of the location plugin to support main server for hosting image definitions and pulling image files from local storage servers…
An overview of how I have this setup may help
Setup is like so:
Head office1 = normal node (DefaultMember)
Head office2 = storage node (Storage)
remote nodes 1-7 (storage nodes named by location)2 Storage groups, “default” and “Headofficestorage”
All storage nodes point to default storage group except Head offfice 2 (Storage) which points to Headofficestorage storage group. I’m using default storage group to replicate all images to the remote nodes and the Headoffice Storage node to keep all other images both those for that site only as well as some presysprep images for the other sites which we don’t want to replicate to the storage nodes.
I have now removed all locations and re-added this time with one for each remote storage node (pointing to default storage group) plus 2 locations for head office
HeadofficeLocal = default storage group
HeadofficeStorage = HeadofficeStorage storage groupLocations I originally had set up one for each “actual” location, the headoffice one pointing to the HeadOfficeStorage storage group when it should have been default (i.e. main server where the snapins are actually located).
So I’ve now created 2 locations for head office
HeadofficeLocal = default storage group
HeadofficeStorage = HeadofficeStorage storage groupI’ve create a brand new snapin using Filezilla which I know works and this is pointing to the default storage group. Deployed snapin still hangs and the fog.log now has new errors…
15/06/2015 16:03 FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\UserTracker.dll hash doesn't match server hash! 15/06/2015 16:03 FOG::ClientUpdater Checking Status : config.ini 15/06/2015 16:03 FOG::ClientUpdater File: config.ini requires an update. 15/06/2015 16:03 FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\config.ini hash doesn't match server hash! 15/06/2015 16:03 FOG::ClientUpdater 1 new modules found! 15/06/2015 16:03 FOG::ClientUpdater Checking Status : 15/06/2015 16:03 FOG::ClientUpdater File: requires an update. 15/06/2015 16:03 FOG::ClientUpdater An exception occurred during a WebClient request. 15/06/2015 16:03 FOG::ClientUpdater at System.Net.WebClient.DownloadFile(Uri address, String fileName) at FOG.SnapinClient.downloadAndDeploy(String localFile) 15/06/2015 16:03 FOG::ClientUpdater Client update will be applied during next service startup. 15/06/2015 16:03 FOG::ClientUpdater Client update process complete, exiting...The reference to C:\Program Files (x86)\FOG\tmp\config.ini does help though as if I check there on the cllient what do I see? The 2 snapins I was trying to deploy earlier!!! Date modified matches when I tried to deploy originally and the file size shows 0
So (very) long story short it looks like the client was pulling the snapin down ok but hitting the tmp folder with zero file size.
Hopefully this might help you help me shed light on where its falling over?
regards Kiweegie
-
Give that particular host a few reboots. it’s got to establish trust between itself and the server again since you updated to FOG Trunk.
When you see the line “hello FOG client!” (don’t remember the exact wording) that means the trust has been re-established.
Then see what your snapins do.
-
@Wayne-Workman Success!
ok the latest snapin has worked as expected. Root cause I think was the locations and how I had set them up. Each host has a Location entry and each location points to a storage group.
I’d set the host I was testing this on to the only location I’d set up for head office and this was pointing to the wrong storage group.
I’ll do some further testing this week but hopefully others with same issue can at least learn from my mistakes…
Wayne, really appreciate the time and effort you put in to help me out with this one, greatly appreciated.
cheers, Kiweegie.
