From itz at primate.net Tue May 2 12:16:53 2017 From: itz at primate.net (Ian Zimmerman) Date: Tue, 2 May 2017 12:16:53 -0700 Subject: [buug] letsencrypt Message-ID: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> Is the a way to get a letsencrypt ceritificate without an already functional httpd? AFAIK all the packaged solutions like dehydrated require that (even if the dehydrated package does not depend on the httpd package). I control the DNS for the domain in question. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From wkoszek at freebsd.czest.pl Tue May 2 13:50:17 2017 From: wkoszek at freebsd.czest.pl (Wojciech Adam Koszek) Date: Tue, 2 May 2017 13:50:17 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> Message-ID: <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> Ian If you are willing to switch to acme.sh client, it can do a DNS based validation. You pass it a hook to a script which will make DNS zone changes via API. It comes with many ready to use hooks-scripts. You must provide API secret only. If not that, I've used Python -m SimpleHTTPServer 80 to accomplish the same with the original client. So basically I start a simple Python http server and kill it right after verification Wojciech Sent from my iPhone > On May 2, 2017, at 12:16 PM, Ian Zimmerman wrote: > > Is the a way to get a letsencrypt ceritificate without an already > functional httpd? AFAIK all the packaged solutions like dehydrated > require that (even if the dehydrated package does not depend on the > httpd package). > > I control the DNS for the domain in question. > > -- > Please *no* private Cc: on mailing lists and newsgroups > Personal signed mail: please _encrypt_ and sign > Don't clear-text sign: > http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html > _______________________________________________ > buug mailing list > buug at buug.org > http://buug.org/cgi-bin/mailman/listinfo/buug From Michael.Paoli at cal.berkeley.edu Tue May 2 14:42:58 2017 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Tue, 02 May 2017 14:42:58 -0700 Subject: [buug] letsencrypt In-Reply-To: <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> Message-ID: <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> If you use certbot client (available in Debian backports & later), and use it in --manual mode, it gives you script bits you can use to fire up http listener under Python. I have wrapper scripts that generate key(s) and CSR(s), then use cerbot in --manual mode with various options, in any case, e.g.: $ Getcerts example.com ... ------------------------------------------------------------------------------- Make sure your web server displays the following content at http://example.com/.well-known/acme-challenge/kY4B_8mcPEu0U6iViCrwyByrYvVSIZg8VuSR2zNVsow before continuing: kY4B_8mcPEu0U6iViCrwyByrYvVSIZg8VuSR2zNVsow.uBv74F95SBTHmImLwOI3zhA3qsAKdz1R87ZIF9sMkM4 If you don't have HTTP server configured, you can run the following command on the target server (as root): mkdir -p /tmp/certbot/public_html/.well-known/acme-challenge cd /tmp/certbot/public_html printf "%s" kY4B_8mcPEu0U6iViCrwyByrYvVSIZg8VuSR2zNVsow.uBv74F95SBTHmImLwOI3zhA3qsAKdz1R87ZIF9sMkM4 > .well-known/acme-challenge/kY4B_8mcPEu0U6iViCrwyByrYvVSIZg8VuSR2zNVsow # run only once per server: $(command -v python2 || command -v python2.7 || command -v python2.6) -c \ "import BaseHTTPServer, SimpleHTTPServer; \ s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \ s.serve_forever()" ------------------------------------------------------------------------------- Press Enter to Continue ... There's also a DNS validation means ... but I've not tried it yet ... might(?) require DNSSEC (which I have on some domains), and may not be available with the certbot client, but it is available in the API, and I believe it's available via at least (some) other client(s). > From: "Wojciech Adam Koszek" > Subject: Re: [buug] letsencrypt > Date: Tue, 2 May 2017 13:50:17 -0700 > Ian > > If you are willing to switch to acme.sh client, it can do a DNS > based validation. You pass it a hook to a script which will make DNS > zone changes via API. It comes with many ready to use hooks-scripts. > You must provide API secret only. > > If not that, I've used Python -m SimpleHTTPServer 80 to accomplish > the same with the original client. So basically I start a simple > Python http server and kill it right after verification > > Wojciech > > Sent from my iPhone > >> On May 2, 2017, at 12:16 PM, Ian Zimmerman wrote: >> >> Is the a way to get a letsencrypt ceritificate without an already >> functional httpd? AFAIK all the packaged solutions like dehydrated >> require that (even if the dehydrated package does not depend on the >> httpd package). >> >> I control the DNS for the domain in question. >> >> -- >> Please *no* private Cc: on mailing lists and newsgroups >> Personal signed mail: please _encrypt_ and sign >> Don't clear-text sign: >> http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From itz at primate.net Tue May 2 20:37:26 2017 From: itz at primate.net (Ian Zimmerman) Date: Tue, 2 May 2017 20:37:26 -0700 Subject: [buug] letsencrypt In-Reply-To: <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> Message-ID: <20170503033316.2446.1C07FFF0@matica.foolinux.mooo.com> On 2017-05-02 13:50, Wojciech Adam Koszek wrote: > If not that, I've used Python -m SimpleHTTPServer 80 to accomplish the > same with the original client. So basically I start a simple Python > http server and kill it right after verification Well, apart from the fact that I use port 80 for other nefarious purposes :), I guess I would find this straightforward enough. But do you really not need any content on the "server", like a cgi or something that will reply to whatever letsencrypt sends? Sorry for my webby ignorance. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From wkoszek at freebsd.czest.pl Tue May 2 22:58:03 2017 From: wkoszek at freebsd.czest.pl (Wojciech Adam Koszek) Date: Tue, 2 May 2017 22:58:03 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170503033316.2446.1C07FFF0@matica.foolinux.mooo.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170503033316.2446.1C07FFF0@matica.foolinux.mooo.com> Message-ID: <2A8B3D9D-A90A-4FA5-9186-DCC48FD0F434@freebsd.czest.pl> Client is this thing. Client will receive a response requesting it to store a file with certain content in a public space. Python http server will serve this file to the bot which will come from the LetsEncrypt server for verification. W. Sent from my iPhone > On May 2, 2017, at 8:37 PM, Ian Zimmerman wrote: > >> On 2017-05-02 13:50, Wojciech Adam Koszek wrote: >> >> If not that, I've used Python -m SimpleHTTPServer 80 to accomplish the >> same with the original client. So basically I start a simple Python >> http server and kill it right after verification > > Well, apart from the fact that I use port 80 for other nefarious > purposes :), I guess I would find this straightforward enough. But do > you really not need any content on the "server", like a cgi or something > that will reply to whatever letsencrypt sends? Sorry for my webby > ignorance. > > -- > Please *no* private Cc: on mailing lists and newsgroups > Personal signed mail: please _encrypt_ and sign > Don't clear-text sign: > http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html > _______________________________________________ > buug mailing list > buug at buug.org > http://buug.org/cgi-bin/mailman/listinfo/buug From itz at primate.net Sun May 7 18:19:31 2017 From: itz at primate.net (Ian Zimmerman) Date: Sun, 7 May 2017 18:19:31 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> Message-ID: <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> On 2017-05-02 14:42, Michael Paoli wrote: > If you use certbot client (available in Debian backports & later), > and use it in --manual mode, it gives you script bits you can > use to fire up http listener under Python. I installed the certbot package from jessie-backports. Initial cert generation went perfectly, but then the simulated renewal with "certbot renew --dry-run" seems to be quite fragile due to fscked DNS on their staging server. Given that, I have to decide how often to run the cronjob with the real renewal. Do you (anyone reading this) know how close the cert must be to expiration for certbot to try renewing it? Thanks, i -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From wkoszek at freebsd.czest.pl Sun May 7 18:47:11 2017 From: wkoszek at freebsd.czest.pl (Wojciech Adam Koszek) Date: Sun, 7 May 2017 18:47:11 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> Message-ID: <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> You start getting reminders around 2 weeks before the expiration date, so I guess anything closer to expiration should be fine. The acme.sh client automatically installs the proper crontab entry for renewals. You may take a look what it's doing W. Send from an iPhone > On May 7, 2017, at 6:19 PM, Ian Zimmerman wrote: > >> On 2017-05-02 14:42, Michael Paoli wrote: >> >> If you use certbot client (available in Debian backports & later), >> and use it in --manual mode, it gives you script bits you can >> use to fire up http listener under Python. > > I installed the certbot package from jessie-backports. > > Initial cert generation went perfectly, but then the simulated renewal > with "certbot renew --dry-run" seems to be quite fragile due to fscked > DNS on their staging server. > > Given that, I have to decide how often to run the cronjob with the real > renewal. Do you (anyone reading this) know how close the cert must be > to expiration for certbot to try renewing it? > > Thanks, > i > > -- > Please *no* private Cc: on mailing lists and newsgroups > Personal signed mail: please _encrypt_ and sign > Don't clear-text sign: > http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html > _______________________________________________ > buug mailing list > buug at buug.org > http://buug.org/cgi-bin/mailman/listinfo/buug From itz at primate.net Sun May 7 19:25:24 2017 From: itz at primate.net (Ian Zimmerman) Date: Sun, 7 May 2017 19:25:24 -0700 Subject: [buug] letsencrypt In-Reply-To: <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> Message-ID: <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> On 2017-05-07 18:47, Wojciech Adam Koszek wrote: > You start getting reminders around 2 weeks before the expiration date, > so I guess anything closer to expiration should be fine. I guess I have not been clear enough. I'm not afraid of running the client too often and being kicked or penalized. I'm afraid of running it too rarely, and missing renewal because: at time _t_ certbot decides it's too far in the future, so doesn't try. (so what is "too far" - hence my question) at time _t+1_ certbot tries, but fails due to random fsckup (which I know to be possible). at time _t+2_ it's too late, cert has expired. It's a tradeoff - I could run it every minute and I would be very confident of eventual success, but that would be wasteful. > The acme.sh client automatically installs the proper crontab entry for > renewals. I'll take a look, but this seems to be behavior inherently specific to the client, plus a human policy decision. BTW, knowing this I am glad I have not selected acme.sh as the client to run :-) -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From Michael.Paoli at cal.berkeley.edu Sun May 7 21:53:33 2017 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Sun, 07 May 2017 21:53:33 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> Message-ID: <20170507215333.17326c6a3wpzhb8k@webmail.rawbw.com> Well, I seem to recall (which may *not* be fully accurate) ... that the default behavior is renewal attempts start at 30 days before expiration, and continue daily thereafter until successfully renewed/replaced. I'm fairly sure that information is in the various documentation/FAQ(s) or the like - at least that's where I seem to recall having read it before. Some bits of what I do (not that I'd at all recommend everyone do same): o I use a relatively "manual" "renewal" process ... but that's highly aided by a pair of scripts I wrote - so it automates much of the process. o "rewnew" - it needn't explicitly be a renewal, requesting new cert for same, is in most ways equivalent ... but I think there's an extra option to pass to effectively say yes, that's what I want to do and ignore that there are still active matching certs[1] o I use a dedicated non-privileged ID for most all of the cert request / "renew" process - it generates key(s), CSR(s), requests cert(s), interacts with ACME, and obtains cert(s). o If I added an expect layer between some of the (major) "helper"/wrapper scripts I use, it would then almost be a push-button fire-and-forget operation ... but it's "easy enough" as it is thus far, I've not taken it to that point ... yet. o Thus far I've not entrusted certbot or the like, to itself install new/updated cert into web server(s), etc. Also, probably not a bad idea to wrap some monitoring around certs and expirations in general. E.g. if one automates it to renew at 30 days remaining, probably have it trigger some alarm/notification when days remaining gets down to 15. references/excerpts/footnotes: 1. certbot(1) --duplicate - peeked at my script - that's the option > From: "Ian Zimmerman" > Subject: Re: [buug] letsencrypt > Date: Sun, 7 May 2017 19:25:24 -0700 > On 2017-05-07 18:47, Wojciech Adam Koszek wrote: > >> You start getting reminders around 2 weeks before the expiration date, >> so I guess anything closer to expiration should be fine. > > I guess I have not been clear enough. > > I'm not afraid of running the client too often and being kicked or > penalized. I'm afraid of running it too rarely, and missing renewal > because: > > at time _t_ certbot decides it's too far in the future, so doesn't try. > (so what is "too far" - hence my question) > > at time _t+1_ certbot tries, but fails due to random fsckup (which I > know to be possible). > > at time _t+2_ it's too late, cert has expired. > > It's a tradeoff - I could run it every minute and I would be very > confident of eventual success, but that would be wasteful. > >> The acme.sh client automatically installs the proper crontab entry for >> renewals. > > I'll take a look, but this seems to be behavior inherently specific to > the client, plus a human policy decision. > > BTW, knowing this I am glad I have not selected acme.sh as the client to > run :-) From itz at primate.net Mon May 8 11:33:36 2017 From: itz at primate.net (Ian Zimmerman) Date: Mon, 8 May 2017 11:33:36 -0700 Subject: [buug] Distributed DDS? Message-ID: <20170508183031.9605.0A188841@matica.foolinux.mooo.com> I can't seem to do much of anything on the web today. Among other things, Github CSS seems to be broken (buttons not responding). Some other sites have even more severe CSS problems. I wonder if we're seeing another distributed DDS attack against a major CDN or two, possibly in revenge to Macron victory in France. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From rick at linuxmafia.com Mon May 8 12:17:27 2017 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 8 May 2017 12:17:27 -0700 Subject: [buug] Distributed DDS? In-Reply-To: <20170508183031.9605.0A188841@matica.foolinux.mooo.com> References: <20170508183031.9605.0A188841@matica.foolinux.mooo.com> Message-ID: <20170508191727.GQ24846@linuxmafia.com> Quoting Ian Zimmerman (itz at primate.net): > I can't seem to do much of anything on the web today. Among other > things, Github CSS seems to be broken (buttons not responding). Some > other sites have even more severe CSS problems. > > I wonder if we're seeing another distributed DDS attack against a major > CDN or two, possibly in revenge to Macron victory in France. Suggest checking recent posting to NANOG's main mailing list. I don't currently have time to plow through those, but if there's something major afoot, I'd expect to see it mentioned there. https://mailman.nanog.org/pipermail/nanog/ From itz at primate.net Mon May 8 14:46:28 2017 From: itz at primate.net (Ian Zimmerman) Date: Mon, 8 May 2017 14:46:28 -0700 Subject: [buug] letsencrypt In-Reply-To: <20170507215333.17326c6a3wpzhb8k@webmail.rawbw.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> <20170507215333.17326c6a3wpzhb8k@webmail.rawbw.com> Message-ID: <20170508214037.15363.396F44C9@matica.foolinux.mooo.com> On 2017-05-07 21:53, Michael Paoli wrote: > Well, I seem to recall (which may *not* be fully accurate) > ... that the default behavior is renewal attempts start at 30 days > before expiration, and continue daily thereafter until successfully > renewed/replaced. I'm fairly sure that information is in the > various documentation/FAQ(s) or the like - at least that's where I > seem to recall having read it before. Re-reading certbot.eff.org, it does indeed say "distant future" is defined as 30 days. My bad for missing it the first time. Given that, I think I'm comfortable with a daily cronjob. It would be _really_ unlucky for letsencrypt DNS to be fscked 30 consecutive days. Thanks for the ideas, I'll add them to the "when bored" list :-) -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From Michael.Paoli at cal.berkeley.edu Mon May 8 20:26:23 2017 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Mon, 08 May 2017 20:26:23 -0700 Subject: [buug] A few follow-ups from last week's meeting (burning ISOs to optical, etc.) Message-ID: <20170508202623.29479a171e8qoau8@webmail.rawbw.com> A few follow-ups from last week's meeting ... As for CLI burning of optical media, I generally use wodim. From my bit of cheat-sheet notes - some of which may be inaccurate/outdated: burning: CD-R CD-RW DVD DVD+-RW DVD+RW DVD-RW CR-RW: for previously written CD-RW blank=all to rewrite all data, or blank=fast to minimally blank wodim -dao blank=all && eject wodim -dao blank=fast && eject DVD+RW: new DVD+RW requiers formatting, but wodim should automatically detect and do that. wodim should allow reformmatting with -format, but seems to fail to do that reformat: dvd+rw-format -force /dev/dvd dvd+rw-format -force /dev/sr0 # wodim -dao big.iso - ends up with lots of extra stuff on end growisofs -Z /dev/sr0=big.iso - ends up with lots of extra stuff on end formats as new: dvd+rw-format -force[=full] /dev/dvd blanks and goes to sequential mode: dvd+rw-format -blank[=full] /dev/dvd DVD-RW: wodim -dao FOO.iso # cannot fixate #padsize=0 #-nopad DVD-R: wodim -dao FOO.iso Also, wodim may also be quite useful in conjunction with mkisofs or similar. Also, ... ISOs, ... I don't always bring them to meetings, nor necessarily have them already burned to optical, but with sufficient advance notice, such arrangements can generally be made. Have a look here - and yes it includes the latest Debian point release, and also at least some BSD flavor(s) (though those may be rather out-of-date now): https://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc I'll also mention, as another quite local good resource - and yes, even including things BSD: Berkeley Linux Users Group http://www.berkeleylug.com/ From Michael.Paoli at cal.berkeley.edu Tue May 9 08:14:27 2017 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Tue, 09 May 2017 08:14:27 -0700 Subject: [buug] letsencrypt DNS (validation) In-Reply-To: <20170508214037.15363.396F44C9@matica.foolinux.mooo.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> <20170507215333.17326c6a3wpzhb8k@webmail.rawbw.com> <20170508214037.15363.396F44C9@matica.foolinux.mooo.com> Message-ID: <20170509081427.13935ty77x0vu3m8@webmail.rawbw.com> Curious if you're seeing actual DNS problems, or problems with DNS validation method, or if it's "just" issues with TTLs and negative caching and perhaps a modest bit of latency on propagation (e.g. to all delegated nameservers plus a few seconds or so ... more than that?). > From: "Ian Zimmerman" > Subject: Re: [buug] letsencrypt > Date: Mon, 8 May 2017 14:46:28 -0700 > On 2017-05-07 21:53, Michael Paoli wrote: > >> Well, I seem to recall (which may *not* be fully accurate) >> ... that the default behavior is renewal attempts start at 30 days >> before expiration, and continue daily thereafter until successfully >> renewed/replaced. I'm fairly sure that information is in the >> various documentation/FAQ(s) or the like - at least that's where I >> seem to recall having read it before. > > Re-reading certbot.eff.org, it does indeed say "distant future" is > defined as 30 days. My bad for missing it the first time. > > Given that, I think I'm comfortable with a daily cronjob. It would be > _really_ unlucky for letsencrypt DNS to be fscked 30 consecutive days. > > Thanks for the ideas, I'll add them to the "when bored" list :-) From itz at primate.net Tue May 9 21:17:52 2017 From: itz at primate.net (Ian Zimmerman) Date: Tue, 9 May 2017 21:17:52 -0700 Subject: [buug] letsencrypt DNS (validation) In-Reply-To: <20170509081427.13935ty77x0vu3m8@webmail.rawbw.com> References: <20170502191440.12941.1D68502C@matica.foolinux.mooo.com> <6B5E4F70-7EAC-42BA-BA38-767EF0DD672E@freebsd.czest.pl> <20170502144258.985013y21t1jwv9c@webmail.rawbw.com> <20170508011005.21200.188F2D17@matica.foolinux.mooo.com> <504A7543-1700-4BFC-B158-7949E60D2A99@freebsd.czest.pl> <20170508021137.23005.01F4E698@matica.foolinux.mooo.com> <20170507215333.17326c6a3wpzhb8k@webmail.rawbw.com> <20170508214037.15363.396F44C9@matica.foolinux.mooo.com> <20170509081427.13935ty77x0vu3m8@webmail.rawbw.com> Message-ID: <20170510035434.2679.0C5349BE@matica.foolinux.mooo.com> On 2017-05-09 08:14, Michael Paoli wrote: > Curious if you're seeing actual DNS problems, or > problems with DNS validation method, or if it's > "just" issues with TTLs and negative caching and > perhaps a modest bit of latency on propagation (e.g. > to all delegated nameservers plus a few seconds or so ... > more than that?). I saw it fail three times, with the error message different for the first time and then identical in the next two cases. First time: WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/very.loosely.org.conf produced an unexpected error: Failed authorization procedure. very.loosely.org (tls-sni-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No valid IP addresses found for very.loosely.org. Skipping. FailedChallenges: Failed authorization procedure. very.loosely.org (tls-sni-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No valid IP addresses found for very.loosely.org Second and third time: WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/very.loosely.org.conf produced an unexpected error: Failed authorization procedure. very.loosely.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for very.loosely.org. Skipping. FailedChallenges: Failed authorization procedure. very.loosely.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for very.loosely.org I self host very.loosely.org; loosely.org which delegates it to me is hosted by dyn. At the times corresponding to the above error logs for letsencrypt, I see _no_ queries (successful or not) in my named logs. It resolved instantly on our lovely primate.net server. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html From Michael.Paoli at cal.berkeley.edu Tue May 16 06:29:02 2017 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Tue, 16 May 2017 06:29:02 -0700 Subject: [buug] BALUG: meeting TODAY!: Tu 2017-05-16 (& note RSVP policy) & other BALUG News Message-ID: <20170516062902.10142t4ued8qhhus@webmail.rawbw.com> BALUG: meeting TODAY!: Tu 2017-05-16 (& note RSVP policy) & other BALUG News ------------------------------ items, details further below: BALUG meeting TODAY: Tu 2017-05-16 (& note RSVP policy) giveaways (Books/publications, CDs/DVDs, ...) help BALUG! :-) - volunteering, venue, ... Twitter https://twitter.com/#!/BALUG_org Upcoming BALUG list changes! ------------------------------ For our 2017-05-16 BALUG meeting (note also RSVP policy) At least presently we don't have a specific speaker/presentation lined up for this meeting, but that doesn't prevent us from having interesting and exciting meetings and discussions. We also manage to sometimes secure/confirm a speaker too late for us to announce or fully publicize the speaker (that's happened at least twice in the past). Got questions, answers, and/or opinions? We typically have some expert(s) and/or relative expert(s) present to cover Linux and related topic areas. Want to hear some interesting discussions on LINUX and other topics? Show up at the meeting, and feel free to bring an agenda if you wish. Want to help ensure BALUG has speakers/presentations lined up for future meetings? Help refer speakers to us and/or volunteer to be one of the speaker coordinators. Great food and people, and interesting conversations to be had. As was decided unanimously at the 2017-03-21 BALUG meeting, there are significant chagnes to the RSVP policy - in short, if you want to be sure there's a meeting to go to, be sure to send your RSVP in time for us to receive it by not later than 5pm of date of meeting. Please RSVP to rsvp at balug.org if you're planning to attend, and also note our revised RSVP policy further below. Meeting kicks off at 6:30 P.M. - we start with meet and greet and chat and such, then proceed with dining around 7:00 P.M. for dinner - please arrive before 7:00 P.M. if you want to join us for dinner. RSVP Please RSVP if you're planning to attend. To do so please e-mail us a note to rsvp at balug.org indicating meeting date. If you'll be bringing additional guest(s) please let us know total number of folks you're RSVPing for. Also please let us know any special requirements or concerns you may have (e.g. if you have any particular dietary considerations, so that we might possibly be able to accommodate you, or if you won't be dining with us but do wish to otherwise join our meeting). IF WE'VE RECEIVED EXACTLY ZERO RSVPs BY 5:00 P.M. ON DATE OF MEETING, MEETING MAY BE CANCELLED WITH NO FURTHER NOTIFICATIONS. So, if we receive your RSVP in time, then there is a meeting, if we receive zero RSVPs in time, there may not be a meeting, so if you want to be sure there's a meeting to go to, be sure to send your RSVP in time for us to receive it by not later than 5:00 P.M. US/Pacific time on date of meeting. Host(s) and any speaker(s)/presenters will be presumed to be RSVPed yes, but will not be counted towards the total of RSVPs received even if they've explicitly RSVPed (hosts/speaker(s)/presenter(s) will be communicated with if meeting is cancelled for any reason). 6:30pm Tuesday, May 16th, 2017 2017-05-16 Henry's Hunan Restaurant 110 Natoma St. (between 2nd & New Montgomery) San Francisco, CA 94105-3704 1-415-546-4999 http://henryshunan.com/ Easy Transit/Parking Access: short walk from BART, MUNI, parking Trip planning: http://www.511.org/ Delicious Hunan cuisine and reasonably priced. Meeting Details... Cost/Dining: The meetings are always free, but dinner is not (unless you are our guest speaker, in which case we also treat you to dinner). For Henry's Hunan Restaurant, if folks are agreeable, we'll share and dine "family" style, and split up the costs, and typical cost per person including tax and tip (but not including beverages beyond complementary tea) would be in the $13.00 to $20.00 range, and commonly around $15.00 to $17.00. Cash may be preferred to ease splitting up the check. One can also specifically order the dish(es) one needs/prefers (e.g. for dietary considerations) - and we also commonly order some dish(es) that may meet various dietary considerations) (e.g. vegetarian, non-pork, ...). Please arrive by 7:00 P.M., we expect to order entrees at that time, and may order appetizer(s) and/or soup(s) anytime after 6:30 P.M. ------------------------------ We typically have various giveaway items at BALUG meetings. We'll likely have at least the below plus additional items. Books and other titles! have a look/read here: https://www.wiki.balug.org/wiki/doku.php?id=balug:books_and_publications CDs/DVDs/ISOs, etc. - have a peek here: http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc We may also be able to "burn" images per request or copy to USB flash, etc. Donations of blank or +-RW media, USB flash, or funding thereof, also appreciated. See the above URL for details (and the inventory (qty.) of what we specifically have "burned" and available on-hand does also frequently change). ------------------------------ help BALUG! :-) - volunteering, venue ... You can do useful and cool stuff volunteering to help BALUG, e.g. following up on many leads for possible venue, among many other possibilities. Quite a variety of opportunities to help BALUG. Come talk to us at a meeting and/or drop us a note at: balug-contact at balug.org These opportunities may include, among other possibilities: o venue arrangement (e.g. followup on potential leads on-site coordination/preparations), see also: http://lists.balug.org/pipermail/balug-admin-balug.org/2014-July/001504.html o chief/assistant cat herder o assist on speaker coordination/procurement, etc. o assist on publicity o Linux Systems Administration (e.g. do/assist/learn, with/under some quite experienced and skilled Linux systems administrator(s)). o webmaster, assistant webmaster, designer, graphic artist o archivist/history/retrieval/etc. o and other various/miscellaneous tasks BALUG would like to be doing (also feel free to suggest ideas!) ------------------------------ Twitter - you can also follow BALUG on Twitter: https://twitter.com/#!/BALUG_org ------------------------------ Upcoming BALUG list changes?! Yes, for the past many years, much of BALUG, including our lists, has been and is still presently hosted on DreamHost.com. We will be changing that in the not-too-horribly-distant-future. We'll update on status when that's about to change and when it does change. We'll provide more details as we approach and go through that transition, and we'll make it as painless as feasible. ------------------------------ Feedback on our publicity/announcements (e.g. contacts or lists where we should get our information out that we're not presently reaching, or things we should do differently): publicity-feedback at balug.org ------------------------------