On Apr 12, Jan Kowalsky wrote:
I try my first steps with ifupdown role and I wondering why there is
a
bridge "br0" attached without configuring it.
My config:
'brnc':
inet: 'static'
bridge_ports: 'none'
The result:
cat interfaces.config.d/*
# This file is managed remotely, all changes will be lost
allow-hotplug enp2s0
iface enp2s0 inet manual
# This file is managed remotely, all changes will be lost
allow-boot br0
iface br0 inet dhcp
bridge_fd 0
bridge_maxwait 0
bridge_ports enp2s0
iface br0 inet6 auto
# This file is managed remotely, all changes will be lost
allow-boot brnc
iface brnc inet manual
bridge_fd 0
bridge_maxwait 0
bridge_ports none
Maybe it's related with the lxc-role. But also there is no br0
configured at all.
Any idea?
Sure. As the documentation explains[1], the 'debops.ifupdown' role has
a concept of predefined interface layouts. On a host that is not detected as
an LXC/OpenVZ container it will try to create one or two bridges (br0, br1)
attached to the detected physical Ethernet interfaces. This is done so that
the host can be easily used as a VM/container hypervisor, in which case you
could attach the VM/container network interfaces to these bridges to give
network access to them.
[1]:
https://docs.debops.org/en/latest/ansible/roles/debops.ifupdown/getting-s...
I think that you could disable this by setting:
ifupdown__default_interfaces: {}
in the Ansible inventory. Although test it with console access handy in case
the network configuration is wrong.
Unfortunately, 'debops.ifupdown' configuration is in a bit of a mess. The role
redesign happened while I was creating the concept of the custom filter
plugins that parse the configuration from multiple sources and merge them into
one YAML list internally - this is now used in multiple DebOps roles via the
'debops.ansible_plugins' role. The 'debops.ifupdown' does the
configuration
parsing by itself, and in a convoluted manner - it uses YAML dictionaries
instead of YAML lists as the base configuration model, and uses multiple
"sources of truth" combined in an awkward way to derive a list of network
interfaces from that.
Since that time the new configuration model matured, but the 'debops.ifupdown'
role still needs to be updated to use it. This will probably result in some
incompatibilities between existing configuration if you use YAML dictionaries
as a base (like you did above; I know - it's according to the docs), but it
should be pretty easy to convert to list-based configuration later - lists can
be used right now as well, it's just that the default configuration forces
a particular interface layout on you.
Since I got some experience in different networking model at work - internal
network as a default one, with external accessed via VLANs at a later time
- I plan to redesign the whole concept of interface layouts a bit. There
shouldn't be a default interface and additional ones, IMO - all interfaces
should be on the same "level" of importance. IP forwarding and masquerade
should be configured per interface entriely, and now it's split between
'debops.ifupdown' and 'debops.ferm' - I plan to streighten that up a bit
before the next release.
Cheers,
Maciej