mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 15:05:57 +03:00
[GH-ISSUE #1999] [Feature request] Allow easy access to change domain for TRMM #3196
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#3196
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 @P6g9YHK6 on GitHub (Sep 12, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1999
Is your feature request related to a problem? Please describe.
It is currently impossible to change the domain of the main rmm server without a paid support service and for something that should be just an option in the UI it is not a good look.
Describe the solution you'd like
a single field to edit on the ui that would then either require either a manual or automated change of config for the agents.
Describe alternatives you've considered
Paid service.
Additional context
i understand that if it is not in place already it is because it is a pain to put in place due to all the moving parts but the feature request is pertinent.
@conlan0 commented on GitHub (Sep 17, 2024):
if you're skilled enough/know where to look you can achieve this yourself. Though it would be nice to be able to do it easily it can already be scripted right now and there's def other features that are more important rn.
@P6g9YHK6 commented on GitHub (Sep 18, 2024):
a simple todo list would help anyone make a script that could do the job also
@WilDevSec commented on GitHub (Jan 31, 2025):
Pretty simple to do, change all occurrences of the domain in these locations:
/var/www/rmm/dist/env-config.js
/etc/nginx//sites-available/front-end.conf & rmm.conf & meshcentral.conf
/rmm/api/tacticalrmm/tacticalrmm/local_settings.py
Then restart services.
@P6g9YHK6 commented on GitHub (Feb 5, 2025):
can someone confirm this ?
@WilDevSec commented on GitHub (Feb 6, 2025):
Sorry I missed one bit in order to get meshcentral working again:
You also need to go to /meshcentral/meshcentral-data/config.json and update to the new domains
Then go to /meshcentral/meshcentral-data/signedagents and delete all the files in there.
Then restart services.
You then have to generate new deployments and re-install all agents.
The dynamic installation binaries include the domain so not sure how else to get around this.
And reinstalling all agents makes this a pointless method, may as well just re-install from scratch with new domain.
@damiankw commented on GitHub (Mar 5, 2025):
Just for the record, I just installed TacticalRMM using subdomains (rmm.mydomain, api.rmm.mydomain, mesh.rmm.mydomain) not knowing this wouldn't work due to the SSL Wildcard, so I had to run through @WilDevSec 's notes to get it all working, and it all seems to work fine afterward.
A complete summary though, because their notes were SLIGHTLY wrong, you need to update all references to your domains in:
And then delete all contents of: /meshcentral/meshcentral-data/signedagents
I'm not sure if it's entirely pointless to do on an existing install though, you might be able to simply overwrite the MeshAgent.msh file and your TacticalRMM executable on client machines for it to point your new instance, without deleting them from the */signedagents folder?