Architecture #12179
Updated by François ARMAND over 6 years ago
Now that we are further on the way, we discover that the current proposal doesn't allow to implement complex pre-run hooks.
Typically, we have in some case in ONE pre-hook:
* several classes matche used to chose a list of commands,
* then, the list of command is executed to raise new clases,
* test for file existense or content and yield more classes,
* based on the final set of classes, build a new command,
* execute the final command once.
Moreover, the JSON content for reporting is missing basic information:
* the technique name,
* the component name to use for the hook,
* the component value to use (or None).
Base on that, we think that we need:
* to evolve the hook XML for technique metadata (see below),
* to evolve JSON output to add in the "reports" parameter the missing values (see ex below).
* to make hook be bundles, and not only generic method. A hook bundle must be out of a technique, because it may be use by several version of a technique (or even several techniques). That "hook bundle library" would be defined in parallel of Techniques, and distributed in each node (nothing private on it, and it will be rather small, with low-frequency evolution).
* simple, generic method-like, hook bundle will be part of that library for the most common needs (typically, service restart, package install). That wrapping bundle will also allows to cleanly manage reporting for the hook (typically, we want a pre-hook to report a specific component value on a service restart different than the one automatically provided by the corresponding generic method),
* with that evolution, the general "condition" parameter of the hook is no more useful. For complexe condition management like the one exposed in introduction, it will be the responsability of the bundle to know what to do in which case. And in generic, simple hook bundle, "condition" can be a parameter.
* we need to choose a naming convention for the hook bundle (to have some kind of namespacing). We propose for now "run_hook_".
New metadata for hooks:
<pre>
<PRE bundle="runhook_package" >
<report name="check_visudo_installed" value="ok"/> // value optionnal, if missing => "None"
<PARAMETER name="package" value="visudo"/>
<PARAMETER name="condition" value="debian"/>
... more parameters ...
</PRE>
</pre>
New output:
<pre>
"pre-run-hook" usebundle => run_hook_package(json)
....
"post-run-hook" usebundle => run_hook_myTechniqueComplexeHook(json)
Where json is:
{
"parameters": { "package": "visudo", "condition": "debian", ... }
, "reports" : [
{ "id": "report id" , "mode": "audit" , "technique":"some technique", "name":"check_visudo_installed", "value":"ok" }
, { "id": "report id" , "mode": "enforce", "technique":"some technique", "name":"check_visudo_installed", "value":"ok" }
, ...
]
}
</pre>