Project

General

Profile

Actions

Bug #10580

closed

Cannot mix audit/enforce mode on directives based on the same technique

Added by Rémi Verchère about 7 years ago. Updated almost 6 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Web - Config management
Target version:
-
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Very large
Priority:
25
Name check:
Fix check:
Regression:

Description

I'm trying to do the following:

- Use the global audit mode
- Having a directive based on the technique "File download (Rudder server)", inherited from the global audit mode
- Having a second directive based on the same technique, but enforced

Issue occurs when trying to update directives, with the following error:

Inconsistant policy mode: both audit and enforce applied

When the 2 directives have the same audit/enforce mode, I do not have this issue.


Related issues 4 (0 open4 closed)

Related to Rudder - Architecture #10625: Don't merge directive from same technique on generationReleasedVincent MEMBRÉActions
Related to Rudder - Bug #2736: We can't apply Directives from different versions of the same Technique on a nodeRejectedActions
Has duplicate Rudder - Bug #10666: Creating a directive in audit mode generates an errorRejectedActions
Is duplicate of Rudder - User story #11851: Port techniques to multi-versionned formatReleasedActions
Actions #1

Updated by François ARMAND about 7 years ago

  • Related to Architecture #10625: Don't merge directive from same technique on generation added
Actions #2

Updated by François ARMAND about 7 years ago

Unfortunally, this is a limitation of the current implementation of directives. To make that works, we need to solve #10625 before. This is a known pain point, we are working on it by small bit :/

Actions #3

Updated by François ARMAND almost 7 years ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
  • Effort required set to Very large
Actions #4

Updated by François ARMAND almost 7 years ago

  • Related to Bug #2736: We can't apply Directives from different versions of the same Technique on a node added
Actions #5

Updated by Jonathan CLARKE almost 7 years ago

  • Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
  • Priority changed from 0 to 30
Actions #6

Updated by François ARMAND almost 7 years ago

  • Has duplicate Bug #10666: Creating a directive in audit mode generates an error added
Actions #7

Updated by François ARMAND almost 7 years ago

A "workaround" is to have different technique for Audit and Enforce.

For a technique built with the technique editor, it means "clone" it.
For a technique for the technique library, you will have to do the following step (with for example the "package management" technique):

cd /var/rudder/configuration-repository/techniques/applications/
cp -r packageManagement packageManagementAudit
# here you can delete all versions but the last one with
# $ rm -rf newTechniqueNameForAudit/1.0 newTechniqueNameForAudit/2.0
# but packageManagement has only one version, so no need for it.  
sed -ie "s/Package management/Package management For Audit/g" packageManagementAudit/1.0/metadata.xml
git add packageManagementAudit/
git commit -m "Add a dedicated package management for audit" 
rudder server reload-techniques

And then, you can use the "Package management For Audit" for audit, and the "Package management" for enforce.

So the remaining question is how about "migrating" a directive from the audit to enforce technique, if you want to do so, whithout having to copy/paste all fields.
As the two techniques have exactly the same parameters, you will be able to do it with the API:

#you can find the directive id in the directive "technical details" part (hidden by default, under "technique version")
# "jq" is a litte, powerful utility that allows to select part of a json document: http://stedolan.github.io/jq/manual/
curl -k -H "X-API-Token: yourAPItoken" -H "Content-Type: application/json" -X GET 'https://your-rudder/api/latest/directives/the-directive-id' | jq ".data.directives[0]" > mydirective.json
# edit mydirective to:
# - delete the 2nd line with the id: "id": "the-directive-id",
# - change the line with "techniqueName" to use the id of the technique ID, which is the name of the directory used in the "cp -r" above 
#   (in the example, from "packageManagementAudit" to "packageManagement")
# - adapt displayName, shortDescription, longDescription if needed
# then create the new directive: 
curl -k -H "X-API-Token: yourAPItoken" -H "Content-Type: application/json" -X PUT 'https://your-rudder/api/latest/directives' -d"@mydirective.json" 
# you should get an answer looking like: 
# {"action":"createDirective","result":"success",.... }

