Add support for www.cloudns.net DynDNS

[mattmac24]

Hi,

I use cloudns.net for their free name servers and they give you the option of updating the A Record in a variety of ways. I don't know how to add the capability to FreeNAS but they list a wget command, perl script, python script and PHP code ready to copy and run.

Would it be easily possible to add this capability to FreeNAS? How would I do this?

Also I think this setup is the cheapest way to get a dynamic DNSworking with your own custom domain name. If anybody knows of a cheaper way please let me know :).

 

[SweetAndLow]

Does freenas offer a other or manual option when selecting which service you use? That will be the option you are looking for. Then input your domain, URL and auth token.

 

[mattmac24]

Not that I can see unfortunately.

 

[DrKK]

You could make a jail, perl is basically already in the jail, and set the Perl script to run or whatever, at appropriate times.

 

[jgreco]

You could make a jail, perl is basically already in the jail, and set the Perl script to run or whatever, at appropriate times.

Dear lord, why would you do that. Just put their suggested wget command in a FreeNAS system cron entry and be done with it.

GUI -> Tasks -> Add Cron Job -> {$foo}

 

[DrKK]

Dear lord, why would you do that. Just put their suggested wget command in a FreeNAS system cron entry and be done with it.

GUI -> Tasks -> Add Cron Job -> {$foo}

That's sensible. I never think about adding anything to the base appliance since I always have jails all around.

Do what jgreco suggested! :)

 

[jgreco]

I didn't get a chance to see what the suggested "wget" command was, but it's more likely to produce correct results if run from the base system anyways. So, bonus for that. I expect most end-users here are probably going through some sort of residential NAT gateway, so that's an added layer of complication. If you're NAT'ing and you want resolvability from the Internet, you need to use the external IP address (which might be derived from the source IP on the wget request). If you want resolvability on your own local net, that's a different issue, in which case the jail thing would be broken.

Some of us are fortunate and get to work with real IP space.

 

[DrKK]

I didn't get a chance to see what the suggested "wget" command was, but it's more likely to produce correct results if run from the base system anyways. So, bonus for that. I expect most end-users here are probably going through some sort of residential NAT gateway, so that's an added layer of complication. If you're NAT'ing and you want resolvability from the Internet, you need to use the external IP address (which might be derived from the source IP on the wget request). If you want resolvability on your own local net, that's a different issue, in which case the jail thing would be broken.

Some of us are fortunate and get to work with real IP space. :)

It's interesting, isn't it. In some sense, 95% of people are not actually "on the internet" at all. Their router is on the internet, just shouting back to their computer, "Hey, the internet said *this*", over and over again.

 

[jgreco]

Well, I'm just looking forward to some day which might not ever come around, when we can jettison IPv4 and everybody - even end users - has a /56 of IPv6 to work with.

NAT sucks. While we're at it, behind-the-NAT network software designs that assume "everything is on one network" suck. I love documentation that talks about port forwarding on your "router" ... what the hell is that? My routers route packets. My networks are segmented and well designed.

Been sitting here and watching the IPv4 depletion train wreck with some amusement.

 

[DrKK]

IPv6 is a lie. We must cull the population to preserve IPv4 space!

 

[jgreco]

I know you think you're being funny, but.

IPv6 isn't a lie. It isn't super-compelling though as long as we retain the current client-server model ... which is totally evil, I should note. The "cloud" has done a lot of damage in that it reduces the need for IPv6. Look at the IoT, where your IP-enabled thermostat is probably proxying stuff through some random cloud in order for you to be able to get "always-connected" behaviour. Even though I could give my thermostat its very own IP, it is still dependent on "the cloud" for Internet functionality.

But I'm probably an outlier; most users don't have /24's of space available.

IPv6 would give everyone massive amounts of IP space.

 

[DrKK]

"The client-server model is totally evil"

"Anything that reduces the need for IPv6 has done 'damage'."

This sounds like it could be a lively discussion :) Perhaps we should start a thread in off-topic.

 

[jgreco]

This sounds like it could be a lively discussion :) Perhaps we should start a thread in off-topic.

Whasssamatta, chicken? I'll beat yer punk *** right here...

Seriously, some aspects of the current client-server paradigm are total bovine excreta. Consider what I was just talking about, for example. There are lots of devices that arguably have sufficient on-unit smarts to do local communication which are nevertheless requiring the Internet as an intermediary.

 

[Ericloewe]

There are lots of devices that arguably have sufficient on-unit smarts to do local communication which are nevertheless requiring the Internet as an intermediary.

A particularly egregious example is the current paradigm for synchronizing devices.

My phone is connected to my desktop over Bluetooth and USB, but calendars and stuff are still synced through the internet, via Wi-Fi.

It's the lazy solution, and it's actually a few steps back from what we used to have.

 

[gpsguy]

Just get HP or the DoD to give up some of their /8 addresses. ;-)

We must cull the population to preserve IPv4 space!

 

[jgreco]

My phone is connected to my desktop over Bluetooth and USB, but calendars and stuff are still synced through the internet, via Wi-Fi.

The latter is a better general solution. While you may in fact have your calendars and contacts stored on your desktop, that's only one possibility. We run a caldav/carddav server for all of that, and do it on a dedicated VM "somewhere" in the local "cloud" here. Any iOS device, Android device, Mac, or PC that needs access to that information works with the shared central repository for that stuff. Updates can happen locally or from remote. It all gets backed up and it's very reliable.

I disagree that it's "the lazy solution." The lazy solution is to let Google or Apple manage all that for you, on their "cloud" services.

 

[mattmac24]

Dear lord, why would you do that. Just put their suggested wget command in a FreeNAS system cron entry and be done with it.

GUI -> Tasks -> Add Cron Job -> {$foo}

Thanks for this solution! It works :)

 

[jgreco]

Glad to hear it.