XternA / income-generator

A set & forget, multi-platform, lightweight, self-updating container stack managing passive income applications utilising unused internet bandwidth. With native OS solution for fast deployment in mind with global tool access and multi-proxy support.
Other
73 stars 8 forks source link

expose gaga node port #19

Closed b8ky closed 3 months ago

b8ky commented 4 months ago

Seems like that's the port they want, might as well expose it as rewards are affected by it. Works on my machine. Additional firewall/port forwarding may be required, depending on setup.

XternA commented 4 months ago

Could you kindly provide more details that this is the port that is required by GaGaNode? I don't see anywhere in the documentation that states you must expose the following port.

Sure, on a server you may require configuring your firewall to enable ingress/egress rules to the server but shouldn't need to be for the application unless you need to explicitly have access to UI or something like that.

Merging it is not a problem but I need to consider everyone who's using it and additional changes will need to be made to the the script tool in case the ports are to be configurable.

Thanks.

b8ky commented 4 months ago

It's optional and affects mining rewards, it's the "port open" boolean in their web dashboard under mining -> nodes. The 36060 seems to be the default port (as seen eg https://docs.gaganode.com/running/how-to-run-gaganode-on-windows-desktop.html third pic from botton), not sure if you can change it, but guessing within-container port would have to match exposed port.

As for what it "does", it seems like it affects mining rewards when going by web ui dashboard under mining -> mining rules.

XternA commented 4 months ago

Appreciate the pointers. Seems this information was only shown in the Windows Desktop guide, which is why it wasn't mentioned elsewhere. Probably signifies that it's not that important.

To say that it affects mining rewards is probably false and mostly will only be related if all deployed instances are Datacenters. As long as your mining rewards is not a flat line then it's working.

I would think to interpret the ports as being to open a specific port tunnel to the server as most servers have a restricted firewall so redirecting traffic to specific inbound port makes sense. This port is apparently meaningless if the node is installed on a residential.

Anyways I opened this port myself. I will do a couple of testing with all my servers and local nodes before I approve this. I'd like to understand further how much extra it will actually have any effect.

Thanks for your patience and point this out.

XternA commented 3 months ago

So I've given it time to test and monitor with the ports being enabled on both local residential and on the cloud servers.

This is my conclusion:

Therefore I am likely to reject this PR merge. Exposing the port to the docker container also introduces risk in general unless it has a UI dashboard that you require accessing from the browser, which isn't the case here. Alternatively since it's unnecessary it will also introduce other complexity for other users setting things up or having to mess around to configure their router firewall etc.

As long as you see your device added and visible in the UI dashboard then it's already working and able to communicate with the server.

I do appreciate your time looking into this and raising the concerns which has given me ample time to prove the experiment, but this PR is really not required.