# and if you want to update an already migrated directive from an updated source, you can use a similar procedure as above to retrieve 
# the source directive, but only keep the "parameters" part with a different jq filter (which is the only part you want to update on that example):
curl -k -H "X-API-Token: yourAPItoken" -H "Content-Type: application/json" -X GET 'http://your-rudder/rudder-web/api/latest/directives/8434c259-da5b-4b34-8e7d-1ae281c37acf' | jq '{"parameters": .data.directives[0].parameters}' > mydirective.json
# and update the migrated directive, after you retrieved it's id with in the UI:
curl -k -H "X-API-Token: yourAPItoken" -H "Content-Type: application/json" -X POST 'http://your-rudder/api/latest/directives/migrated-directive-id' -d"@plop5.json" 
# response:
# {"action":"updateDirective","id":"d3ff1811-e4e3-42e4-a3bb-c6aa5b1342d1","result":"success" ....

We do know that the process are cumbersome, tedious and error prone, and we are very sorry for that, but we wanted to allow users to at least have a workaround. The real solution is of course to correct the root problem described in the ticket.

Actions #8

Updated by Hamlyn Mootoo almost 7 years ago

The text substitution indicated above (sed -ie "s/Package management/Package management For Audit/g" packageManagementAudit/1.0/metadata.xml) does not seem to have the intended effect of naming the package differently in the GUI. This sed statement does not find a match in matadata.xml.

Actions #9

Updated by François ARMAND almost 7 years ago

Oh sorry, it may depends of the technique library version. The most robust way to do it it to change the <displayName> content to match your wishes.

Actions #10

Updated by Benoît PECCATTE almost 7 years ago

  • Priority changed from 30 to 29
Actions #11

Updated by Hamlyn Mootoo almost 7 years ago

I tried actually duplicating techniques as you suggested, but I get errors. For example, using the file content technique, I duplicated it and got:

Policy update error for process '188' at 2017-06-26 17:05:12 
⇨ Cannot write configuration node
⇨ Exit code=1 for hook: '/opt/rudder/etc/hooks.d/policy-generation-node-ready/10-cf-promise-check'.
stdout:
stderr: '/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContentAudit/7.0/checkGenericFileContent.cf:23:0: error: Duplicate definition of bundle check_generic_file_content with type agent
/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContentAudit/7.0/checkGenericFileContent.cf:360:0: error: Duplicate definition of bundle check_generic_file_content_edition with type edit_line
/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContentAudit/7.0/checkGenericFileContent.cf:451:0: error: Duplicate definition of bundle check_generic_file_content_edition_in_zone with type edit_line
/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContent/7.0/checkGenericFileContent.cf:23:0: error: Duplicate definition of bundle check_generic_file_content with type agent
/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContent/7.0/checkGenericFileContent.cf:343:0: error: Duplicate definition of bundle check_generic_file_content_edition with type edit_line
/var/rudder/share/34d86720-f7ed-44e5-8249-a4749eb74e02/rules.new/cfengine-community/checkGenericFileContent/7.0/checkGenericFileContent.cf:434:0: error: Duplicate definition of bundle check_generic_file_content_edition_in_zone with type edit_line
Actions #12

Updated by Benoît PECCATTE almost 7 years ago

  • Category set to Web - Config management
Actions #13

Updated by Hamlyn Mootoo almost 7 years ago

I believe this was actually working okay with 4.1.3 (making a copy of the technique as described above). When I upgraded to 4.1.5, I believe it broke.

Actions #14

Updated by Hamlyn Mootoo almost 7 years ago

After some more testing I determined that if I remove the Audit version of the technique from git, commit it, delete the Audit version from the directory, re-copy from the original, and re-commit in git, and reload the techniques, then it starts working again. Is there an easier way?

Actions #15

Updated by Hamlyn Mootoo almost 7 years ago

After more extensive testing, it seems that even what I mentioned above does not work reliably.

Actions #16

Updated by Nicolas CHARLES almost 7 years ago

Hi Hamlyn,

simply duplicating the technique would not be enough, you'd need to:
  • change names of all bundle common, bundle agent, bundle edit_line and body * in the duplicated technique
  • edit the metadata.xml to replace the name in BUNDLES/NAME by the replacement made in previous point
Actions #17

Updated by Benoît PECCATTE over 6 years ago

  • Priority changed from 29 to 27
Actions #18

Updated by Alexis Mousset almost 6 years ago

  • Status changed from New to Rejected
  • Priority changed from 27 to 25

Since 4.3 it is possible with most techniques in latest version. See #11851 to track this migration, closing this ticket as duplicate.

Actions #19

Updated by Alexis Mousset almost 6 years ago

  • Is duplicate of User story #11851: Port techniques to multi-versionned format added
Actions

Also available in: Atom PDF