Trunk 5749 Snapin deployment issue
-
when imaging a PC from a remote storage node the snapins are not installed from the storage node but from the main fogserver.
This is causing the imaging process to crawl as it downloads the snapins across our slow MPLS network. -
Is the snapin set to replicate? Can you verify the files exist on the storage nodes? Are you using the location plugin?
-
@Wayne-Workman said in Trunk 5749 Snapin deployment issue:
Is the snapin set to replicate? Can you verify the files exist on the storage nodes? Are you using the location plugin?
I dont have the replicatre box checked. Although the snapins are on the remote node.
I will check the box. -
@Wayne-Workman said in Trunk 5749 Snapin deployment issue:
Is the snapin set to replicate? Can you verify the files exist on the storage nodes? Are you using the location plugin?
ok, I verified that all my snapins are set to replicate and I verified that all the files are at the remote node. and yes I am using the location plugin. The snapins are still being pulled from the main fogserver across the slow mpls network.
This is going to be a very long weekend! please help…Thanks.
-
@Greg-Plamondon Can you delete the files on the non-master nodes and let replication put them back?
-
What happens when you create a snapin task?
-
@Wayne-Workman said in Trunk 5749 Snapin deployment issue:
@Greg-Plamondon Can you delete the files on the non-master nodes and let replication put them back?
I have, and I can see them replicate in /var/log/fog/fogsnapinrep.log and I verified they are on the remote node
-
@Tom-Elliott can you clarify if the location plugin applies to snapins? How does the server decide what storage node to use for snapin deployments?
-
@Quazz said in Trunk 5749 Snapin deployment issue:
What happens when you create a snapin task?
when I create the snapin task everything runs as normal except that the files get downloaded from the management fogserver and not the storage node.
-
@Greg-Plamondon I’ve been thinking about this. Perhaps we can work around the issue for now?
What does the snapin do? Can we get a screen shot of the snapin settings? It might be trivial to turn the snapin into a simple script that WOULD pull the larger files from the correct places and execute them.
-
@Wayne-Workman said in Trunk 5749 Snapin deployment issue:
@Greg-Plamondon I’ve been thinking about this. Perhaps we can work around the issue for now?
What does the snapin do? Can we get a screen shot of the snapin settings? It might be trivial to turn the snapin into a simple script that WOULD pull the larger files from the correct places and execute them.
sure!!
Most of my snapins are self extracting sfx archives or msi packages.
-
@Greg-Plamondon Ok, I think this will be very simple.
I hope you have groups made for all hosts at each physical location - that will make it even easier.
This will be more a guide than a complete solution for you, but I can give examples if needed. I would rather you at least try on your own before I just hand off free work.
Make a samba share on each fog storage node. This can optionally include the master node too. Instructions on that:
https://wiki.fogproject.org/wiki/index.php?title=Password_Protected_Samba_Share
You can absolutely tweak that to your liking per-site.Next, you’ll write a batch script that you will test manually (no snapins, yet).
This script willxcopythe file you need from ONE of the storage nodes Samba shares to the local c:\ drive somewhere. Then, the batch file will initiate the executable it just copied.Make a script for each storage node. Test each script manually. Ensure it works. Test run them by right clicking them, and selecting “Run as administrator”, this is closer to what the fog client will do than just double clicking on them.
Then, create a snapin for each of the scripts, use the batch template. Test each snapin on a single lone computer at each site - ensure it works.
Then, after ensuring all snapins work at all sites, use those groups that you hopefully have made and associate the correct snapin to the correct groups.
With this setup, whenever computers are imaged, the snapin will auto-deploy post-imaging and get done what you need.
Helpful advice: Put numbers in front of the snapin names to dictate the order in which they are executed.
-
@Wayne-Workman
I don’t want to come across as rude but your method seems a little sloppy. I would rather use fog as it was/is being designed to work. creating groups and scripts for every snapin would be tedious.
We have 27 Locations with different application sets at each. I appreciate your effort, And believe me I have “tried” I never asked for a handout or " free work" I just wanted a fix for my problem.Thanks.
-
@Greg-Plamondon Well you made it seem like it was urgent, I wanted to help, and it’s meant to be a temporary fix that will accomplish the end goal. I don’t know how it’s sloppy, as I didn’t give you any code, but just a guide. Paired with fog snapins, the script I described would probably be about two lines long. Copy and then run, basically. Fog is all about customization, to quote Tom “tom is my name, and customization is the game”. And the samba setup is very standard, very basic.
If you piled all the copy and runs into a single script for each site, you’d have a snapin per site basically.
Feel free to wait for a better idea from someone here. All I was trying to do is help.
-
@Wayne-Workman
I said the method was sloppy not the code, (but that’s a matter of opinion)But your right it was urgent at the time and I already have a samba share at each node for drivers for imaging. I see now what your guide was accomplishing and it would have worked fine if I would have paid more attention to detail when reading your post. Thanks again. -
@Greg-Plamondon
Please see:
https://news.fogproject.org/fog-client-v0-11-4-released/0.11.4 now downloads from the storage node if locations are setup.