zilchms
commented
1 year ago 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?
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.