Need ability to not automatically configure jdbc.

[kbaltrinic]

The current default cookbook automatically configures JDBC. This is problematic in that it requires that the password be placed in a node attribute, making it visible anyone who can run node searches with knife.

I have attempted to simply leave the attributes at their default and set the real password elsewhere but this results in a tug-o-war where the default recipe sets one value then my cookbook sets another value. This causes the sonar.conf file to change on every chef run and hence the service gets restarted every chef run.

This is a simple enough issue that I can send in a PR for it, but before I do that, what would be preferred:

1. Simply remove this code from the default recipe and require that people call the jdbc resource themselves. (I prefer this because I think it is the only option that really makes sense in a production environment.) This also implies the the default jdbc attributes can be removed. Implementors can pick whatever means they want to get the needed values (chef-vault for instance).
2. Add logic to skip the jdbc configuration if the ['sonarqube']['jdbc'] attribute is nil.
3. Add an additional attribute that acts as a flag to turn this functionality on or off.

[pghalliday]

Would it make sense to add an LWRP to set the JDBC params?

What I usually do is set passwords in encrypted data bags and then override the node attributes in a parent cookbook. I'm guessing that this still exposes them through node searches though? Adding an LWRP would allow the same kind of approach without setting node attributes (only LWRP attributes).

I must admit I haven't used node searches much but wouldn't LWRP attributes also be searchable? In which case neither of our approaches is good as you will still use a resource in another recipe to generate the config.

[kbaltrinic]

So now I am confused. Admittedly I am a bit unclear as to the difference between an LWRP and a regular resource, but the cookbook has a JDBC resource already so I don't follow what a new JDBC resource would do distinct from the existing one. To my mind, all that is needed is to not invoke the current resource as part of the default recipe but invoke it in a separate optional recipe and we're done. This way no one needs to set or use the node attributes. They can still use the resource by directly providing values from a data_bag or chef vault or from wherever. All the existing tests and such would need to be updated to run both the default recipe and the new one, but otherwise I think it would be good to go. If you would like I can submit a PR for this (though it may be a week or so for me to get to it) to demonstrate my thinking.

[pghalliday]

ok i missed that - you're right, i already created an LWRP. Also I just had a look around and I don't think resource attributes are exposed like node attributes so this would work. I think you're right I shouldn't be putting sensitive data in node attributes. This is what encrypted data bags (or Chef Vault) are for. I think you're right about the solution. By the way I also do the same in the sonarqube-mysql cookbook default recipe which I now think should also be converted to an LWRP to avoid the use of node attributes

[willmanio]

Closing due to inactivity.