On Behalf Of Tim Nelson > The above makes sense to me. But say I have things > that are in a > particular order at the moment, how will I be able to ensure > that they're > still ordered with cfengine 3?
Just throwing something out here, but if the system state is dependant on a particular ordering, doesn't that say something about the convergence of those rules? I guess what I'm saying is: "Why does ordering matter in a convergent system?"[0] -- we know we'll run the shellcommands sometime during the next cfengine pass/invocation (to restart inetd, for example). Convergence guarentees that after this pass, the system will be in a "better" configuration. The trouble comes in that state is not preserved across cfengine invokations. The restart_inetd class that's defined when you editfiles /etc/inetd.conf won't be defined the next time cfengine runs. So one option for cfengine3 could be to preserve more state, and have actions explicitly clear that state... idea: classes that are defined by an action (using the new "set" keyword) are kept until they are cleared. (this might be implemented by a state DB or by giving them to cfenvd) <conceptcode> editfiles: { /etc/inetd.conf AppendIfNoSuchLine "#Hello World" set=restart_inetd } shellcommands: restart_inetd:: "/etc/init.d/inetd restart" clear=restart_inetd </conceptcode> --Joe [0] Traugott et al.'s http://www.infrastructures.org/papers/turing/turing.html notwithstanding _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine