User story #9351
closed
User story #1808: Add an Audit mode to Rudder: only check properties, no modification on nodes
User story #7219: Add dry-run support to system techniques
Create a dedicated abort report when enforce is used in place of audit
Description
We must take into account the case where for an unknown reason (read: bug), the agent start to do "enforce" action where it should do "audit" one.
In that case, the agent must abort the remaining of the run (fails early and prevent further potential unwanted modification).
In that case, a report message must be produce and then special cased in the compliance calcul to explain to the user the problem.
So, we need to choose the message type.
I mainly see two possibilities:
- an error message (type = reulst_error) for a new component on common, with a dedicated message
- a log_info message, like startRun / endRun
In fact, what we would want to have is a "run_info" type (or "meta", or "protocol", or "control" which would be user in place of "log_info" for meta reporting about the run itself, and not the policies. So in that regard, "log_info" seem better than error.
Or perhaps we could have log_info, but on a dedicated component like "runinfo" ?
For information, this is start run / end run ex
rudder=> select * from ruddersysevents where executiontimestamp = '2016-10-13 10:35:59+02' and keyvalue in ('StartRun', 'EndRun');
id | executiondate | nodeid | directiveid | ruleid | serial | component | keyvalue | executiontimestamp | eventtype | policy | msg
----------+-------------------------------+--------+-------------+----------------------+--------+-----------+----------+------------------------+-----------+--------+-----------------------------------------
25278594 | 2016-10-13 10:36:52.457596+02 | root | common-root | hasPolicyServer-root | 254 | common | EndRun | 2016-10-13 10:35:59+02 | log_info | common | End execution with config [747884874]
25278478 | 2016-10-13 10:36:03.659206+02 | root | common-root | hasPolicyServer-root | 254 | common | StartRun | 2016-10-13 10:35:59+02 | log_info | common | Start execution with config [747884874]
(2 lignes)
Files
Updated by François ARMAND about 8 years ago
- Tracker changed from Bug to User story
Updated by Nicolas CHARLES about 8 years ago
- Related to Bug #9332: If we are in audit mode, and agent does not support audit, the web interface shows "No answer" for this node added
Updated by François ARMAND about 8 years ago
- Translation missing: en.field_tag_list set to Blocking 4.0
Updated by Nicolas CHARLES about 8 years ago
- log_info report are not displayed in the output by command rudder agent run, so we'd need to update the rudder agent run output (so for old agents it won't show up)
- this is probably important to show the message to the user, even with old rudder agent command - so we'd need to have a result_error report, and so a new component (so new reports in case of success also)
Updated by Benoît PECCATTE about 8 years ago
Why not a new key instead of a new component
Updated by François ARMAND about 8 years ago
The idea of the new component was to be able to process all that kind of messages (abort, start/end run, why not tomorow report format version or compression) in a different way than policy one, because semantically they are related to the protocol about what is a Rudder agent run - and we should have them whatever the agent is.
For the displaying to the user... In fact I believe it's a good think to not display that to the user like other policy check are, because (again :) semantically, it is not the same thing. So we should special case the displaying of that information, like we special cased the information about what config version is run. And as thing are well and good on that world, we are already just doing that with a big message :)
So for now, we will just add a new "common / log_info", and in a future version, we will migrate all the meta-log_info toward a new component home.
Updated by François ARMAND about 8 years ago
To be clearer, we are going to have:
- a log_info message, that will be hidden from the console output when run interactively (i.e: filtered by "rudder agent run"), but will be processed by the policy server for compliance processing,
- PLUS a special big message, not necessary in log format, always show by "rudder agent run" (i.e even without the -i option), to inform the user that an abort happened.
Updated by Nicolas CHARLES about 8 years ago
François ARMAND wrote:
To be clearer, we are going to have:
- PLUS a special big message, not necessary in log format, always show by "rudder agent run" (i.e even without the -i option), to inform the user that an abort happened.
rudder agent run command filters out everything that is not a Rudder report - so old agent have no way to display, without the -i option, a big message (unless we update the rudder agent run command, but then, it's not an old agent anymore, so we don't need the message)
That leaves us with only a report "result_error" to display to the user that he is trying to do audit on a non-compatible agent
Updated by Nicolas CHARLES about 8 years ago
- File Capture du 2016-10-17 12_47_51.png added
After some thoughts, we realized there is an issue with abort in ncf: we cannot generate a valid Technique system report in ncf (we don't really have at hand the trackingvariable of technique common, unless we do some super hackish stuff - and there is no way to bubble back the abort in Rudder)
Plus we'd like to have a coherent semantic for all "internal parts" of the agent, like:- correct usage of audit on audit compatible agent
- update
- ncf initialisation
etc etc
which could report on the summary of agent, and could be correctly parsed on the web interface
For the record, here is the output of the agent if aborted because using audit in non audit compatible system
Updated by Nicolas CHARLES about 8 years ago
- File deleted (
Capture du 2016-10-17 12_47_51.png)
Updated by Alexis Mousset about 8 years ago
In #9420 we added:
rudder_common_report("Common", "log_info", "&TRACKINGKEY&", "Abort run", "${reason}", "${message}");
with reason being:
unsupported_dryrunrepaired_during_dryrun
depending on the cause of the abort.
Updated by François ARMAND about 8 years ago
- Status changed from New to In progress
- Assignee changed from Benoît PECCATTE to François ARMAND
Updated by Alexis Mousset about 8 years ago
- Assignee changed from François ARMAND to Alexis Mousset
Updated by Alexis Mousset about 8 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Alexis Mousset to Benoît PECCATTE
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/1067
Updated by Alexis Mousset about 8 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset rudder-techniques|15d89e7ef024466d9489148459401ffe9d8fd17e.
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 4.0.0~rc2 to 4.0.0~rc1
Updated by Alexis Mousset about 8 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 4.0.0 which was released the 10th November 2016.
Updated by Vincent MEMBRÉ almost 7 years ago
- Related to Bug #9521: If we are in non-compliance only report mode, we don't get the wrong mode error message, and node in is "no answer" in the interface added