Topics created by blainey

@Sebastian-Roth This is more by design.

Typically snapins are one time run. If needed to rerun a while later, you can run it individually to the host needed, or you could task the host to run all snapins associated.

Maybe something we can limit in the future, but I guess I need better understanding.

Snapins run in queue.

For example, if a host has 25 Snapins to install, it installs 1, 2, 3, etc… It will not install 25 at once.

Now, based on the information, I believe the question here is about number of machines running snapins at once. Lets say you have 25 Machines to install Snapin 1, you want this to be limited?

Right now the code doesn’t take into consideration the number of snapin tasks as a queued process.

Hopefully this all makes sense.

Thank you,

@blainey While reading through the whole topic again and again I get the impression that it might be easier than expected. I think Eduardo is right about what he calls “hairpin NAT” but I think the term might be a bit missleading. When you use 10.10.1.4 as storage node IP the clients within the 192.168.1.x network try to contact their default gatway to reach out to that. Those requests come into your gateway on the wrong interface and usually get dropped.

On the other hand. I can tell the Master server the node ip is 192.168.1.2.
This results in replication not working but imaging via the local node is successful.

What if we tackle it from this side. I guess it still won’t be easy but can give it a try. Set the storage node IP in the web UI storage node settings to 192.168.1.2. Now with that you “only” need to make sure two things:

the Linux OS on your main FOG server needs to know how to reach 192.168.1.2 -> ip route add 192.168.1.0/24 via 10.10.1.4 dev eth0 (probably you need to set a different network interface than eth0 - just the one where 10.10.1.3 is configured to) you have port forwards and rules on the gatway to allow FTP traffic through -> this might be a bit of an issue because FTP uses random ports as well as connections going both ways depending on the FTP mode used (active or passive - not sure which one we do really)

This setup will only work if the gateway doesn’t do NATing. If it does we need to find a different solution.

@blainey Replication needs FTP (random ports for the data channel) and HTTP.