Andy, thanks for all your answers. On Wednesday, June 5, 2013 9:25:38 AM UTC-7, Andy Parker wrote: > > As Trevor said, you'll also need to make sure that the channel remains > encrypted. I think that the portions of the code that you are going to be > trying to swap out (namely network communication infrastructure) are not > currently designed for that. It will probably take a lot of moving things > around and creation of some new classes to make something like this slot in > cleanly. Also, all of this functionality will need to be optional so that > scenarios that don't use kerberos don't take on new dependencies. >
WRT securing the channel: our current plans are to continue to rely on server certificates for channel encryption. I should amend my prior description by saying that we want to use Kerberos for *agent* authentication. Technically Kerberos provides master auth too, but we will be relying on traditional certificate based SSL server auth as part of securing the channel. It might be possible to use SLL with Kerberos TLS and skip the master certs, but that's not something that we need now. WRT moving code / backward compatibility: so far the server changes look relatively non-invasive. The client changes seem likely to be more invasive, but I understand the requirement to not regress on any existing behavior/dependencies. My goal is to make it "just work" with minimal to zero configuration. We'll see how achievable that is... > Before you start making pull requests for something this large, I think it > would be good to outline the parts that you are changing and what the > design will be. This also seems like something that would fit well into the > armature process (https://github.com/puppetlabs/armatures). > Yes. I want to get through a round of client prototyping first, but I think an armature would help structure this work. When I know a bit more I'll work on a draft. > I wouldn't worry about webrick. It is really only acceptable for > development setups. As far as multiple webserver setups, we try to stick to > plain rack, if possible. When that isn't possible then try to make sure > that there is a way of configuring either puppet or the webserver to work > together. I believe that historically we have tried to work with apache + > passenger and nginx + ??? (that one is a little more fuzzy to me) > OK. That's helpful. I think I'm working within standard apache idioms though there are some details that remain to be worked out. We can discuss this more when I start working up a formal change for this part of the master modifications (POC rest.rb diff here: https://github.com/mzeren-vmw/puppet/commit/draft_kerberos_baby_steps). -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
