mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #999] Change Default Ports 80 and 443 #2552
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#2552
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @daygle on GitHub (Mar 8, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/999
Version:- Current
Type:- Docker
Would someone have instructions on how to change the default ports 443 and 80 in the docker install? I have attempted to do this by changing the ports in the docker-compose.yml file.
ports:
After changing the ports the TacticalRMM webpage loads correctly. Unfortunately when attempting to login with my credentials I am unable to login (after the auth code is entered) - I think it shows a 'Bad login' message. Changing back to port 443 and 80 I am once again able to login.
It appears that I may be missing something.
Any help would be much appreciated.
@dinger1986 commented on GitHub (Mar 8, 2022):
You can't, this isn't a tactical restriction but mesh. It needs to communicate on 443.
@AddoSolutions commented on GitHub (Nov 29, 2023):
This is either incorrect, or no longer the case. I can use Mesh on a different port without a problem
@silversword411 commented on GitHub (Nov 29, 2023):
Tactical doesn't support changing the port to anything other than 443 because of all the places it's hardcoded into.
You're on your own if you want to try and go thru the code, customize everything necessary and get it to work.
@wh1te909 commented on GitHub (Nov 29, 2023):
support was added recently in https://github.com/amidaware/tacticalrmm/pull/1643 (docker only of course)
@AddoSolutions commented on GitHub (Nov 29, 2023):
I guess that’s why I’m saying this. That is the point of an issue, to point out that it’s not supported, and is a pretty standard function.
I believe this issue should at least be left open, even if not resolved
Get Outlook for iOShttps://aka.ms/o0ukef
From: Dan @.>
Sent: Wednesday, November 29, 2023 4:56:30 PM
To: amidaware/tacticalrmm @.>
Cc: Nick Artman @.>; Comment @.>
Subject: Re: [amidaware/tacticalrmm] Change Default Ports 80 and 443 (Issue #999)
support was added recently in #1643https://github.com/amidaware/tacticalrmm/pull/1643 (docker only of course)
—
Reply to this email directly, view it on GitHubhttps://github.com/amidaware/tacticalrmm/issues/999#issuecomment-1832763505, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA5OGCLGMZXZHU3LEORDDY3YG6VQ5AVCNFSM5QHOOWN2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTGI3TMMZVGA2Q.
You are receiving this because you commented.Message ID: @.***>
@AddoSolutions commented on GitHub (Mar 14, 2024):
@dinger1986 Can we re-open this issue? The request remains open, is possible, and being able to change default ports is a pretty standard function of most software. It is also one of the main reasons I am not using this platform
@wh1te909 commented on GitHub (Mar 14, 2024):
i've re-opened it, but will require some significant rework as everything communicates thru https and secure websockets, 443 also standard across the industry for https (when's the last time you had to type in a port number when going to a website xD)
@AddoSolutions commented on GitHub (Mar 14, 2024):
That is correct, but there are applications where using non-standard ports is preferable. I will review and see what it'd take to get there.
@aNostalgicTrooper commented on GitHub (Mar 20, 2024):
I understand port 443 is standard for HTTPS, but for IP re-usage changing the port number would be an incredibly useful feature.
For hosted services its nice to be able not have to use a new IP every time I need to host a new application, where if I could change the port number I have much more flexibility with IP usage.
I very much appreciate how baked into the code the port numbers are, some other applications bake it in at the point of install after you chose what port you want to use.
I am very serious about becoming a sponsor but this is a slight issue.
@dinger1986 commented on GitHub (Mar 20, 2024):
By hosted services you mean on servers running other services? Which is a problem because you might have conflicting services on a hosted server which then will prevent install
@AddoSolutions commented on GitHub (Mar 20, 2024):
Not if you are dockerized – That is one of the anchor tennants of containerization, you can have as many pieces of software running on one box, without conflict, so long as you have enough resources to support it.
@aNostalgicTrooper commented on GitHub (Mar 21, 2024):
I tend to host many VM’s on a cluster and then use NAT to fort forward in from the outside world. Though we do have a number of IP’s coming into the firewall and can use Port Address Translation (PAT) the clients will always expect to be coming back in on 443 in this case so have to use an IP that does not have 443 NAT’d though it already.
Unless I am totally overlooking something in this case.
@AddoSolutions commented on GitHub (Mar 21, 2024):
Correct, which is what I am looking for – I need to be able to have the clients talk on a different port.
Code-wise, there shouldn't be too much in the way to get this moving. I am still trying to get some time to dig into the codebase, but there should only be two different components that need updating:
Easiest route:
In most other packages, there is a separate environment variable that is provided (ex.
PUBLIC_URL) that is what is used for any published URLs. That URL can include a:1234at the end, and since the software is just plopping in the exact URL provided in the env, the only code change is to use the env variable everywhere instead of something generated.@dinger1986 commented on GitHub (Mar 21, 2024):
Why not use nginx or another proxy? There's plenty of guides on our docs.
Especially if you are running docker seems fairly standard practice
@ssteeltm commented on GitHub (Mar 22, 2024):
If dont want proxy, why not just use the old nats port. Guess its waste of time.
@wh1te909 commented on GitHub (Mar 22, 2024):
Even if using the old nats port, the agent still sends http requests back to the server. The agent does support custom urls/ports but this is not currently documented. On the server side should just be a matter of changing nginx to listen on another port other than 443 and then yes going through the code to find everywhere URLs are generated etc.
@AddoSolutions commented on GitHub (Mar 22, 2024):
This – to be clear, it makes no difference to me what port the application server listens on (although it should really be configurable) that is outside of the scope of this issue,
I specifically am requesting that I can do a NAT from port X to 443 on the application server, and the client will still be able to communicate correctly as long as the application server has been told what that port is. As long as I can do that, that will close this issue
Based on your comment, this may just be a docs thing, although I was expressly told this was NOT possible earlier
@wh1te909 commented on GitHub (Mar 22, 2024):
there are still places inside the code where 443/https is hardcoded so no it won't work until we find all those
@aNostalgicTrooper commented on GitHub (Mar 22, 2024):
From my understanding there was a lot of hard coded places that could not be addressed by simple PAT or Proxy usage as the clients will be talking back to 443 and the PAT rule or Proxy just wont be listening.
Sadly all these hardcoded places need to be written on installation of an instance or on a configuration page that runs a script to go and change all known ports things live on to answer back from all the clients out there.
This is not just a simple task though as if an application is written with hardcoding these in mind its not so easy to make them changes later on. I fully accept that.
People short on IP addresses who self host in their own owned infrastructure would very much appreciate this being a feature though.
I am going to have to try and free up an IP address for testing as I do very much like the look of TRMM
@AddoSolutions commented on GitHub (Mar 23, 2024):
So looking through the code here, I see a few spots that would likely need addressed, but there aren't a ton:
Client:
github.com/amidaware/rmmagent@51f6e93a35/agent/agent.go (L220)Server:
github.com/amidaware/rmmagent@51f6e93a35/agent/agent.go (L220)github.com/amidaware/tacticalrmm@89aceda65a/api/tacticalrmm/core/management/commands/get_mesh_exe_url.py (L33)github.com/amidaware/tacticalrmm@89aceda65a/api/tacticalrmm/clients/views.py (L378)@Timtams23 commented on GitHub (Aug 21, 2024):
Is it in the future plans to allow these codes to be variable so that users that want to use ports other than 80 or 443 can simply specify the port and the code will allow it?
I appreciate the teams work on this amazing service.
@wh1te909 commented on GitHub (Aug 21, 2024):
yes it's planned i'm actually working on it now
@ScubaCaribe commented on GitHub (Dec 2, 2025):
Do we happen to have any updates on if/when this will be addressed?