PfSense / BSD 'fetch' command and Linode API



  • Hi,

    I'd like to use Linode's API to update a dynamic IP address for purposes of updating DNS.  I don't have wget or curl on the pfSense box and don't mind using fetch.  Any help is appreciated.

    So basically, as a URL in a web browser with the proper parameters set, I.e: api_key, domainid, and resourceid, and target, the request works correctly.

    https://api.linode.com/?api_key=your-api-key&api_action=domain.resource.update&domainid=your-domain-id&resourceid=your-resource-id&target=$myip

    I've also tested it with curl at the command line (Linux), and it works fine.

    curl -s https://api.linode.com/?api_key=your-api-key&api_action=domain.resource.update&domainid=your-domain-id&resourceid=your-resource-id&target=$myip

    When I try to use "fetch" the response that I get back is: "no match", and it's a shell response… not a response from the Linode API.

    Any suggestions?  Thanks.


  • Moderator

    Try to encapsulate the URL with double quotes    "https://url"  ..



  • Hi,

    Double quotes around the URL was part of the solve, thanks BBcan177.

    There were a couple of other things to note with my setup.

    I use the nanobsd (embedded/read-only file system). 
    It appears that fetch wants to write some kind of output to a temporary space, I noticed this based on some output regarding "…read-only file system...".

    So during that process, I forced fetch to write to a specific file under /tmp which is a writable partition on the nanobsd install using the -o parameter… below you can see an example which includes that file that I created under /tmp using the touch command, i.e: touch /tmp/testfile1.

    fetch -qo /tmp/testfile1 "https://api.linode.com/?api_key=your-api-key&api_action=domain.resource.update&domainid=your-domain-id&resourceid=your-resource-id&target=[remote_addr]"

    Hopefully this is useful for someone.  Have fun.

    Notes:

    The /tmp/testfile1 is just to catch the fetch output and is more or less just a bit bucket of sorts… the Linode API receives the request.
    I didn't need to escape the '&'s with the '' because of the "" quotes wrapping the url, effectively turning off shell interpretation.
    [remote_addr] is substituted automatically with the IP of the system that is making the request to the Linode API.  See: https://www.linode.com/api/dns/domain.resource.update

    Other Resources:

    https://travismaynard.com/writing/dynamic-dns-using-the-linode-api



  • Why not just use the built in dynamic DNS functionality? You can choose the "custom" type and put in the URL for Linode. Then it'll correctly tie into the process for IP changes to update immediately and won't have read-only issues you mentioned.



  • Hey Chris,

    I spent months using no-ip (free) with the Dynamic DNS service in pfSense… only to get these messages in the system logs:

    php-fpm[32255]: /rc.dyndns.update: phpDynDNS (xxxxx.noip.me): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.

    I found myself each month getting a notification from no-ip saying… "You need to confirm that you are actually using this service or your service will be disabled" (even though it's free).  So what was happening based on the log above... is that the DynamicDNS feature in pfSense wasn't informing no-ip that even though the IP didn't change... that it was actually using the darn service.  What I was doing each month was clicking an email link, going to the no-ip page and "Confirm by pressing this button".

    Your point is well taken to try using the Custom DNS feature of the Dynamic DNS service in pfSense... I just didn't think about it and came cross a way that I understood when I came across some free time.  I guess I just missed the elegant way and worked out a different solution that works too.  Like they say... there's more than 1 way to skin a cat.

    I'll still take a look at the Custom DNS feature in pfSense.  Linode is not at all like no-ip in terms of crying that the API doesn't get hit for 25 days... so it'll probably work out just fine.

    Maybe it would be helpful to have a feature in the Dynamic DNS service to explicitly control the update frequency to the Dynamic DNS provider, just to keep their system on notice considering the above case that I had?  I know how it is with feature requests and software... and I don't expect this feature to ever exist.  Just my 0.02.

    Thanks for your thought.

    Best,

    -Will


Log in to reply