如果 _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.
原因是覆盖此配置的各个部分(例如集群设置)并不容易。 要么全有,要么全无。
换句话说,如果我想在 _group_vars/wazuh_managers.yml_ 中定义这些变量中的 _most_ 并使用 _host_vars/manager01.yml_ 之类的东西覆盖几个设置,那么不修改任务就不容易。
目前,我的每个主机变量在其主机变量文件中都有这个哈希的完整副本,其中更改了一个或两个设置。 看起来不干。 如果大多数常用设置都在一个组变量文件中,并且特定于主机的一两个设置在一个主机变量文件中,那就太好了。
也许有一种方法可以利用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 ,
这真是个好主意。
这种变化是微妙的,需要一种以前的方法来将主要的配置与公共条目分开,然后在一个或多个具有更多可定制条目的配置中分开。
将尽快启动针对此更改的测试。
非常感谢您的合作,非常感谢您的贡献。
最好的祝福,
阿方索·鲁伊斯-布拉沃
@SitoRBJ感谢您的反馈,我完全同意,需要进行测试。 说到这,你们使用Test Kitchen或类似的东西进行测试吗? 如果有一些测试贡献,你们会感兴趣吗?
例如使用 InSpec 的一些基本测试
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0
测试厨房的相关资料:
https://kitchen.ci
你好@paulcalabro ,
我们还没有为 Ansible 使用 Test Kitchen。 请,任何贡献表示赞赏。 如果您想测试,他们非常欢迎。
非常感谢您的关注和帮助,这对我们非常有用。
亲切的问候,
阿方索·鲁伊斯-布拉沃
我的两分钱:
最初,目前的配置看起来有点吓人 TBH,需要用户阅读一大堆行,并且可能还必须通过代理配置模板,才能了解真正发生的事情。
我想知道扁平化配置文件是否可能是一种可能的解决方案——至少是一个短期的解决方案? 例如,为什么在wazuh_agent_config
repo
#$ ? 为什么repo
不能处于顶层? 这样的方法不会简化事情吗?
IMO,一般来说,撤消深度嵌套,将配置文件分成多个部分(不一定创建多个文件,因为这可能会在记住每个文件定义的内容时引入额外的认知开销),并为每个部分和/或特定配置选项添加注释可以使配置文件整体更直观。
关于下一步的任何想法?
谢谢。
大家好。 我提交了一个拉取请求以供审查,该提案提供了类似于 OP 建议的内容,同时保持与角色已经建立的工作方式的兼容性。
欢迎任何反馈,谢谢!
最有用的评论
我的两分钱:
最初,目前的配置看起来有点吓人 TBH,需要用户阅读一大堆行,并且可能还必须通过代理配置模板,才能了解真正发生的事情。
我想知道扁平化配置文件是否可能是一种可能的解决方案——至少是一个短期的解决方案? 例如,为什么在
wazuh_agent_config
repo
#$ ? 为什么repo
不能处于顶层? 这样的方法不会简化事情吗?IMO,一般来说,撤消深度嵌套,将配置文件分成多个部分(不一定创建多个文件,因为这可能会在记住每个文件定义的内容时引入额外的认知开销),并为每个部分和/或特定配置选项添加注释可以使配置文件整体更直观。
关于下一步的任何想法?
谢谢。