Using location with ddcli...
Using location with ddclient
- Accueil
- Espace Client
- Community Forum
- Services
- Dynamic DNS Service
- Using location with ddclient
- Community Forum
- Using location with ddclient
Topic: Using location with ddclient
After using Dynu for a while, realized that the DDNS location feature would simplify management of my domain names. By default, ddclient has no support for location, but it can be added with a one-line change. Unfortunately the ddclient source code is pretty ugly with lots of copied/pasted slightly modified functions that all look similar. Use at your own risk, but here is how I modified mine for location support:
#1- Search for: sub nic_dyndns2_update {
(If you don't search on the entire string above, you will end up in the wrong place.)
#2- Search for: my $reply
(This will find the location with the function nic_dyndns2_update)
#3- Insert these lines before the "my $reply" line:
# ddclient hack to support Dynu location based updates
($url =~ /&hostname=[^.&]+&/) && ($url =~ s/&hostname=/&location=/);
In simple terms, if you specify a hostname that does not contain a period (which cannot be legit since its not fully qualified), this hack will rewrite the hostname= to location= allowing Dynu to treat as a location.
In ddclient.conf, you can use something like:
server=api.dynu.com, login=<your-login>, password=<your-pass> location-string
Note there is a quirk with how Dynu handles location-based updates that can cause issues. I had manually set the IP addresses of two of my hosts via the control panel to one of my external servers. I then used the API to change them "back" to my other server via API. The API returned "nochg" (does not require change) even though the current IP addresses were different from what I was passing in the API. Think itsrelated to making both changes from the same IP address. In typical DDNS operation, most updates are in response to an ISP IP address update which appears to work consistently.
Should Dynu wish to investigate, the exact replication steps are:
From IP address H, use the API to update location L to IP address X
good X
From IP address H, use the control panel to update hostnames with location L to address Y
From IP address H, use the API to update location L to IP address X
nochg
From IP address H, use the API to update location L to IP address Z
nochg
Am guessing the API calls have a caching layer to prevent unneeded updates (very sensible), but seems like a cache key/invalidation issue. Seems like its assuming that all API calls from H for location L are the same (but that is not correct unless myip=H). Probably should be using X/Y/Z (myip) rather than H. If using H is deliberate behavior (because it makes it harder to abuse the service), then should be documented since it has side-effects. Regardless, seems like a control panel update change should invalidate the cache if a location is set for the hostname being updated.
Great service and hope this benefits someone. Thanks.
#1- Search for: sub nic_dyndns2_update {
(If you don't search on the entire string above, you will end up in the wrong place.)
#2- Search for: my $reply
(This will find the location with the function nic_dyndns2_update)
#3- Insert these lines before the "my $reply" line:
# ddclient hack to support Dynu location based updates
($url =~ /&hostname=[^.&]+&/) && ($url =~ s/&hostname=/&location=/);
In simple terms, if you specify a hostname that does not contain a period (which cannot be legit since its not fully qualified), this hack will rewrite the hostname= to location= allowing Dynu to treat as a location.
In ddclient.conf, you can use something like:
server=api.dynu.com, login=<your-login>, password=<your-pass> location-string
Note there is a quirk with how Dynu handles location-based updates that can cause issues. I had manually set the IP addresses of two of my hosts via the control panel to one of my external servers. I then used the API to change them "back" to my other server via API. The API returned "nochg" (does not require change) even though the current IP addresses were different from what I was passing in the API. Think itsrelated to making both changes from the same IP address. In typical DDNS operation, most updates are in response to an ISP IP address update which appears to work consistently.
Should Dynu wish to investigate, the exact replication steps are:
From IP address H, use the API to update location L to IP address X
good X
From IP address H, use the control panel to update hostnames with location L to address Y
From IP address H, use the API to update location L to IP address X
nochg
From IP address H, use the API to update location L to IP address Z
nochg
Am guessing the API calls have a caching layer to prevent unneeded updates (very sensible), but seems like a cache key/invalidation issue. Seems like its assuming that all API calls from H for location L are the same (but that is not correct unless myip=H). Probably should be using X/Y/Z (myip) rather than H. If using H is deliberate behavior (because it makes it harder to abuse the service), then should be documented since it has side-effects. Regardless, seems like a control panel update change should invalidate the cache if a location is set for the hostname being updated.
Great service and hope this benefits someone. Thanks.
Reply with quote | Report
This is awsome!
I got my ddclient settings done correctly. Thank you so much.
I got my ddclient settings done correctly. Thank you so much.
Reply with quote | Report
Author | Topic: Using location with ddclient |
---|---|
teamvraz Joined: 05/09/2015 |
Using location with ddclient vendredi 9 décembre 2016 08:46
After using Dynu for a while, realized that the DDNS location feature would simplify management of my domain names. By default, ddclient has no support for location, but it can be added with a one-line change. Unfortunately the ddclient source code is pretty ugly with lots of copied/pasted slightly modified functions that all look similar. Use at your own risk, but here is how I modified mine for location support:
#1- Search for: sub nic_dyndns2_update { (If you don't search on the entire string above, you will end up in the wrong place.) #2- Search for: my $reply (This will find the location with the function nic_dyndns2_update) #3- Insert these lines before the "my $reply" line: # ddclient hack to support Dynu location based updates ($url =~ /&hostname=[^.&]+&/) && ($url =~ s/&hostname=/&location=/); In simple terms, if you specify a hostname that does not contain a period (which cannot be legit since its not fully qualified), this hack will rewrite the hostname= to location= allowing Dynu to treat as a location. In ddclient.conf, you can use something like: server=api.dynu.com, login=<your-login>, password=<your-pass> location-string Note there is a quirk with how Dynu handles location-based updates that can cause issues. I had manually set the IP addresses of two of my hosts via the control panel to one of my external servers. I then used the API to change them "back" to my other server via API. The API returned "nochg" (does not require change) even though the current IP addresses were different from what I was passing in the API. Think itsrelated to making both changes from the same IP address. In typical DDNS operation, most updates are in response to an ISP IP address update which appears to work consistently. Should Dynu wish to investigate, the exact replication steps are: From IP address H, use the API to update location L to IP address X good X From IP address H, use the control panel to update hostnames with location L to address Y From IP address H, use the API to update location L to IP address X nochg From IP address H, use the API to update location L to IP address Z nochg Am guessing the API calls have a caching layer to prevent unneeded updates (very sensible), but seems like a cache key/invalidation issue. Seems like its assuming that all API calls from H for location L are the same (but that is not correct unless myip=H). Probably should be using X/Y/Z (myip) rather than H. If using H is deliberate behavior (because it makes it harder to abuse the service), then should be documented since it has side-effects. Regardless, seems like a control panel update change should invalidate the cache if a location is set for the hostname being updated. Great service and hope this benefits someone. Thanks. |
suite2e11 Joined: 16/11/2017 |
Using location with ddclient dimanche 18 mars 2018 06:26
This is awsome!
I got my ddclient settings done correctly. Thank you so much. |
It is currently vendredi 27 décembre 2024 03:29 US Mountain Standard Time
vendredi 27 décembre 2024 03:29