starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 06:55:52 +03:00

hosts if not already present #2436

New issue

Open

opened 2026-03-14 04:02:35 +03:00 by kerem · 5 comments

kerem commented

2026-03-14 04:02:35 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Nov 5, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/779

Originally assigned to: @wh1te909 on GitHub.

Is your feature request related to a problem? Please describe.
I ran into an edge case where celery was taking significantly longer than normal due to localhost not resolving locally.

Describe the solution you'd like
I'd like for Tactical to be fast at all times and resolve localhost without making a network request.

Describe alternatives you've considered
This if more of a discussion about a strange edge case and possible documentation in case others run into the same problem. I've considered not opening this request and making note of it for future reference but that doesn't help the community.

Additional context
I installed Ubuntu 20.04 in an nspawn container with debootstrap and then installed Tactical using the standard install. One asset was added. Everything was working as expected. Then I introduced Nebula and in the process changed the DNS to use a server in the cloud. This caused significant delays in the frontend but technically everything still worked.

The troubleshooting process led to a celery being slow and timing celery shows about a 5 second delay. Compare the production timing with the dev timing.

Production

time /rmm/api/env/bin/celery -A tacticalrmm list bindings
Queue                        Exchange                     Routing Key
----------------             ----------------             ----------------
celery                       celery                       celery

real    0m0.337s
user    0m0.306s
sys     0m0.028s

Dev

time /rmm/api/env/bin/celery -A tacticalrmm list bindings
Queue                        Exchange                     Routing Key
----------------             ----------------             ----------------
celery                       celery                       celery

real    0m5.726s
user    0m0.321s
sys     0m0.039s

The output of time /rmm/api/env/bin/celery -A tacticalrmm report showed redis://localhost/ was used which clued me into localhost. This lead to the question: Where is localhost resolved? A fresh Ubuntu install creates /etc/hosts and adds the various localhost flavors for name resolution.

Fresh install of Ubuntu 20.04 in VM

127.0.0.1 localhost
127.0.1.1 $hostname

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Comparing a fresh Ubuntu 20.04 install with an nspawn install, /etc/hosts is missing from the nspawn install and present in the full install. /etc/nsswitch.conf is the same for host resolution: hosts: files dns. This leads us to DNS. Both systems have /etc/resolv.conf symlinked to /run/systemd/resolve/stub-resolv.conf which is provided by systemd-resolved.service. The change I made that broke celery was changing the symlink to /run/systemd/resolve/resolv.conf and adding a DNS=1.1.1.1 entry to /etc/systemd/resolved.conf, effectively removing systemd-resolved from the equation.

The systemd-resolved documentation states "systemd-resolved' will resolve synthetic records, one of which is localhost. If localhost is not in /etc/hosts and the DNS has not been changed, localhost will still resolve locally without making any DNS requests over the network. However, if localhost is not in /etc/hosts and the DNS has been changed, there will be significant delays in the frontend of Tactical.

Adding localhost to /etc/hosts if it's not already present doesn't introduce any problems because the installer adds them. I suggest checking for localhost and if it's not already present, add it to /etc/hosts.

