puppetboard has no explicit SELinux context for httpd

[t-valette]

puppetboard has no explicit SELinux context for httpd

[bschonec]

Would a simple addition of:

selinux::fcontext {'puppetboard':
seltype => 'httpd_sys_content_t',
pathspec => '/srv/puppetboard(/.*)?,
}

suffice if $::puppetboard::manage_selinux is true?

[jhunt-steds]

Would a simple addition of:

selinux::fcontext {'puppetboard': seltype => 'httpd_sys_content_t', pathspec => '/srv/puppetboard(/.*)?, }

suffice if $::puppetboard::manage_selinux is true?

That does make Puppetboard stop throwing 500 Internal Server Error and probably would be enough for most use cases. However, if you're using SSL to connect to PuppetDB on a different server it can't verify the cert, because SELinux doesn't permit Apache to read any of the certs it uses to verify the connection (/etc/puppetlabs/puppet/ssl/certs/ca.pem and the Puppet cert/key for the Puppetboard server e.g. /etc/puppetlabs/puppet/ssl/certs/puppetboard.example.com.pem and /etc/puppetlabs/puppet/ssl/private_keys/puppetboard.example.com), because that file a type of puppet_etc_t. If I copy them someplace that labels them with httpd_sys_content_t instead it does work, so this issue can be worked around, and maybe having Puppetboard on a different server is an edge use case. On the other hand, if you're looking for a one-stop "just works" solution it'd be necessary to either relabel the certs (probably bad) or allow Apache to read files labeled with puppet_etc_t (could have unintended consequences), or I guess make up some new type for the certs and allow both Puppet and Apache to read it. The last one might be out of reach because, I'm guessing, it'd require work from upstream.