https://bugs.contribs.org/show_bug.cgi?id=10300
--- Comment #59 from Jean-Philippe Pialasse <[email protected]> ---
(In reply to Dave Liquorice from comment #58)
> (In reply to Dave Liquorice from comment #57)
>
> > I don't suffer the chained CNAME issue, or at least all the suggested test
> > lookups in https://bugs.contribs.org/show_bug.cgi?id=8362 all return an A
> > record, under djbdns.x86_64 1.05-8.el6.sme and smeserver-letsencrypt.noarch
> > 0.4-2.
test can be tricky because you need an empty dns cache for each individual
test, as one (even non successful) will already populate a list of akadns
servers and mostly help the next request.
hence, you will need at least a sv t dnscache (and the same for
dnscache.forwarder if enabled) or a reboot between each test.
Also to note a functioning cache of akadns servers will likely need to be
renewed entirely after 5 hours. So getting it to work now after 2 attempts ,
does not guaranty the next cron job will not fail with curl dns error.
What I we have seen with the previous workaround is that in some settings its
tended to help by making curl wait more for a first answer, but if it failed to
get it, then the entire script failed to run as without the workaround.
>
> But I do now with:
>
> Server version: SME 9.2
> djbdns.x86_64 1.05-10.el6.sme from smeupdates-testing
> smeserver-letsencrypt.noarch 0.4-3 from smecontribs
>
> [root@srv1 ~]# dehydrated -c
> # INFO: Using main config file /etc/dehydrated/config
> ERROR: Problem connecting to server (get for
> https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
>
> [root@srv1 ~]# dig k.pconline.com.cn
> Works OK
>
> [root@srv1 ~]# dig www.apl.com
> [root@srv1 ~]# dig acme-staging.api.letsencrypt.org
> [root@srv1 ~]# dig +noall +ans -t a www.paypal.com
> ;; connection timed out; no servers could be reached
>
> Tried each lookup several times with the same results.
>
> Backing out djbdns to djbdns.x86_64 1.05-8.el6.sme gave the curl error for
> dehydrated -c ran as the first command in a shell after the reboot. All the
> digs consistently work and now dehydrated -c refuses to fail.
having to sme aside on the same connection I have the opposite result.
[root@sme9x64 ~]# sv t dnscache
#wait 30 seconds
[root@sme9x64 ~]# curl https://acme-v01.api.letsencrypt.org/directory
{
"key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change";,
"new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz";,
"new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert";,
"new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg";,
"revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert";
}
[root@sme9x64 ~]# rpm -qa djbdns
djbdns-1.05-10.el6.sme.x86_64
[root@sme9x64 ~]#
compared to
[root@sme9x64 ~]# sv t dnscache
#wait 30 seconds
[root@sme9x64 ~]# curl https://acme-v01.api.letsencrypt.org/directory
curl: (6) Couldn't resolve host 'acme-v01.api.letsencrypt.org'
[root@sme9x64 ~]# rpm -qa djbdns
djbdns-1.05-8.el6.sme.x86_64
but i will dig more
--
You are receiving this mail because:
You are the QA Contact for the bug._______________________________________________
Mail for each SME Contribs bug report
To unsubscribe, e-mail [email protected]
Searchable archive at https://lists.contribs.org/mailman/public/contribteam/
