I just built the PuppetDB 1.4.0 RPMs on OpenSuSE 12.1. The specfile works
much better on OpenSuSE now. Two issues came up, however:
The ''BuildRequires:sles-release'' needs to have a conditional
around it so
that it can tell between SLES and OpenSuSE. I think this works (I
don''t
have a SLES box to test against):
%if 0%{?sles_version}
BuildRequires: sles-release
%else
BuildRequires: openSUSE-release
%endif
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/
I''d like to thank the PuppetLabs folks for making the specfile MUCH
more
OpenSuSE friendly. It only took me ten minutes this time to fix the
problems in the specfile - 1.3.0 took a lot longer.
Thanks!
Jeffrey.
--
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+unsubscribe@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.
Jeff, I''ve packaged puppetdb for OpenSUSE/SLES. all versions, and it''s available in the systemsmanagement:puppet repository. It builds puppetdb fully from source, no binary blobs, has SuSE compatible init/systemd scripts, etc. Download Top level for all repos: http://download.opensuse.org/repositories/systemsmanagement:puppet/ Build Project: https://build.opensuse.org/package/show/systemsmanagement:puppet/puppetdb -- Later, Darin On Thu, Sep 26, 2013 at 11:51 AM, Jeffrey Watts <jeffrey.w.watts@gmail.com> wrote:> I just built the PuppetDB 1.4.0 RPMs on OpenSuSE 12.1. The specfile works > much better on OpenSuSE now. Two issues came up, however: > > The ''BuildRequires:sles-release'' needs to have a conditional around it so > that it can tell between SLES and OpenSuSE. I think this works (I don''t > have a SLES box to test against): > %if 0%{?sles_version} > BuildRequires: sles-release > %else > BuildRequires: openSUSE-release > %endif > > 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/ > > I''d like to thank the PuppetLabs folks for making the specfile MUCH more > OpenSuSE friendly. It only took me ten minutes this time to fix the > problems in the specfile - 1.3.0 took a lot longer. > > Thanks! > Jeffrey. > > -- > 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+unsubscribe@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+unsubscribe@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.
Thanks Darin! Jeffrey. On Thu, Sep 26, 2013 at 11:01 AM, Darin Perusich <darin@darins.net> wrote:> Jeff, > > I''ve packaged puppetdb for OpenSUSE/SLES. all versions, and it''s > available in the systemsmanagement:puppet repository. It builds > puppetdb fully from source, no binary blobs, has SuSE compatible > init/systemd scripts, etc. > > Download Top level for all repos: > http://download.opensuse.org/repositories/systemsmanagement:puppet/ > > Build Project: > https://build.opensuse.org/package/show/systemsmanagement:puppet/puppetdb > -- > Later, > Darin > > > On Thu, Sep 26, 2013 at 11:51 AM, Jeffrey Watts > <jeffrey.w.watts@gmail.com> wrote: > > I just built the PuppetDB 1.4.0 RPMs on OpenSuSE 12.1. The specfile > works > > much better on OpenSuSE now. Two issues came up, however: > > > > The ''BuildRequires:sles-release'' needs to have a conditional around it so > > that it can tell between SLES and OpenSuSE. I think this works (I don''t > > have a SLES box to test against): > > %if 0%{?sles_version} > > BuildRequires: sles-release > > %else > > BuildRequires: openSUSE-release > > %endif > > > > 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/ > > > > I''d like to thank the PuppetLabs folks for making the specfile MUCH more > > OpenSuSE friendly. It only took me ten minutes this time to fix the > > problems in the specfile - 1.3.0 took a lot longer. > > > > Thanks! > > Jeffrey. > > > > -- > > 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+unsubscribe@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+unsubscribe@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+unsubscribe@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.
On Sep 26, 2013, at 9:01 AM, Darin Perusich <darin@darins.net> wrote:> Jeff, > > I''ve packaged puppetdb for OpenSUSE/SLES. all versions, and it''s > available in the systemsmanagement:puppet repository. It builds > puppetdb fully from source, no binary blobs, has SuSE compatible > init/systemd scripts, etc. > > Download Top level for all repos: > http://download.opensuse.org/repositories/systemsmanagement:puppet/ > > Build Project: > https://build.opensuse.org/package/show/systemsmanagement:puppet/puppetdbJeff/Darin: I don''t have anything to add other than to say this is awesome, and thanks so much for doing this. I''ll try and make sure that you''re kept in the loop if we make any upstream changes that affect packaging! deepak> -- > Later, > Darin > > > On Thu, Sep 26, 2013 at 11:51 AM, Jeffrey Watts > <jeffrey.w.watts@gmail.com> wrote: >> I just built the PuppetDB 1.4.0 RPMs on OpenSuSE 12.1. The specfile works >> much better on OpenSuSE now. Two issues came up, however: >> >> The ''BuildRequires:sles-release'' needs to have a conditional around it so >> that it can tell between SLES and OpenSuSE. I think this works (I don''t >> have a SLES box to test against): >> %if 0%{?sles_version} >> BuildRequires: sles-release >> %else >> BuildRequires: openSUSE-release >> %endif >> >> 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/ >> >> I''d like to thank the PuppetLabs folks for making the specfile MUCH more >> OpenSuSE friendly. It only took me ten minutes this time to fix the >> problems in the specfile - 1.3.0 took a lot longer. >> >> Thanks! >> Jeffrey. >> >> -- >> 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+unsubscribe@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+unsubscribe@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+unsubscribe@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.
> 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+unsubscribe@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.
On 27 September 2013 13:26, Ken Barber <ken@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? > >In our setup we have a "main" puppet infrastructure and a couple of child infrastructures. Each puppet setup has its own CA. The puppetmasters in the children are agents to the main puppet infrastructure, so they have a separate ssldir for the master. With this change it just worked out of the box if we co-hosted a puppetdb instance on them as it would use the ssldir from the master. -- 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+unsubscribe@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.
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 <ken@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+unsubscribe@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+unsubscribe@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.
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.watts@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 <ken@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+unsubscribe@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+unsubscribe@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+unsubscribe@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.
> 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.The patch is close, but I think we should probably check all files in advance though not just one, and also warn when we fall through.>> 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''d be curious to see what your puppet.conf looks like in this case. Also, were the certificates previously signed before the installation occurred?>>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).No disagreements here. 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+unsubscribe@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.
Ken, here''s my puppet.conf:
[main]
logdir = /var/log/puppet
modulepath = /etc/puppet/modules
rundir = /var/run/puppet
ssldir = $vardir/ssl
[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
server = puppetmaster.example.com
show_diff = true
[master]
autosign = /etc/puppet/autosign.conf
ca_name = Puppet CA: puppetmaster.example.com
certname = puppetmaster.example.com
reports = http,puppetdb
reporturl = http://puppetdashboard.example.com:3000/reports/upload
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
storeconfigs = true
storeconfigs_backend = puppetdb
[test]
manifest = /etc/puppet/environments/test/manifests/site.pp
modulepath = /etc/puppet/environments/test/modules
This was an upgrade, so the certs were already signed and in place.
Hope this helps,
Jeffrey.
On Sun, Sep 29, 2013 at 1:20 PM, Ken Barber <ken@puppetlabs.com> wrote:
> > 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.
>
> The patch is close, but I think we should probably check all files in
> advance though not just one, and also warn when we fall through.
>
> >> 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''d be curious to see what your puppet.conf looks like in this
case.
> Also, were the certificates previously signed before the installation
> occurred?
>
> >>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).
>
> No disagreements here.
>
> 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+unsubscribe@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.