Ufw supports vrrp, but community.general.ufw plugin does not

[whitfieldts]

Summary

UFW seems to support vrrp (and it is listed as a protocol in the man page for ufw), but is not supported by the ufw plugin:

Issue Type

Feature Idea

Component Name

ufw

Ansible Version

$ ansible --version
ansible [core 2.16.3]
  config file = None
  configured module search path = ['/home/tim/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/tim/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.12.3 (main, Nov  6 2024, 18:32:19) [GCC 13.2.0] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Community.general Version

$ ansible-galaxy collection list community.general

# /usr/lib/python3/dist-packages/ansible_collections
Collection        Version
----------------- -------
community.general 8.3.0 

Configuration

$ ansible-config dump --only-changed
CONFIG_FILE() = None

OS / Environment

Debian 12 Bookworm

Steps to Reproduce

 # Keepalived (protocol 112)
  - name: firewall trust ips (keepalived)
    community.general.ufw:
      rule: allow
      src: 192.168.1.0/24
      dest: 224.0.0.18
      proto: vrrp

Expected Results

I expected ufw to add the vrrp rule. When run manually:

root@control3:~# ufw allow from 192.168.1.0/24 to 224.0.0.18 proto vrrp
Rule added
root@control3:~# ufw status | grep vrrp
224.0.0.18/vrrp            ALLOW       192.168.1.0/24/vrrp       
root@control3:~# 

Actual Results

TASK [firewall trust ips (keepalived)] **********************************************************************************************************************************************************************************************************************************************************************
fatal: [worker2]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [worker1]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [control3]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [control1]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [control2]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [worker4]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}
fatal: [worker3]: FAILED! => {"changed": false, "msg": "value of proto must be one of: ah, any, esp, ipv6, tcp, udp, gre, igmp, got: vrrp"}

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/ufw.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @ahtik @ovcharenko @pyykkis
click here for bot help

[felixfontein]

I don't see how this is a bug, since the documentation does not mention that the module supports vrrp. This sounds more like a feature request/idea.

[whitfieldts]

I understand your interpretation, but I think most of people would expect the module support any ufw configurations they require to run their system. I'm currently a bit confused on what I should do to keep my system configuration managed and automated. Is there is a way to support vrrp on a server without having to do a manual step? Perhaps there is an equivalent rule that will allow this traffic to pass, but in my testing only explicitly calling out vrrp is successful. I understand that answering this question is not what this bug forum is for, but it makes a difference as to whether this module actually allows someone to manage a ufw configuration in some very common scenarios.

…

On Sat, Jan 11, 2025, 6:33 AM Felix Fontein ***@***.***> wrote: I don't see how this is a bug, since the documentation does not mention that the module supports vrrp. This sounds more like a feature request/idea. — Reply to this email directly, view it on GitHub <#9562 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQKZ54T45NZGZ23WVGJJ2SL2KD6SBAVCNFSM6AAAAABU7NX7TGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBVGIYTCMBRGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[russoz]

Hi @whitfieldts

While I understand your perspective, which makes perfect sense, this is a volunteer-based project, and it has been running in one form or another for a long number of years. Not all, heck, most of the modules are probably out of sync with their underlying tools, waiting for people to step up and make the necessary improvements.

From the collection maintenance point of view, categorising the issur as a bug or a feature is more than just splitting hairs on labelling, there are semantic consequences to those denominations: a bug is a promise (stated in the docs) that is partially or completely unfulfilled, whilst a new feature is a new promise. Bugs, when fixed, are ported back to old releases (while still supported), so people using those releases can benefit from it, whilst features only exist moving forward.

We obviously cannot make the decision for you on whether this module will solve your problem, what we can do is ask if you would be willing to help improve the code by adding this missing feature, and we can provide you support making that happen.

Hope you read this in the friendly tone I wrote - internet sometimes twists those things.

Cheers

[whitfieldts]

I completely took all of this as friendly input. I also expected that I am not (at least currently) a contributor. I do appreciate the community's hard work and I realize that I benefit heavily from those efforts. Your explanation on why this is a feature makes sense to me. What should I do to move this report to a feature request.

…

On Sat, Jan 11, 2025, 2:37 PM Alexei Znamensky ***@***.***> wrote: Hi @whitfieldts <https://github.com/whitfieldts> While I understand your perspective, which makes perfect sense, this is a volunteer-based project, and it has been running in one form or another for a long number of years. Not all, heck, most of the modules are probably out of sync with their underlying tools, waiting for people to step up and make the necessary improvements. From the collection maintenance point of view, categorising the issur as a bug or a feature is more than just splitting hairs on labelling, there are semantic consequences to those denominations: a bug is a promise (stated in the docs) that is partially or completely unfulfilled, whilst a new feature is a new promise. Bugs, when fuxed are ported back to old releases (while still supported), so people using those releases can benefit from it, whilst features only exist moving forward. We obviously cannot make the decision for you on whether this module will solve your problem, what we can do is ask if you would be willing to help improve the code by adding this missing feature, and we can provide you support making that happen. Hope you read this in the friendly tone I wrote - internet sometimes twists those things. Cheers — Reply to this email directly, view it on GitHub <#9562 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQKZ54UHTXLVG4XE5UL3XNL2KFXIXAVCNFSM6AAAAABU7NX7TGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBVGM4DMMBVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[felixfontein]

If supporting vrrp is just about allowing one more value for proto, and nothing else, then it should be very simple to implement. Basically add it to the lists in line 118 and 344, and add a second item to the list in line 116 with The value V(vrrp) is supported since community.general 10.3.0., and write a corresponding changelog fragment.

What should I do to move this report to a feature request.

Nothing, I already did that by editing the post to replace "Bug Report" by "Feature Idea", and changing the label.