-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
Comments
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 Are there any disadvantages to this approach that I'm unaware of? |
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. |
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. |
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. |
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. |
You mean like the |
Oh. Well, at least I can take solace in the fact that my idea probably wasn't silly if it's already implemented. |
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! :-) |
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.
The text was updated successfully, but these errors were encountered: