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 <
[email protected]> 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 <[email protected]>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
>> <[email protected]>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 [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> 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 [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> 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 [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
