@george1421 Ultimately I want the real FOG server (Central-Master in this case) to be mostly used as the main administration point so the imaging actions of other admins in other countries can be monitored for usage, issues, and consistency.

I’m intending to disable the storage node features of the Central Master server so it’s not assigned to any Storage group, and let storage nodes take up the responsibility of deploy/capture for their respective countries.

This way I’m imagining I’ll be able to quickly see the imaging usage of other countries, the admins who are using it, ensure consistency of FOG versions across the network, and reduce the amount of maintenance needed in general by me to keep them all running (using the AccessControl plugin to restrict them somewhat).

I want to have nodes for countries, but centralise the management aspect .

@george1421 Thank you so much for the step-by-step on that process, that does clear up a lot of my questions.

So the bottom line for my own deployment is the hosts will be required to pull the 8MB bzImage kernel file over WAN from the Central-Master whether I like it or not.
It’s not a very big file now that I’m really poking at it, but I’ll need to plan in advance to allow more than HTTP & SQL ports in our VPN firewall rules for remote subnets to reach the Central-Master server - probably TFTP or FTP?

In terms of connectivity with the FOG client do you happen to know what protocols that’s going to need allowed? If there’s already a wiki entry you can tell me to shove off now

Sorry I wasn’t very clear on that, London-Master is a storage node that has isc-dhcp-server installed on it.

The DHCP next-server option is pointing to itself, client machines pick it up just fine and those services are working no problem when Central-Master is unreachable(aside from the obvious lack of connection to the SQL DB).

I suppose then the issue is more in the ‘boot.php’ file referenced in my second picture handing out what I presume to be the TFTP settings?
I’d like for that php file handed out during PXE boot to reflect that the primary FOG server is not where it should be pulling bzimage kernel files from

Hi all,

I’m hoping someone can give me some advice on how to set up FOG to boot from the master node in a given storage group/location

I’ve defined groups and nodes within those groups and also with the location plugin, but PXE booting isn’t working in a way that I’d expect.

For example purposes, the locations are defined like below:

• UK
• US
• EU

And the storage groups are defined like so:

• London
• New York
• Paris

So I’ve set it up with a master server that should provide the central management for Locations/Storage Groups/User accounts/Hosts/Images/etc. on the example IP 10.11.5.132

And there’s a Master Storage node for the London group on the example IP 10.11.5.133 which is handing out it’s own DHCP range on the subnet 10.11.17.0/24

I realise that it’s convoluted when you’re reading a text description, so here’s a diagram of the topology for this:

As you can see from above, the problem I’m having is that clients on the DHCP subnet for the London-Master node are still reaching out to the Central-Master server during iPXE boot. This isn’t a problem in this test environment, but we don’t want any traffic heavier than HTTP and SQL over the WAN connection when these are separated by physical sites.

In testing, I’m finding that while it’s pulling iPXE boot files from the London-Master , the boot.php file is directing it to pull the bzimage kernel from the Central Master node - shown below:

I had thought that by checking the setting ‘Use inits and kernels from this node’ for London-Master it would load bzimage from that node, yet it’s still insistent on pulling kernel files from Central-Master.

Does anyone know if what I’m describing is possible in FOG?

As a follow up - is there any way (within FOG) to get the clients shown in my diagram to use the local IP for the London-Master node on the 10.11.17.0/24 subnet rather than it’s WAN IP of 10.11.5.133 - I want this to keep the client subnet isolated as much as possible from the rest of the network. I suppose I could apply my own rules to redirect connections from 10.11.5.133 to 10.11.17.1 but it would be preferable if FOG was aware of this.

Sorry there’s a lot to unpack here, I appreciate any help that you can offer