[DEPRECATION WARNING]: Skipping task due to undefined Error

[mkgardner]

The debops.ferm role has two errors that give the following error messages:

TASK [debops.ferm : Remove ip(6)tables rules if requested] ********************* [DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this will be a fatal error.. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

TASK [debops.ferm : Configure ip(6)tables rules] ******************************* [DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this will be a fatal error.. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Environment:

• Debian 8 "Jessie" (upgraded as of today, 2016-04-05)
• Ansible 2.0.1.0-1~bpo8+1 from debian-backports

[drybjed]

Hmm, is that with a default config? Or did you set anything in the Ansible inventory to configure additional firewall rules?

[mkgardner]

On Tue, Apr 5, 2016 at 4:42 PM, Maciej Delmanowski <[email protected]

wrote:

Hmm, is that with a default config? Or did you set anything in the Ansible inventory to configure additional firewall rules?

Default config. I didn't define any variables.

I figured out where the error is occurring but not why. Commenting out " ferm__dependent_rules" in both tasks prevents the error from triggering. Uncommenting causes the error to return.

Mark

Mark Gardner

[drybjed]

OK, so here's the thing - debops.ferm can be used by multiple roles as a dependency, therefore the playbook the error shows up as is important. Do you know which one it is? Is that in common playbook by any chance?

[mkgardner]

On Tue, Apr 5, 2016 at 5:26 PM, Maciej Delmanowski <[email protected]

wrote:

OK, so here's the thing - debops.ferm can be used by multiple roles as a dependency, therefore the playbook the error shows up as is important. Do you know which one it is? Is that in common playbook by any chance?

Not the common playbook exactly. I have been working my way through the common playbook systematically to understand what it does. So I created another playbook in which I have been typing in the role entries one by one and then planned to switch to the common playbook once I understand everything. That has been working up until the ferm role.

One of the differences was I did not use the role:: prefix in the tag names. (Shorter typing.) That hasn't made a difference until now. I went back and added the role:: prefix to all the tags so that the are exactly like in common.yml and it now works without an error. Not sure why that caused a problem but it is now gone.

Thanks for your help. And thanks for DebOps. Sorry for the distraction.

Mark

Mark Gardner

[drybjed]

Hmm, that's weird, tag names shouldn't affect the variables, unless something changed in Ansible. But I think that I know what happened. As you can see in the playbook, debops.ferm uses dependent variables to configure additional things for other roles. However, these variable contents are defined in the defaults/main.yml of those other roles. if these roles (debops.ntp, debops.postfix, debops.sshd) are not included in the playbook, Ansible does not read their variables, and the dependent variables you specified are indeed, undefined.

[mkgardner]

On Wed, Apr 6, 2016 at 8:28 AM, Maciej Delmanowski <[email protected]

wrote:

Hmm, that's weird, tag names shouldn't affect the variables, unless something changed in Ansible. But I think that I know what happened. As you can see in the playbook, debops.ferm uses dependent variables to configure additional things for other roles https://github.com/debops/debops-playbooks/blob/master/playbooks/common.yml#L46-L49. However, these variable contents are defined in the defaults/main.yml of those other roles. if these roles (debops.ntp, debops.postfix, debops.sshd) are not included in the playbook, Ansible does not read their variables, and the dependent variables you specified are indeed, undefined.

Would adding "| default('')" to the use of the variables lessen the dependency on the other roles allowing debops.ferm to be more independent?

Mark

Mark Gardner

[drybjed]

No need to, if you write your own playbook just omit these dependent variables. Instead of writing:

    - role: debops.ferm
      tags: [ 'role::ferm' ]
      ferm__dependent_rules:
        - '{{ ntp_ferm_dependent_rules }}'
        - '{{ postfix_ferm_dependent_rules }}'
        - '{{ sshd__ferm__dependent_rules }}'

in your playbook, just write:

    - role: debops.ferm
      tags: [ 'role::ferm' ]

That way, debops.ferm will only configure its own settings. When you add the rest of the roles that need a firewall configured, add their respective dependent variables to the debops.ferm role entry, like before.

NB, the default debops.ferm configuration might block the SSH access, which is configured by the debops.sshd role through the dependent variables. Just mentioning that so you know what happened when you will lose the ability to connect to the host. :-) Local (console) access might be useful then.

[mkgardner]

On Wed, Apr 6, 2016 at 8:38 AM, Maciej Delmanowski <[email protected]

wrote:

No need to, if you write your own playbook just omit these dependent variables. Instead of writing:

- role: debops.ferm
  tags: [ 'role::ferm' ]
  ferm__dependent_rules:
    - '{{ ntp_ferm_dependent_rules }}'
    - '{{ postfix_ferm_dependent_rules }}'
    - '{{ sshd__ferm__dependent_rules }}'

in your playbook, just write:

- role: debops.ferm
  tags: [ 'role::ferm' ]

That way, debops.ferm will only configure its own settings. When you add the rest of the roles that need a firewall configured, add their respective dependent variables to the debops.ferm role entry, like before.

NB, the default debops.ferm configuration might block the SSH access, which is configured by the debops.sshd role through the dependent variables. Just mentioning that so you know what happened when you will lose the ability to connect to the host. :-) Local (console) access might be useful then.

Thanks Maciej. DebOps is big, intertwined, and a lot to understand but it will save me a lot of time once I grok it.

Mark

Mark Gardner

[drybjed]

That's an unfortunate consequence of designing for production environment, I suppose. The secure deployments are complicated, no way around that unfortunately.

[mkgardner]

On Wed, Apr 6, 2016 at 8:42 AM, Maciej Delmanowski <[email protected]

wrote:

That's an unfortunate consequence of designing for production environment, I suppose. The secure deployments are complicated, no way around that unfortunately.

But that is also the benefit of DebOps... I don't have to do it by hand. You have already done it for me. :-) I just have this bad habit of wanting to know how things work.

Mark

Mark Gardner

[drybjed]

Sounds like a bad habit indeed. :-)