Comments (12)
After some reviewing, I can see how to make an app obey this. I forked the runtipi-appstore and modified the syncthing app to use APP_DOMAIN instead of APP_PORT (link here)
Because APP_PORT resolves solely to the outside port used by Tipi for the app, the app is available via all interfaces/IP addresses. By using APP_DOMAIN instead, it resolves to "ip:port", and the IP in this case is what is configured as the listenIP address in config.json
The resulting tests show that Syncthing via Tipi is not available via the local LAN IP address.
However, it is available via its Tailscale IP address (resolved via the Tailscale domain)
What from here? This would mean that apps in the app store would need to be updated. Perhaps there's a better way I'm not thinking of. As well, Tipi itself would need to accommodate this too.
from runtipi.
I'll also note that I can manually edit the ports section of a docker-compose.yml of an app to achieve only having that app respond via Tailscale, but that of course gets overridden during app upgrades and I haven't found out how to achieve this using the user-config method either.
from runtipi.
Thanks for your research @willjasen. Indeed this would require a change in all apps. I added this to the backlog so I can revisit this issue later. Does the user_config not allow you to override the port?
from runtipi.
I can specify "${APP_DOMAIN}:inside-port" within user-config (for example, doing this for syncthing would resolve to something like "100.64.0.1:8090:8384" in user-config/syncthing/docker-compose.yml), but since user-config seems to be in addition to, apps are still available via all interfaces/IPs (via apps/syncthing/docker-compose.yml). If there's a way in Docker Compose to negate a previous statement, I think I could get it working, but I don't think that there is.
from runtipi.
You are correct, it would only add an entry to the list. What we could do is by default to listen on all interfaces and if the user specify a custom listenIp, it is always binding to this ip
from runtipi.
According to here, the listenIp parameter is read into the environment map as INTERNAL_IP. I think that this means there's a bit of duplication here, as listenIp and INTERNAL_IP are kind of the same thing - INTERNAL_IP can always be set manually through the GUI but when listenIp is set via settings.json, it will override it, but this setting should be tweakable but stately from either the GUI or config. A distinction between the two is the juxtaposition I found myself in originally as I kept tweaking both listenIp and INTERNAL_IP yet never yielded the sort of binding results that I sought out.
I first propose that these two variables are merged into one - listenIp seems like it would more easily collapse into INTERNAL_IP. Along with the collapse, INTERNAL_IP should be more thought of as a BIND_IP (either a specific IP address available to the system or the wildcard 0.0.0.0 which binds to any IPv4 interface, but the rename isn't necessary, so long as everyone else understands the distinction).
For APP_PORT, my quick fix is here. By performing this logic, it omits the need to re-calibrate the app store (somewhat). I feel like there's some further consideration for this change on how it reflects against exposing an app. In the case I have, I'm not exposing apps to the public, and if I did, I would either do so via a Tailscale funnel or Cloudflare tunnel. In the end, I think this is gonna be one of those changes that requires a heads up to everyone when pushed. Since Tipi currently uses the first network interface's IP address, lots of people have x.y.w.z already within their config, and I think most people will need to change their INTERNAL_IP parameter into 0.0.0.0 so that Tipi will listen on all interfaces. The worst case here I foresee is that Tipi then binds to say the wired network interface and is only accessible via its address, but since most people are somewhat using x.y.w.z and 0.0.0.0 synonymously, they shouldn't see a break. However, for those out there like me, setting INTERNAL_IP to something like in an overlay network will ensure that Tipi and its apps are only accessible via that interface's address. It also doubles as redundancy in some cases, where the overlay network works over both wired and wireless interfaces, so if the wired connection goes down, it seamlessly transitions over to the wireless interface.
Those are my thoughts, I welcome any input. It's possible that I'm missing some intended use of listenIp or INTERNAL_IP that offers a distinction of the two. The beginnings of my professional background is in network engineering but I do a little bit of everything, so that leaks over into programming. Keeping services bound to particular interfaces is an important way to handle modes of accessibility and helps provide least privileged access for security hygiene.
from runtipi.
So to clarify with a bit of history, INTERNAL_IP
was initially auto-generated and used to generate hostname env variables (needed by some apps). Some users have had issues because their system had two or more IPs and the automated system would pick up the wrong one. This is when the setting listenIp
was added. The name discrepancy between listenIp
and INTERNAL_IP
was created just because I felt it would sound wrong for users to "set" an internal IP. However, in retrospect it should have been named differently. Now for your use case, I think adding a BIND_IP
env var and bindIp
setting with default 0.0.0.0
is the best move forward in a backward-compatible thought. Still, I'm concerned about the confusion it could bring for people to have both these settings. Maybe @willjasen you have an idea on how we could rename INTERNAL_IP and listenIp
to something more understandable. The only requirement I need is to not break any existing config
from runtipi.
Sorry for the radio silence! I'm juggling lots of things. I'm also preparing to change my hosting architecture so that I don't have to rely on Tipi solely to bind its interface properly.
I think if you're going for a non-breaking change, then a bindIp parameter should be added, though listenIp is really the same thing in my mind. The bindIp parameter should have a default of "0.0.0.0" so that all IPs are listened in on and the user can then change that to a specific interface IP address to then limit where Tipi is listening. Maybe add a bit of logic so that the bindIp parameter doesn't get set to just anything that is put in - check that the IP being entered is an IP available on the system.
I could see confusion for some between bindIp and listenIp and such so if that's to be collapsed, I would assume that's a breaking change, and the only way to somewhat manage that is to give everyone plenty of heads up before.
from runtipi.
This issue is stale because it has been open for 30 days with no activity.
from runtipi.
This issue is stale because it has been open for 30 days with no activity.
from runtipi.
This issue was closed because it has been inactive for 14 days since being marked as stale.
from runtipi.
This issue is stale because it has been open for 30 days with no activity.
from runtipi.
Related Issues (20)
- [BUG] After Update to 3.1.2 Runtipi cannnot start anymore! HOT 3
- [BUG] formfield type password length check HOT 8
- [BUG] Archivebox dead after update from 3.1.0 to 3.1.2 HOT 5
- [BUG] AppStore integration app search categories is not de-selectable HOT 3
- [REQUEST] IPV6 Support HOT 3
- [BUG] Fresh install - Safari - WS issue HOT 8
- [REQUEST] add a default basic-auth middleware to tipi HOT 1
- [BUG] Unhealthy Traefik or weird runtipi-reverse-proxy service error. HOT 10
- [BUG] docker of apps running, but not present in My Apps tab HOT 8
- [REQUEST] Allow users to attach volumes to containers HOT 2
- [BUG] When changing the global settings the .env of apps isnt updating HOT 1
- Pending restart (app) HOT 2
- [BUG] Cloudflared webUI is broken. HOT 1
- Add Brazilian Portuguese translation support HOT 1
- [BUG] Failed to copy system files HOT 2
- [REQUEST] runtipi-cli additions
- [BUG] runtipi-cli app update error
- Auto backup before app update
- [BUG] runtipi-cli error if executed outside its working directory
- [REQUEST]Paperless-ngx: Add local domain automatically to PAPERLESS_CSRF_TRUSTED_ORIGINS
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from runtipi.