no-re...@cfengine.com wrote: > Forum: Cfengine Help > Subject: Re: Cfengine Help: Re: Managing user accounts with Cfengine 3 > Author: neilhwatson > Link to topic: https://cfengine.com/forum/read.php?3,21099,21109#msg-21109 > > CPAN's search features are what I'd like to see. It saves countless hours of > Perl hacking when you can search CPAN to see modules that do just what need > along with usually sufficient documentation. > > In Cfengine context one might search for 'Red Hat services' and see bundles > that might use chkconfig or service for audits or actions. The searcher > could then download the bundles and fit into their policy. CPAN is the > published state of a module. Maintainers keep the modules however they do. > It is not a repository like github. I suppose it could be but is the > management worth it? > > Mark is working on something so I'm content to wait on that for now.
And this raises another interesting issue about potentially misleading way of understanding. At a multi-OS site, even thinking "Red Hat services" or "chkconfig" can actually be misleading and can lead to poor practice. At a multi-OS site I actually should _not_ be thinking about wanting a bundle that does "chkconfig FOO". That's the wrong way up. Rather I should be thinking about wanting a bundle that "enables service FOO". Then when I install that bundle, it _itself_ will work out that our machines A, B and C are Redhat (therefore decide _internally_ to employ "chkconfig" as the local technology) whereas our machines P, Q and R are Solaris (therefore employ Solaris's appropriate technology) and finally machines our X, Y and Z are Yet-Another-UN*X (and again employ existing technology provided by that OS). This is part of trying to ensure that the invented wheels are as round as possible across the range of likely usage, not merely that they are something vaguely round-ish enough for the author's limited context. Which heads back towards some sort of peer-review system for quality and "good practice" validation (rather than simply a free-for-allcomers drop-area) for items in such a collection. Remember, if a particular example happens to work but is poorly implemented, then new users writing local things might start adopting bad habits from those poor examples. So while a generally "open to all suggestions" policy would be great, there should be at least a small amount of gatekeeping by some of the established developers. -- : David Lee (ECMWF) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine