Using location with ddcli...
Using location with ddclient
- Home
- Control Panel
- 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-stringNote 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 Xgood XFrom IP address H, use the control panel to update hostnames with location L to address YFrom IP address H, use the API to update location L to IP address XnochgFrom IP address H, use the API to update location L to IP address ZnochgAm 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.
Reply with quote | Report
Author | Topic: Using location with ddclient |
---|---|
teamvraz Joined: 9/5/2015 |
Using location with ddclient Friday, December 9, 2016 8:46 AM
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-stringNote 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 Xgood XFrom IP address H, use the control panel to update hostnames with location L to address YFrom IP address H, use the API to update location L to IP address XnochgFrom IP address H, use the API to update location L to IP address ZnochgAm 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: 11/16/2017 |
Using location with ddclient Sunday, March 18, 2018 6:26 AM
This is awsome!I got my ddclient settings done correctly. Thank you so much.
|
It is currently Saturday, November 16, 2024 1:31 AM US Mountain Standard Time
Saturday, November 16, 2024 1:31 AM