[Puppet Users] Re: pupptboard Could not reach PuppetDB error
Yo guys, I was able to find the secret sauce that got this working for me! When I gave the command: setsebool -P httpd_can_network_relay=1 And reloaded the page.. voila! Everything worked. And there's nothing like success but success. Just wanted to let you know... Tim On Fri, Mar 20, 2015 at 9:27 PM, Tim Dunphy bluethu...@gmail.com wrote: Hey guys, I was able to find out the cause of the problem. I had SELinux enabled! Once I gave the 'setenforce 0' command, puppetboard starts working and filling in with data. So, I've been googling around for a little while, and still haven't found anything useful. Does anyone know the correct SELinux commands to make this error go away? [Fri Mar 20 20:47:49 2015] [error] ERROR:pypuppetdb.api:Could not reach PuppetDB on localhost:8080 over HTTP. Thanks! Tim On Fri, Mar 20, 2015 at 7:46 PM, Tim Dunphy bluethu...@gmail.com wrote: Hey all, I just had to setup puppetdb on a new host. And everything seemed to go smoothly using the python pip install method. But when I load up the page with the puppetbaord on it, I see an 'internal server error' message on the web page. Tailing the apache error log gives me this: [Fri Mar 20 19:37:35 2015] [error] ERROR:pypuppetdb.api:Could not reach PuppetDB on localhost:8080 over HTTP. This is my jetty file: [root@puppet:~] #grep -v '#' /etc/puppetdb/conf.d/jetty.ini [jetty] host = 0.0.0.0 port = 8080 ssl-host = 0.0.0.0 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 And this is my settings file: [root@puppet:~] #cat /var/www/puppetboard/settings.py PUPPETDB_HOST = 'localhost' PUPPETDB_PORT = 8080 PUPPETDB_TIMEOUT = 60 And here I can see that puppetdb is listening on all ports: [root@puppet:~] #lsof -i :8080 COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME java11983 puppetdb 15u IPv6 140324244 0t0 TCP *:webcache (LISTEN) And puppetdb is working just fine according to the logs: [root@puppet:~] #tail -5 /var/log/puppetdb/puppetdb.log 2015-03-20 19:42:53,147 INFO [c.p.p.command] [bfb4c274-1a9c-4316-bc0c-685d2d073c08] [replace facts] mail.jokefire.com 2015-03-20 19:42:54,598 INFO [c.p.p.command] [adf079ee-b0bb-480a-bf64-6e01e7525009] [replace facts] hadoop1.jokefire.com 2015-03-20 19:42:56,532 INFO [c.p.p.command] [a33a19fa-87a9-4bbe-af94-3f337e1214b2] [replace facts] lb2.jokefire.com 2015-03-20 19:42:57,422 INFO [c.p.p.command] [0b6c4e73-8ebb-42de-8f72-a409d4f6de1c] [replace facts] hadoop2.jokefire.com 2015-03-20 19:42:59,311 INFO [c.p.p.command] [cd04f4e3-802f-4c58-aced-3a38856764bf] [replace catalog] logs.jokefire.com And I can see the puppetdb is populated: puppetdb=# select * from certnames limit 5; name | deactivated --+- mail.mydomain.com| logs.mydomain.com| activemq.mydomain.com| lb1.mydomain.com | mcollective.mydomain.com | (5 rows) Does anyone have any ideas as to why this new puppetboard machine can't authenticate against the puppetdb? Thanks, Tim ~ -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAOZy0ema9Lk38pf11R6Ve5RfmOBBkt-kr0qir13AQkeOFCuqiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Use value from a hash defined in hiera datasource elsewhere in the same hiera datasource
I have a hiera (YAML based) data source:
--
# /etc/puppet/hieradata/foo.yaml
webapp::options:
http_port: 8080
timeout: 500
#
# Set the http_port for foo
#
# any of these approaches gave an empty value
foo::http_port: %{hiera('options['http_port']')}
foo::http_port: %{hiera('options::http_port')}
foo::http_port: %{hiera('options.http_port')}
--
The foo class needs to know the http_port of the webap, and in my case it
should be set to whatever value is in webapp::options['http_port']. The
only work around I found is to do this:
--
# /etc/puppet/hieradata/foo.yaml
webapp_http_port: 8080
webapp::options:
http_port: %{hiera('webapp_http_port')}
timeout: 500
#
# Set the http_port for foo
#
foo::http_port: %{hiera('webapp_http_port')}
--
But I was hoping to just extract the value from the hash. Thoughts?
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/9a6be0d5-56bd-4b55-a806-8b3d71d7bc9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] new to puppet.
Hi, the best way is to start with learning puppet vm and the according website: https://docs.puppetlabs.com/learning/index.html https://docs.puppetlabs.com/learning/index.html At https://puppetlabs.com/learn https://puppetlabs.com/learn you have the possibility to get a guide through Puppet basics without the need for a VM. It is always the best to first understand the concept behind puppet and then start with real world problems. hth, Martin On 19.03.2015, at 15:45, manyi anche...@gmail.com wrote: does anyone has a manifest I can use to: 1. Create an account for Mary, maryjane on all systems 2. Create a specific user on just a specific system (For example, create account john.doe on puppet-domain but not on puppetagent) -- 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 puppet-users+unsubscr...@googlegroups.com mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/78b8556c-2bff-4da4-a335-101a19a5f402%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/78b8556c-2bff-4da4-a335-101a19a5f402%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/F88CFF7B-8194-48E9-B72C-BD2356F3DA2A%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: How can I diagnose hopeless performance.
On Friday, 20 March 2015 08:18:15 UTC, jamese wrote: Try running puppet with --debug and --evaltrace to see where it's taking the time. Ah! As before, the evaltrace for the empty node definition lists a handful of things being evaluated in negligible times. But that out put is bracketed by debug info. It is preceded by... Debug: Loaded state in 40.54 seconds Debug: Loaded state in 90.30 seconds And followed by Debug: Stored state in 130.67 seconds Notice: Finished catalog run in 224.24 seconds So the time appears to be going on loading and saving State. So I look. And I find the answer. Our server is running applications written in Perl, using Catalyst. Those applications track user sessions.in files created below a sessions directory. We have configured Puppet to Tidy the sessions directories, by removing files over 3 days old. Currently, we have something like 1200 files in the sessions directory tree. A few hundred sessions per day. Plausible. /var/lib/puppet/state/state.yaml has *four hundred thousand* lines related to these session files. So in its state file, Puppet is keeping a record of every session file it has ever deleted. It looks like every time it starts, it reads them all in. And every time it finishes, it writes them all back out again, even though they don't exist. If I remove the state directory, puppet processes the empty node in no time at all FFS! This is not quite the behaviour I want. But how can I stop it? -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/154122c1-d228-4de6-82db-d1df8fe1bd9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: How can I diagnose hopeless performance.
On Sat, Mar 21, 2015 at 12:08:07PM -0700, Robert Inder wrote: On Friday, 20 March 2015 08:18:15 UTC, jamese wrote: Try running puppet with --debug and --evaltrace to see where it's taking the time. Ah! As before, the evaltrace for the empty node definition lists a handful of things being evaluated in negligible times. But that out put is bracketed by debug info. It is preceded by... Debug: Loaded state in 40.54 seconds Debug: Loaded state in 90.30 seconds And followed by Debug: Stored state in 130.67 seconds Notice: Finished catalog run in 224.24 seconds So the time appears to be going on loading and saving State. So I look. And I find the answer. Our server is running applications written in Perl, using Catalyst. Those applications track user sessions.in files created below a sessions directory. We have configured Puppet to Tidy the sessions directories, by removing files over 3 days old. Currently, we have something like 1200 files in the sessions directory tree. A few hundred sessions per day. Plausible. /var/lib/puppet/state/state.yaml has four hundred thousand lines related to these session files. So in its state file, Puppet is keeping a record of every session file it has ever deleted. It looks like every time it starts, it reads them all in. And every time it finishes, it writes them all back out again, even though they don't exist. If I remove the state directory, puppet processes the empty node in no time at all FFS! This is not quite the behaviour I want. But how can I stop it? In your place I'd probably just purge stale sessions with a cron job. Any particular reason why puppet's tidy is better than find-rm? -- 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 [1]puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit [2]https://groups.google.com/d/msgid/puppet-users/154122c1-d228-4de6-82db-d1df8fe1bd9c%40googlegroups.com. For more options, visit [3]https://groups.google.com/d/optout. References Visible links 1. mailto:puppet-users+unsubscr...@googlegroups.com 2. https://groups.google.com/d/msgid/puppet-users/154122c1-d228-4de6-82db-d1df8fe1bd9c%40googlegroups.com?utm_medium=emailutm_source=footer 3. https://groups.google.com/d/optout -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20150321220819.GA30516%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
