How to allow local broadcasting and discovery for more than one instance on the same host?

linuxserver / docker-syncthing

GNU General Public License v3.0

293 stars 45 forks source link

How to allow local broadcasting and discovery for more than one instance on the same host? #45

Closed gamato closed 1 year ago

gamato commented 3 years ago

Current Behavior

Syncthing uses broadcasts for local discovery. When run in a container as suggested by LSIO the local discovery does not work and a relay server must be used for local connections involving such a syncthing instance. This is very slow and inefficient on local networks.

Desired Behavior

It would be great if this was documented/explained and an alternative setup suggested (such that the local discovery works and local devices / syncthing instances can see and communicate with the LSIO dockerised syncthing instances).

Alternatives Considered

Merely using network_mode=host is not enough if one needs to run more than one Syncthing instance. GUI address is hardcoded in the container run script. It would be useful if it could be changed like it is possible in the official Syncthing docker image (via ENV variable STGUIADDRESS that is directly supported by Syncthing app).

github-actions[bot] commented 3 years ago

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

gamato commented 3 years ago

Implemented in #46

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

gamato commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

And what can I do about it? It's been 8 weeks since I opened this issue, even provided a patch / pull request, yet no one from linuxserver team has done anything about it. :-[

aptalca commented 3 years ago

Thanks, I'll look into it. But we do have a big backlog of issues and PRs done a lot more critical than others.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

gamato commented 2 years ago

Again, what can I do about it? It's been months since I opened this issue, even provided a patch / pull request, yet no one from linuxserver team has done anything about it so far. :-[

aptalca commented 2 years ago

Thanks for the PR, but to be honest your use case is a very fringe one (hosting two instances on the same server with host networking) therefore it was triaged with a lower priority. We didn't get a chance to look at it yet. Too many fires to put out, ones that affected masses.

flatline-studios commented 2 years ago

This is funny. The change is basically two lines. I'd bet it took longer to write that reply than to quickly review the changes. ;)

aptalca commented 2 years ago

I don't find it funny at all. There is a lot that goes into reviewing a PR, which includes quite a bit of testing, and hypothesizing what else it could affect and potentially break. Not to mention, even if it works, we may decide not to merge it after all, if it is likely to create more support burden. So no, it really doesn't matter how many lines it is.

You are welcome to fork it, maintain your own image and provide support for it.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.