starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-13 12:50:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

How to turn off debug mode in headscale serve #14

New Issue
Closed
opened 2025-12-29 01:19:59 +01:00 by adam · 8 comments
adam commented 2025-12-29 01:19:59 +01:00
Owner
Copy Link

Originally created by @bharathmsd7 on GitHub (Jul 26, 2021).

headscale serve command runs in debug mode by default.

Is there any way to run serve as a background process so the new connections can be established while i am not logged in to the server. (Running the serve without a terminal).

Thanks in advance.

Originally created by @bharathmsd7 on GitHub (Jul 26, 2021). `headscale serve` command runs in **debug** mode by default. Is there any way to run serve as a background process so the new connections can be established while i am not logged in to the server. (Running the serve without a terminal). Thanks in advance.
adam closed this issue 2025-12-29 01:19:59 +01:00
adam commented 2025-12-29 01:19:59 +01:00
Author
Owner
Copy Link

@gtsatsis commented on GitHub (Jul 26, 2021):

You can use systemd (or any other init system) to serve as a background process (service), here's an example systemd unit file:

[Unit]
Description=headscale
After=network.target

[Service]
User=headscale
Group=headscale
WorkingDirectory=/etc/headscale
ExecStart=/usr/bin/headscale serve
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
SecureBits=keep-caps
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

This unitfile assumes that you have a user and group named headscale, that your configs are in /etc/headscale (and that the user has permission to access them), and allows you to run it on privileged ports via the CAP_NET_BIND_SERVICE (80, 443 as prime examples) [note that you might have to run sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/headscale to actually let the binary also have that capability).

As for the debug mode, it actually says in the message- You can set the environment variable GIN_MODE to release, which you can also do in the systemd unitfile by adding Environment=GIN_MODE=release under [Service]. ^-^

@gtsatsis commented on GitHub (Jul 26, 2021): You can use systemd (or any other init system) to serve as a background process (service), here's an example systemd unit file: ``` [Unit] Description=headscale After=network.target [Service] User=headscale Group=headscale WorkingDirectory=/etc/headscale ExecStart=/usr/bin/headscale serve AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE SecureBits=keep-caps NoNewPrivileges=yes [Install] WantedBy=multi-user.target ``` This unitfile assumes that you have a user and group named `headscale`, that your configs are in `/etc/headscale` (and that the user has permission to access them), and allows you to run it on privileged ports via the `CAP_NET_BIND_SERVICE` (80, 443 as prime examples) [note that you might have to run `sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/headscale` to actually let the binary also have that capability). --- As for the debug mode, it actually says in the message- You can set the environment variable `GIN_MODE` to `release`, which you can also do in the systemd unitfile by adding `Environment=GIN_MODE=release` under `[Service]`. ^-^
adam commented 2025-12-29 01:20:00 +01:00
Author
Owner
Copy Link

@bharathmsd7 commented on GitHub (Jul 26, 2021):

You can use systemd (or any other init system) to serve as a background process (service), here's an example systemd unit file:

[Unit]
Description=headscale
After=network.target

[Service]
User=headscale
Group=headscale
WorkingDirectory=/etc/headscale
ExecStart=/usr/bin/headscale serve
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
SecureBits=keep-caps
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

This unitfile assumes that you have a user and group named headscale, that your configs are in /etc/headscale (and that the user has permission to access them), and allows you to run it on privileged ports via the CAP_NET_BIND_SERVICE (80, 443 as prime examples) [note that you might have to run sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/headscale to actually let the binary also have that capability).

As for the debug mode, it actually says in the message- You can set the environment variable GIN_MODE to release, which you can also do in the systemd unitfile by adding Environment=GIN_MODE=release under [Service]. ^-^

Can you share how to run this systemd unit file.
And I am not sure whether i need to create user and group named headscale, if yes how should I do it.
I am new to linux. Testing this in my Ubuntu 18.04 machine.

@bharathmsd7 commented on GitHub (Jul 26, 2021): > You can use systemd (or any other init system) to serve as a background process (service), here's an example systemd unit file: > > ``` > [Unit] > Description=headscale > After=network.target > > [Service] > User=headscale > Group=headscale > WorkingDirectory=/etc/headscale > ExecStart=/usr/bin/headscale serve > AmbientCapabilities=CAP_NET_BIND_SERVICE > CapabilityBoundingSet=CAP_NET_BIND_SERVICE > SecureBits=keep-caps > NoNewPrivileges=yes > > [Install] > WantedBy=multi-user.target > ``` > > This unitfile assumes that you have a user and group named `headscale`, that your configs are in `/etc/headscale` (and that the user has permission to access them), and allows you to run it on privileged ports via the `CAP_NET_BIND_SERVICE` (80, 443 as prime examples) [note that you might have to run `sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/headscale` to actually let the binary also have that capability). > > As for the debug mode, it actually says in the message- You can set the environment variable `GIN_MODE` to `release`, which you can also do in the systemd unitfile by adding `Environment=GIN_MODE=release` under `[Service]`. ^-^ Can you share how to run this systemd unit file. And I am not sure whether i need to create user and group named headscale, if yes how should I do it. I am new to linux. Testing this in my Ubuntu 18.04 machine.
adam commented 2025-12-29 01:20:00 +01:00
Author
Owner
Copy Link

