firewalld doesn't work with default Linode kernel on Fedora 30

Jan 20 08:03:10 li1562-136 systemd: Starting firewalld - dynamic firewall daemon...

Jan 20 08:03:10 li1562-136 systemd: Started firewalld - dynamic firewall daemon.

Jan 20 08:03:10 li1562-136 kernel: libcrc32c: Module is not signed with expected PKCS#7 message

Jan 20 08:03:10 li1562-136 firewalld[14790]: ERROR: Failed to load nf_conntrack module:

;modprobe: ERROR: could not insert 'nf_conntrack':

Linode 莫名其妙的firewalld无法启动，提示错误，百度什么都搜索不到，谷歌多次搜索，终于有结果。

linode官网的论坛：https://www.linode.com/community/questions/18185/firewalld-doesnt-work-with-default-linode-kernel-on-fedora-30

mkdir /lib/modules/$(uname -r) touch /lib/modules/$(uname -r)/modules.{builtin,order}

for i in /sys/module/*; do echo kernel/${i##**/}.ko; done >> /lib/modules/$(uname -r)/modules.builtin

depmod -a

看命令应该就是重新修复一下所用内核对应好的modules的目录

也可以看看其它牛B高手写的：

https://www.getpagespeed.com/server-setup/fix-firewalld-in-centos-7

We have by far the largest RPM repository with dynamic stable NGINX modules and VMODs for Varnish 4.1and 6.0 LTS.

If you want to install nginx, Varnish and lots of useful modules for them, this is your one stop repository to get all performance related software.

You have to maintain an active subscription in order to be able to use the repository!

If you’ve carelessly updated to CentOS 7.7, high chances are that your FirewallD is now broken.

The breakage happens because FirewallD is trying to be too smart for you.
It now attempts to check whether specific kernel modules are there for its proper function.

However, those checks miserably fail on some non-stock kernels.

Whether you’re using OVH, Linode or many other cloud providers – you might have this sames problem, because those providers all use cut-down kernels where the required modules are present, but being built-in, they are not even present in lsmod listing.

So FirewallD with these kernels does not start, because it fails to see the built-in modules. How do get around that?

One manual solution is generating modules.builtin file specific for your kernel, which will list those modules for FirewalD to see.

However, this needs to be regenerated every time the kernel is upgraded. Who likes manual solutions after all? I know I don’t.

Permanent fix for FirewallD

Here’s a solution that will persist throughout kernel upgrades and doesn’t involve hacking FirewallD code.

In a nutshell, we are going to create a service that starts just before FirewallD and ensures that our modules.builtin is pre-generated for successfull startup of FirewallD.

Create /usr/local/sbin/rebuild-builtin-modules with contents:

#!/bin/bash
# script for creating builtin modules file
MODULES_DIR=/lib/modules/$(uname -r)
mkdir -p ${MODULES_DIR}
# touch ${MODULES_DIR}/modules.{builtin,order}
/bin/truncate --size=0 ${MODULES_DIR}/modules.builtin
/bin/truncate --size=0 ${MODULES_DIR}/modules.order
for i in /sys/module/*; do echo kernel/${i##**/}.ko; done >> ${MODULES_DIR}/modules.builtin
depmod -a

Create /etc/systemd/system/rebuild-builtin-modules.service

[Unit]
Description=Rebuild built-in modules list for loaded kernel
Before=firewalld.service

[Service]
Type=oneshotExecStart=/usr/local/sbin/rebuild-builtin-modules

[Install]
WantedBy=multi-user.target

Now set up permissions and launch things up:

chmod 0644 /etc/systemd/system/rebuild-builtin-modules.service
chmod 0755 /usr/local/sbin/rebuild-builtin-modules
chown root:root /etc/systemd/system/rebuild-builtin-modules.service 
chown root:root  /usr/local/sbin/rebuild-builtin-modules
systemctl enable --now rebuild-builtin-modules.service/usr/local/sbin/rebuild-builtin-modules
systemctl restart firewalld

Now FirewallD should work, whether you reboot or update kernels, etc. 🙂

打赏