Incompatible Ansible version detected on Stretch

[ganto]

I'm sorry to bring this up again, but here my experience with a fresh installed Debian Stretch:

TASK [Check for Ansible version without known vulnerabilities] *****************
fatal: [default -> localhost]: FAILED! => {
    "assertion": "((ansible_version.minor == 2) and (ansible_version.full | version_compare(\"2.2.2.0\", \">=\"))) or (ansible_version.minor != 2)", 
    "changed": false, 
    "evaluated_to": false, 
    "failed": true, 
    "msg": "VULNERABLE or unsupported Ansible version DETECTED, please update to Ansible >= v2.1.5 or a newer Ansible release >= v2.2.2! To skip, add \"--skip-tags play::security-assertions\" parameter. Check the debops-playbook changelog for details. Exiting."
}

$ ansible --version        
ansible 2.2.1.0                                                                                                                                                                                                                               
  config file = /home/vagrant/vagrant-debops/ansible.cfg                                                                                                                                                                                      
  configured module search path = ['/home/vagrant/vagrant-debops/ansible/library', '/home/vagrant/.local/share/debops/debops-playbooks/playbooks/library', '/usr/share/ansible/library']  

$ apt-cache show ansible
Package: ansible
Version: 2.2.1.0-2
Installed-Size: 12494
Maintainer: Harlan Lieberman-Berg <hlieberman@debian.org>
Architecture: all
Depends: python-crypto (>= 2.6), python-jinja2, python-paramiko, python-pkg-resources, python-yaml, python:any (<< 2.8), python:any (>= 2.7.5-5~), python-httplib2, python-netaddr
Recommends: python-kerberos, python-selinux, python-winrm (>= 0.1.1), python-xmltodict
Suggests: cowsay, sshpass
Description: Configuration management, deployment, and task execution system
Description-md5: db2b21b0d2286fccc4401d5982361488
Homepage: https://www.ansible.com
Tag: admin::automation, admin::configuring, admin::file-distribution,
 admin::package-management, implemented-in::python,
 interface::commandline, role::program, use::configuring,
 works-with::software:running
Section: admin
Priority: optional
Filename: pool/main/a/ansible/ansible_2.2.1.0-2_all.deb
Size: 1674706
MD5sum: b824617ab20ad46f75f8d4f3833fed1f
SHA256: 16b3211df8d7b76de08bff06ba733d6a748f99475aa00f365ed1eadc69f33fa7

The comment in 789e342bcbf4808d65fe9fb56d329ddcc334d4a3 says, that this is due to role incompatibilities? Any more info on which role/task is not working with stock Ansible?

[drybjed]

I don't remember at the moment, sorry. I think that it was an issue related to templating, so maybe that Ansible and Jinja combination? I guess running the playbook with an override for this check would show the culprit.

[ganto]

Hmn, I guess I found the issue (btw. happens also on Debian Jessie with the backports version 😞), it's (at least) in debops.ferm, most likely also other roles:

TASK [debops.ferm : Remove firewall rules] *************************************
task path: /home/vagrant/.local/share/debops/debops-playbooks/roles/debops.ferm/tasks/main.yml:86
fatal: [webmail]: FAILED! => {
    "failed": true, 
    "msg": "{{ lookup(\"template\", \"lookup/ferm__parsed_rules.j2\", convert_data=False) | from_yaml }}: An unhandled exception occurred while running the lookup plugin 'template'. Error was a <class 'yaml.representer.RepresenterError'>, original message: cannot represent an object: accept_ansible_controller"
}

See ansible/ansible#20290. Hehe, it's even a bug that you (@drybjed) opened 👍

[drybjed]

I guess a link to this bug could be added as a comment near the assert task so we don't need to look for it again. Thanks for finding it!