Feature request: Webhooks

[noseshimself]

Why

MagicDNS is not exactly doing what I really need without a lot of hacks on my DNS servers. In a number of cases it would be easier to just update a "real" name server or use a completely different mechanism.

Information could be scraped from logs but that's inefficient. A special peer could be crafted to serve as bridge to external tools but that seems to be the completely wrong direction.

Description

Please add a simple mechanism that will call an external tool

The path to the tool should be configurable (and calls should only be made if it has been configured) and should send "event" (e. g. "client is ready"/"client has closed the connection"), account, client name and IP address(es). The exit code of the subprocess can be safely ignored. It's not your problem.

[kedare]

Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com)

[noseshimself]

Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com)

In a way you might have the better idea; a webhook (being a remote procedure call using http(s) will be a mechanism that would be applicable even if you did not have a shell (thank you, Apple, for trying to keep users away from using the devices they own) or want to avoid having to use curl.

[kradalby]

I think that webhooks would be a neat feature, I do not think we want to open the can of worms that is executing things outside of the go binary.

We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback.

[noseshimself]

We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback.

I believe I put my immediate need in my original request: I need to remotely update a DNS server because MagicDNS is breaking things on my end. That's why I am interested in the events "link up" and "link down" (assuming that you will never reassign IP addresses on the fly while connections are active.

I can certainly see other useful events (e. g. "account added", "node added", or "deleted").

Personally I would leave parsing the stuff to the consumer and keep the configuration part on your side as simple as possible. One hook per consumer and you either provide whatever you want as JSON and drop it off in front of the feet of the consumer(s) or you put all data into the URI itself and the consumer has to take that apart.

The only one who is able to judge which is easiest to implement is you. If you need to know which events the users would like to see it might be best to enable discussions and put it there.

[tiredofit]

This is a feature of Tailscale and seems to be very useful. I too have problems with MagicDNS and the concept of hooks on specific actions would be extremely beneficial.

Tailscale implementation: https://tailscale.com/blog/webhooks/

[noseshimself]

This is a feature of Tailscale and seems to be very useful

It is extremely useful. By mirroring my mesh-names of machines into my general DNS domains I'm able to have systems behind "mesh routers" (yes, I installed tailscale on OPNSense) using these addresses, too.

[celevra]

+1

[tarasglek]

In theory this could already be done by following the headscale log. It would be nice if headscale supported emitting events to something like NATS

[sosnik]

Would also like to have events emitted, whether as webhooks or as another mechanism doesn't really matter to me.

In the meantime, a hacky solution might be to use something like headscale nodes list -o json on a timer to dump status information in a machine-readable state.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.