Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for https://www.ipify.org/ #297

Closed
troglobit opened this issue Feb 17, 2020 · 8 comments
Closed

Add support for https://www.ipify.org/ #297

troglobit opened this issue Feb 17, 2020 · 8 comments

Comments

@troglobit
Copy link
Owner

Many DDNS providers don't have their own checkip infrastructure, In-a-Dyn plugins for these providers usually fall back to use the service provided by Dyn.com

This is a proposal to add support for https://www.ipify.org/ for a native In-a-Dyn checkip function. See https://github.com/troglobit/lipify/ for an implementation that can easily be integrated.

@SimonPilkington
Copy link
Contributor

Is it necessary to add this entire implementation to Inadyn? curl is ubiquitous and could easily be invoked from a shell script invoked by Inadyn to query the ipify API and output the address to stdout for Inadyn to collect. This would also be more flexible. Inadyn could ship with a default script querying ipify using curl, but e.g. with Inadyn running on my router it's just nvram get wan0_ipaddr.

Are there any disadvantages to this approach that I'm unaware of?

@troglobit
Copy link
Owner Author

Let me rephrase. In retrospect I did not mean integrating lipify (14 kiB) into Inadyn. I just wanted to write down an idea I had while at work, before forgetting about it. Really didn't expect any pushback. Inadyn already has all the support required to do a HTTP GET query on it's own.

This proposal is only about adding support for a more neutral checkip server than dyn.com which is the default for providers that don't have their own. This could hardly be a bad thing as I suspect more people than I dislike Oracle.

Also, even if it's beside the point, not all targets have curl.

@SimonPilkington
Copy link
Contributor

Oh no, that wasn't pushback, just discussion. Sorry if my wording was too strong. The ACME client I use is a C application like Inadyn and it uses potentially user-provided scripts to handle challenges, so I wondered if the same approach could be used here.

@troglobit
Copy link
Owner Author

Sorry, I was probably too tired and English isn't my first language. Well in general I have no problem with a script-based approach. For core components though I'd like to see Inadyn be self-reliant. I've run into way too many limited embedded systems that barely have a working shell.

@SimonPilkington
Copy link
Contributor

Fair. I figured if my 2013 router had curl it would be pretty widely available, but also that if that was nonsense you'd know to tell me off.

How do you feel about my idea as an alternative approach? Perhaps as a per-provider entry in the config? I might feel like trying for it one of these days.

@troglobit
Copy link
Owner Author

@SimonPilkington
Copy link
Contributor

Oh. Well, at least I can take solace in the fact that my idea probably wasn't silly if it's already implemented.

@troglobit
Copy link
Owner Author

Definitely not silly. There are lots of small things like that which make it such a great tool. The real challenge is always to figure out what is core functionality and adds value, without making it too complex to maintain, and what's better suited for external helper scripts.

As always, thank you for your input! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants