On 18-02-11 00:03, [email protected] wrote: > This is an interesting discussion. > > In principle I agree with Neil that this could potentially be a big security > concern. On the other hand, it's a potentially very useful technique, which > is already used in the form of /etc/cron.d/, /etc/path.d/, > /etc/apache2/modules.d/, and many other tools that make use of a generic > "include" directory. This makes it possible for different components to "plug > themselves" into some other piece of the system simply by dropping a file > somewhere. What I'm envisioning is the day when Unix and Linux systems come > cfengine-enabled by default, and as you install different packages, they > could put their configuration policies in /var/cfengine/inputs.d/ or > something like that to be automatically handled and configured by cfengine. > > Of course, a cfengine policy is hardly a generic thing, so care still needs > to be taken to ensure that the content of the policies actually reflects what > we want from the system. But that is true as well for any of those other > components. > > Youe are right a lot of Unix/Linux tools allow to import files from a directory. The idea of that different packages could put their configuration policies in a directory is nice one. It will still be difficult to automate it, because you have to add it to your bundlesequence or use it as method in configuration file.
It would be nice if a package adds a cfengine conmfiguration bundle that can be used as an library like (COPBL). For example to rotate files with cfengine instead of logrotate or check if the daemons are running. -- ******************************************************************** * Bas van der Vlies e-mail: [email protected] * * SARA - Academic Computing Services Amsterdam, The Netherlands * ******************************************************************** _______________________________________________ Help-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/help-cfengine
