[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 <notifications@github.com

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 <notifications@github.com

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 <notifications@github.com

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 <notifications@github.com

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 <notifications@github.com

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. :-)