On a normal setup puppet master --configprint ssldir and puppet agent --configprint ssldir should return the same thing. And normally you don't have your master configuration on agent nodes. But doing that sort of fallback sounds like a good solution that should cover most cases well.
On 27 September 2013 20:13, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: > My concern is that after downloading the PuppetDB RPM from PuppetLabs it > should not throw errors on installation, which it currently does if you > install it on a server that is not the master. I also believe that having > the PuppetDB separate from the Puppetmaster is not an edge case (I'd > actually argue it's best practice, especially in this era of > virtualization). > > Gary Wilson's proposed patch seems to solve the problem - try 'puppet > master' first, and then fall back to 'puppet agent'. IMHO if someone has a > more complicated setup where that wouldn't work, then the onus should be on > them to modify puppetdb-ssl-setup. > > Thanks for your consideration, > Jeffrey. > > > > On Fri, Sep 27, 2013 at 6:26 AM, Ken Barber <k...@puppetlabs.com> wrote: > >> > Lastly, the puppetdb-ssl-setup script still does not work when the >> PuppetDB >> > does not reside on the Puppetmaster. The fix is pretty simple, and the >> > issue is in the bug tracker. I created a question and answer on >> > ask.puppetlabs.com to try and help others that run into it: >> > >> https://ask.puppetlabs.com/question/3333/puppetdbs-puppetdb-ssl-setup-script-does-not-work-when-the-puppetdb-is-not-on-the-puppetmaster/ >> >> So the ticket for those reading along at home is here: >> >> http://projects.puppetlabs.com/issues/17523 >> >> And I must admit its controversial but saying it 'doesn't work' isn't >> entirely true. More precisely there are situations where it doesn't >> work, and I want to hear what people have to add to this - as its a >> really interesting topic that we probably need some community feedback >> on. >> >> Let me show you an example, with an empty puppet.conf ... the settings >> returned are identical: >> >> root@puppetdb1:~# puppet apply --configprint hostcert >> /etc/puppet/ssl/certs/puppetdb1.vm.pem >> root@puppetdb1:~# puppet master --configprint hostcert >> /etc/puppet/ssl/certs/puppetdb1.vm.pem >> >> But when you have overrides in relation to agent/master that create >> differences between the [master] and [agent] sections things go wrong. >> Try this one on for size: >> >> root@puppetdb1:~# cat /etc/puppet/puppet.conf >> [master] >> ssldir = /tmp >> >> [agent] >> ssldir = /tmp2 >> root@puppetdb1:~# puppet master --configprint hostcert >> /tmp/certs/puppetdb1.vm.pem >> root@puppetdb1:~# puppet agent --configprint hostcert >> /tmp2/certs/puppetdb1.vm.pem >> >> So like I said ... this is actually fine for some people, and >> preferential, but for others its not fine. The question is, what is >> the better default I think. >> >> So in my opinion I would have thought that agent was a better default >> over master as some people presume, but that changed some time ago in >> 0.9.2: >> >> >> https://github.com/puppetlabs/puppetdb/commit/de23912a73f6adadf36f26d438939d4c9e49a68b >> >> I suppose there are arguments for either direction, but I'm not as >> clear on the direction to move this to use the [master] section >> specifically. I can't help but feel its a less common case. Erik - >> perhaps you can chime in on the thread and give us your reasoning for >> wanting this in the first place? >> >> I guess we have been apprehensive on moving on that ticket because >> changing default behaviour is often scary ... if we change it its >> going to break for some people without a doubt. So what is the answer? >> Perhaps a flag to allow people to choose? What do people think the >> setting should be, and why? >> >> ken. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-users+unsubscr...@googlegroups.com. >> To post to this group, send email to puppet-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/puppet-users. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out. > -- Erik Dalén -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
