From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 8821C1FF0E4 for ; Thu, 05 Nov 2026 09:19:19 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 9CF492145E; Thu, 05 Nov 2026 09:19:16 +0100 (CET) Date: Thu, 5 Nov 2026 09:19:12 +0100 From: Arthur Bied-Charreton To: Stefan Hanreich Subject: Re: [PATCH pve-firewall 3/3] fix #1965: firewall: cache cluster config Message-ID: References: <20261104141931.399659-1-a.bied-charreton@proxmox.com> <20261104141931.399659-4-a.bied-charreton@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793866753063 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.669 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 6EYLIRSQZSZW6NIA2FPGJO7PJK4NJ5KM X-Message-ID-Hash: 6EYLIRSQZSZW6NIA2FPGJO7PJK4NJ5KM X-MailFrom: a.bied-charreton@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Nov 04, 2026 at 05:15:20PM +0100, Stefan Hanreich wrote: > On 11/4/26 3:20 PM, Arthur Bied-Charreton wrote: > > [...] > > > + # cluster.fw is not bumped on SDN changes, however a change in the SDN config may make a > > + # rule that previously failed to parse valid again, or invalidate a previously valid one. > > + # re-verify all rules if the ipsets names yielded by the current SDN config differ from the > > + # stored ones. > > + my $names = sub { join(',', sort keys(($_[0] // {})->{ipset}->%*)) }; > > + my $sdn_ipsets_changed = $names->($sdn_conf) ne $names->($cluster_conf->{sdn}); > > + $cluster_conf->{sdn} = $sdn_conf; > > + > > + return $cluster_conf if !$sdn_ipsets_changed; > > + > > + my $reverify = sub { > > + my ($rules, $conf, $rule_env) = @_; > > + for my $rule ($rules->@*) { > > + delete $rule->{errors}; > > + verify_rule($rule, $cluster_conf, $conf, $rule_env, 1); > > verify_rule can die, so we should probably eval here? Or at least in the loop below? > good point, thanks! will fix that if we decide we want this change.