I believe the last proposal for significant changes to the CRConfig was https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity
Jonathan G On 5/9/19, 8:19 AM, "Steve Malenfant" <[email protected]> wrote: Should there be 2 type of CR-Config? A major (all) and minor (less dangerous things)? Currently seems like a few things gets propagated if you want it or not. SSL, Steering and Federation. No CR-Config required. Steve On Thu, May 9, 2019 at 10:17 AM Derek Gelinas <[email protected]> wrote: > I agree with this for this implementation, but I find myself wondering if > there's anything else that might be detached from the primary crconfig in > order to help automate things/separate them from more dangerous activities, > like disconnecting servers from services or setting them offline, that sort > of thing. > > Thoughts on that? I can start a new thread if desired since this is > somewhat out of the scope of the original conversation. > > Derek > > > On May 9, 2019, at 9:47 AM, Matthew Jackson <[email protected]> > wrote: > > > > That sounds good to me! Thanks everyone! > > > > On Wed, May 8, 2019 at 4:28 PM Chris Lemmons <[email protected]> wrote: > > > >> I think the out-of-band solution might be the cleanest and safest. > >> It's a bit more work, but it keeps things separate that should be > >> separate. Additionally, it significantly reduces the risk that an > >> error in the ACME logic causes trouble for unrelated DSs. > >> > >> On Wed, May 8, 2019 at 9:00 AM Steve Malenfant <[email protected]> > >> wrote: > >>> > >>> If adding "static entries" is less or non disruptive. Probably having > >>> another endpoint that doesn't require CR-Config could be acceptable. > Like > >>> steering and others. > >>> > >>> I'm assuming we are only talking about the DNS challenge so far and > >> nothing > >>> about updating the certs themselves. Looks like TR handles this > >>> automatically so far, but not the edge caches... > >>> > >>> Steve > >>> > >>> On Wed, May 8, 2019 at 9:19 AM Fieck, Brennan < > [email protected] > >>> > >>> wrote: > >>> > >>>> Yeah, automatic snapping is risky. I'm +1 on implementing IMS, though. > >> I'm > >>>> not sure it'll be as > >>>> easy as Rob thinks - well, `/snapshot` would be, but I think > >>>> `/snapshot/new` will be significantly > >>>> more involved. > >>>> > >>>> As far as ACME challenges go, we could build a client into TR, so that > >> the > >>>> endpoint for TO actually > >>>> just acts as a gateway and requests that TR handle certificate/key > >>>> generation. That should eliminate > >>>> the race condition, and wouldn't require that a "fake" Static DNS > >> Entry be > >>>> added to a Delivery Service. > >>>> ________________________________________ > >>>> From: Derek Gelinas <[email protected]> > >>>> Sent: Tuesday, May 7, 2019 6:15 PM > >>>> To: [email protected] > >>>> Subject: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates > / > >>>> automatic Snapshot > >>>> > >>>> This was my suggestion when discussed on slack earlier as well. > >> Probably > >>>> the easiest to implement though I think Rob's suggestion also had > >> merit. > >>>> I'm -1 on anything that auto snaps, and LE can't really wait around > >> for a > >>>> user snap. > >>>> > >>>> On Tue, May 7, 2019 at 7:29 PM Rawlin Peters <[email protected] > > > >>>> wrote: > >>>> > >>>>> Putting the TXT record into the delivery service's static DNS entries > >>>>> does seem like the path of least resistance, but the automatic > >>>>> snapshot requirement could be a little dicey as Jeremy and Rob have > >>>>> described. > >>>>> > >>>>> Another possible option could be to have TR query a new "out-of-band" > >>>>> TO endpoint (i.e. like the steering and federations endpoints that TR > >>>>> polls periodically for real-time data) that would allow it to get the > >>>>> LetsEncrypt DNS challenges in a real-time manner. > >>>>> > >>>>> Then we wouldn't have to do an automatic snapshot, and whatever TO > >>>>> endpoint you call to make a LetsEncrypt request for a DS would just > >>>>> populate the DB with the challenge, then TR would query all the > >>>>> challenges and update its TXT records appropriately. > >>>>> > >>>>> This all kind of assumes that the integration is mostly in Traffic > >>>>> Ops. Is that along the lines of what you are proposing? What's the > >>>>> end-to-end request/response flow? > >>>>> > >>>>> - Rawlin > >>>>> > >>>>> On Tue, May 7, 2019 at 2:28 PM Matthew Jackson < > >> [email protected]> > >>>>> wrote: > >>>>>> > >>>>>> Hey all, > >>>>>> > >>>>>> I'm working to add integration with LetsEncrypt to get signed certs > >>>>>> automatically for delivery services. In order to prove that I own > >> the > >>>>>> domain, LetsEncrypt does a DNS challenge and requires that a token > >> from > >>>>>> them is put as a TXT record at "_acme-challenge.domain.com". They > >>>>> verify > >>>>>> that the token is there before returning the certs. > >>>>>> > >>>>>> I'm using Traffic Router to do this "DNS" authentication, but this > >> will > >>>>>> require a Snapshot to be taken in order to update TR. LetsEncrypt > >>>>> doesn't > >>>>>> really allow for a break between the request and the challenge, so > >> this > >>>>>> would all have to be done in a row. One option for this would be > >> to > >>>> add > >>>>>> the TXT record through the "Static DNS Entries" endpoint, > >> automatically > >>>>>> call the Snapshot, and verify the server was updated before > >> returning > >>>> to > >>>>>> LetsEncrypt. But I wanted to reach out to get everyone's thoughts > >> / > >>>>> other > >>>>>> ideas before proceeding. > >>>>>> > >>>>>> Any thoughts or ideas? > >>>>>> > >>>>>> Thanks > >>>>>> Matt > >>>>> > >>>> > >> > >
