To avoid people playing with it, this could be a semi-documented setting in the config files that's not listed by default.
Allow the port to be set before the server runs, so that there is no risk of collision.
Edit:
To clarify, I'm talking about the port the Plex that registers on the local machine, otherwise known as the "internal port". Changing this would also mean that you use NEWNUMBER instead of 32400 when port forwarding or accessing Plex/Web.
That could very easy break about 95 % of all 3.Party channels and players.
/T
Leaving aside the discussion around why channels need a hard-coded port number, quite honestly as a power user I would be perfectly fine with understanding and choosing to break 100% of channels if I could run Plex Server on a port of my choosing.
Just to be sure, you are referring to the internal port number and not the configurable external port number....
Yes, that is correct; I'm referring to being able to change the internal port number.
I honestly can't think of any other server or service which requires a certain port number. Even SSH, FTP, and SMB allow you to change port numbers if you take responsibility for the quirks.
Now, I can certainly understand that it's easier to program, and that a whole bunch of work has been done on top of that choice (most likely 99% of plugins are hardcoded, for example), but neither of those things make it the ideal choice going forward.
Yes, that is correct; I'm referring to being able to change the internal port number.
I honestly can't think of any other server or service which requires a certain port number. Even SSH, FTP, and SMB allow you to change port numbers if you take responsibility for the quirks.
Now, I can certainly understand that it's easier to program, and that a whole bunch of work has been done on top of that choice (most likely 99% of plugins are hardcoded, for example), but neither of those things make it the ideal choice going forward.
Please do consider the fact, that about 90+ % of Plex users are non technical, and even asking for an IP address is a huge task.
When that's said, some 3.Party clients can't use GDM to auto-discover PMS, and as such, also having a port number would further complicate stuff.
And here I don't even dare considering firewall's etc.
And when above is said, as a 3.Party developer, I constantly fight with users, that tries to install my plug-ins on all kinda platforms, and some I even never ever heard about.
Adding port numbers to that, would mean that I personally would stop developing channels.
Right now, I can simply attack 127.0.0.1:32400
And yes, you said you didn't care, but IMHO Plex has to look at the broader perspective.
When that's said, some 3.Party clients can't use GDM to auto-discover PMS...
Right now, I can simply attack 127.0.0.1:32400
Would it be helpful for you if the same config file that sets the port could be read by plugins? Essentially, the code would change to 127.0.0.1:$PLEXPORT. I very much agree that 90% of users should never touch a setting like that, but do we really have to throw the 10% of knowledgeable and self-directed users under the bus to avoid the potential of a squeaky wheel?
Here's maybe a more solution-oriented question:
How would you architect this part of Plex if you wanted to make it easier for developers and give more power to users?
Hypothetically, you have infinite resources, and can start from scratch.
Would it be helpful for you if the same config file that sets the port could be read by plugins? Essentially, the code would change to 127.0.0.1:$PLEXPORT. I very much agree that 90% of users should never touch a setting like that, but do we really have to throw the 10% of knowledgeable and self-directed users under the bus to avoid the potential of a squeaky wheel?
Here's maybe a more solution-oriented question:
How would you architect this part of Plex if you wanted to make it easier for developers and give more power to users?
Hypothetically, you have infinite resources, and can start from scratch.
You are forgetting the fact, that not all 3.Party apps. are running on the PMS itself....
As such only those could access the file, and would as such, have to run with elevated rights, but could be solved with the API providing us with the URL and port.
But for 3.Party apps, not running on the PMS it-self, it would be pure hell, and no idea here, since as said....not all 3.Party can use GDM, and as such, would be clueless, and support would go sky high simply due to that.
Would it be helpful for you if the same config file that sets the port could be read by plugins? Essentially, the code would change to 127.0.0.1:$PLEXPORT. I very much agree that 90% of users should never touch a setting like that, but do we really have to throw the 10% of knowledgeable and self-directed users under the bus to avoid the potential of a squeaky wheel?
Here's maybe a more solution-oriented question:
How would you architect this part of Plex if you wanted to make it easier for developers and give more power to users?
Hypothetically, you have infinite resources, and can start from scratch.
And also had to add.....
Regardless of what port you select, a port scanner would expose it.
IMHO, only a firewall on the unit running your PMS could help here, so yet again, fail to see the value of your request
Regardless of what port you select, a port scanner would expose it.
Frequently randomizing the externally exposed (i.e. internet accessible) port would make much sense, and clients wouldn't have a problem with it. From a security point of view it does make sense since it limits the value of eavesdropped traffic (from Evil Access points).
That being said, if you assume that an attacker is already on the inside of your network, port randomization isn't going to help. It is a bit like playing hide and seek in a library with a loud getto blaster on your neck. Simply listening to traffic tells you where the Plex server is, including its port. And please note that Plex does report frequently to Plex.tv, so that is a frequency you can count on. Like you indicated: firewalling is the solution there. Segmenting your network is another (I isolated all non-privileged clients in one segment).
Besides my personal desire to have services ultimately configurable, the ability that would be unlocked is to be able to run more than a single Plex instance on a server.
Right now PMS can run as another local user (very easy to do), and it can have the library/cache/metadata/plugins folder changed (also quite easy to do), but since the port is locked to 32400, only one process can bind to it, meaning this very small bit of config is standing in the way of a tool for creating our own creative solutions to whatever specific problems we want to tinker with.
Haha, ghettoblaster; big bulky 'portable' systems have been coming back in style recently. Subtle hints at now grown up project managers who were blown away by the dual tape systems as kids.
You are forgetting the fact, that not all 3.Party apps. are running on the PMS itself....
As such only those could access the file, and would as such, have to run with elevated rights, but could be solved with the API providing us with the URL and port.
But for 3.Party apps, not running on the PMS it-self, it would be pure hell, and no idea here, since as said....not all 3.Party can use GDM, and as such, would be clueless, and support would go sky high simply due to that.
As such, IMHO, not worth it
/T
Yes, you are entirely right, I am forgetting the fact that some 3rd party apps don't run locally, and I can't think of a way to make those work without some effort from the developer of each app.
Besides my personal desire to have services ultimately configurable, the ability that would be unlocked is to be able to run more than a single Plex instance on a server.
That is actually an interesting solution to another problem (lack of decent age filtering). Wouldn't a LinuX Container (see http://en.wikipedia.org/wiki/LXC) help? I played with this in the past. and it does allow a lot of flexibility towards port configuration. AFAIK, you could have specific IP-adresses assigned to the different LXC containers...
Yes, you are entirely right, I am forgetting the fact that some 3rd party apps don't run locally, and I can't think of a way to make those work without some effort from the developer of each app.
What's the barrier to 3rd party apps using GDM?
Can only speak for Samsung, but their API dosn't allow direct access to the NIC, in order to sniff for GDM.
As such, I opted a long time ago for Plex to use SSPD, like they do for their DNLA part, but so far no luck
Besides my personal desire to have services ultimately configurable, the ability that would be unlocked is to be able to run more than a single Plex instance on a server.
You can do that easily now with virtual machines, one PMS instance in each virtual machine.