• Good afternoon all, I am currently running FOG on a Raspberry Pi and am about to deploy an RPi to about 150 locations. My question is is it possible to manage all of these FOG servers from one client, instead of having to log into each htttp://ipaddress/fog/management.

    So basically I am looking to manage all of my hosts and images, across about 150 servers on one single web client. This would greatly help consolidate this project into a manageable controller. Thank you in advance.


  • @Sebastian-Roth @george1421 Thank you both. I understand that FOG was not really created for this large of a project, however, I’m interested to see how to handles it and what, if anything, will break along the way. I will keep everyone updated with my experiences and issues so that hopefully somebody else can avoid my mistakes in the future!

    With the amount of stores we have, I think it may be better to use each FOG server independently to avoid overloading any single part of the system. This will make managing the project more difficult but in the end I think it will be better suited for this client. Each store has a maximum of 7 computers so that should be much more within the programs capabilities. For our corporate office and some of the larger daughter sites, (upwards of 300 computers per site) I will be performing local upgrades.

    If I had more time to play around with a central FOG node I might try to make it work, but with Windows 10 support ending at the close of this year, I need to have all 1200+ computer upgraded by then as to not give our compliance department a stroke.

    Again, thank you both for the prompt response and for supporting an opensource program.

  • Senior Developer

    @Brendan-Clemente This sounds like a project not to be rushed into too quickly I reckon. 150 sites is not something FOG was made for and it might not be scaling up to your needs. Not saying that it cannot be done but it’s simply something we don’t have the time and resources to test and development for in our home labs.

    George has brought up the most important things. I myself would tend to use FOG as storage nodes on the satellite sites but as mentioned there are some issues with this way of setting it up. One more I have to add: So far the master node tries to reach out the all storage nodes to grab version information for some pages loaded (e.g. FOG Configuration where it lists all the storage nodes). This will definitely break with 150 storage nodes! So you will have trouble with navigating through the web UI with such an amount of storage nodes. Compared to older versions we have improved this a fair bit in FOG 1.5.6 and later but I still think it won’t work for 150 nodes. This is probably something we can fix if you are willing to work on this together with us but it will take time. It’s not something that we can do on short notice. If you are skilled or one of your co-workers is, then it would be even better. We can tell you what to look at to fix this, you can fix and test and hopefully send in a pull request on github as well.

    Now first look at what George wrote. If you are new to the FOG world some of what he said might not make sense to you. So feel free to ask about the details. It’s way better we talk about these things before you rush into such a big project!

  • Moderator

    FOG doesn’t currently support managing multiple FOG servers through a single pain of glass. There has been some older discussions about doing this using the RESTful API, but the FOG developers are under manned and over worked as it is right now. So that project is sitting on the back burner.

    Personally I would like to see a skilled restful api developer step in and make that bit happen.

    Now with that said, you could switch to a central management console with storage nodes at each locations. There are some caveats with this approach in that you can only capture to the master node (probably at HQ), but you can deploy locally via each fog storage node. Since there is only one database you can manage this environment from the HQ fog server. There are some other drawbacks to this approach in that if the storage node can’t communicate with the master node, no imaging happens. If you have the fog client at the remote sites, those clients need to reach the HQ fog server to check in.