[pve-devel] [RFC pve-firewall v1 0/1] Silence ebtables Audit Messages in dmesg

[pve-devel] [RFC pve-firewall v1 0/1] Silence ebtables Audit Messages in dmesg

[Max R. Carrara]

Silence ebtables Audit Messages in dmesg - RFC v1
=================================================

In short, this is done by switching the `update-alternatives` calls
in pve-firewall.service from ebtables-legacy / iptables-legacy to
ebtables-nft / iptables-nft.

Switching to ebtables-nft in particular silences the audit log spam one
encounters after upgrading a PVE 8.4 node to PVE 9. This should be
alright as the original bug appears to be fixed [1].

As the bug for iptables [0] appears to be fixed as well, switch to
iptables-nft (and ip6tables-nft), too.

! ! ! NOTE ! ! !
----------------

Switching to {eb,ip}tables-nft might come with some very subtle
consequences that aren't really explained anywhere. Moreover, the nft
subsystem probably handles things completely differently, as Wolfgang
pointed out off-list.

Both versions seem to have slightly different featuresets that can be
determined by diffing their respective manpages--for example, so see how
the -nft versions differ from the -legacy ones, it's possible to do the
following (in bash / zsh, as the penguin operator isn't in sh):

  diff -u <(man ebtables-legacy) <(man ebtables-nft) | less

  diff -u <(man iptables-legacy) <(man iptables-nft) | less

Since the original change is referred to "a bit of a hack" [2], consider
this "a bit of a hack" as well, so be wary when applying this. I'll have
this run in my test cluster and my workstation for a bit until I'm
really sure that this doesn't cause any unintended side-effects.

Wanted to send this out for now while I'm reading up on everything, so
that others could have a look at least and install it on their own
setups for testing purposes.

References
----------

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929527
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929976
[2]: https://git.proxmox.com/?p=pve-firewall.git;a=commit;h=c743e671dad7a36871b6ab8e061e4200e64a4f54

Summary of Changes
------------------

Max R. Carrara (1):
  pve-firewall.service: update-alternatives to {ip,eb}tables-nft

 debian/pve-firewall.service | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.39.5



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [RFC pve-firewall v1 1/1] pve-firewall.service: update-alternatives to {ip, eb}tables-nft

[Max R. Carrara]

Back in c743e671d it was necessary to update-alternative `ebtables`
to `ebtables-legacy` due to some bugs [0][1]. However, these bugs
appear to be fixed now.

In Trixie, `ebtables-legacy` seems to cause an enormous amount of audit
message spam in `dmesg` after upgrading from Bookworm--about 5 long
lines every ~10 seconds-- making it very tedious to find anything one
actually cares about.

Thus, use the -nft variants instead of the -legacy ones as the
aforementioned bugs have since long been fixed and the audit log spam
is silenced that way.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929527
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929976

Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
---
 debian/pve-firewall.service | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/pve-firewall.service b/debian/pve-firewall.service
index f95ce6d..c99db26 100644
--- a/debian/pve-firewall.service
+++ b/debian/pve-firewall.service
@@ -8,9 +8,9 @@ Before=shutdown.target
 Conflicts=shutdown.target
 
 [Service]
-ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-legacy
-ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-legacy
-ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
+ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-nft
+ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-nft
+ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-nft
 ExecStart=/usr/sbin/pve-firewall start
 ExecStop=/usr/sbin/pve-firewall stop
 ExecReload=/usr/sbin/pve-firewall restart
-- 
2.39.5



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [RFC pve-firewall v1 1/1] pve-firewall.service: update-alternatives to {ip, eb}tables-nft

[Thomas Lamprecht]

Am 01.08.25 um 17:45 schrieb Max R. Carrara:
> Back in c743e671d it was necessary to update-alternative `ebtables`
> to `ebtables-legacy` due to some bugs [0][1]. However, these bugs
> appear to be fixed now.

Oh, what a throwback ^^ Yeah might be good to change this, but we're
a bit to late for the next release, still see below for a potential
option.

> 
> In Trixie, `ebtables-legacy` seems to cause an enormous amount of audit
> message spam in `dmesg` after upgrading from Bookworm--about 5 long
> lines every ~10 seconds-- making it very tedious to find anything one
> actually cares about.
> 
> Thus, use the -nft variants instead of the -legacy ones as the
> aforementioned bugs have since long been fixed and the audit log spam
> is silenced that way.
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929527
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929976
> 
> Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
> ---
>  debian/pve-firewall.service | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/debian/pve-firewall.service b/debian/pve-firewall.service
> index f95ce6d..c99db26 100644
> --- a/debian/pve-firewall.service
> +++ b/debian/pve-firewall.service
> @@ -8,9 +8,9 @@ Before=shutdown.target
>  Conflicts=shutdown.target
>  
>  [Service]
> -ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-legacy
> -ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-legacy
> -ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
> +ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-nft
> +ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-nft
> +ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

Could we make this opt-in? Then we could a. take more time to thoroughly test
this while b. still being able to tell willing users that they could enabled
the nft variant if they are annoyed by the auditd messages.

An implementation option might be using an node-local environment file
sourced by the unit file, e.g.

Environment="VARIANT=legacy"
EnvironmentFile=-/var/lib/pve-firewall/tables-variant

ExecStartPre=-/usr/bin/update-alternatives --set ebtables-${VARIANT}
...




>  ExecStart=/usr/sbin/pve-firewall start
>  ExecStop=/usr/sbin/pve-firewall stop
>  ExecReload=/usr/sbin/pve-firewall restart
 


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [RFC pve-firewall v1 1/1] pve-firewall.service: update-alternatives to {ip, eb}tables-nft

[Max R. Carrara]

On Fri Aug 1, 2025 at 6:00 PM CEST, Thomas Lamprecht wrote:
> Am 01.08.25 um 17:45 schrieb Max R. Carrara:
> > Back in c743e671d it was necessary to update-alternative `ebtables`
> > to `ebtables-legacy` due to some bugs [0][1]. However, these bugs
> > appear to be fixed now.
>
> Oh, what a throwback ^^ Yeah might be good to change this, but we're
> a bit to late for the next release, still see below for a potential
> option.
>
> >
> > In Trixie, `ebtables-legacy` seems to cause an enormous amount of audit
> > message spam in `dmesg` after upgrading from Bookworm--about 5 long
> > lines every ~10 seconds-- making it very tedious to find anything one
> > actually cares about.
> >
> > Thus, use the -nft variants instead of the -legacy ones as the
> > aforementioned bugs have since long been fixed and the audit log spam
> > is silenced that way.
> >
> > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929527
> > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929976
> >
> > Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
> > ---
> >  debian/pve-firewall.service | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/debian/pve-firewall.service b/debian/pve-firewall.service
> > index f95ce6d..c99db26 100644
> > --- a/debian/pve-firewall.service
> > +++ b/debian/pve-firewall.service
> > @@ -8,9 +8,9 @@ Before=shutdown.target
> >  Conflicts=shutdown.target
> >
> >  [Service]
> > -ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-legacy
> > -ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-legacy
> > -ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
> > +ExecStartPre=-/usr/bin/update-alternatives --set ebtables /usr/sbin/ebtables-nft
> > +ExecStartPre=-/usr/bin/update-alternatives --set iptables /usr/sbin/iptables-nft
> > +ExecStartPre=-/usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-nft
>
> Could we make this opt-in? Then we could a. take more time to thoroughly test
> this while b. still being able to tell willing users that they could enabled
> the nft variant if they are annoyed by the auditd messages.
>
> An implementation option might be using an node-local environment file
> sourced by the unit file, e.g.
>
> Environment="VARIANT=legacy"
> EnvironmentFile=-/var/lib/pve-firewall/tables-variant
>
> ExecStartPre=-/usr/bin/update-alternatives --set ebtables-${VARIANT}
> ...

That's a good idea actually! I'll see what I can do on Monday.

Also, I forgot to mention: Shoutout to Stoiko for pointing me to that
one old commit off-list that sparked the idea of changing to the -nft
variants; much appreciated! Would otherwise probably still be poking
around in the dark.

>
>
>
>
> >  ExecStart=/usr/sbin/pve-firewall start
> >  ExecStop=/usr/sbin/pve-firewall stop
> >  ExecReload=/usr/sbin/pve-firewall restart
>



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [RFC pve-firewall v1 1/1] pve-firewall.service: update-alternatives to {ip, eb}tables-nft

[Thomas Lamprecht]

Am 01.08.25 um 18:07 schrieb Max R. Carrara:
>> An implementation option might be using an node-local environment file
>> sourced by the unit file, e.g.
>>
>> Environment="VARIANT=legacy"
>> EnvironmentFile=-/var/lib/pve-firewall/tables-variant
>>
>> ExecStartPre=-/usr/bin/update-alternatives --set ebtables-${VARIANT}
>> ...
> That's a good idea actually! I'll see what I can do on Monday.

And FWIW, we do not have to chase down this road, moving the
whole update-alternatives into a dedicated script might be also an
option, as could make us also re-use a node option or the like and
have the implementation do some error checking before trying to
execute anything.
OTOH. if we can really default to the nft based ones in a next
point release and drop support for switching in PVE 10 or so
it might not be worth to do much extra work here for something
that is rather short lived anyway; for me either option is fine
(if it works naturally ^^), just wanted to avoid that you think
this is the only acceptable way.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [RFC pve-firewall v1 1/1] pve-firewall.service: update-alternatives to {ip, eb}tables-nft

[Max R. Carrara]

On Fri Aug 1, 2025 at 6:24 PM CEST, Thomas Lamprecht wrote:
> Am 01.08.25 um 18:07 schrieb Max R. Carrara:
> >> An implementation option might be using an node-local environment file
> >> sourced by the unit file, e.g.
> >>
> >> Environment="VARIANT=legacy"
> >> EnvironmentFile=-/var/lib/pve-firewall/tables-variant
> >>
> >> ExecStartPre=-/usr/bin/update-alternatives --set ebtables-${VARIANT}
> >> ...
> > That's a good idea actually! I'll see what I can do on Monday.
>
> And FWIW, we do not have to chase down this road, moving the
> whole update-alternatives into a dedicated script might be also an
> option, as could make us also re-use a node option or the like and
> have the implementation do some error checking before trying to
> execute anything.
> OTOH. if we can really default to the nft based ones in a next
> point release and drop support for switching in PVE 10 or so
> it might not be worth to do much extra work here for something
> that is rather short lived anyway; for me either option is fine
> (if it works naturally ^^), just wanted to avoid that you think
> this is the only acceptable way.

Oh yeah, no worries—I'll see whatever works best, as in, has the best
utility-to-implementation-time ratio :P



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel