Server with multiple network interfaces: Cronicle might not work depending on IP auto-selected

[hoogenm]

If a server has multiple network interfaces, and (the first) one happens to be assigned a 169.254.-number, the Cronicle web UI would not start up (stayed blank). I found out that this is caused by Cronicle auto-selecting the first IP-number, which might not work in some situations. An option to (manually) overrule the IP-number selected by Cronicle, might be helpful in such a situation. My work-around was to disable the (first) interface, then run setup again on a fresh installation. A suggestion to make the already nice Cronicle code more robust might be to create a socket programmatically during setup/startup, and obtain the assigned IP-number from it (then an internet connection might be needed though).

[jhuckaby]

What a strange issue. I've never heard of that before. I am filtering out all "internal" IPs on startup, using os.networkInterfaces().

`internal` <boolean> true if the network interface is a loopback or similar interface that is not remotely accessible; otherwise false

I guess somehow your 169.254.- isn't marked as internal somehow, and is getting added as the primary interface.

I don't know how in the world to reproduce this, but I will try to come up with something. The problem is, someone actually may want the primary IP to be 169.254.-, for example if someone is testing Cronicle on a LAN with two machines connected directly via Ethernet cable. So I guess I have to only skip over 169.254.- if there are other non-internal IPv4 options available in the list.

[ckt114]

Is it possible to tell Cronicle which non-loopback interface to use? I’m testing in VMs and using vagrant so eth0 on all VMs has IP 10.0.2.15 and cronicle wont allow more than one slaves with that same IP although the hostname on each VM is different. Thanks.