@gtsatsis commented on GitHub (Jul 26, 2021):

Sure, but please do take some time to give the documentation a read for yourself, there's a lot more than what I can cover here, haha!

First, copy/move the headscale binary to somewhere like /usr/bin/, so it's in the default path. That'll make it much easier to control headscale, as you can run it from anywhere.

Proceed to creating a [system] user, setting its home directory to /etc/headscale, and denying it access to a shell with sudo useradd --system --home /etc/headscale --shell /bin/false headscale. We'll run headscale as this [low-privileged] user.

Now, ensure that the headscale binary is executable (sudo chmod +x /usr/bin/headscale), and that the headscale user & group can access /etc/headscale (sudo chown -R headscale:headscale /etc/headscale).

To set up the Systemd unit, go ahead and make a file in/called /etc/systemd/system/headscale.service, with the contents mentioned above. Run sudo systemctl daemon-reload to reload systemd's services, and let it know about headscale.service.

If your configs are not already in /etc/headscale, go ahead and move them there along with your WireGuard private key file and the derp.yaml file [if you're using SQLite, also move the database over]. Once done, all that's left to do is sudo systemctl enable --now headscale, which will enable the service to start on boot, as well as start it immediately (--now).

@gtsatsis commented on GitHub (Jul 26, 2021): Sure, but please do take some time to give the documentation a read for yourself, there's a lot more than what I can cover here, haha! First, copy/move the `headscale` binary to somewhere like `/usr/bin/`, so it's in the default path. That'll make it much easier to control headscale, as you can run it from anywhere. Proceed to creating a [system] user, setting its home directory to `/etc/headscale`, and denying it access to a shell with `sudo useradd --system --home /etc/headscale --shell /bin/false headscale`. We'll run headscale as this [low-privileged] user. Now, ensure that the `headscale` binary is executable (`sudo chmod +x /usr/bin/headscale`), and that the `headscale` user & group can access `/etc/headscale` (`sudo chown -R headscale:headscale /etc/headscale`). To set up the Systemd unit, go ahead and make a file in/called `/etc/systemd/system/headscale.service`, with the contents mentioned above. Run `sudo systemctl daemon-reload` to reload systemd's services, and let it know about `headscale.service`. If your configs are not already in `/etc/headscale`, go ahead and move them there along with your WireGuard private key file and the `derp.yaml` file [if you're using SQLite, also move the database over]. Once done, all that's left to do is `sudo systemctl enable --now headscale`, which will enable the service to start on boot, as well as start it immediately (`--now`).
adam commented 2025-12-29 01:20:00 +01:00
Author
Owner
Copy Link

@bharathmsd7 commented on GitHub (Jul 26, 2021):

Thanks for spending time in this @gtsatsis
It worked 🥳🥳🥳.

@bharathmsd7 commented on GitHub (Jul 26, 2021): Thanks for spending time in this @gtsatsis It worked 🥳🥳🥳.
adam commented 2025-12-29 01:20:00 +01:00
Author
Owner
Copy Link

@bharathmsd7 commented on GitHub (Jul 26, 2021):

Hi @gtsatsis

Trying to logging in my peer using
sudo tailscale up -login-server YOUR_HEADSCALE_URL --authkey YOURAUTHKEY

It seems it doesn't responding
In peer checking status of tailscale it shows Logged out
But in Headscale it shows the peer name by executing
headscale -n namespace nodes list

@bharathmsd7 commented on GitHub (Jul 26, 2021): Hi @gtsatsis Trying to logging in my peer using `sudo tailscale up -login-server YOUR_HEADSCALE_URL --authkey YOURAUTHKEY` It seems it doesn't responding In peer checking status of tailscale it shows **Logged out** But in Headscale it shows the peer name by executing `headscale -n namespace nodes list`
adam commented 2025-12-29 01:20:01 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Jul 28, 2021):

@bharathmsd7 are you running headscale behind a proxy?

@juanfont commented on GitHub (Jul 28, 2021): @bharathmsd7 are you running headscale behind a proxy?
adam commented 2025-12-29 01:20:01 +01:00
Author
Owner
Copy Link

@bharathmsd7 commented on GitHub (Jul 28, 2021):

Yep behind an Nginx proxy

@bharathmsd7 commented on GitHub (Jul 28, 2021): Yep behind an Nginx proxy
adam commented 2025-12-29 01:20:02 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Jul 28, 2021):

Then I am going to close this issue. We are tracking the issues with nginx here https://github.com/juanfont/headscale/issues/56

@juanfont commented on GitHub (Jul 28, 2021): Then I am going to close this issue. We are tracking the issues with nginx here https://github.com/juanfont/headscale/issues/56
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#14
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?