We implemented Puppet as a configuration management system at \$work ,  and Puppet is a great tool. Then I heard about some dashboards that could be used on top of it. I've heard about different dashboards (\$management_people *like* dashboards) like Puppet-dashboard and Foreman.

I was advised by several people to give Foreman a try and it's really simple to install. Their wiki covers basic installation and there is even ayum repo that can be used (Epel has to be enabled too). As i have a small network to manage, I decided to setup Foreman on the same host as puppetmaster. Configuring /etc/foreman/* is easy and missing parts can be configured just by looking at the Foreman website wiki/FAQ. But troubles came when I enabled reports : puppetmasterd config was changed to include :

[master]
reports = store, foreman

and the foreman.rb script (copied and modified from /usr/share/foreman/extras/puppet/foreman/templates/foreman-report.rb.erb) integrated in the correct /usr/lib/ruby/site_ruby/1.8/puppet/reports dir. (Note : don't forget to update \$foreman_url).

But no reports were coming in Foreman. hmmm .... error message was :

Report foreman failed: Could not send report to Foreman at http://puppetmaster.mybeautifuldomain.com:3000/reports/create?format=yml: Permission denied - connect(2)

That was not an iptables issue, but selinux one :

type=AVC msg=audit(1329830711.788:28372): avc:  denied  { name_connect } for  pid=13144 comm="puppetmasterd" dest=3000 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket

Here is my locally generated selinux for Foreman :

module foreman 1.0;

require {
type puppetmaster_t;
type http_port_t;
type ntop_port_t;
class tcp_socket name_connect;
}

#============= puppetmaster_t ==============
allow puppetmaster_t http_port_t:tcp_socket name_connect;
allow puppetmaster_t ntop_port_t:tcp_socket name_connect;

Things work really better after I added my foreman.pp selinux module on that host. If you don't know how to compile selinux custom policies, please read the nice Selinux page on the CentOS wiki, and especially the "Manually customizing selinux policies" section. Tools like sealert (from setroubleshoot-server package) and audit2allow are really helpful when there is no pre-defined selinux boolean that can be used.

Hope this helps .. and now going back enjoying reports, including error reports by mail (nice feature)