On Wed, Dec 15, 2010 at 2:05 PM, Daniel Pittman <[email protected]> wrote:
> On Thu, Dec 16, 2010 at 08:04, Ohad Levy <[email protected]> wrote: > > On Wed, Dec 15, 2010 at 6:16 AM, Daniel Pittman <[email protected]> > wrote: > >> On Wed, Dec 15, 2010 at 15:02, Andrew Forgue <[email protected]> > >> wrote: > >> > On Dec 14, 6:15 pm, Daniel Pittman <[email protected]> wrote: > >> >> On Wed, Dec 15, 2010 at 03:10, Andrew Forgue < > [email protected]> > >> >> wrote: > >> >> > On Dec 13, 11:27 pm, Daniel Pittman <[email protected]> wrote: > >> >> >> > diff --git a/lib/puppet/network/resolver.rb > >> >> >> > b/lib/puppet/network/resolver.rb > >> >> >> > new file mode 100644 > >> >> >> > index 0000000..9165efb > >> >> >> > --- /dev/null > >> >> >> > +++ b/lib/puppet/network/resolver.rb > >> >> >> [...] > >> >> >> > + Puppet.debug "Searching for SRV records for #{hostname}" > >> >> >> > + rrs = resolver.getresources(hostname, > >> >> >> > Resolv::DNS::Resource::IN::SRV) > >> >> > >> >> >> Doesn't this resolve the label 'example.com', where you wanted > >> >> >> '_puppet._tcp.example.com'? > >> > >> [...] > >> > >> > So something like a config variable called "use_srv_records" which > >> > defaults to true > >> > >> True or false as consensus says: I like true, but I am not religious > about > >> it. > >> > >> > as well as "srv_record" that defaults to _puppet._tcp.$domain. > >> > Would that be better? I think it would. > >> > >> *nod* I would be very happy with that: it means that there are two > >> sensible auto-discovery methods for Puppet clients starting on a > >> network: DNS-SD, and the puppet.$domain CNAME. Both pretty much > >> harmless, so far as I can tell, if they are not used. > >> > >> If others felt really strongly I would also support doing DNS-SD > >> against 'puppet.$domain', but I don't think that is really a good > >> value-added choice. > >> > >> > This way you can turn on/off the SRV functionality as well as > >> > override the default domain lookup. If the _puppet._tcp.$domain is > >> > NXDOMAIN, it falls back to whatever server is. Is that reasonable? > >> > >> Absolutely. Thank you very much for doing this, by the way: I think > >> adding DNS-SD is a great feature, and will be very pleased to see it > >> come along. It makes big deployments so much easier to manage if the > >> clients can automatically discover and work with any number of puppet > >> master instances without extra configuration. > > > > Does it make sense to add another lookup for the CA server? > > I think in the longer term it would make sense to do an SRV lookup for > each unique service that Puppet uses; SRV lookups (RFC2782) > distinguishes based on service and protocol. Which, I think, would be > vaguely in conflict with the CA requirement, since that uses the same > puppet service (as in, TCP port) for communication. > It doesn't *necessarily* use the same port remember, it just does by default. > I would assume > > that if you have multiple masters you are sharing one common CA? > > or rather do you expect that provisioning takes care for the initial > > certificate generation? > > I honestly assumed that it wasn't work trying to change the rest of > the stack at the same time: getting the basic SRV support in and then > solving the edge cases was enough for me. DNS-SD defined the use of a > text record alongside the SRV record to pass additional key/value > pairs - I don't know the standardization state of that, but it could > theoretically allow exporting of that information. > > In the short term I would expect that being able to set a CA server > name explicitly on the client would be sufficient for any deployment > scenario I can easily imagine... > > Regards, > Daniel > -- > ✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 > 707 > ♽ made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
