One of the reasons many people opted for the TrueCharts versions of apps that were also available in the TrueNAS catalog was their ability to run on ports <9000
I’ve migrated all my TrueCharts apps to custom docker apps but one: Nginx Proxy Manager (NPM)
I need to be able to run NPM on port 443, but iX doesn’t allow docker containers to forward to node ports below 9000. All my other apps run on high ports and are proxied through NPM
As part of the reworking of the App Catalog system, please consider allowing this
I am running caddy on port 443 as a custom app, should be the same way. You just need to use a bridge interface which you need for VMs anyway, and, assign it a static ip. Example:
But I can’t specify which interface individual apps/containers bind to. Are you suggesting I also need to change the “Route v4 Interface” interface in App Settings to be the bridge interface?
If that’s the solution I’ll give it a go, but why is this the case? I’ll be honest: it seems like more of a workaround based on a bug, than a feature. Why allow priveleged ports on a bridge interface but not a physical one?
(Also: yes, already got a bridge interface running on a different physical interface to the one I bind kubernetes to for access to a VM)
No idea if you are using 2 interfaces, I only have 1 network port. Bridges are required due to how things work, required for VMs too if you want to access the host. I don’t see why you can’t make a bridge interface to the one network port you want apps to use though. See Stux video.
Your original question mentioned nothing about wanting to bind to a specific network port with multiple interfaces. It merely asked for being able to assign ports.
It is most definitely not a bug. The reason they restrict ports to 9000+ is they do not want to cause issues with people assigning ports to stuff Scale uses. Once you assign your own IP, this is not a concern as it can’t have any conflict.
Well that’s because we hadn’t started talking about bridge interfaces and workarounds like this at that point. There’s a whole load more about my configuration I haven’t told you about, and if I detailed every little thing, whether I thought it relevant or not, we’d be here all day
I understand why iX restricts use of privileged ports, and that’s obviously not a bug. What seems odd, to me, is that that behaviour is not apparent when you either bind kubernetes to a bridge interface and/or an interface with a static address (you’ve suggested both could be the trigger that changes the behaviour).
I suspect iX are trying to block use of privileged ports on the same IP address that they run the admin webui on (which is a sensible thing to do), but are actually doing this by looking at the interface rather than the IP (otherwise bringing up a bridge interface with the same IP wouldn’t make any difference). It’s a quick, rather than a nuanced, way of doing it. Let’s leave it at that.
FWIW, the webui on my server is bound to 0.0.0.0, so as to make it available on all interfaces and networks the server is in, while the kubernetes is bound to a specific IP address, so I’m still a little unsure how this will turn out. Some experimentation is obviously needed. That said, it would be easier if the restriction simply wasn’t there, or had an “are you sure, this could break things?” tick box for the user that knows what they’re doing.
The new docker backend does not have the port 9000 and above restriction. The only check we have created is to warn you if a port you are selecting is already in use when deploying Apps via the UI. For custom apps or advanced compose usage, we don’t do any sort of validation at this time, you have full freedom to setup as you wish.
It just means nothing on our road-map to change that. If we get lots of requests for some sort of validation to be added to the “Run Custom Compose YAML” then we may consider it. But at the moment nothing planned to do so.
Validation in this case might just be a pre-flight check on ports being available, or YAML syntax checker, that kind of thing. I wouldn’t anticipate much beyond that, and only if really needed. I have a feeling we won’t though
I don’t think it’s a workaround at all WiteWulf. Your OP said: “I need to be able to run NPM on port 443”. You obviously cannot run on port 443 on Scale as the middleware UI runs on 443. So, there are only 2 solutions when using an app. You either have to use a static IP, pretty much trivial and a few minutes time, or, you have to use some other port, which < 9000 or not it doesn’t matter at that point as any port is not default.
This will not change with Eel, you still can’t run it on 443.
My webUI doesn’t run on 443, I deliberately moved it to another port to allow me to run web apps via NPM on 443. The TrueNAS OS knows that it’s webUI is on a different port, but still won’t let me use any ports below 9000 for any custom apps (which is a heavy-handed approach considering there are probably no more than 20 ports actually in use; I’ve not checked and counted). Unless I bring up a bridge interface, in which case it doesn’t apply the same restrictions, even if I’m still running the webUI on that interface and IP address. It’s an imperfect way of protecting the OS’s built-in services that people are taking advantage of to run custom apps on privileged ports. I call that a workaround.
Kris has stated this will change in Electric Eel, that a warning will be given but it won’t stop you, which is different to the current behaviour where the UI blocks you from submitting a port number below 9000, regardless of whether it’s in use or not.
Anyways, it’s academic. My feature request is in the roadmap, so I’m a happy bunny.
Actually that is incorrect. You simply change your TrueNAS port to be something other than 443 and then you can use that for your apps. This is how I do it and it works very well. Oh yeah, what wite wolf said.
Yes, I meant by default and that was the reason for the limitation. Not saying it’s perfect, desirable, etc. They were just trying to prevent using ports that were already used.
It’s trivial, as in seconds of time, to change the IP of the app and thus not have the limit. People resist doing things though. I have a reverse proxy and it works fine on it’s own IP.
Well, I installed the official NGINX Proxy manager when I upgrade to Electric Eel the other day. That allowed me to assign port 443 to it, so I guess the problem has gone away - at least for that one app, which is one of the most important ones.
Perhaps the light has been seen.
I have been installing all my docker containers via the command line and it’s working awesome. The biggest issue I’m seeing is that they don’t show up in the GUI. Not that that’s a major, but more that it’s a bit worrying because it seems like IX still want to be our IT department and tell us what versions we can have, vet them and all that. I guess if their target market is consumers that don’t know IT, or don’t want to pay someone to manage the IT, then it makes sense to have a vetted list of apps - not that I think it’d make that much difference, but it probably makes sense. Not sure that’s who buys TrueNAS though.
Anyway, not to put a negative on it, this is actually a really awesome situation, an early beta and already everything works under the hood. Worth the upgrade in my opinion - even if it is just a beta.
The latest nightly of Eel allows yaml compose files pasted into the ui and the apps show, if you create a custom app. Got a caddy reverse proxy with porkbun and registry separately defined and they work great. Both are built by truenas via compose as I always tend to add stuff to containers. Even defined a custom ip.
Didn’t need cli for anything, except, interestingly seeing any yaml errors.