Location plugin by subnet

[bluenix]

It would be great if the storage node to use for imaging / snapins could automatically be determined based on the subnet of the requesting client.

This would be useful in a situation where computers are physically roaming between locations. If e.g. a snapin/image for that host is queued, it would make sense to download the snapin/image from the storage node that is in the current subnet.

[Wayne Workman]

Great request. I think this can be done without too much difficulty. It would actually solve a lot of issues with locations.

I believe I can do this with PHP, and then Tom might take my example work and improve on it.

[george1421]

@Wayne-Workman you will need to link the location to a subnet (like 192.168.100.0/24 == NYC, 192.168,112.0/24== ATL, and so on). Then the client would have to query the server to find the storage nodes associated with the subnet.

This would solve an issue I have today where I have a user at another site that needs a program. But the only way to install it is over a very slow DSL link even though there is a FOG storage node at that site. (Quick fix was to move the target computer to a different location temporarly).

[Wayne Workman]

@george1421 My thought was to intercept the boot.php request, set location on that host appropriately right then and there, and then pass the query to the boot.php file - all centrally on the main server. I’ve not dug too deep into it, maybe the node is given there, idk. I’ll figure it out though.

One extra field would be needed for nodes, subnet mask.

[Tom Elliott]

@Wayne-Workman No subnet mask field would be needed for the nodes.

You should pull the subnet FROM the node directly. As if you’re on subnet 255.255.192.0 and you originally set the DB value up to 255.255.0.0, you’d be far and away off.

[george1421]

@Tom-Elliott yeah you need the IP address and mask to know where the client is. But this feature will need a fog client feature and a fog server feature to make this work seamlessly. As I see it.

[Tom Elliott]

@george1421 The client would be determined at boot time. The problem is you have to have access to the “central” server first. Then you would need to get the submask of the client booting to the boot.php script (which I don’t know that ipxe tracks).

After that point, you need to find the gateway of the network so you can scan for nodes within the scope of that network and client. Then you need to verify if the information is available on that node that is found.

What happens when there is no node found within scope?

[george1421]

@Tom-Elliott ok maybe I’m thinking of something else.

Let’s say I deploy a snap in to a client (not part of image deploy). The target gets its install command when the fog client checks in with the master node. It sees there is software to install. With this new bit of magical code it would query the fog server to find the nearest storage node in its current location (as defined by the IP address of the target computer and the network defined for the location) there still needs to be some thought put into it, but I can see the basic flow.

[Tom Elliott]

@george1421 For snapins, yes, that would be required. A sending of the subnet mask and gateway with the normal request.

I don’t think this is as easy a thing to add as what others may think.

I can almost certainly say it will not be available for 1.3.0.

[Wayne Workman]

@Tom-Elliott said in Location plugin by subnet:

As if you’re on subnet 255.255.192.0 and you originally set the DB value up to 255.255.0.0, you’d be far and away off.

People should have their settings correct. This is another thing that can be corrected for at installation time for storage nodes.

@george1421 If you know the IP address of the host requesting imaging (which you can get via PHP), and you have an IP and subnet mask for all nodes in the DB, you can just calculate what one it should use. The individual host doesn’t need to pass a subnet mask.

This setup would require the least amount of change to FOS and/or client (none at all), and a subnet mask field for nodes would be needed.