stat path meta character and register best practice

Hi,
is it possible to use the stat module with meta characters:

`

  • stat: path=/etc/rc2.d/S*init_script.sh
    register: i

  • debug: msg=“Path is a simlink”
    when: i.stat.islnk

`

Or what is the elegant way of doing the following (without breaking the very useful ‘ansible-playbook --check’ feature):

`

  • name: check init script present
    shell: if test -f /etc/rc2.d/S*init_script.sh ; then echo true; fi
    register: result
    ignore_errors: true
    changed_when: false

  • name: install init script
    shell: /usr/sbin/update-rc.d init_script.sh remove && /usr/sbin/update-rc.d init_script.sh defaults
    when: result.stdout != ‘true’

`

I am trying to configure Debian init script.
Regards.

The stat module cannot take fileglobs, and must check a specific asset.

What you have with the test is probably reasonable.

I just solved this differently by using the creates argument to the shell module. In my opinion you should know the name of the S and K symlinks so a wildcard shouldn’t be necessary. Here’s my approach:

  • shell: update-rc.d myinitscript defaults
    args:
    creates: /etc/rc2.d/S20myinitscript

This will skip the update-rc.d if the symlink already exists. It will actually be skipped if its’ a regular file or a directory too, but I’m not that paranoid. (Or you’d have to check each symlink that you expect to be created.) Test what’s reasonably going to break, that’s my philosophy here.

Regards,
Tore

@Michael:
Thanks for the confirmation about the stat module.
I am migrating from puppet and I must admit that Ansible is winning on lot’s of aspects but these kind of things were a bit more easy/elegant to accomplish with puppet. May we find some work around in the next modules versions.

@Tore:
Interesting approach, I did not knew this shell module option.

But regarding init script I prefer to let lsb directives and update-rc.d tool taking care of the boot/shutdown order. I think this way, it is easier to work with different platforms and above all with big DevOps teams.

I’ll let you know if I find something in between (but I am not going to search too much as systemd is coming :))

Regards,
Faust