Message ID | 3bbbc672-74d6-37b2-b122-aac537faa9ac@ipfire.org |
---|---|
State | Rejected |
Commit | 816b0e08c68a63d61bb98adf0b6236b6578115d2 |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4JmyMG6gtdz3wsl for <patchwork@web04.haj.ipfire.org>; Sun, 30 Jan 2022 17:08:26 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4JmyMD6wrlz1hX; Sun, 30 Jan 2022 17:08:24 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4JmyMD6fH6z2xy3; Sun, 30 Jan 2022 17:08:24 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4JmyMC5rkjz2xNV for <development@lists.ipfire.org>; Sun, 30 Jan 2022 17:08:23 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4JmyMB509jz1cf; Sun, 30 Jan 2022 17:08:22 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1643562503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Bc8oVvExxEC549OOoL8GNXN/eSUuPk2snLgo60ylhAg=; b=m6mUsUmu0jN5khIp8haY3Rj3qeNLdFV4lpDQPhuo14bPmcATClIbp2vsLp92adPEznjGoZ q4+I18wEA13O5QCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1643562503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Bc8oVvExxEC549OOoL8GNXN/eSUuPk2snLgo60ylhAg=; b=DE5axnwNVofTdV/oQPtOQjK93MLHmLtXfKmuf8oBto6Xa7d2/0MrewzrHzODEBQkcHey+l zx9x0Ggi6Qd5io9Uf/h1oU0hR2vpvSwQkY+ouAtwy2SIZKphp+9dEc05DP/ybuul/irmUS aMwJd1NSTYDjt3TAY2IiEDfdpRVSe6HoCn0iKCNW/punRSXKGtzhngTxA1gkER4EJEvdF/ uk6X+eDPvgQg5cwrTaTrS5AO4UB6BXMcB/0AjB0Z8lf5ouYdPuROytqaKWNIJVPHRUrYvk AcWcRX2bsA7CPnKrEDTJGGvl/xxjZISjgxcNhQOOlZbW6bJ4TU0rzVPjKQzkYg== Message-ID: <3bbbc672-74d6-37b2-b122-aac537faa9ac@ipfire.org> Date: Sun, 30 Jan 2022 17:08:21 +0000 MIME-Version: 1.0 Content-Language: en-US To: "IPFire: Development" <development@lists.ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org> Subject: [PATCH] firewall: Ensure the xt_geoip module is always loaded Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Cc: Arne Fitzenreiter <arne_f@ipfire.org> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
firewall: Ensure the xt_geoip module is always loaded
|
|
Commit Message
Peter Müller
Jan. 30, 2022, 5:08 p.m. UTC
For some reason, this module is not present after the very first boot of
an IPFire installation.
Fixes: #12767
Reported-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
src/initscripts/system/firewall | 3 +++
1 file changed, 3 insertions(+)
Comments
Hello, I would be great to know *why* this is happening. iptables should automatically trigger loading the kernel module. Did we just forget to run something like depmod -a? -Michael > On 30 Jan 2022, at 17:08, Peter Müller <peter.mueller@ipfire.org> wrote: > > For some reason, this module is not present after the very first boot of > an IPFire installation. > > Fixes: #12767 > > Reported-by: Arne Fitzenreiter <arne_f@ipfire.org> > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > src/initscripts/system/firewall | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall > index ebc8168ae..bfab6d538 100644 > --- a/src/initscripts/system/firewall > +++ b/src/initscripts/system/firewall > @@ -39,6 +39,9 @@ iptables_init() { > iptables -P FORWARD DROP > iptables -P OUTPUT ACCEPT > > + # Ensure the xt_geoip module is always loaded (#12767) > + modprobe xt_geoip > + > # Enable TRACE logging to syslog > modprobe nf_log_ipv4 > sysctl -q -w net.netfilter.nf_log.2=nf_log_ipv4 > -- > 2.31.1
Hello Michael, thanks for your reply. I have no idea, but am interested in the root cause of this as well. It only happens while loading the firewall engine on first boot. On every subsequent boot, iptables does not complain. Thanks, and best regards, Peter Müller > Hello, > > I would be great to know *why* this is happening. > > iptables should automatically trigger loading the kernel module. > > Did we just forget to run something like depmod -a? > > -Michael > >> On 30 Jan 2022, at 17:08, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> For some reason, this module is not present after the very first boot of >> an IPFire installation. >> >> Fixes: #12767 >> >> Reported-by: Arne Fitzenreiter <arne_f@ipfire.org> >> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >> --- >> src/initscripts/system/firewall | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >> index ebc8168ae..bfab6d538 100644 >> --- a/src/initscripts/system/firewall >> +++ b/src/initscripts/system/firewall >> @@ -39,6 +39,9 @@ iptables_init() { >> iptables -P FORWARD DROP >> iptables -P OUTPUT ACCEPT >> >> + # Ensure the xt_geoip module is always loaded (#12767) >> + modprobe xt_geoip >> + >> # Enable TRACE logging to syslog >> modprobe nf_log_ipv4 >> sysctl -q -w net.netfilter.nf_log.2=nf_log_ipv4 >> -- >> 2.31.1 >
Hello, So what would be different upon first boot? We will probably run a location update after the first time we connect to the internet and refresh the database, because the one that was shipped is likely too old. However, I checked the code of the xt_geoip module and it does not look like it would complain in any way that it would look like the module does not exist - so the kernel simply cannot find it. That only leaves us with a missing module on the dependency tree (but we would never update that in production I believe) or that the file can simply not be opened. strace might help with this. -Michael > On 1 Feb 2022, at 17:19, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > > thanks for your reply. > > I have no idea, but am interested in the root cause of this as well. It only happens > while loading the firewall engine on first boot. On every subsequent boot, iptables > does not complain. > > Thanks, and best regards, > Peter Müller > >> Hello, >> >> I would be great to know *why* this is happening. >> >> iptables should automatically trigger loading the kernel module. >> >> Did we just forget to run something like depmod -a? >> >> -Michael >> >>> On 30 Jan 2022, at 17:08, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> For some reason, this module is not present after the very first boot of >>> an IPFire installation. >>> >>> Fixes: #12767 >>> >>> Reported-by: Arne Fitzenreiter <arne_f@ipfire.org> >>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>> --- >>> src/initscripts/system/firewall | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>> index ebc8168ae..bfab6d538 100644 >>> --- a/src/initscripts/system/firewall >>> +++ b/src/initscripts/system/firewall >>> @@ -39,6 +39,9 @@ iptables_init() { >>> iptables -P FORWARD DROP >>> iptables -P OUTPUT ACCEPT >>> >>> + # Ensure the xt_geoip module is always loaded (#12767) >>> + modprobe xt_geoip >>> + >>> # Enable TRACE logging to syslog >>> modprobe nf_log_ipv4 >>> sysctl -q -w net.netfilter.nf_log.2=nf_log_ipv4 >>> -- >>> 2.31.1 >>
diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall index ebc8168ae..bfab6d538 100644 --- a/src/initscripts/system/firewall +++ b/src/initscripts/system/firewall @@ -39,6 +39,9 @@ iptables_init() { iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT + # Ensure the xt_geoip module is always loaded (#12767) + modprobe xt_geoip + # Enable TRACE logging to syslog modprobe nf_log_ipv4 sysctl -q -w net.netfilter.nf_log.2=nf_log_ipv4