This reverts the changes from 36744e5. This will be reimplemented once
the build process is better documented and properly implemented
by any downstream not yet using it (as of now linuxserver.io).
See https://github.com/linuxserver/docker-ddclient/issues/77
There is no way the user can meaningfully set `if-skip` because the
user doesn't have control over how ddclient reads an interface's
settings (ddclient could theoretically run `ip addr show`, run
`ifconfig`, read a file in `/dev`, make a system call, use a Perl
library, etc.).
Allow update of a DNS record hosted by the Gandi LiveDNS service.
Signed-off-by: Jimmy Thrasibule <jimmy.thrasibule@orange.com>
Reviewed-by: Richard Hansen <rhansen@rhansen.org>
* Support IPv6 addresses.
* Support updating addresses that aren't the client's own addresses.
* Set status to 'failed' if the update fails for any reason.
* Don't skip hosts if a previous update failed.
* Check for a non-OK code from the update server.
* Strip headers before processing responses.
This still uses API v1 because API v2 currently has some limitations;
see #180 for details.
Fixes#180
Now all that is needed to add a new unit test is to create a `t/*.pl`
file and list it in the `handwritten_tests` variable.
To run the test suite, run:
./autogen && ./configure && make check
Fixes#147
This makes it easier to package ddclient, especially as enhancements
are made such as unit tests or a man page.
I chose GNU Autoconf and Automake mostly because I'm familiar with
them, but also because I know they are well supported. Unfortunately
they can be difficult to understand/maintain (especially Autoconf), so
we may want to convert to something else later.
Addresses #146, #147
`fw-banlocal` is problematic:
* There's not much point to it. Regardless of whether it is enabled,
the end result is a DNS record that is not being updated to a
useful value. It does cause a warning to be logged, but because it
is not enabled by default it doesn't help the poor user who is
trying to figure out why they can't reach their machine. By the
time they realize that enabling this option would have saved them
hours of troubleshooting, they no longer need to enable it because
they already know what the problem is.
* It's a misnomer: `fw-banlocal` doesn't just filter out local IP
addresses from `use=fw`, it also filters them out of all other
address sources except `use=ip`.
* It doesn't filter out local IPv6 addresses.
* The resulting warning ("unable to determine IP address") is
misleading.
We might want to add a warning whenever a non-global address is
discovered (along with an option to silence the warning), but that
should be done in a future commit if at all.
