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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
