DNP_DAPPMANAGER icon indicating copy to clipboard operation
DNP_DAPPMANAGER copied to clipboard

Two DAppNodes on the single (local) network

Open 3alpha opened this issue 2 years ago • 3 comments

Currently, DAppNode assumes that is only such device on the network. However, there has been an intrest to make DAppNodes aware of each other so that they are able to run in the single local network concurrently.

To acomplish that, following changes should be made to DAppManager.

  • Refactoring of UPnP module. Currently, DAppManager scans for the ports exposed by the Docker containers and asks router via UPnP to expose same ports to the Internet. With two DAppNodes on the same network, that won't be possible anymore. With the packages that use ephimeral ports that won't be an issue, but packages that use fixed ports, like VPN and DNP_HTTPS, additional step will have to be taken to make experience seamless.
  • At start time, DAppManager should detect whether "DAppNode" wifi network exists and start DNP_WIFI container with some other SSID
  • Also, it should detect whether 'dappnode.local' domain resolves on the local network and change it to something else. For this small changes in DNP_HTTPS are necessary.
  • For DNP_WIREGUARD, DAppManager should change port that is exposed to the outside and reflect that in configuration files

It is important to note that experience with DNP_HTTPS on second DAppNode will be little worse since in the domain will be necessary to specify port.

3alpha avatar Mar 17 '22 11:03 3alpha

yeah! this would be a really nice feature in DAppNode

Refactoring of UPnP module. Currently, DAppManager scans for the ports exposed by the Docker containers and asks router via UPnP to expose same ports to the Internet. With two DAppNodes on the same network, that won't be possible anymore. With the packages that use ephimeral ports that won't be an issue, but packages that use fixed ports, like VPN and DNP_HTTPS, additional step will have to be taken to make experience seamless.

what about having a master option to be set through the UI, that would mean having a "master" dappnode with a preference on non-ephemeral ports. DAppNodes without this master option will do port-forwarding of fixed ports to other

At start time, DAppManager should detect whether "DAppNode" wifi network exists and start DNP_WIFI container with some other SSID

This is a good one. Again, this could be taken into account by this master option: DAppNodeWIFI-master vs DAppNodeWIFI-slave or whatever

Also, it should detect whether 'dappnode.local' domain resolves on the local network and change it to something else. For this small changes in DNP_HTTPS are necessary.

Could be dappnode.local for the master dappnode and dappnode.local-slave or whatever

pablomendezroyo avatar Mar 17 '22 12:03 pablomendezroyo

I thought about that and I think that is not necessary and would introduce complexity we don't need. For example, what happens when "master" DAppNode goes offline? Does something change with the "slave" one? That's why I think it is better just to have all DAppNodes that are born equal and just detect stuff when they start. For example, during the start DAppNode checks whether it can forward 443 port. If it cannot, it has to be able to chose different port and print appropriate message for the HTTPS access.

Another benefit of this is that users can have different devices on the network which already use ports which DAppNode want to use. This way that problem completely disappears since only thing important in this framework is whether port is free or not.

3alpha avatar Mar 17 '22 15:03 3alpha

Started https://github.com/dappnode/DNP_HTTPS/pull/63 for this.

3alpha avatar Mar 18 '22 10:03 3alpha