Module Request: interface_configuration

[kdhlab]

Module Description

I have been playing with implementing the "interface_settings" module as defined in the roadmap, and have found that the "interface_assignments" module has most of the backend code to make this module work already implemented and that using the existing module, it should be fairly straightforward to make a single module that can assign, and configure interfaces, rather than duplicating calls.

Minimum Viable Product (MVP)

options:
  identifier:
    description:
      - "Technical identifier of the interface, used by hasync for example"
    type: str
    required: true
  device:
    description:
      - Physical Device Name eg. vtnet0, ipsec1000 etc,.
    type: str
    required: true
  description:
    description:
      - Interface name shown in the GUI. Identifier in capital letters if not provided.
      - Input will be trimmed, as no whitespaces are allowed.
    type: str
    required: false
  enabled:
    description:
      - Enable or disable the interface
    type: bool
    required: false
  locked:
    description:
      - Prevent interface removal
    type: bool
    required: false
  block_private:
    description:
        - When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8) and Carrier-grade NAT addresses (100.64/10). This option should only be set for WAN interfaces that use the public IP address space.
      type: bool
      required: false
  block_bogons:
    description:
        - When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8) and Carrier-grade NAT addresses (100.64/10). This option should only be set for WAN interfaces that use the public IP address space.
      type: bool
      required: false
  ipv4_configuration_type:
    description:
      - 
    type: str
    required: false
  ipv6_configuration_type:
    description:
      - 
    type: str
    required: false
  ipv4_address:
    description:
      - 
    type: str
    required: false
  ipv4_gateway:
    description:
      - 
    type: str
    required: false
  ipv6_address:
    description:
      - 
    type: str
    required: false
  ipv6_gateway:
    description:
      - 
    type: str
    required: false
  track6_interface:
    description:
      - 
    type: str
    required: false
  track6_prefix_id:
    description:
      - 
    type: int
    required: false
  mac_address:
    description:
      - 
    type: str
    required: false
  promiscuous_mode:
    description:
      - 
    type: bool
    required: false
  mtu:
    description:
      - If you leave this field blank, the adapter's default MTU will be used. This is typically 1500 bytes but can vary in some circumstances.
    type: int
    required: false
  mss:
    description:
      - If you enter a value in this field, then MSS clamping for TCP connections to the value entered above minus 40 (IPv4) or 60 (IPv6) will be in effect (TCP/IP header size).
    type: int
    required: false
  dynamic_gateway:
    description:
      - If the destination is directly reachable via an interface requiring no intermediary system to act as a gateway, you can select this option which allows dynamic gateways to be created without direct target addresses. Some tunnel types support this.
    type: bool
    required: false

Examples

    - name: Assign interface and configure ipv4 vlan
      puzzle.opnsense.interface_configuration:
        device: "vlan0.1.00{{ item.vlan }}"
        identifier: "vlan{{ item.vlan }}"
        description: "{{ item.description }}"
        enabled: True
        ipv4_configuration_type: "static"
          ipv4_address: "10.100.0.1"
          ipv4_subnet: "24"
      loop: "{{ vlan_list }}"

Additional Notes (Optional)

• Here is a pretty hacky POC I have been playing with so far. https://github.com/kdhlab/puzzle.opnsense/tree/interface_config Before I spend more time on the implementation I wanted to get some opinions on the approach.
• If this paradigm is accepted interface_assignments should be aliased to interface_configuration and should maintain backwards compatibly.

[KiLLuuuhh]

Hi @kdhlab,
Thank you so much for this contribution! From my point of view, your paradigm seems reasonable, and I am looking forward using your implementation!

I also think the idea of aliasing interface_assignments to interface_configuration while maintaining backward compatibility is the way to go.

Happy coding 😃

[opoplawski]

@kdhlab any more progress on this?

[KiLLuuuhh]

@kdhlab any more progress on this?

Hello @opoplawski
Not sure if you are aware of #158?

[opoplawski]

I did find that after posting, thanks. That appears to be stalled as well though.