| Age | Commit message (Collapse) | Author |
|---|
|
set service dns dynamic timeout <60-3600>
|
|
This should make the help messages more consistent for DNS related
CLI subtree.
|
|
|
|
Apply next round of configuration tree updates to 'service dns dynamic'
with the following changes:
- Migrate `service dns dynamic interface <interface> [use-web]`
to `service dns dynamic address <interface>`
or `service dns dynamic address web [web-options]`
This communicates the intent that dynamic dns IP address is detected
in only one way - using the `<interface>` or using an external web
request, not both.
- When using external web request, (`service dns dynamic address web`),
external url is optional (`web-options url`). Ddclient defaults are
used when unspecified,
- Rename all config `login` to `username` for consistency and also to
align better with alternative ddclient backends in consideration.
- Apply global 'ipv6-enable' to per service 'ip-version: ipv6'. Selecting
usage of IPv4 or IPv6 (or both simultaneously) is now at per service
(protocol) level instead of global level. This allows more control on
the ability to select IPv4 in some cases and IPv6 in some other cases
wherever supported by the underlying ddclient protocol.
- While the IP address (and by extension, the detection mechanism) is
global, the way it is applied to a particular ddclient protocol depends
on whether it supports IPv4 or IPv6 or both.
- Related to the above, this also prevents generating incorrect config
file (`ddclient.conf`) with multiple global sections leading to an
unpredictable behavior of ddclient.
- Implement provider (protocol) specific custom tweaks whenever possible
(e.g., `zone`, `username`, `server` are not necessary in all cases).
- Move service name from a combination of 'protocol' (with protocol
config autodetected) and custom (with protocol config specified) to a
single 'service' key. This allows for consisent setup of multiple
config for the same ddclient protocol (with different options and
credentials). This also avoid ambiguity with usual networking term
'protocol' and ddclient specific term 'protocol' (and can change with
a move to a different backend).
- Apply upfront XML constraints and validations consistently wherever
applicable.
- RFC2136 specific change: Rename rfc2136 config `record` to `host-name`
for consistency.
- Cloudflare specific change: While ddclient still supports authenticating
with email and global auth key, skipping `username` in config will
indicate the intent to use API token authentication (with special
'token' literal as `username`).
|
|
* Re-use XML building blocks when poossible
* Use XML constraints when possible (password)
* Capitalize protocols (HTTP) in <help> strings
|
|
Apply validations and completions to dynamic DNS protocols supported.
This also opens up additional protocols supported by ddclient 3.10.
Additional details:
- Validation and constraint have been added for interface names as well.
- While at it, the help texts got some copyedit and rewording.
|
|
|
|
|
|
If a parameter is required is determined from the Python string on commit.
This "indicator" is not used consistently and sometimes missing, or added where
it is not required anymore due to Python script improvement/rewrite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If there is no zone option given it will be "guessed" as in the past.
This means (hostname -> resulting zone entry)
domain.com -> com
foo.domain.com -> domain.com
bar.foo.domain.com -> foo.domain.com
I have zero experience in the CloudFlare zone option what it is and what
it does. SO maybe we still have a chance to auto render this setting.
|
|
Internally, we can accept more than one server of each type for sending dynamic DNS updates, but due to a strong check in CLI, it is not possible to add more than one server with the same protocol (except "custom", but it allows to add only one more server). The patch relaxing this limitation by allowing adding as many servers with the same protocol, as needed.
|
|
|
|
|
|
A lot of XML code is duplicated (VLAN, interface address) for instance. Such
XML definitions should be moved to feature.xml.i files and then just pulled in
via GCC preprocessor #include definition in e.g. bond or ethernet definitions.
This will give us the ability to single-source repeating node definitions as:
* Interface Address
* Interface Description
* Interface Disable
* VLAN (both vif-s and vif-c)
The .in suffix of the interface-definitions is a marker that those files are
input files to the GCC preprocessor. They will be rendered into proper XML
files in the build directory.
Some node definitions have been reworder to remove escaped double quote
occurances which would have been warned about by the GCC preprocessor.
|
