Discussion:
[gentoo-user] replacement for ddclient?
(too old to reply)
Grant Edwards
2023-06-04 14:50:01 UTC
Permalink
Can anybody recommend a replacement for ddclient as a dynamic IP
service updater? I've been trying to use it for decades, and there
have been periods when it works as it's supposed to. But, usually it
doesn't, and I'm sick of fighting with it.

At the moment, it _always_ tries to do an update for reasons I can't
figure out. It has also started says that the last update attempt
failed even though it worked fine.

I've tried deleting the cache file so many times I've lost count, but
that never helps.

It has also started warning about the file mode for /etc/ddclient.conf
even though it's set exactly the way the warning says to set it:

# ls -l /etc/ddclient.conf
-r-------- 1 ddclient ddclient 509 Jun 3 08:36 /etc/ddclient.conf
# ddclient
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
CONNECT: checkip.dynu.com (IPv4)
CONNECTED: using SSL

And then it _doesn't_ warn you when it's unable to create a cache file
or find a cache file (which then causes it to misbehave).

I keep thinking that the next update might fix things, and sometimes
it does, but then something else is usually broken.

--
Grant
Jack
2023-06-04 16:20:01 UTC
Permalink
Post by Grant Edwards
Can anybody recommend a replacement for ddclient as a dynamic IP
service updater? I've been trying to use it for decades, and there
have been periods when it works as it's supposed to. But, usually it
doesn't, and I'm sick of fighting with it.
At the moment, it _always_ tries to do an update for reasons I can't
figure out. It has also started says that the last update attempt
failed even though it worked fine.
I've tried deleting the cache file so many times I've lost count, but
that never helps.
It has also started warning about the file mode for /etc/ddclient.conf
# ls -l /etc/ddclient.conf
-r-------- 1 ddclient ddclient 509 Jun 3 08:36 /etc/ddclient.conf
# ddclient
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
CONNECT: checkip.dynu.com (IPv4)
CONNECTED: using SSL
I have ddclient installed, and in my case /etc/ddclient.conf is 600 not
400, but I get the same error.  However, it appears it isn't actually
running, so I actually have no idea how my IP is getting updated.  In
addition, looking at the project's github page, although there is still
some activity, the current lead is not working on it, so it might be
time to look for a replacement.
Post by Grant Edwards
And then it _doesn't_ warn you when it's unable to create a cache file
or find a cache file (which then causes it to misbehave).
I keep thinking that the next update might fix things, and sometimes
it does, but then something else is usually broken.
--
Grant
Jack
2023-06-04 16:50:01 UTC
Permalink
I may have an explanation.  How did you run ddclient when you got that
error?  I think its check for ownership is very specific, and if you
just run ddclient from command line as either yourself or root, you are
not the owner (ddclient) of the file.  When run as a service (rc-service
ddclient start, in my case) the process is owned by ddclient, so the
ownership matches.  Also - that is just a warning, not an error, so it
should work anyway.

Jack
Post by Grant Edwards
Can anybody recommend a replacement for ddclient as a dynamic IP
service updater? I've been trying to use it for decades, and there
have been periods when it works as it's supposed to. But, usually it
doesn't, and I'm sick of fighting with it.
At the moment, it _always_ tries to do an update for reasons I can't
figure out. It has also started says that the last update attempt
failed even though it worked fine.
I've tried deleting the cache file so many times I've lost count, but
that never helps.
It has also started warning about the file mode for /etc/ddclient.conf
# ls -l /etc/ddclient.conf
-r-------- 1 ddclient ddclient 509 Jun 3 08:36 /etc/ddclient.conf
# ddclient
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
WARNING: file /etc/ddclient.conf: file /etc/ddclient.conf should be owned only by ddclient or not be writable.
CONNECT: checkip.dynu.com (IPv4)
CONNECTED: using SSL
And then it _doesn't_ warn you when it's unable to create a cache file
or find a cache file (which then causes it to misbehave).
I keep thinking that the next update might fix things, and sometimes
it does, but then something else is usually broken.
--
Grant
Grant Edwards
2023-06-04 20:40:01 UTC
Permalink
Post by Jack
I may have an explanation.  How did you run ddclient when you got that
error?  I think its check for ownership is very specific, and if you
just run ddclient from command line as either yourself or root, you are
not the owner (ddclient) of the file.  When run as a service (rc-service
ddclient start, in my case) the process is owned by ddclient, so the
ownership matches.  Also - that is just a warning, not an error, so it
should work anyway.
You're right, I was not running it as user ddclient.

It's not checking to see if the file is owned by the user ddclient,
it's checking to see if it's owned by the user _running_
ddclient. Either the code needs to be changed to check what the
warning says or the warning text needs to be changed.

Ignoring that warning, it still doesn't seem to correctly determine
whether an update attempt fails or not. As a result of that it tries
to do an update every time it runs, even though the IP address has not
changed since the last update (which did not fail, regardless of what
ddclient thinks).

