[Requested] Multi-Site Location Patch [Requested]
-
This post is deleted! -
the roaming issue has never been a problem of ours because we use FOG purely for image deployment. Software rollouts, Windows Updates, Printers etc is handled by other products, so unless the machine needs to be re-imaged this issue doesn’t crop up an we are in the habbit of confirming location before kicking off the image.
-
how have you disabled the Primary server as a storage node so nothing is deployed from it?
wouldn’t option 3 be as easy as having a hardcoded “fogstoragenode” DNS A record entry for primary deployment and that’s your multi site done
as in primary site has the “fogserver” which is what the agents talk to to look for queued jobs, send back their login info etc. but when it comes to actual deployment of either image or snap-in they automatically look to the “fogstoragenode” dns entry instead of the “fogserver” dns entry
each branch site has a “fogstoragenode” dns A record so the agents on that site talk to the correct one
just thinking of ways to make it easier for any roaming users, so they always download from the “local” storagenode for Images and Snap-Ins
we have a lot of roaming users, so would be good to ignore what site they are at and make the whole process automatic.
-
[quote=“Devlin7, post: 2571, member: 612”]Brilliant. Thanks for this. Just out of interest I have been having issues installing a storage node. [I have posted a support question but it has largely been ignored. I can can’t install FOG storage nodes on Ubuntu 10.04 [32 or 64 bit]. Can anybody confirm that it works/doesn’t work and suggest a work around?[/quote]
I don’t know about Ubuntu 10.04 but I have gotten a working storage node up and running on Ubuntu 11.10.
The main thing I was missing the first couple times I tried is that the username and password that the FOG setup spits out for the storage node needs to be entered into the FOG Managment console while creating the Storage Node Object. -
Here’s what I’m doing for Portable Storage Nodes.
[INDENT=1]Install a standard storage node on the laptop. (assume you set the ip address as 192.168.1.2 during setup)[/INDENT]
[INDENT=1]Edit the /var/www/fog/commons/config.php[/INDENT]
[INDENT=1]Replace all “192.168.1.2” entries with getenv(“SERVER_ADDR”)[/INDENT]
[INDENT=1]Register a static DHCP Reservation for each site the laptop will be at.[/INDENT]
[INDENT=1]Enter a storage node entry in the managment console for each location that the laptop will be at using the static reservation set.[/INDENT]This basically tricks the storage node to use it’s current ip address from the config.php rather than a static IP address. The storage node entries can then be set different locations and the laptop server will only be “on location” when it gets the proper IP address for the subnet it’s on.
I’ve not tested this yet but there is no reason it shouldn’t work.
You can then “Disable” the Primary Storage Node by simply not assigning it a location. If you have not installed the Multi-Location PXE server and group all nodes in the same Storage Group you should be able to even have images automatically push down to the laptop storage nodes
Something to think about.
Stephen.
-
Hey Lee - glad to see you are still active. Had to rebuild my setup her in Montana as my ESxi host ran into a disk controller problem and we weren’t able to salvage the drives…of course we didn’t have a backup…luckily though because of my year old install of this patch we had copies of all of the images on the 2 remote nodes.
Question is this, when you say “[B][SIZE=3]patched for 0.31” [/SIZE][/B]it sounds safe to assume that we don’t yet want to update to 0.32?
Stephen your Portable storage node sounds like a cool idea…we only use fog a couple of times a year so the effort of building a Fog storage node (even on a VM) at our remote sites seems like extra effort. May have to try it out.
Thanks, Pat -
Hi Pat,
yes the files are based around on the 0.31 code, i haven’t yet changed it to 0.32 because there were so many changes being made, it seemed sensible to wait for 0.33 to be released and i will then re-code the location patch etc for 0.33.
@Syluspilot
DNS A record would only work if each site had it’s own local DNS wouldn’t it? however atleast 75% of our sites use the DNS from our main office (or atleast the DNS records are replicated). but i do like the concept of your approach
-
Lee,
How did you set the replication to happen between 6am and 6pm?
-
turn off FOGImageReplicator Service manually (/etc/init.d/FOGImageReplicator stop)
and then set a crontab to run the command to enable it at 6pm and then use crontab again to turn it off at 6am…sudo -s
crontab -e
add this at the bottom of the file:
0 18 * * * /etc/init.d/FOGImageReplicator start
0 6 * * * /etc/init.d/FOGImageReplicator stop -
Lee,
I got some help from a co-worker, and basically set it up as a cron job that runs @ 21:00 daily. We tested to make sure that the process ended, by commenting out the sleep line. But am still curious as to how you set it up.
-
[quote=“Lee Rowlett, post: 3259, member: 28”]turn off FOGImageReplicator Service manually (/etc/init.d/FOGImageReplicator stop)
and then set a crontab to run the command to enable it at 6pm and then use crontab again to turn it off at 6am…sudo -s
crontab -e
add this at the bottom of the file:
0 18 * * * /etc/init.d/FOGImageReplicator start
0 6 * * * /etc/init.d/FOGImageReplicator stop[/quote]Thanks, I didn’t see your response before I left the other comment. Since no one should be uploading images after 6, I don’t need the process to run in a loop, and everything should be uploaded by 9.
Thank you again for your quick answer.
-
Hey all,
Just wanted to update you. The portable FOG storage nodes work well. They have been tested at 3 remote sites imaging concurrently. All went relatively well. No major hitches.
My next issue is the [URL=‘http://fogproject.org/forum/threads/fog-multi-site-multicast.796/’]Multicast from storage nodes[/URL] for which I have opened a new thread.
Stephen.
-
Thanks for the update Stephen…interested to try it out.
Wondering where to start looking for my issue with this.
Right now I’m working at one of the “remote locations” (it’s summer vacation for the schools). I’ve uploaded a new image from a machine, but what I am finding is that the Upload process is pushing the image files over to the “main location”, however when I try to pull it down to another client with a “deploy”, the target client is looking for it here in the remote location.
In both cases, the hosts are configured to be at the “remote location”, but the image upload is not saving to the remote storage node. I can copy it easy enough, but I would like to save as much time as possible.
Is this by design? Or did I miss a step?
Thanks, Pat
-
[quote=“PatinMT, post: 3976, member: 913”]Thanks for the update Stephen…interested to try it out.
Wondering where to start looking for my issue with this.
Right now I’m working at one of the “remote locations” (it’s summer vacation for the schools). I’ve uploaded a new image from a machine, but what I am finding is that the Upload process is pushing the image files over to the “main location”, however when I try to pull it down to another client with a “deploy”, the target client is looking for it here in the remote location.
In both cases, the hosts are configured to be at the “remote location”, but the image upload is not saving to the remote storage node. I can copy it easy enough, but I would like to save as much time as possible.
Is this by design? Or did I miss a step?
Thanks, Pat[/quote]
Hey Pat,
Because of how the Location patch is coded uploaded images get pushed back to the main storage node. This is because of the Image Replicator service.
As far as I can tell* an image that is added to a secondary storage node is not uploaded back to the master storage node. Transfers are downwards only. So the image needs to be uploaded to the master storage node so that it can then be redistributed throughout the storage group.
[INDENT=1]* I only took a quick look at that part of the code so I may be misinterpreting this.[/INDENT]You can find the code in /var/www/fog/service/Pre_Stage1.php for this function.
Stephen.
-
Update on the Portable Storage Nodes.
We now have 3 laptops configured as storage nodes across 15 location.
There is however an issue I have encountered with the web interface’s Dashboard on the Home page. What seems to be happening is that the dashboard is trying to gather information the 18 storage nodes (multiple entries for each laptop) that FOG has in it’s database but mostly not connected. This is causing navigation away from the Home page to stall while the information gathering completes/fails. It will get to the other pages but it takes it’s time. All other page changes in the web interface appear run as quickly as with only the master node in place.
With 18 storage nodes defined and a max 4 servers connected at any one point, getting away from the Home page can take up to a minute.
It’s something to look into if the Location patch is going to be integrated into the full version eventually.
FYI
Stephen
-
I have noticed that after applying this you can’t delete computer from the web GUI I 'm no coding master but if you have a chance could you take a look and see if this could be fixed.
-
We’ve noticed the same thing, also we used to be able to search for example by service tag on a Dell, but now that returns nothing…
-
This is a change from 0.31 to 0.32 you have to use 0.31 for this patch to work. It work great on a 0.31 system for me along with some other modifications we can image machines all on the remote network with very little WAN traffic.
