Exactly - this is the way to do it now. Or... to realize that you can usually rewrite your config so that order does not matter.
M
Quoting Brendan Strejcek <[EMAIL PROTECTED]>:
Moore, Joe wrote:
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)
An interesting idea. One could think about this as exceptions that can be raised during one cfagent run and handled in a subsequent run.
We might be able to do this now with:
SetState("preserved_class",10,Preserve) SetState(non_preserved_class,60,Reset) UnsetState(myclass)
(See http://www.cfengine.org/docs/cfengine-Reference.html#alerts )
All those are used in the "alerts" sections, which would just be weird to use for what you discuss above, not in the least because "alerts" is one of those magic non-actionsequence actions.
_______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
_______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
