dead code on a box won't make you fail an audit. you can show that build-essential is not in the expanded run_list of any server that matters, you can also write an anti-build-essential recipe that uninstalls it all and show its presence in the expanded run_list on those servers, plus you can audit your servers via "knife ssh '*:*' rpm -q gcc" and such and hand that information over to the auditor. all that should be more than enough proof that you have a working prevent control, and that there's no nodes which need any remediation and everything conforms to policy. beyond that, time is probably "better spent" developing a detect control to alert in nagios or whatever if gcc gets installed on a box rather than worrying about a dead chef recipe copied down because of a depends line sitting on the server.
I disagree. The largest issue I see in having them in the same cookbook is the dependencies they carry. In a security or compliance sensitive environment I may not even want build-essentials on my Chef server, much less on my node (even if it isn't being used). I can see a compelling case for splitting cookbooks when there are large sets of dependencies that are not used by a piece that is useful to many people.
Archive powered by MHonArc 2.6.16.