Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug/Maintenance in/for configuration templates #158

Closed
zilchms opened this issue Apr 28, 2023 · 1 comment · Fixed by #164
Closed

Bug/Maintenance in/for configuration templates #158

zilchms opened this issue Apr 28, 2023 · 1 comment · Fixed by #164

Comments

@zilchms
Copy link
Contributor

zilchms commented Apr 28, 2023

This is a bug report and a discussion (hopefully) at the same time.
This module offers 2 templates (one .erb and one .epp) for configurations and a parameter in the certificate::x509 class to change the configuration file to be used (defaults to: openssl/cert.cnf.erb). This works perfectly fine as long as one uses the .erb template. However as soon as someone wants to change the path-parameter to use the cert.cnf.epp template instead, syntax errors occure. This is caused by the use of the template function (which does not allow epp template files; the appropriate function for epp-templates would be epp() ).

This bug could surely be fixed by specialcasing based on the file-ending or similar means, but in my opinion this doesnt tackle the underlying issue of how the configuration file is managed. Is there a reason to allow users to exchange templates accross modules?
In my opinion this is bad practice and should someone need a very custom configuration file, we should either expand our template to be generic enough for all use-cases, or the user can generate this file themselfes and pass it through the cnf parameter of the same class. Albeit I am not sure if there should be a check added to only manage the cnf file if the cnf-parameter is empty.
At the same time it seems the templates have diverged in their features and functionalities, this is bad for maintainability.

In my opinion the steps to correct this bug and improve maintainability, we should merge the features of the two templates into one template (probably best done in one .epp template), use the correct function for rendering the template and possibly get rid of the cnf_tpl parameter as cross referencing templates from other modules seems wrong on a very basic level.

In the end there should only exist one template (that provides all functionalities/configuration options a user needs) and all features someone suggest get added to this one template to ensure this is maintainable.

Maybe a maintainer can provide some thoughts, if this would be appreciated? I can provide code/tests and documentation should the changes be wanted.

@zilchms zilchms changed the title Bug/Maintenance Bug/Maintenance in/for configuration templates Apr 28, 2023
@zilchms
Copy link
Contributor Author

zilchms commented May 2, 2023

After gathering some more insight, I would advocate for moving configuration management in the certificates::x509 class from a file resource with the erb template to a openssl::configs resource.
This would remove the last dependency on the cert.cnf.erb template (which could therefore be removed), and would make the cnf_tpl parameter in the certificates::x509 class no longer supported, (but keeps most of the features the parameter can provide by enabling them through the openssl::configs class.

Edit: Maybe we want to make handling the configs similiar to the certificates.pp and the certificates::x509 class? So other modules for example can define configs from a config type?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant