Do not provide example integrations as classes

[smortex]

The module configure PuppetBoard, but also has classes to setup Apache
configuration to serve it. Unfortunately, such configuration is very
site specific, and providing it in the module confuse users who discover
that their setup is exposed to the internet without authentication.

At some point, LDAP authentication was added which partially fix the
issue, but only for users who can authenticate their users with LDAP.

It is also quite common to use the Puppet CA to authenticate clients,
or use Passenger instead of wsgi, or use another web server than apache,
and any combination of this, making a generic solution not viable.

Remove all these apache-specific examples from the module classes, and
provide examples configuration for different setups. It will be easier
to add new integration examples by just dropping more files in the
example directory, without cluttering the module with complex mostly
private code.

[smortex]

Hopefully this will help to avoid the number of PuppetBoard instances exposed on the Internet to continue to be so common. Here is a report from shodan for the trend of the number of results for the search "http.title:puppetboard"

[paran1]

Do not provide example integrations as classes

The title implies that you are only removing examples. That is not correct, they are fully usable.

The module configure PuppetBoard, but also has classes to setup Apache
configuration to serve it. Unfortunately, such configuration is very
site specific, and providing it in the module confuse users who discover
that their setup is exposed to the internet without authentication.

I installed puppetboard first time last week and was very happy that these classes where provided and think removing them would be very unhelpful. The module should have at least one easy way to get the puppetboard up and running.

The added documented examples here would instead suggest I add a ton of code to my manifests, which is much more work.

If users get surprised that a Puppet module to install a web application makes said web application available to the web, they probably have bigger issues. If this is a concern then maybe change the default to only accept connections from localhost unless some parameter is given?

Also this is not a security concern for everybody. My server running puppetdb and pupeptboard on a network behind several firewalls.

It is also quite common to use the Puppet CA to authenticate clients,
or use Passenger instead of wsgi, or use another web server than apache,
and any combination of this, making a generic solution not viable.

The apache classes are optional. Those with more complex requirements will simply not use them.

That a super generic solution is not possible is not a good reason to not provide a minimal working config.

Remove all these apache-specific examples from the module classes, and
provide examples configuration for different setups. It will be easier
to add new integration examples by just dropping more files in the
example directory, without cluttering the module with complex mostly
private code.

Before they were examples. Now they are compex and "mostly private". Don't know what you mean by private. They are definiely not very complex.

Having the apache classes does not prevent adding documentation for more complex use cases.

[paran1]

Is there any way to know how many are using the included classes?