xargs echo: No such file or directory

[dleblanc-vidcruiter]

The shell commands checking /var/ossec/bin/.process_list for client-syslog and ossec-agentlessd appears to not function at least on CentOS 7.6

CentOS Linux release 7.6.1810 (Core)```

This is the output generated by ansible

```TASK [ansible-role-wazuh-manager : Check if client-syslog is enabled] *********************************************************************************************************************************************
fatal: [X.X.X.X]: FAILED! => {"changed": false, "cmd": "\"grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo\"\n", "delta": "0:00:00.009534", "end": "2019-05-29 16:10:24.049119", "msg": "non-zero return code", "rc": 127, "start": "2019-05-29 16:10:24.039585", "stderr": "/bin/sh: grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo: No such file or directory", "stderr_lines": ["/bin/sh: grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo: No such file or directory"], "stdout": "", "stdout_lines": []}

PLAY RECAP ********************************************************************************************************************************************************************************************************
X.X.X.X                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

Specifically this seems to be caused by the changes in this commit id 8291e4ab9fa0317090bc5f0f636d8b40580d640b to the following tasks:

• name: Check if client-syslog is enabled
• name: Check if ossec-agentlessd is enabled

Rolling these 2 blocks back to the version used prior to the above mentioned commit appears to solve the issue and allows me to proceed.

more specifically the error appears to be related to the following as removing these 2 lines from the shell command appears to work

|
    set -o pipefail

using the following changes:

- name: Check if client-syslog is enabled
  shell:
        "grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo"
  args:
    removes: /var/ossec/bin/.process_list
    executable: /bin/bash
  changed_when: false
  check_mode: false
  register: csyslog_enabled
  tags:
    - config

...
- name: Enable client-syslog {{csyslog_enabled}}
  command: /var/ossec/bin/ossec-control enable client-syslog
  notify: restart wazuh-manager
  when:
    - csyslog_enabled.stdout == '0' or "skipped" in csyslog_enabled.stdout
    - syslog_output is defined and syslog_output
  tags:
    - grep_test
    - config

I can see from the trapped csyslog_enabled output that things are working as expected

TASK [ansible-role-wazuh-manager : Enable client-syslog {'stderr_lines': [], u'changed': False, u'end': u'2019-05-29 16:55:45.614948', 'failed': False, u'stdout': u'1', u'cmd': u"grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo", u'rc': 0, u'start': u'2019-05-29 16:55:45.608342', u'stderr': u'', u'delta': u'0:00:00.006606', 'stdout_lines': [u'1']}] ***
skipping: [X.X.X.X]

[jm404]

Hi @dleblanc-vidcruiter ,

Thank you for reporting this. We will test it with older commits as you stated to check if it's related to this lines:

https://github.com/wazuh/wazuh-ansible/blob/8291e4ab9fa0317090bc5f0f636d8b40580d640b/roles/wazuh/ansible-wazuh-manager/tasks/main.yml#L201-L203

Best Regards,

Jose

[rshad]

Hi @dleblanc-vidcruiter,

It's my pleasure to assist you!

Regarding the error you reproted about the commit 8291e4a, I was trying to reproduce it by installing Wazuh manager using ansible using the same repository's commit version.

---

My Attempt Details

Ansible Version

In my case, I'm using ansible 2.8.1

[root@localhost bin]# ansible --version
ansible 2.8.1
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /bin/ansible
  python version = 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]
[root@localhost bin]#

Requested Info: Please advice with ansible version you used when the error got produced

Operating System image I used in my attempt

[root@localhost bin]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@localhost bin]#

I used a similar image of Centos as yours.

In my case, my attempt succeeded without any errors at all. And specifically focusing on both problematic tasks:

1) Check if client-syslog is enabled
2) Enable client-syslog {{csyslog_enabled}}

Both succeeded with status ok: [192.168.0.109] where 192.168.0.109 is the manager host IP.

---

What do the problematic lines are put for ?

As already was mentioned, the main error is produced when reaching the task:

- name: Check if client-syslog is enabled
  shell: |
    set -o pipefail
    "grep -c 'ossec-csyslogd' /var/ossec/bin/.process_list | xargs echo"
  args:
    removes: /var/ossec/bin/.process_list

In this case we set pipefail because all Shell commands that uses pipelining should have pipefail set before getting executed.

Without the pipefail option set, a shell command that implements a pipeline can fail and still return 0. If any part of the pipeline other than the terminal command fails, the whole pipeline will still return 0, which may be considered a success by Ansible. Pipefail is available in the bash shell.

This feature was added in Ansbile-Lint in the rule ID E306. Check more details here

---

It would be great if you provide to us the following information

1. Ansible Version: Ansible version you used when the error got produced
2. User Permissions:Are you sure that the user executing the playbook has the sufficient permissions .
3. Simulating Playbook: Is it possibe to create a test playbook which simulate the problematic task by replacing the file /var/ossec/bin/.process_list with /var/ossec/bin/.test handly created by you. And write ossec-csyslogd into /var/ossec/bin/.test more than once. Try to run this task and let us know about the results.

Kind Regards,

Rshad Zhran

[manuasir]

Hello @dleblanc-vidcruiter ,

We're going to close this issue since it had no activity for the last month. Please, don't hesitate to open a new issue if you consider it.

Cheers