Ok.. I found my issue. Basically, everyone that said "you don't need to
change anything" was right, although you (ken) pointing out the httpd
raised my awareness. The method is "http" not "httpd" -- Force of habbit
and restarting the apache server caused me to "typo" and add the 'd'.
Without it, it works fine:
/etc/puppet/puppet.conf
[main]
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
reports = store, puppetdb, http
reporturl = http://puppetmaster.mydomain.com/reports/upload
modulepath =
/etc/puppet/modules:/usr/share/puppet/modules:/etc/puppet/env/modules/$environment
storeconfigs = true
storeconfigs_backend = puppetdb
[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
report = true
environment = master
server = puppetmaster.mydomain.com
On Friday, April 25, 2014 9:32:10 AM UTC-4, Mark Cartwright wrote:
>
> Background:
> I had started with a basic install of Open Source puppet (3.4.2 on master
> and clients) and Dashboard (1.2.23), both running as Passenger applications
> under Apache. I have not (so far) configured Inventory for the Dashboard
> but wouldn't mind adding this if I can get basic reports back -- we use the
> dashboard mostly for Radiator view to quickly see how many nodes are Failed
> or Unresponsive, and this functionality doesn't seem to be readily
> available via PuppetDB out of the box (yes, I could write something for it,
> but I'd rather not re-invent the wheel if I can get Dashboard going again.
>
> I installed PuppetDB (1.6.3) from yum repo after getting a lot of
> heartache in our test environment trying to use modules. Everything seems
> to be working well (discounting the Dashboard) and I can query the
> PostgreSQL server directly or access the build-in web API/GUI without a
> problem. I'm also using a puppetdb-rundeck module to feed catalog/fact
> data into rundeck as that was the primary purpose (replacing puppet-rundeck
> that was exceedingly slow).
>
> As soon as PuppetDB began collecting report/catalog data, it stopped going
> to the dashboard. Below I'll past the contents of my key config files.
> Worth noting, currently all pieces are installed on the same server as
> this is a fairly small environment (~ 70 agents) and until it's working
> 100% I thought I'd keep it simple. So far I have no performance complains
> and the queue depth has never been above 0.
>
> /etc/puppet/puppet.conf:
> [main]
> logdir = /var/log/puppet
> rundir = /var/run/puppet
> ssldir = $vardir/ssl
> reports = httpd
> reporturl = http://puppetmaster.mydomain.com/reports/upload
> modulepath =
> /etc/puppet/modules:/usr/share/puppet/modules:/etc/puppet/env/modules/$environment
> storeconfigs = true
> storeconfigs_backend = puppetdb
>
> [agent]
> classfile = $vardir/classes.txt
> localconfig = $vardir/localconfig
> report = true
> environment = master
> server = puppetmaster.mydomain.com
>
> /etc/puppet/puppetdb.conf:
> [main]
> server = puppetmaster.mydomain.com
> port = 8081
> soft_write_failure = false
>
> /etc/puppet/routes.yaml
> ---
> master:
> facts:
> terminus: puppetdb
> cache: yaml
>
> /etc/puppet/auth.conf (mostly default. Added this one stanza directly
> above the last one that denies everything):
> path /facts
> allow *
>
> /etc/puppetdb/conf.d/jetty.ini:
> [jetty]
> host = puppetmaster
> port = 8080
> ssl-host = puppetmaster
> ssl-port = 8081
> ssl-key = /etc/puppetdb/ssl/private.pem
> ssl-cert = /etc/puppetdb/ssl/public.pem
> ssl-ca-cert = /etc/puppetdb/ssl/ca.pem
>
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4d187bdd-9114-4ec8-ae08-57e59715909a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
