lego
lego copied to clipboard
Add Hover as DNS-style provider
Support for Hover (http://hover.com/) (was: TuCows) as a DNS provider
This method mimics a HTTP client because Hover lacks a formal/public API. The work is based on adapting some reverse-engineering into Go.
Hello, in order for a PR adding a DNS provider to be accepted, you have to:
- [ ] add a description to your PR
- [ ] be able to maintain this provider
- [ ] have a homogeneous design with the other providers
- [ ] add tests (units)
make test
- [ ] add tests ("live") https://github.com/go-acme/lego/blob/c938de68f262c057542d44bcb67ef961cefcc60e/providers/dns/cloudflare/cloudflare_test.go#L125-L151
make test
- [ ] add a provider descriptor
- [ ] generate CLI help, documentation, and readme.
make generate-dns
- [ ] be able to do: (and put the output of this command to a comment in your PR)
rm -rf .lego
./lego -m [email protected] --dns YOUR_PROVIDER_NAME -d *.example.com -d example.com -s https://acme-staging-v02.api.letsencrypt.org/directory run
Note the wildcard domain is important.
- [ ] pass the linter (golangci-lint must be installed):
make checks
- [ ] do
go mod tidy
Hello,
If this provider doesn't have an API and/or official API documentation, I'm not sure we will agree to add this provider.
Also https://github.com/chickenandpork/hoverdnsapi has a dependency on lego, we will not allow that.
Here is what I recommend:
- create a document describing the API and put it in a repository or in lego
- create in lego a light client instead of an external library
Without this, it will not be possible for us to accept your PR.
I'm not sure we will agree to add this provider
Does this mean literally "I am not sure", or is it a soft way of saying "we will not" ? If the PR has zero chance of ever being merged, then we should just abandon it now, but if there's a chance I'll be able to use it to maintain the DNS records I use on my services, that would be immensely useful, hence I'd prefer to continue if there's a chance of being accepted.
When I said "I am not sure", I meant that I needed time to think about it.
For the rest, I think I answered in my previous comment https://github.com/go-acme/lego/pull/1255#issuecomment-698024302
If you want to use your external library you will have to modify it in order to remove lego dependencies. But I would really prefer to have a minimalistic implementation of the client in lego.
Do my answers allow you to make progress on the subject?
Do my answers allow you to make progress on the subject?
TL;DR: yes, sorry to go silent. Will attempt this weekend.
I appreciate that you're blunt and clear; none of this USA "I don't think" meaning actually a polite "heck no!". I understand if my implementation can lead to later maintenance concerns.
Honestly, my immediate response was somewhere between "aw shoot, I need to discard the work and start again" with the comment that was made at the same time mine was, and was unsure what example of a "light client" I could follow to make it as consistent as possible. I mean: the words make sense, but it seems there's a specific example in mind, and consistency helps review.
...but I see that you're willing to go forward -- maybe at least to get the functionality there? -- with the external library if I can clean it up. If I remember correctly, there was some import of types to ensure compatibility, but I can likely remove those.
I can try to move forward this weekend if that's OK, and I do really appreciate the feedback, I regret going silent for a while.
By "light" client I mean something like that:
- https://github.com/go-acme/lego/tree/master/providers/dns/arvancloud/internal
- https://github.com/go-acme/lego/tree/master/providers/dns/cloudns/internal
- https://github.com/go-acme/lego/tree/master/providers/dns/conoha/internal
- https://github.com/go-acme/lego/tree/master/providers/dns/dynu/internal
- ...
In summary, a client that only handle TXT records.
Hi; Took me a while to move the dependent code to a ./internal/
to break the dependency -- changed country, changed jobs, hardware packed up shipping containers forever, etc.
This update is rebased, has the external dependency added, and unit tests OK. The underlying code still functions fine as a CLI tool as well before copying tinto this module.