Name: puppet-puppetboard
Owner: Vox Pupuli
Description: Puppet module to install and manage puppetboard
Created: 2013-08-11 21:10:29.0
Updated: 2018-01-16 22:35:16.0
Pushed: 2018-01-15 16:54:42.0
Homepage: https://forge.puppet.com/puppet/puppetboard
Size: 296
Language: Puppet
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
This is the puppetboard puppet module.
Puppetboard is an open source puppet dashboard
https://github.com/voxpupuli/puppetboard
puppet module install puppet-puppetboard
Note Oracle linux 5 on puppet versions 4.6.0 to 4.7.1 has pip package problem which will cause an error trying to install puppetboard.
Note that this module no longer explicitly requires the puppetlabs apache module. If you want to use the apache functionality of this module you will have to specify that the apache module is installed with:
puppet module install puppetlabs-apache
On RedHat type systems, EPEL may also need to be configured; you can use the stahnma/epel module if you don't already have it configured.
This module also requires the git
and virtualenv
packages. These can be enabled in the module by:
s { 'puppetboard':
nage_git => true,
nage_virtualenv => true,
or by:
s { 'puppetboard':
nage_git => 'latest',
nage_virtualenv => 'latest',
Declare the base puppetboard manifest:
s { 'puppetboard': }
NOTE: In order to have reports present in the dashboard, report storage must be enabled on the Puppet master node. This is not the default behavior, so it mush be enabled.
See https://docs.puppet.com/puppetdb/latest/connect_puppet_master.html#enabling-report-storage for instructions on report storage.
By default, puppetboard displays only 10 reports. This number can be controlled to set the number of reports to show.
s { 'puppetboard':
ports_count => 40
If you are running puppetboard in an environment which does not have network access to public CDNs, puppet board can load static assets (jquery, semantic-ui, tablesorter, etc) from the local web server instead of a CDN:
s { 'puppetboard':
fline_mode => true,
by default, puppetboard defaults to “production” environment. This can be set to default to a different environment.
s { 'puppetboard':
fault_environment => 'customers',
or to default to “All environments”:
s { 'puppetboard':
fault_environment => '*',
s { 'puppetboard':
nage_selinux => false,
If you want puppetboard accessible through Apache and you're able to use the
official puppetlabs/apache
Puppet module, this module contains two classes
to help configuration.
The first, puppetboard::apache::vhost
, will use the apache::vhost
defined-type to create a full virtual host. This is useful if you want
puppetboard to be available from http://pboard.example.com:
nfigure Apache on this server
s { 'apache': }
s { 'apache::mod::wsgi': }
nfigure Puppetboard
s { 'puppetboard': }
cess Puppetboard through pboard.example.com
s { 'puppetboard::apache::vhost':
ost_name => 'pboard.example.com',
rt => 80,
The second, puppetboard::apache::conf
, will create an entry in
/etc/apache2/conf.d
(or /etc/httpd/conf.d
, depending on your distribution).
This is useful if you simply want puppetboard accessible from
http://example.com/puppetboard:
nfigure Apache
sure it does *not* purge configuration files
s { 'apache':
rge_configs => false,
m_module => 'prefork',
fault_vhost => true,
fault_mods => false,
s { 'apache::mod::wsgi': }
nfigure Puppetboard
s { 'puppetboard': }
cess Puppetboard from example.com/puppetboard
s { 'puppetboard::apache::conf': }
You can also relocate puppetboard to a sub-URI of a Virtual Host. This is useful if you want to reverse-proxy puppetboard, but are not planning on dedicating a domain just for puppetboard:
s { 'puppetboard::apache::vhost':
ost_name => 'dashes.acme',
gi_alias => '/pboard',
In this case puppetboard will be available (on the default) on http://dashes.acme:5000/pboard. You can then reverse-proxy to it like so:
rect /pboard /pboard/
rseProxy /pboard/ http://dashes.acme:5000/pboard/
yPassReverse /pboard/ http://dashes.acme:5000/pboard/
RedHat/CentOS has restrictions on the /etc/apache directory that require wsgi to be configured to use /var/run.
ass { 'apache::mod::wsgi':
wsgi_socket_prefix => "/var/run/wsgi",
nfigure Apache on this server
s { 'apache': }
s { 'apache::mod::wsgi':
gi_socket_prefix => "/var/run/wsgi",
nfigure Puppetboard
s { 'puppetboard': }
cess Puppetboard through pboard.example.com, port 8888
s { 'puppetboard::apache::vhost':
ost_name => 'puppetboard.example.com',
rt => '8888',
If you would like to use certificate auth into the PuppetDB service you must configure puppetboard to use a client certificate and private key.
You have two options for the source of the client certificate & key:
If you choose option 1, generate the new certificates on the CA puppet master as follows:
puppet cert generate puppetboard.example.com
Note: this name cannot conflict with an existing certificate name.
The new certificate and private key can be found in $certdir/
Here's an example, using new certificates:
_dir = '/var/lib/puppetboard/ssl'
petboard_certname = 'puppetboard.example.com'
s { 'puppetboard':
nage_virtualenv => true,
ppetdb_host => 'puppetdb.example.com',
ppetdb_port => 8081,
ppetdb_key => "${ssl_dir}/private_keys/${puppetboard_certname}.pem",
ppetdb_ssl_verify => "${ssl_dir}/certs/ca.pem",
ppetdb_cert => "${ssl_dir}/certs/${puppetboard_certname}.pem",
If you are re-using the existing puppet client certificates, they will already exist on the node (assuming puppet has been run and the client cert signed by the puppet master). However, the puppetboaard user will not have permission to read the private key unless you add it to the puppet group.
Here's a complete example, re-using the puppet client certs:
_dir = $::settings::ssldir
petboard_certname = $::certname
s { 'puppetboard':
oups => 'puppet',
nage_virtualenv => true,
ppetdb_host => 'puppetdb.example.com',
ppetdb_port => 8081,
ppetdb_key => "${ssl_dir}/private_keys/${puppetboard_certname}.pem",
ppetdb_ssl_verify => "${ssl_dir}/certs/ca.pem",
ppetdb_cert => "${ssl_dir}/certs/${puppetboard_certname}.pem",
Note that both the above approaches only work if you have the Puppet CA root certificate added to the root certificate authority file used by your operating system. If you want to specify the location to the Puppet CA file ( you probably do) you have to use the syntax below. Currently this is a bit of a gross hack, but it's an open issue to resolve it in the Puppet module:
_dir = $::settings::ssldir
petboard_certname = $::certname
s { 'puppetboard':
oups => 'puppet',
nage_virtualenv => true,
ppetdb_host => 'puppetdb.example.com',
ppetdb_port => 8081,
ppetdb_key => "${ssl_dir}/private_keys/${puppetboard_certname}.pem",
ppetdb_ssl_verify => "${ssl_dir}/certs/ca.pem",
ppetdb_cert => "${ssl_dir}/certs/${puppetboard_certname}.pem",
This module is maintained by Vox Pupuli. Voxpupuli welcomes new contributions to this module, especially those that include documentation and rspec tests. We are happy to provide guidance if necessary.
Please see CONTRIBUTING for more details.
Please log tickets and issues on github.