Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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 k...@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+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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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//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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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+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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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//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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
On 27 September 2013 13:26, 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//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+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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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//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.
[Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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//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+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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
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.wa...@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//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+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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
Thanks Darin!
Jeffrey.
On Thu, Sep 26, 2013 at 11:01 AM, Darin Perusich da...@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.wa...@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//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+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.
--
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.
Re: [Puppet Users] PuppetDB 1.4.0 on OpenSuSE
On Sep 26, 2013, at 9:01 AM, Darin Perusich da...@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
Jeff/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.wa...@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//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+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.
--
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.
