ā migrate legacy DynDNS plugin to ddclient because of the deprecation warning hanging around
ā Good migration documentation found
ā migrate legacy DynDNS plugin to ddclient because of the deprecation warning hanging around
ā Good migration documentation found
Call for #ddclient testers on #OpenBSD: the `net/ddclient` package is currently at 3.9.1, but we've got a patch updating to 4.0.0 in review:
https://marc.info/?t=176774244800001&r=1&w=2
This is a pretty big jump from the old version we currently have, but is necessary for some #DynDNS providers. I'm run-testing this patch with #Gandi, but it supports so many providers that it'd be best to get a better sampling.
My configuration management for the #OpenBSD #ReverseProxy is now updated to uninstall any prior version of #ddclient, _then_ install my self-packaged v4.0.0 (but only under OpenBSD amd64/7.8-stable, for which it's built.) A little troubleshooting of #ACMEClient #LetsEncrypt errors resulting in #relayd failing to start and now everything is _finally_ running smoothly!
Suffice it to say, some of my documentation is getting updated in addition to these package & config management tweaks!
Backport of #ddclient 4.0.0 from #OpenBSD amd64/-current to 7.8-stable was painless, as expected. Now packaged and have to update configuration management for my #ReverseProxy to install it, test configuration updates, etc.
Crossing my fingers that things will be up and running fairly soon...
And I now have #ddclient 4.0.0 building & packaging under #OpenBSD amd64 -current! Only one minor patch required (an errant semicolon in `configure.ac`.)
I suspect it'll backport to amd64/7.8-stable without issue, especially since the 3.11.2 patch sent to ports@ a couple years ago still applies & builds fine on -current. I just need to figure out _where_ I'm going to do that... probably that 2010 Apple MacBook that I _just_ installed 7.8-stable on as a hot spare for my workstation.
My #OpenBSD -current dev environment is updated to the latest snapshot and ports tree updated. I can confirm that Pascal Stumpf's latest patch sent to ports@ updating #ddclient to 3.11.2 still builds successfully:
https://marc.info/?l=openbsd-ports&m=170928539629489&w=2
Sadly, neither it nor the earlier 3.10.0 patch were ever committed.
Now to try building the 4.0.0 release:
https://github.com/ddclient/ddclient/releases/tag/v4.0.0
Well, not _now_. I need some sleep.
What now?! Oh, various #LetsEncrypt failures. Ah, right, have to run my configuration management twice due to some chicken-and-egg situations with #ACMEClient and #httpd #relayd.
That should do it, ri- Ah! Nope, turns out I was using a self-built #ddclient package due the #OpenBSD port & package being outdated and not supporting my #DNS provider.
Of course, my OpenBSD dev VM is running -current. Fine, I'll have to submit a patch to ports@ anyway. Then I'll have to backport to 7.8-stable... 2/2
Sysadmin journal: setting up wireguard on all of my Linux desktops
I have several mostly interchangeable Linux computers for personal use. All but one are laptops; the mini-tower which isnāt is used as both a desktop and my home network server, e.g., for DNS and for SSHing into the home network from the outside when Iām traveling with one of the laptops.
A pro-democracy activist group that Iām part of has asked everyone in the group to use a VPN whenever accessing group stuff online (including Signal, Matrix, Proton, etc.) and has recommended using a VPN all the time. I am not convinced this is worth the effort, but it probably canāt hurt, and I donāt want to be the Guy Who Wasnāt Following The Rules if something does end up going down, so today I set out to make this happen.
I signed up for a VPN service that uses wireguard (no, Iām not going to tell you which one, that would be giving away information unnecessarily) and set out to figure out how to set up this VPN to be active all the time on my phone and all of my Linux computers. Below are my notes about the bumps in the road I hit while figuring this out and how I got over them.
The VPN service I signed up with has a bespoke Android client so setting it up for Android was trivial.
The service allowed me to add other devices to my account and download a standard-format wireguard configuration file for each, to be imported into wireguard, which I was able to do easily in NetworkManager on Debian after installing the wireguard package (Iām actually not 100% certain that it was necessary to import the wireguard package, I think it may have worked even if I hadnāt done that):
I wanted to configure the VPN to connect automatically. You canāt do that from the Settings app but you can do it from nm-connection-editor or nmcli. In the connection editor:
nm-connection-editor, a.k.a., the āAdvanced Network Configurationā desktop appIn nmcli, you can do ānmcli connection modify [connection-name] connection.autoconnect yesā.
I configure all my Linux machines via Ansible, so I wanted to figure out how to do the wireguard VPN configuration automatically using the nmcli Ansible module, i.e., I wanted to do the import as described above manually the first time and then figure out how to replicate in Ansible code what the manual import did so I wouldnāt have to do it manually in the future. Unfortunately, though the documentation claims this should be possible, for some reason I donāt have the ability to specify wireguard.peers to the module, so I canāt do the configuration automatically. Therefore, I set up an Ansible rule that checks if the VPN is configured and fails if it isnāt, so that I am reminded to configure it manually if/when Iām setting up a new computer:
- name: make sure wireguard VPN is configured and autoconnect is on nmcli: conn_name: "{{wireguard['vpn_name']}}" autoconnect: yes state: present register: nmcli check_mode: true failed_when: nmcli.changed or 'Exists' not in nmcli Next, I had to deal with the fact that when I enabled the VPN on my desktop, my ddclient configuration stopped getting my correct public IP address and instead started putting the egress IP of my VPN into my dynamic DNS entry. The reason for this is obvious. I told ddclient to use=web, web=http://checkip.dyndns.com/, and that is obviously going to go through the VPN and get the VPNās IP rather than mine. I donāt know if the fix I came up with is the best one, but it works: use=cmd, cmd='curl --silent --interface enp2s0 http://checkip.dyndns.com/ | perl -ne \'chomp; if (s/.\b([1-9][0-9]\.[1-9][0-9]\.[1-9][0-9]\.[1-9][0-9])\b./$1/){print;exit}\''
Next problem: I need to be able to log into my home desktop from outside the house. Solution: add routing policy rules on my home desktop so that traffic to/from our family server in the cloud bypasses the VPN, so that I can SSH into the cloud server from anywhere and then SSH into the home desktop from the cloud server. I deployed a script to /etc/NetworkManager/dispatcher.d to add the routing rules when the VPN comes up and remove them when it comes down. The commands the script runs look like this:
ip -4 rule add from [server IP] table mainip -4 rule add to [server IP] table main
It specifies ādelā instead of āaddā to remove the rules. I figured this out with the help of this Reddit posting. Note that this needs to be a dispatcher script because NetworkManager ignores PostUp and PreDown lines in wireguard configuration files when importing them, and as far as I can tell there is no way to configure directly in NetworkManager commands to be run when an interface goes up or down.
Final challenge: when I am working on one of my laptops and I need to SSH into my desktop, I want to do so directly via the private IP address on the home network when Iām at home, or indirectly through my cloud server when Iām out of the house, and I want this to happen automatically. Fortunately, I already had a NetworkManager dispatcher script which automatically generates ah SSH configuration file thatās included by my main SSH configuration. The old purpose of this script was so that when Iām out of the house with laptop A and I want to SSH into laptop B, which is on my home network but not accessible from the outside, that SSH automatically gets proxied through my desktop, which is accessible from the outside. I was able to augment this script to add the new functionality. Now whenever one of my laptops connects to my home network, the script adds to my SSH config a Host section for the desktop with a HostName line in it specifying the internal domain host name which resolves to its internal IP address, whereas when the laptop connects to a network outside my home, instead of the HostName line it adds a ProxyJump line specifying the host name of my cloud server.
If youāre one of the two people in the world who read this blog posting all the way to the end, drop a comment and let me know. š
#Ansible #ddclient #Linux #NetworkManager #sysadmin #VPN #wireguard
Sysadmin journal: setting up wireguard on all of my Linux desktops
I had to hack together a few things to use wireguard transparently on my Android phone and all of my Linux laptops and desktop.
#ddclient #Linux #NetworkManager #VPN #wireguard #Ansible #SysAdmin
https://blog.kamens.us/2025/05/10/sysadmin-journal-setting-up-wireguard-on-all-of-my-linux-desktops/
seriously, wtf @cloudflare
https://github.com/ddclient/ddclient/issues/820
this broke my vpn because the dns was set to 1.0.1.1 instead of the actual ip.
(real ip obfuscated but you can clearly see it's different to 1.0.1.1)
thankfully there is a workaround for now
#ddclient getting a major number update.
@mauro I have a yunohost instance running on a VM on my network. My #namecheap domain DNS supports dynamicDNS and I use #ddclient on the VM side to synchronize my dynamic IP to DNS.
spdns.de / spdyn.de notices since months that my dyndns client uses an outdated TLS version. I use ddClient on the Raspberry Pi OS from the Package Manager. The Docker version does not provoke any errors.
Additionally: Since four weeks, ddClient is deprecated.
Will switch to inadyn -> https://github.com/troglobit/inadyn
#ddclient 3.10 as shipped on #debian #bookworm is broken and doesn't even read its config file correctly. Also, the project is declared mostly dead by its maintainer. Any suggestions for altneratives?
IMHO the dyndns2 "protocol" should be possible to be implemented with about 3 lines of bash script. (But why should I do this if surely it has already been done better)
If you use #ddclient for your #ddns, beware. In my Debian install, ddclient.conf had read access for all users, giving access to DDNS credentals to virtually all users.
Just so you realize how dangerous this is, anybody with access to a user account can change your A records and point them to their own servers, without you noticing. And all of this from a very simple API.
Achja:
- #heimdall
- #homebridge
- #paperless-ngx
- #awtrix
- #diun
- #ddclient
- #tasmoadmin
Heute habe ich in der Mittagspause einen #Pixelfed-Server aufgesetzt. Das war der leichte Part.
Ich mƶchte ihn zu Hause laufen lassen. SSL-Test sagt: IPv4: A+. #IPv6: nicht erreichbar. Stimmt. Da ich von der Telekom ein ganzes Netz erhalte, hat der Pixelfedserver eine eigene IPv6. #Dyndns macht die Fritzbox aber auf der eigenen IPv6. Hab versucht, das Dyndns-Script der Fritzbox anzupassen, ohne Erfolg. Dann habe ich versucht, #ddclient auf dem server einzurichten.
@stevepdp@mstdn.social @pingudroid@mastodon.art I hear you! I've been trying to get #Mastodon setup on my #RaspberryPi as a #SingleUserInstance since last Friday now ... Managed to get only till getting the dynamic DNS to automatically update using #DDClient today.
Still need to figure out how to get #SSL certificates setup.
But gives the old neurons a chance to feel young again. š
@nicd #dynamicIPaddress #DDNS #DNS If you look at my website (www.whatwasitagain.com) section "IP address changing every day" there is a way I used using #dynu #DDclient https://www.dynu.com/DynamicDNS/IPUpdateClient/DDClient
which has never failed since I set it up.