I've found that my DNS provider offers their own client, and I'm going
to try that. If that doesn't work, it shouldn't take more than about a
an hour to write my own in Python. [I've wasted way more than that
trying to get ddclient to work in the past few days.]
Jack
2023-06-04 20:50:01 UTC
Permalink
Post by Jack
Post by Jack
I may have an explanation.  How did you run ddclient when you got
that
Post by Jack
error?  I think its check for ownership is very specific, and if you
just run ddclient from command line as either yourself or root, you
are
Post by Jack
not the owner (ddclient) of the file.  When run as a service
(rc-service
Post by Jack
ddclient start, in my case) the process is owned by ddclient, so the
ownership matches.  Also - that is just a warning, not an error, so
it
Post by Jack
should work anyway.
You're right, I was not running it as user ddclient.
It's not checking to see if the file is owned by the user ddclient,
it's checking to see if it's owned by the user _running_
ddclient. Either the code needs to be changed to check what the
warning says or the warning text needs to be changed.
I agree - it's probably ASSUMING that it's being run as the user
ddclient, which obviously isn't always the case.
Post by Jack
Ignoring that warning, it still doesn't seem to correctly determine
whether an update attempt fails or not. As a result of that it tries
to do an update every time it runs, even though the IP address has not
changed since the last update (which did not fail, regardless of what
ddclient thinks).
I think I did see issues filed at github for that problem. Given the
lack of any core maintainer, you're probably going in the right
direction.
Post by Jack
I've found that my DNS provider offers their own client, and I'm going
to try that. If that doesn't work, it shouldn't take more than about a
an hour to write my own in Python. [I've wasted way more than that
trying to get ddclient to work in the past few days.]
Grant Edwards
2023-06-05 00:50:01 UTC
Permalink
Post by Jack
Post by Grant Edwards
You're right, I was not running it as user ddclient.
It's not checking to see if the file is owned by the user ddclient,
it's checking to see if it's owned by the user _running_
ddclient. Either the code needs to be changed to check what the
warning says or the warning text needs to be changed.
I agree - it's probably ASSUMING that it's being run as the user
ddclient, which obviously isn't always the case.
Post by Grant Edwards
Ignoring that warning, it still doesn't seem to correctly determine
whether an update attempt fails or not. As a result of that it tries
to do an update every time it runs, even though the IP address has not
changed since the last update (which did not fail, regardless of what
ddclient thinks).
I think I did see issues filed at github for that problem. Given
the lack of any core maintainer, you're probably going in the right
direction.
I posted an issue on github that mentioned the cache problem, and the
reply was "yes, the cache is broken, but there's nobody to fix it".
One would think that the broken cache would only affect the behavior
when it's first started, so there's a different bug that makes it
think updates are failing when they aren't.
Grant Edwards
2023-06-05 03:20:01 UTC
Permalink
Post by Grant Edwards
I've found that my DNS provider offers their own client, and I'm going
to try that.
That app seems work nicely except for one thing: it sends the password
in cleartext using HTTP. The application doesn't support SSL
connections to the server that's used to update DDNS addresses,
and apparently the server doesn't support digest authentication.
Post by Grant Edwards
If that doesn't work, it shouldn't take more than about a
an hour to write my own in Python. [I've wasted way more than that
trying to get ddclient to work in the past few days.]
I'm not happy about that password being sent in cleartext. :/

They have a nicely documented API, and the server does support HTTPS,
so it may be time to write my own DDNS client daemon.

--
Grant
Robin Atwood
2023-06-09 15:40:03 UTC
Permalink
On Mon, 5 Jun 2023 03:11:57 -0000 (UTC)
Post by Grant Edwards
They have a nicely documented API, and the server does support HTTPS,
so it may be time to write my own DDNS client daemon.
Doesn't your router have a Dynamic DNS function? I stopped using
ddclient years ago because my D-Link router does the updates. It is in
a much better position to know when it is necessary!

Robin
--
Matt Connell
2023-06-09 16:20:01 UTC
Permalink
Post by Robin Atwood
Post by Grant Edwards
They have a nicely documented API, and the server does support HTTPS,
so it may be time to write my own DDNS client daemon.
Doesn't your router have a Dynamic DNS function? I stopped using
ddclient years ago because my D-Link router does the updates. It is in
a much better position to know when it is necessary!
Same. OpnSense handles my updates for me. It supports a good number
of DNS providers right out of the box.
Grant Edwards
2023-06-09 16:40:01 UTC
Permalink
Post by Robin Atwood
On Mon, 5 Jun 2023 03:11:57 -0000 (UTC)
Post by Grant Edwards
They have a nicely documented API, and the server does support HTTPS,
so it may be time to write my own DDNS client daemon.
Doesn't your router have a Dynamic DNS function?
Yes (OpenWRT), but the last time I tried it, I couldn't get it to
work. I've updated OpenWRT a few times since, but have never
revisisted the DDNS client feature to see if it would work.
Post by Robin Atwood
I stopped using ddclient years ago because my D-Link router does the
updates. It is in a much better position to know when it is
necessary!
I agree that having the router/firewall do it is the right way to do it.

I've currently got the app provided by Dynu working.

I'll soon be switching to a TP-Link ER650 router/firewall when I
change ISPs. It only supports a few DDNS services, and Dynu isn't
supported (according to the manual).

--
Grant
Grant Edwards
2023-06-09 17:00:01 UTC
Permalink
Post by Grant Edwards
I agree that having the router/firewall do it is the right way to do it.
I've currently got the app provided by Dynu working.
Interestingly, what the Dynu-provided client does is equivalent to this:

#!/bin/bash
while true
do
curl http://api.dynu.com/nic/update?username=<...>?password=<...>?hostname=<...>
sleep 120
done

The "/nic/update" command assumes that if you don't provide an IP
address, then it's supposed to use the source IP address of the
incoming TCP connection. It returns a single status string that tells
you if the "update" request resulted in a change, nochange, or failure
of some sort. [IIRC, if the IP changes, it tells you the new IP
address also.] So, the app doesn't faff around trying to determine
if/when the outside IP address has changed or even what that IP
address is.
Post by Grant Edwards
I'll soon be switching to a TP-Link ER650 router/firewall when I
change ISPs. It only supports a few DDNS services, and Dynu isn't
supported (according to the manual).
According to a recent post in the TP-Link forums, the latest ER605
firmware version has a "General" DDNS provider choice that can be
configured to work with Dynu, so that'll be the long-term solution.

https://community.tp-link.com/en/business/forum/topic/598958

Loading...