@Baughn, thanks for your PR! By analyzing the history of the files in this pull request, we identified @eduarrrd, @tomberek and @rbvermaa to be potential reviewers.

@tomberek This client is primarily for dyn.com's DNS service, so members.dyndns.org would be the overwhelmingly common case.

By default that's the server the client contacts. However, the way the module is coded at present leads to including a blank server= line in the configuration file, which makes parsing fail and stops it from working at all.

I'm with tomberek here. Unless it is a highly exceptional case not to use dyndns.com it should not be default. So far, I don't know anyone using it (I certainly don't) but I open to any evidence. In general I doubt that the majority of dynamic DNS user use an oracle-owned pay-only service.

Also I'm not convinced by the broken config file. If you don't set the other parameters such as domain or user it doesn't work either.

Why is the path quoted? It's a simple value (https://nixos.org/nix/manual/#idm140737318208368).

Well, according to the documentation, the default value for server (presuming none is set) is members.dyndns.org. I simply copied that. At the moment ddclient simply doesn't work at all unless you manually set the server, so I fail to see how this isn't an improvement.

As for the path, /etc/ddclient.conf does not compare equal to "/etc/ddclient.conf".

I think the point behind the comparison was to detect if someone (like me) wanted to place a full config file somewhere instead of using the options. This keeps any secrets out of the Nix store. Will this change that?

No. It fixes a false negative, I don't see how it could add any false positives.

As for the rest of it... I wouldn't object strongly to making the lack of an explicit server a fatal error instead of silently constructing a non-working configuration, but I stand by my patch. Users of ddclient on different OSs do not need to explicitly state their server, if they use Dyn, and IMO therefore neither should we.

A number of the example configs you can look up won't even include their server address, since it's the default, so it might be a mite confusing if it's needed.

Comparison fix: The comparison always fails in the existing code, presumably because strings do not compare equal to their equivalent path. This doesn't make nixos-rebuild fail, but it leads to ddclient crashing on startup because /etc/ddclient.conf is not actually generated.

Default fix: Still don't think this is a good idea. a) upstream default may change. In that case this will break hard for everyone relying on the default (which according to your speculation is almost everyone). Best of all: there would be no mitigation. b) I don't think many people are using this. The default made sense when there was a free tier and it was not owned by everyone's darling Oracle.

I don't have an opinion on the server option but one of the fixes should be implemented. Both sound fair to me.

Cherry-picked ee5ff81 into master for the time being.