first of: Thanks for all the remarkable work you folks are doing for the community.
I am a long time (must be about 15 years now) lxc user. My use cases are entirely server oriented.
I am in the process now of migrating some installations from pure lxc to incus.
On those servers i have a working and somewhat bullet tested network setup with the physical device, a macvlan interface and some netfilter rulesets juggling the traffic in between.
On my test systems it was a bit of a learning experience to create an initial profile, which does not create the lxbr0 interface. But that’s all good.
The problem i have occurs when i add a user to either the incus or (relevant for my use case) the incus-admin group the bridge and along with that the respective netfilter rules (using nft here) get created respectively appended to my existing environment.
That happens regardless of there being no incus admin init at all (a fresh install) or with a (for me) working profile at the root level.
My question is: Are there any configuration options i can apply that tell the incus daemon to not do these kinds of actions regardless of what i happen to do on the comand line?
When you setup Incus with incus admin init, you are prompted to create a managed network interface incusbr0, which is a private bridge. If you do select to have it created, it will be added to the default profile of Incus (incus profile show default). If you do not need the incusbr0 managed interface, you may remove it, or you can just as well keep it but create containers without incusbr0.
You mention though that Incus adds netfilter rules when you add a non-root user to the incus or incus-admin Unix groups. Now, this is strange. Can you replicate this in a VM? Obviously, you can use Incus to create such a VM. If you can provide minimal instructions, it would be great so that we can replicate.
it was late yesterday and i meshed up two different things.
About two weeks ago i had that problem of incus building its incusbr0 on my dev system.
But that was right after spawning out all my lxc-to-incus migrated containers into separate projects thinking they 'd just inherit their profiles from the default and at this stage i added a user to the incus group. That was a bit premature i guess. Now, with the appropriate projects default profiles in place there is no incusbr0 anymore.
Since this is my dev machine the nft rules i use are not registered in the nftables.service but applied by a script to setup the specific dev environment. So incus applying its own rules in that situation seems reasonable.
Yesterday i had some long ours of configuring and getting to run a backup image (qcow2) from one of the projects. Since that image is a bit older, I had to dist-upgrade the debian installation to install the incus-base package.
Now here is pebkac #2: The lxbr0 bridge was of course created by lxc-net which debian nowadays ships with the default set to true. And lxc-net seems to not care about a systemctl enabled nftables.service and applies its rules anyway.
Well, sorry for the noise.
The only takeaway for the kids out there (and me) might be:
Make sure to create fitting profiles for newly generated projects and learn to read what is actually written even if it’s late.
