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

Reply via email to