I''ve configured puppet to use storedconfigs and puppetDB, If I start the puppet master using the init script puppetmaster I get a permission denied error when a node connects: Master: [root@puppet ~]# service puppetmaster start Starting puppetmaster: [ OK ] Node: [root@puppet-slave ~]# puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit ''replace facts'' command for puppet-slave.test.net to PuppetDB at puppet.test.net:8081: Permission denied - connect(2) warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run If I start the puppet master using the script puppet command, it works fine: Master: [root@puppet ~]# puppet master start Node: [root@puppet-slave ~]# puppet agent --test info: Caching catalog for puppet-slave.test.net info: Applying configuration version ''1340967639'' notice: /Stage[main]/Drupal/Exec[install-drupal]/returns: executed successfully notice: Finished catalog run in 17.72 seconds Anyone come across this behaviour before, or found a solution? All packages are from RPM installs (except ruby gems for pupetdb....) [root@puppet ~]# rpm -qa | grep puppet puppet-server-2.7.17-1.el6.noarch puppetlabs-release-6-1.noarch puppet-2.7.17-1.el6.noarch puppetdb-0.9.1-2.el6.noarch puppetdb-terminus-0.9.1-2.el6.noarch -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I''m running RHEL 6.3, using the packages from the puppetlabs yum repository, and I am getting the exact same problem (with the exact same solution, which I didn''t even think to try until Brett thoughtfully provided it). I start puppetmaster''s init script with: service puppetmaster start. I get the exact same error if I use the built in database or the postgres database. Everything has been installed from scratch, I deleted all config files from the previous puppet server configuration when storeconfig''s sqlite3 plugin started dying repeatedly on our network of about 30 computers. This has been the only hiccup in a wonderfully uneventful upgrade from puppet 2.6.16 to puppet 2.7.18. - Maura Dailey On Friday, June 29, 2012 7:03:36 AM UTC-4, Brett Maton wrote:> > I''ve configured puppet to use storedconfigs and puppetDB, > If I start the puppet master using the init script puppetmaster I get a > permission denied error when a node connects: > > Master: > [root@puppet ~]# service puppetmaster start > Starting puppetmaster: [ OK ] > > Node: > [root@puppet-slave ~]# puppet agent --test > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Failed to submit ''replace facts'' command for puppet-slave.test.net to > PuppetDB at puppet.test.net:8081: Permission denied - connect(2) > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > If I start the puppet master using the script puppet command, it works > fine: > > Master: > [root@puppet ~]# puppet master start > > Node: > [root@puppet-slave ~]# puppet agent --test > info: Caching catalog for puppet-slave.test.net > info: Applying configuration version ''1340967639'' > notice: /Stage[main]/Drupal/Exec[install-drupal]/returns: executed > successfully > notice: Finished catalog run in 17.72 seconds > > Anyone come across this behaviour before, or found a solution? > > All packages are from RPM installs (except ruby gems for pupetdb....) > > [root@puppet ~]# rpm -qa | grep puppet > puppet-server-2.7.17-1.el6.noarch > puppetlabs-release-6-1.noarch > puppet-2.7.17-1.el6.noarch > puppetdb-0.9.1-2.el6.noarch > puppetdb-terminus-0.9.1-2.el6.noarch > > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4i8zI10rtR8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi Maura, I asked the question on the puppet IRC channel, the solution in my case was to add SELinux rules to allow the puppetdb process to do it''s thing. Something to check :) Brett On 17 Jul 2012, at 01:34, Maura Dailey wrote:> I''m running RHEL 6.3, using the packages from the puppetlabs yum repository, and I am getting the exact same problem (with the exact same solution, which I didn''t even think to try until Brett thoughtfully provided it). I start puppetmaster''s init script with: service puppetmaster start. I get the exact same error if I use the built in database or the postgres database. Everything has been installed from scratch, I deleted all config files from the previous puppet server configuration when storeconfig''s sqlite3 plugin started dying repeatedly on our network of about 30 computers. This has been the only hiccup in a wonderfully uneventful upgrade from puppet 2.6.16 to puppet 2.7.18. > > - Maura Dailey > > On Friday, June 29, 2012 7:03:36 AM UTC-4, Brett Maton wrote: > I''ve configured puppet to use storedconfigs and puppetDB, > If I start the puppet master using the init script puppetmaster I get a permission denied error when a node connects: > > Master: > [root@puppet ~]# service puppetmaster start > Starting puppetmaster: [ OK ] > > Node: > [root@puppet-slave ~]# puppet agent --test > err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit ''replace facts'' command for puppet-slave.test.net to PuppetDB at puppet.test.net:8081: Permission denied - connect(2) > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > If I start the puppet master using the script puppet command, it works fine: > > Master: > [root@puppet ~]# puppet master start > > Node: > [root@puppet-slave ~]# puppet agent --test > info: Caching catalog for puppet-slave.test.net > info: Applying configuration version ''1340967639'' > notice: /Stage[main]/Drupal/Exec[install-drupal]/returns: executed successfully > notice: Finished catalog run in 17.72 seconds > > Anyone come across this behaviour before, or found a solution? > > All packages are from RPM installs (except ruby gems for pupetdb....) > > [root@puppet ~]# rpm -qa | grep puppet > puppet-server-2.7.17-1.el6.noarch > puppetlabs-release-6-1.noarch > puppet-2.7.17-1.el6.noarch > puppetdb-0.9.1-2.el6.noarch > puppetdb-terminus-0.9.1-2.el6.noarch > > > > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4i8zI10rtR8J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ugh, that''s horrible. I''d ruled it out earlier for something
unrelated and
promptly forgot about it. Of course, setting the system into permissive
mode made one glaring thing crop right up:
type=AVC msg=audit(1342542891.975:47155): avc: denied { name_connect }
for pid=3883 comm="puppetmasterd" dest=8081
scontext=unconfined_u:system_r:puppetmaster_t:s0
tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket
Thanks for the quick response. I guess puppetmaster''s targeted policy
in
RHEL still has a few kinks (I''ll forgive them on this one, since
puppetdb
is a fairly new invention).
- Maura Dailey
On Tue, Jul 17, 2012 at 4:29 AM, Brett Maton
<brett.maton@googlemail.com>wrote:
> Hi Maura,
>
> I asked the question on the puppet IRC channel, the solution in my case
> was to add SELinux rules to allow the puppetdb process to do it''s
thing.
> Something to check :)
>
> Brett
>
> On 17 Jul 2012, at 01:34, Maura Dailey wrote:
>
> I''m running RHEL 6.3, using the packages from the puppetlabs yum
> repository, and I am getting the exact same problem (with the exact same
> solution, which I didn''t even think to try until Brett
thoughtfully
> provided it). I start puppetmaster''s init script with: service
puppetmaster
> start. I get the exact same error if I use the built in database or the
> postgres database. Everything has been installed from scratch, I deleted
> all config files from the previous puppet server configuration when
> storeconfig''s sqlite3 plugin started dying repeatedly on our
network of
> about 30 computers. This has been the only hiccup in a wonderfully
> uneventful upgrade from puppet 2.6.16 to puppet 2.7.18.
>
> - Maura Dailey
>
> On Friday, June 29, 2012 7:03:36 AM UTC-4, Brett Maton wrote:
>>
>> I''ve configured puppet to use storedconfigs and puppetDB,
>> If I start the puppet master using the init script puppetmaster I get a
>> permission denied error when a node connects:
>>
>> Master:
>> [root@puppet ~]# service puppetmaster start
>> Starting puppetmaster: [ OK ]
>>
>> Node:
>> [root@puppet-slave ~]# puppet agent --test
>> err: Could not retrieve catalog from remote server: Error 400 on
SERVER:
>> Failed to submit ''replace facts'' command for
puppet-slave.test.net to
>> PuppetDB at puppet.test.net:8081: Permission denied - connect(2)
>> warning: Not using cache on failed catalog
>> err: Could not retrieve catalog; skipping run
>>
>> If I start the puppet master using the script puppet command, it works
>> fine:
>>
>> Master:
>> [root@puppet ~]# puppet master start
>>
>> Node:
>> [root@puppet-slave ~]# puppet agent --test
>> info: Caching catalog for puppet-slave.test.net
>> info: Applying configuration version ''1340967639''
>> notice: /Stage[main]/Drupal/Exec[**install-drupal]/returns: executed
>> successfully
>> notice: Finished catalog run in 17.72 seconds
>>
>> Anyone come across this behaviour before, or found a solution?
>>
>> All packages are from RPM installs (except ruby gems for pupetdb....)
>>
>> [root@puppet ~]# rpm -qa | grep puppet
>> puppet-server-2.7.17-1.el6.**noarch
>> puppetlabs-release-6-1.noarch
>> puppet-2.7.17-1.el6.noarch
>> puppetdb-0.9.1-2.el6.noarch
>> puppetdb-terminus-0.9.1-2.el6.**noarch
>>
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/4i8zI10rtR8J.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Deepak Giridharagopal
2012-Jul-17 18:33 UTC
Re: [Puppet Users] puppetmaster init script - bug ?
Hi Maura, I''ve created http://projects.puppetlabs.com/issues/15567 to track the issue on the Puppet Labs side. The communication between a puppetmaster and puppetdb happen over HTTPS, and the default port puppetdb listens on for HTTPS is 8081 (though you can change that if you like). That should be the only port that needs to be open. deepak On Tue, Jul 17, 2012 at 10:39 AM, Maura Dailey <maura@eclipse.ncsc.mil>wrote:> Ugh, that''s horrible. I''d ruled it out earlier for something unrelated and > promptly forgot about it. Of course, setting the system into permissive > mode made one glaring thing crop right up: > > type=AVC msg=audit(1342542891.975:47155): avc: denied { name_connect } > for pid=3883 comm="puppetmasterd" dest=8081 > scontext=unconfined_u:system_r:puppetmaster_t:s0 > tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket > > Thanks for the quick response. I guess puppetmaster''s targeted policy in > RHEL still has a few kinks (I''ll forgive them on this one, since puppetdb > is a fairly new invention). > > - Maura Dailey > > > On Tue, Jul 17, 2012 at 4:29 AM, Brett Maton <brett.maton@googlemail.com>wrote: > >> Hi Maura, >> >> I asked the question on the puppet IRC channel, the solution in my case >> was to add SELinux rules to allow the puppetdb process to do it''s thing. >> Something to check :) >> >> Brett >> >> On 17 Jul 2012, at 01:34, Maura Dailey wrote: >> >> I''m running RHEL 6.3, using the packages from the puppetlabs yum >> repository, and I am getting the exact same problem (with the exact same >> solution, which I didn''t even think to try until Brett thoughtfully >> provided it). I start puppetmaster''s init script with: service puppetmaster >> start. I get the exact same error if I use the built in database or the >> postgres database. Everything has been installed from scratch, I deleted >> all config files from the previous puppet server configuration when >> storeconfig''s sqlite3 plugin started dying repeatedly on our network of >> about 30 computers. This has been the only hiccup in a wonderfully >> uneventful upgrade from puppet 2.6.16 to puppet 2.7.18. >> >> - Maura Dailey >> >> On Friday, June 29, 2012 7:03:36 AM UTC-4, Brett Maton wrote: >>> >>> I''ve configured puppet to use storedconfigs and puppetDB, >>> If I start the puppet master using the init script puppetmaster I get a >>> permission denied error when a node connects: >>> >>> Master: >>> [root@puppet ~]# service puppetmaster start >>> Starting puppetmaster: [ OK ] >>> >>> Node: >>> [root@puppet-slave ~]# puppet agent --test >>> err: Could not retrieve catalog from remote server: Error 400 on SERVER: >>> Failed to submit ''replace facts'' command for puppet-slave.test.net to >>> PuppetDB at puppet.test.net:8081: Permission denied - connect(2) >>> warning: Not using cache on failed catalog >>> err: Could not retrieve catalog; skipping run >>> >>> If I start the puppet master using the script puppet command, it works >>> fine: >>> >>> Master: >>> [root@puppet ~]# puppet master start >>> >>> Node: >>> [root@puppet-slave ~]# puppet agent --test >>> info: Caching catalog for puppet-slave.test.net >>> info: Applying configuration version ''1340967639'' >>> notice: /Stage[main]/Drupal/Exec[**install-drupal]/returns: executed >>> successfully >>> notice: Finished catalog run in 17.72 seconds >>> >>> Anyone come across this behaviour before, or found a solution? >>> >>> All packages are from RPM installs (except ruby gems for pupetdb....) >>> >>> [root@puppet ~]# rpm -qa | grep puppet >>> puppet-server-2.7.17-1.el6.**noarch >>> puppetlabs-release-6-1.noarch >>> puppet-2.7.17-1.el6.noarch >>> puppetdb-0.9.1-2.el6.noarch >>> puppetdb-terminus-0.9.1-2.el6.**noarch >>> >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/puppet-users/-/4i8zI10rtR8J. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks for creating this ticket. Here''s what I''ve uncovered so
far. The
following (generated by audit2allow) worked so long as I was using port
8081:
module puppetdb 1.0;
require {
type puppetmaster_t;
type transproxy_port_t;
class tcp_socket name_connect;
}
#============= puppetmaster_t =============allow puppetmaster_t
transproxy_port_t:tcp_socket name_connect;
However, we''ve got something else running on 8081 on our network
(unsurprising, since 8081 seems to be a popular port for many services), so
I moved to a different port and had to use this (changing the port for
puppetdb didn''t seem to have any effect until after a reboot, even
though I
carefully shut down puppetdb and puppetmaster, so I suspect there is some
kind of caching going on):
module morepuppetdb 1.0;
require {
type puppetmaster_t;
type port_t;
class tcp_socket name_connect;
}
#============= puppetmaster_t =============allow puppetmaster_t
port_t:tcp_socket name_connect;
I did not have to open any ports in iptables, since puppetdb runs on the
same machine as my puppetmaster. I did uncover an seboolean,
puppetmaster_use_db, but this appears to only help if you are directly
connecting to postgres or mysql. I think it would be worth investigating to
see what this bool does. In the mean time, I''m going to roll out the
second
module on my server so that I can get operational again.
- Maura Dailey
On Tue, Jul 17, 2012 at 2:33 PM, Deepak Giridharagopal <
deepak@puppetlabs.com> wrote:
> Hi Maura,
>
> I''ve created http://projects.puppetlabs.com/issues/15567 to track
the
> issue on the Puppet Labs side. The communication between a puppetmaster and
> puppetdb happen over HTTPS, and the default port puppetdb listens on for
> HTTPS is 8081 (though you can change that if you like). That should be the
> only port that needs to be open.
>
> deepak
>
>
> On Tue, Jul 17, 2012 at 10:39 AM, Maura Dailey
<maura@eclipse.ncsc.mil>wrote:
>
>> Ugh, that''s horrible. I''d ruled it out earlier for
something unrelated
>> and promptly forgot about it. Of course, setting the system into
permissive
>> mode made one glaring thing crop right up:
>>
>> type=AVC msg=audit(1342542891.975:47155): avc: denied { name_connect
}
>> for pid=3883 comm="puppetmasterd" dest=8081
>> scontext=unconfined_u:system_r:puppetmaster_t:s0
>> tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket
>>
>> Thanks for the quick response. I guess puppetmaster''s targeted
policy in
>> RHEL still has a few kinks (I''ll forgive them on this one,
since puppetdb
>> is a fairly new invention).
>>
>> - Maura Dailey
>>
>>
>> On Tue, Jul 17, 2012 at 4:29 AM, Brett Maton
<brett.maton@googlemail.com>wrote:
>>
>>> Hi Maura,
>>>
>>> I asked the question on the puppet IRC channel, the solution in
my
>>> case was to add SELinux rules to allow the puppetdb process to do
it''s
>>> thing.
>>> Something to check :)
>>>
>>> Brett
>>>
>>> On 17 Jul 2012, at 01:34, Maura Dailey wrote:
>>>
>>> I''m running RHEL 6.3, using the packages from the
puppetlabs yum
>>> repository, and I am getting the exact same problem (with the exact
same
>>> solution, which I didn''t even think to try until Brett
thoughtfully
>>> provided it). I start puppetmaster''s init script with:
service puppetmaster
>>> start. I get the exact same error if I use the built in database or
the
>>> postgres database. Everything has been installed from scratch, I
deleted
>>> all config files from the previous puppet server configuration when
>>> storeconfig''s sqlite3 plugin started dying repeatedly on
our network of
>>> about 30 computers. This has been the only hiccup in a wonderfully
>>> uneventful upgrade from puppet 2.6.16 to puppet 2.7.18.
>>>
>>> - Maura Dailey
>>>
>>> On Friday, June 29, 2012 7:03:36 AM UTC-4, Brett Maton wrote:
>>>>
>>>> I''ve configured puppet to use storedconfigs and
puppetDB,
>>>> If I start the puppet master using the init script puppetmaster
I get a
>>>> permission denied error when a node connects:
>>>>
>>>> Master:
>>>> [root@puppet ~]# service puppetmaster start
>>>> Starting puppetmaster: [
OK ]
>>>>
>>>> Node:
>>>> [root@puppet-slave ~]# puppet agent --test
>>>> err: Could not retrieve catalog from remote server: Error 400
on
>>>> SERVER: Failed to submit ''replace facts''
command for
>>>> puppet-slave.test.net to PuppetDB at puppet.test.net:8081:
Permission
>>>> denied - connect(2)
>>>> warning: Not using cache on failed catalog
>>>> err: Could not retrieve catalog; skipping run
>>>>
>>>> If I start the puppet master using the script puppet command,
it works
>>>> fine:
>>>>
>>>> Master:
>>>> [root@puppet ~]# puppet master start
>>>>
>>>> Node:
>>>> [root@puppet-slave ~]# puppet agent --test
>>>> info: Caching catalog for puppet-slave.test.net
>>>> info: Applying configuration version
''1340967639''
>>>> notice: /Stage[main]/Drupal/Exec[**install-drupal]/returns:
executed
>>>> successfully
>>>> notice: Finished catalog run in 17.72 seconds
>>>>
>>>> Anyone come across this behaviour before, or found a solution?
>>>>
>>>> All packages are from RPM installs (except ruby gems for
pupetdb....)
>>>>
>>>> [root@puppet ~]# rpm -qa | grep puppet
>>>> puppet-server-2.7.17-1.el6.**noarch
>>>> puppetlabs-release-6-1.noarch
>>>> puppet-2.7.17-1.el6.noarch
>>>> puppetdb-0.9.1-2.el6.noarch
>>>> puppetdb-terminus-0.9.1-2.el6.**noarch
>>>>
>>>>
>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/puppet-users/-/4i8zI10rtR8J.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.