_wazuh_manager_config_ハッシュを再構築するか、設定の小さなチャンクを簡単にオーバーライドできるようにコードを変更すると、理想的です。
wazuh_manager_config:
active_responses:
- command: host-deny
level: 6
location: local
timeout: 600
- command: restart-ossec
location: local
rules_id: '100002'
- command: win_restart-ossec
location: local
rules_id: '100003'
alerts_log: 'yes'
api:
basic_auth: 'yes'
behind_proxy_server: 'no'
bind_addr: 0.0.0.0
ciphers: ''
drop_privileges: 'true'
experimental_features: 'false'
honor_cipher_order: 'true'
https: 'no'
https_ca: ''
https_cert: /var/ossec/etc/sslmanager.cert
https_key: /var/ossec/etc/sslmanager.key
https_use_ca: 'no'
port: 55000
secure_protocol: TLSv1_2_method
use_only_authd: 'false'
authd:
enable: true
force_insert: 'yes'
force_time: 0
port: 1515
purge: 'no'
ssl_agent_ca: null
ssl_auto_negotiate: 'no'
ssl_manager_cert: /var/ossec/etc/sslmanager.cert
ssl_manager_key: /var/ossec/etc/sslmanager.key
ssl_verify_host: 'no'
use_password: 'no'
use_source_ip: 'yes'
...etc. etc. etc.
その理由は、この構成の個々の部分(クラスター設定など)をオーバーライドするのは簡単ではないためです。 それはすべてか無かです。
言い換えると、これらの変数の_most_を_group_vars / wazuh_managers.yml_で定義し、_host_vars / manager01.yml_のようなものを使用していくつかの設定をオーバーライドしたい場合、タスクを変更しないと簡単にできません。
現在、私の各ホスト変数には、1つまたは2つの設定が変更された、ホスト変数ファイルにこのハッシュの完全なコピーがあります。 乾燥していないようです。 一般的な設定のほとんどがグループ変数ファイルにあり、ホストに固有の1つまたは2つの設定がホスト変数ファイルにあると便利です。
combine
フィルターを活用して、より大きな構成の一部を簡単にオーバーライドできるようにする方法があるかもしれません。
例えば{{ {'a':{'foo':1, 'bar':2}, 'b':2} | combine({'a':{'bar':3, 'baz':4}}, recursive=True) }}
出力:
{'a':{'foo':1, 'bar':3, 'baz':4}, 'b':2}
(出典:https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#combining-hashes-dictionaries)
こんにちは@paulcalabro 、
これは本当に良い考えです。
この変更は微妙であり、共通のエントリを使用してメインの構成を分離し、さらにカスタマイズ可能なエントリを使用して1つまたは複数の構成を分離できるようにするには、以前のアプローチが必要です。
この変更のテストは、できるだけ早く開始されます。
コラボレーションありがとうございました。あなたのような貢献に感謝します。
よろしくお願いします、
Alfonso Ruiz-Bravo
@SitoRBJフィードバックをありがとう、そして私は完全に同意します、テストが必要です。 そういえば、テストキッチンなどを使ってテストしていますか? いくつかのテストの貢献があれば、皆さんは興味がありますか?
たとえば、InSpecを使用したいくつかの基本的なテスト
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0
テストキッチンに関する情報:
https://kitchen.ci
こんにちは@paulcalabro 、
まだAnsible用のTestKitchenを使用していません。 どうぞ、どんな貢献でも大歓迎です。 テストをご希望の場合は、大歓迎です。
ご関心をお寄せいただき、誠にありがとうございます。大変参考にさせていただきます。
敬具、
Alfonso Ruiz-Bravo
私の2セント:
当初、構成は現在のところ、少し威圧的なTBHに見えます。ユーザーは、実際に何が起こっているのかを理解するために、一連の行全体を読み通す必要があり、エージェント構成テンプレートも確認する必要があります。
構成ファイルをフラット化することが可能な解決策になるかどうか疑問に思っていました-少なくとも短期的な解決策ですか? たとえば、なぜrepo
がwazuh_agent_config
の下にあるのですか? repo
がトップレベルになれないのはなぜですか? そのようなアプローチは物事を単純化しませんか?
IMOは、一般に、深いネストを元に戻し、構成ファイルをセクションに分割し(ファイルごとに定義されたものを記憶する際に余分な認識オーバーヘッドが発生する可能性があるため、必ずしも複数のファイルを作成する必要はありません)、セクションごとのコメントや特定の構成オプションを追加できます。構成ファイルを全体的に直感的にします。
次のステップに関するアイデアはありますか?
ありがとう。
こんにちは、みんな。 私は、役割のすでに確立された作業方法との互換性を維持しながら、OPが提案したものと同様の何かを提供する提案を含むプルリクエストをレビューのために提出しました。
フィードバックは大歓迎です、ありがとう!
最も参考になるコメント
私の2セント:
当初、構成は現在のところ、少し威圧的なTBHに見えます。ユーザーは、実際に何が起こっているのかを理解するために、一連の行全体を読み通す必要があり、エージェント構成テンプレートも確認する必要があります。
構成ファイルをフラット化することが可能な解決策になるかどうか疑問に思っていました-少なくとも短期的な解決策ですか? たとえば、なぜ
repo
がwazuh_agent_config
の下にあるのですか?repo
がトップレベルになれないのはなぜですか? そのようなアプローチは物事を単純化しませんか?IMOは、一般に、深いネストを元に戻し、構成ファイルをセクションに分割し(ファイルごとに定義されたものを記憶する際に余分な認識オーバーヘッドが発生する可能性があるため、必ずしも複数のファイルを作成する必要はありません)、セクションごとのコメントや特定の構成オプションを追加できます。構成ファイルを全体的に直感的にします。
次のステップに関するアイデアはありますか?
ありがとう。