Originally created by @NiceGuyIT on GitHub (Nov 5, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/779 Originally assigned to: @wh1te909 on GitHub. **Is your feature request related to a problem? Please describe.** I ran into an edge case where celery was taking significantly longer than normal due to `localhost` not resolving locally. **Describe the solution you'd like** I'd like for Tactical to be fast at all times and resolve `localhost` without making a network request. **Describe alternatives you've considered** This if more of a discussion about a strange edge case and possible documentation in case others run into the same problem. I've considered not opening this request and making note of it for future reference but that doesn't help the community. **Additional context** I installed Ubuntu 20.04 in an nspawn container with [`debootstrap`](https://linux.die.net/man/8/debootstrap) and then installed Tactical using the standard install. One asset was added. Everything was working as expected. Then I introduced [Nebula](https://github.com/slackhq/nebula) and in the process changed the DNS to use a server in the cloud. This caused significant delays in the frontend but technically everything still worked. The troubleshooting process led to a celery being slow and timing celery shows about a 5 second delay. Compare the production timing with the dev timing. **Production** ```text time /rmm/api/env/bin/celery -A tacticalrmm list bindings Queue Exchange Routing Key ---------------- ---------------- ---------------- celery celery celery real 0m0.337s user 0m0.306s sys 0m0.028s ``` **Dev** ```text time /rmm/api/env/bin/celery -A tacticalrmm list bindings Queue Exchange Routing Key ---------------- ---------------- ---------------- celery celery celery real 0m5.726s user 0m0.321s sys 0m0.039s ``` The output of `time /rmm/api/env/bin/celery -A tacticalrmm report` showed `redis://localhost/` was used which clued me into `localhost`. This lead to the question: Where is `localhost` resolved? A fresh Ubuntu install creates `/etc/hosts` and adds the various localhost flavors for name resolution. **Fresh install of Ubuntu 20.04 in VM** ```text 127.0.0.1 localhost 127.0.1.1 $hostname # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ``` Comparing a fresh Ubuntu 20.04 install with an `nspawn` install, `/etc/hosts` is missing from the nspawn install and present in the full install. `/etc/nsswitch.conf` is the same for host resolution: `hosts: files dns`. This leads us to DNS. Both systems have `/etc/resolv.conf` symlinked to `/run/systemd/resolve/stub-resolv.conf` which is provided by `systemd-resolved.service`. The change I made that broke celery was changing the symlink to `/run/systemd/resolve/resolv.conf` and adding a `DNS=1.1.1.1` entry to `/etc/systemd/resolved.conf`, effectively removing `systemd-resolved` from the equation. The [`systemd-resolved`](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Synthetic%20Records) documentation states "systemd-resolved' will resolve synthetic records, one of which is `localhost`. If `localhost` is not in `/etc/hosts` and the DNS has not been changed, `localhost` will still resolve locally without making any DNS requests over the network. However, if `localhost` is not in `/etc/hosts` and the DNS _has_ been changed, there will be significant delays in the frontend of Tactical. Adding `localhost` to `/etc/hosts` if it's not already present doesn't introduce any problems because the installer adds them. I suggest checking for `localhost` and if it's not already present, add it to `/etc/hosts`.

kerem added the

In Process

label

2026-03-14 04:02:35 +03:00

kerem commented

2026-03-14 04:02:46 +03:00

Author

Owner

@wh1te909 commented on GitHub (Nov 6, 2021):

sounds good, the install script already adds entries to /etc/hosts so i'll also add localhost if not present

@wh1te909 commented on GitHub (Nov 6, 2021): sounds good, the install script already adds entries to `/etc/hosts` so i'll also add localhost if not present

kerem commented

2026-03-14 04:02:51 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Dec 11, 2021):

For reference, here is /etc/hosts after a fresh install with hostname vs-23-ubuntu. I don't know if IPv6 is necessary if the application is not IPv6 aware.

127.0.0.1 localhost
127.0.1.1 vs-23-ubuntu

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Also /etc/os-release for version info.

NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

@NiceGuyIT commented on GitHub (Dec 11, 2021): For reference, here is `/etc/hosts` after a fresh install with hostname `vs-23-ubuntu`. I don't know if IPv6 is necessary if the application is not IPv6 aware. ```text 127.0.0.1 localhost 127.0.1.1 vs-23-ubuntu # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ``` Also `/etc/os-release` for version info. ```text NAME="Ubuntu" VERSION="20.04.3 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.3 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal ```

kerem commented

2026-03-14 04:02:56 +03:00

Author

Owner

@ninjamonkey198206 commented on GitHub (May 3, 2022):

If this still needs to be resolved, I could probably knock it out pretty quick. Should be the kind of grunt work I can currently handle while I'm learning the rest. Should just need the update and install scripts edited, unless I'm mistaken.

@ninjamonkey198206 commented on GitHub (May 3, 2022): If this still needs to be resolved, I could probably knock it out pretty quick. Should be the kind of grunt work I can currently handle while I'm learning the rest. Should just need the update and install scripts edited, unless I'm mistaken.

kerem commented

2026-03-14 04:03:01 +03:00

Author

Owner

@ninjamonkey198206 commented on GitHub (Jun 3, 2022):

I'll add this in while I'm reworking the scripts. Planned to rework the host entries anyway.

@ninjamonkey198206 commented on GitHub (Jun 3, 2022): I'll add this in while I'm reworking the scripts. Planned to rework the host entries anyway.

kerem commented

2026-03-14 04:03:06 +03:00

Author

Owner

@ninjamonkey198206 commented on GitHub (Jun 11, 2022):

@wh1te909 this has been added in the rework of the bash scripts I've been working on. Silver and Dinger are going to help test it all.

@ninjamonkey198206 commented on GitHub (Jun 11, 2022): @wh1te909 this has been added in the rework of the bash scripts I've been working on. Silver and Dinger are going to help test it all.