Talk:Dynamic DNS
Separation of DDNS providers and applications to update them?
I just realised that the subsection for ddclient is buried inside the section for Afraid.org DDNS. However, it looks like each of these sections are dedicated to a single DDNS provider (i.e. a server) rather than the programs to update them.
Would it make sense to make two separate sections, "DDNS Providers" and "Programs to Update DDNS Hosts"? I know there are several more programs out there that are like ddclient which support many different providers.
--TheFlyingPengwyn (talk) 23:17, 1 November 2015 (UTC)
- Yes, it would certainly make much more sense than the current layout, but it should be clearly described which tools support which servers. Perhaps only the general tools should be moved into separate section, at least for the start? -- Lahwaacz (talk) 23:45, 1 November 2015 (UTC)
- I had a go at restructuring it a bit. I left most of the subsections as they were but I did touch up their formatting a bit. I'm not familiar with the style guidelines though so it might be a bit off.--TheFlyingPengwyn (talk) 12:07, 2 November 2015 (UTC)
Starting ddclient after networking is up
I'm adding this explanation here since the summary field is too small, and in case I'm wrong and my edit is wrong after all, so the discussion can be continued here.
I've read the documentation and if I've understod it correctly, the previous example was just plain wrong:
# systemctl edit --full ddclient.service
[Unit] Description=Dynamic DNS Update Client After=network.target PartOf=network-online.target [Service] Type=forking PIDFile=/var/run/ddclient.pid ExecStart=/usr/bin/ddclient [Install] WantedBy=network-online.target
This might have worked in systems where some other service is depending on network-online.target; and in such case network-online.target is activated, and it is actually network-online.target which pulls in ddclient.service - which is vice versa to what was intended! This will not work if network-online.target is not wanted by anything.
However, the current example should want network-online.target, and in addition does not need a full drop-in replacement:
# systemctl edit ddclient.service
[Unit] Wants=network-online.target
-- Wild Penguin (talk) 20:39, 13 December 2016 (UTC)
- The intention is not to start
network-online.target
whenddclient.service
is started (which is whatWants=network-online.target
inddclient.service
does), but to startddclient.service
afternetwork-online.target
is started and thatddclient.service
is stopped/restarted whennetwork-online.target
is stopped/restarted. I think this is what you need:[Unit] Description=Dynamic DNS Update Client After=network.target After=network-online.target PartOf=network-online.target [Service] Type=forking PIDFile=/var/run/ddclient.pid ExecStart=/usr/bin/ddclient [Install] WantedBy=network-online.target
-- Lahwaacz (talk) 21:05, 13 December 2016 (UTC)
- I think herein lies the confusion: "The intention is not to start
network-online.target
whenddclient.service
is started (which is whatWants=network-online.target
inddclient.service
does)" - I digress:
- I think herein lies the confusion: "The intention is not to start
- network.target (or no other target, if I've understod systemd correctly) is *started* per se. Instead, they are used by the system to track the state of the system. A target is activated when / if prerequisities (services) are met, and some services may depend on a target (and start only when the required targets are reached). According to systemd man page, network-online.target is activated if and only if some service "Wants" it:
- From systemd.special manpage: "Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.". Also see: https://systemd.io/NETWORK_ONLINE
- I still think my example is more correct.
- Another matter is, that ddclient does not require a configured netwrok connection per se. There is a bug (or some think it is a bug): if /etc/resolv.conf is missing when ddclient is started, it does not update it's internal tracking of nameservers - which causes it to fail - even if resolv.conf is created. If resolv.conf is there at startup, ddclient will track the changes of that file. IIRC the original author does not think this is a bug (I don't have time to search the discussion right now) - but whether ddclients behaviour is correct or not, is out of scope of this discussion in any case. However, the point here is: ddclient does not need to be stopped even if the network changes (as long as resolv.conf is updated correctly) - though I haven't confirmed this behaviour --Wild Penguin (talk) 14:41, 14 December 2016 (UTC)
- If something has to be restarted when the network goes down and up, you can't make it work according to this systemd specification. If ddclient is not the case, even better. In any case, ideally none of this would be necessary (as stated in the last section of [1]). So I'd say the best improvement for the page would be a reference to the supposed bug report. -- Lahwaacz (talk) 18:01, 14 December 2016 (UTC)
Other tools than ddclient
<shameless promotion> There is a new tool (alpha) called ddupdate which among other things handles the non-ddclient compatible services here. It's a different beast: python, linux-centric, plugin-based, user help...
- github: https://github.com/leamas/ddupdate
- pypi: https://pypi.python.org/pypi/ddupdate/0.0.5
- Fedora/Mageia packages: https://copr.fedorainfracloud.org/coprs/leamas/ddupdate/
</shameless promotion>
—This unsigned comment is by Leamas (talk) 22:13, 2 January 2018. Please sign your posts with ~~~~!
- When somebody actually makes an Arch package, it can be mentioned. -- Lahwaacz (talk) 08:25, 3 January 2018 (UTC)
now-DNS is compatible with ddclient; now-DNS is not compatible with ddclient
now-DNS is listed in both the compatible and incompatible sections, this is probably a mistake but I'm not sure. since they have a ddclient configuration listed, I suggest it should be removed from the incompatible section.
—This unsigned comment is by Pounce (talk) 15:50, 4 October 2018. Please sign your posts with ~~~~!