FAQ
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.

Search Discussions

  • Maura Dailey at Jul 17, 2012 at 8:24 am
    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.
  • Brett Maton at Jul 17, 2012 at 8:29 am
    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.
  • Maura Dailey at Jul 17, 2012 at 4:39 pm
    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 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 at Jul 17, 2012 at 6:33 pm
    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 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 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.
  • Maura Dailey at Jul 17, 2012 at 7:42 pm
    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 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 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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 29, '12 at 11:03a
activeJul 17, '12 at 7:42p
posts6
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase