Add common pre- and post- agent run action triggered by technique logic
We would like to have some cfengine code shared between more than one version of a technique. This is needed to be able to "merge" common action like restarting a service if its config file was updated, or execute a command to get a common information.For example we would have 3 versions of technique A :
To generate the final content.
After some thought on it (see comments), the chosen solution is to add a notion of run-hooks implemented like that:
- in metadata.xml, we add an optionnal section in <AGENT> with the following parameters: pre or post hook, hook type (service restart, command, variable from command, package), parameters (a list of k/value), condition (a class expression)
- during generation, on a given node, we:
- accumulate pre (post) hooks which differ on type or parameters
- merge (i.e: accumulate reportid, "or" condition) hooks with same type / parameters
- we add the resulting pre (post) hooks in the bundle sequence by mapping them to the corresponding method calls
Note: reports are for all directive registering for a hook. It makes no sense to have a report for only one directive (because in that case, it is not a common code, it's some code specific to one directive that should be defined in the directive logic)
Fixes #11858: Add common pre- and post- agent run action triggered by technique logic
#3 Updated by François ARMAND 9 months ago
Some more precisions:
- this a pre-hook / post-hook general mecanism, need to factor out common actions that need to be done only one time, for a run, for all the directives from the same technique (OR for the whole run for all techniques ?)
- examples are:
- restart a service if it was modified during the run
- visudo edit and replace in one go (NOTE: it may be more logic to have only atomic visudo)
- get all package repository keys (because extremelly long)
- update package list (or any other long running process that need to be done only time per run, and even must be done only one time to have some consistency along the run)
#4 Updated by François ARMAND 9 months ago
Thought iteration +1:
- in fact, we just need a to had a pre-trigger and post-trigger. The triggers come from a new technique standard file, named "action-triggers.json".
- the action-triggers.json contains pre- and post- hook registration
- a hook line is composed of a hook type (service restart, command execution, etc), a condition (a class expression), list of reportIds, and some parameters,
- on node policy generation, we merge all pre- and post-hooks for a node, with some merging logic:
- for a some hook type, with same parameters, we OR class condition and |+| reportId,
- we add the pre- and post- code logic in the standard system bundle list
#7 Updated by François ARMAND 8 months ago
- Description updated (diff)
- Category set to Web - Config management
- Assignee set to François ARMAND
- Target version set to 4.3.0~beta1
Full solution for that problem:
- we need to add a couple of optionnal json file to keep pre-/post-run hooks definition, and use it in technique parsing and policy generation: this ticket with updated description.
- for each hook "kind", we need a corresponding "hook_action-name" ncf method: #11857
- and then, we need to finish #11851 with the correct addition of hooks.
#10 Updated by François ARMAND 8 months ago
We forgot to manage the case where we have two directive with the same hook/parameters (say, "service-restart"), one in "enforce" and the other in "audit".
In that case, we need to "enforce" the restart, but the reporting for the audit directive will be broken (not expecting a change).
So, we need to not only give the reportIds but also the corresponding policy mode (and the method implementation will have to do the case matching when writting reports).