As seen in the wild with DynDNS.com -- status '14' is being stored
for the first host which is removed from @hosts ending up reading
empty host for next line causing 'nochg' to be misplaced in an empty
host. The same likely applies for multi-host handling so expand to
loop where writing to config and use $hosts when logging to catch all.
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Thu, 01 Jun 2023 06:59:38 GMT
RECEIVE: Server: Apache/2.4.18 (Ubuntu)
RECEIVE: Strict-Transport-Security: max-age=31536000
RECEIVE: X-UpdateCode: n
RECEIVE: Vary: Accept-Encoding
RECEIVE: Content-Type: text/plain
RECEIVE: Accept-Ranges: none
RECEIVE: X-User-Status: vip
RECEIVE: Connection: close
RECEIVE: Transfer-Encoding: chunked
RECEIVE:
RECEIVE: 14
RECEIVE: nochg 192.168.178.20
RECEIVE: 0
RECEIVE:
Looks like there is a bug in line 542 in ddclient.in. The syntax of how the server URL is being set is different to all the other dynamic DNS services. To be precise there is one additional parameter. Instead of handing over the URL, the server variable receives the second "1" in the code below.
$globals{postscript} can now contain a full command string including
arguments. In order to facilitate this, the file executability check
(-x) has been modified such that the first substring up to the first
space (if it exists) is what is checked, rather than the whole string.
Example bodies I've seen:
```
0013
good 127.0.0.1
0
```
```
0013
nochg 127.0.0.1
0
```
```
007
nohost
0
```
Seems like the trailing zero was not there before as the code relied
on `pop`. Instead, we find the first line that matches `good`/`nochg`.
This is no longer used since commit 6c951a0395 ("Add files via
upload"), which updated to the Cloudflare API v4. The new API does not
require any preprocessing of the domain name.
This will make it possible for the Debian package to fetch the list of
supported firewall/router devices and prompt the user to choose one
upon installation.
This will make it possible for the Debian package to fetch the list of
supported built-in web-based IP discovery services and prompt the user
to choose one upon installation.
The new code will always warn if ddclient.conf is accessible by others,
warn if it is owned by ddclient and accessible by the group,
and otherwise warn if it is writable but not owned by ddclient.
This primarily allows two permission modes for ddclient.conf:
First, the classic `ddclient:ddclient mode 0600` as well as the
more restrictive `root:ddclient mode 0640` which previously
warned unnecessarily.
