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.
> 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].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
