Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add config validation option #27

Open
juju4 opened this issue Oct 17, 2021 · 2 comments
Open

Add config validation option #27

juju4 opened this issue Oct 17, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@juju4
Copy link

juju4 commented Oct 17, 2021

as best practice, executable should have a test/dry-run option to test configuration (syntax and working execution)

Something that can be used for example in ansible template deployment to ensure not deploying broken config
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/template_module.html#parameter-validate

@kesheldr
Copy link
Contributor

kesheldr commented Nov 3, 2021

Okay, if you give us a concrete example of how that could work then I can add that to the list.

@juju4
Copy link
Author

juju4 commented Nov 6, 2021

My main usage is ansible (or any provisioners/CI/CD) but valid for manual admin work too unless blindly deploying.

- name: Copy a new sudoers file into place, after passing validation with visudo
  ansible.builtin.template:
    src: /mine/sudoers
    dest: /etc/sudoers
    validate: /usr/sbin/visudo -cf %s

In my current ansible role, I have

- name: Configure sysmon
  template:
    src: "{{ sysmon_template }}"
    dest: /opt/sysmon/config.xml
    mode: '600'
    backup: "{{ sysmon_backup | default('yes') }}"
  notify:
    - restart sysmon

no validate option native to sysmon.
I could put a xmllint check to validate file is valid xml, eventually test against sysmon dtd (but not available in current package)
this could include also self-check like permissions issue (ssh keys or log target not writable but here more read config, write log file, can load ebpf rules...), dry-run few seconds in foreground to validate can collect few events...

Another example for the systemd hardening, for most tools, I need to run over time to validate work without impact (and supposing relevant activities happen during this...). The more complete the validate/dry-run/self-test is, the easier it can be done.

@MarioHewardt MarioHewardt added the enhancement New feature or request label Mar 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants