Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Run a command on ip update #570

Open
brko7 opened this issue Dec 14, 2023 · 7 comments
Open

Feature request: Run a command on ip update #570

brko7 opened this issue Dec 14, 2023 · 7 comments
Labels

Comments

@brko7
Copy link

brko7 commented Dec 14, 2023

  1. What's the feature?

Add an environment variable for a command or a path to bash script, which will run on an IP change.

  1. Extra information?

Helpful for wireguard tunnels to run this script.

Wireguard doesn't know that the peer IP changed and maintains the connection on the old DNS IP until it is restarted or reconfigured by running the mentioned script. This feature would enable the server1 that changed IP and updated the DNS to run an additional command to notify the server2 connected to server1 via wg tunnel to run the script on server2 so the new IP would be added.

@qdm12
Copy link
Owner

qdm12 commented Jan 18, 2024

How are you running DDNS updater? In its Docker image? Or as a binary outside a container (not yet pre-built but will be soon).
If it's in the Docker image, unfortunately it has no base system so there is no bash or any shell to run scripts (plus you would have to run it on the host (or container as root with NET_ADMIN) eventually, to fiddle with Wireguard.

@qdm12 qdm12 changed the title Feature request: Run a command or a bash script on ip update Feature request: Run a command on ip update Jan 18, 2024
@brko7
Copy link
Author

brko7 commented Jan 19, 2024

Hi, thanks for the reply. I am running as a Docker image. Thanks for clarifying; I will look into triggering a command based on a web push that DDNS-updater is making or some other solution.

I am running site-to-site wireguard between two servers, and on both servers, I do not have a dedicated IP, so I run DNS-updater. So when the IP of one server changes, the other stops connecting to it. I can run scripts on both servers to check the connection every few minutes, but I was hoping as ddns-updater knows when the IP changed to somehow automatically trigger reconnection on the other server.

@qdm12
Copy link
Owner

qdm12 commented Jan 19, 2024

DDNS-updater could definitely either:

  • serve the current history data (I need to do this it's in progress Get records API route #178) over http. You could have a shell script checking periodically for changes with curl.
  • send an http request when it's updated. More event driven, but you would need some http server to listen for these requests, maybe a bit too complicated 🤔 Or I can code up such little server to run arbitrary commands if you want, it shouldn't take me long.

You could also have a program/script reading the ddns updater logs and acting on them? 🤔 With docker logs -f ddns-updater and some grep-ing, that could be feasible? Feel free to share such script, I would add it to the readme!

@qdm12 qdm12 added Category: Good idea 🎯 This is a good idea, judged by the maintainers and removed Category: Label missing ❗ labels Jan 19, 2024
@brko7
Copy link
Author

brko7 commented Jan 19, 2024

Thanks for the ideas! Probably the best thing for me would be to have an event-driven trigger as ip-s change once every 5-7 days and I feel it would be a waste of resources to have script checking every minute or so. But yes maybe I can try greping the docker logs that should not be resource intensive at all.

Great I will share up here if I can think of something useful.

@qdm12
Copy link
Owner

qdm12 commented Jan 19, 2024

Here's a quick untested script to do it:

docker logs -f ddns-updater | \
  while IFS= read -r line; do
      if [[ "$line" =~ "your_predefined_regex" ]]; then
          ./your-action-script.sh
      fi
  done

I feel it would be a waste of resources to have script checking every minute or so. But yes maybe I can try greping the docker logs that should not be resource intensive at all.

Ehh more or less the same, doing an HTTP GET every second would likely not affect performance at all, despite the 'feeling' 😄 And having a one second delay would be fine too to be fair. Event driven is always better obviously, but if time driven is a lot easier, it's worth it here 😉

@incaseoftrouble
Copy link

incaseoftrouble commented Feb 9, 2024

A docker-compatible approach would be to touch / write a file. Scripts could easily check the modification time regularly or use filesystem events (inotify) for instant response.

EDIT: Actually, you could just monitor updates.json for changes :D You'd probably want to know which address has changed.

Using inotify should be something like (haven't tried it)

import pathlib
import json
import inotify.adapters

path = pathlib.Path('/path/to/updates.json')
def _main():
    i = inotify.adapters.Inotify()
    i.add_watch(str(path))
    for _ in i.event_gen(yield_nones=False):
      print("Address changed!")
      with path.open("rt") as f:
        data = json.load(f)
      # Do stuff

or simply check path.stat().st_mtime every second or so, that would be without dependencies :)

@brko7
Copy link
Author

brko7 commented Feb 13, 2024

Thanks for all the ideas and info, for now I ended up creating a service on both sides of the wireguard VPN tunnel. It runs every 2minutes and runs wireguard reresolvedns script just like in the arch docs under 5.2:

https://wiki.archlinux.org/title/WireGuard

As I am not running any production critical workloads 2minutes is fine. When ddns-updater updates the record reresolve services catches it in under 2minutes which suits me well for now.

But thanks for the ideas and script which I would definitely test somewhere in the future if I will need VPN back up in the matter of seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants