记录一次Linux Firewalld防火墙故障排查的案例Error：Action org.fedoraproject.FirewallD1.config.info is not registered
1、故障现象
在一个生产服务器上，系统为CentOS7.3，防火墙使用的是系统默认的firewalld。偶然发现，在执行以下防火墙管理命令时，报错如下：
# firewall-cmd --list-all
Error: Action org.fedoraproject.FirewallD1.config.info is not registered
虽然查看防火墙配置规则列表的命令报错了，但其它的规则配置命令仍然能正常使用，只是配置完后，没办法通过命令查看配置结果。不管是查看service，还是port，还是all，都会报上面的错误。
2、问题排查
（1）先查看firewalld服务的运行状态和事件日志信息，如下所示：
# systemctl status firewalld -l
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since 三 2018-04-25 21:23:25 CST; 3h 15min ago
Docs: man:firewalld(1)
Main PID: 168206 (firewalld)
CGroup: /system.slice/firewalld.service
└─168206 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --destination 192.168.122.0/24 --out-interface virbr0 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete OUTPUT --out-interface virbr0 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
分析：
- 从上述内容中首先可以看到的是，firewalld服务状态运行是正常的。
- 其次是服务的事件日志中打印了一些warning信息，这些信息比较有误导性。需要明确的一点是，warning级别的事件，还不足以对服务和管理命令的正常使用造成影响，所以这里可以忽略这些warning信息。
（2）考虑到这些warning信息是关于网桥virbr0的，而这台服务器上恰好配置了kvm虚拟化，也使用了一个br0的网桥。所以有必要查看一下libvirtd服务的运行状态。
# systemctl status libvirtd -l
● libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since 二 2018-01-23 00:27:07 CST; 3 months 1 days ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 1417 (libvirtd)
CGroup: /system.slice/libvirtd.service
├─1417 /usr/sbin/libvirtd
├─2869 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
└─2870 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
1月 23 00:27:08 localhost dnsmasq[2869]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
1月 23 00:27:08 localhost dnsmasq-dhcp[2869]: read /var/lib/libvirt/dnsmasq/default.hostsfile
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: info : libvirt version: 3.2.0, package: 14.el7_4.5 (CentOS BuildSystem < http://bugs.centos.org>, 2017-12-07-15:37:23, c1bm.rdu2.centos.org)
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: info : hostname: localhost
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: error : virNetSocketReadWire:1808 : 读取数据时进入文件终点: 输入/输出错误
4月 25 19:22:34 localhost libvirtd[1417]: 2018-04-25 11:22:34.364+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 20:37:48 localhost libvirtd[1417]: 2018-04-25 12:37:48.301+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:04:14 localhost libvirtd[1417]: 2018-04-25 13:04:14.186+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:19:29 localhost libvirtd[1417]: 2018-04-25 13:19:29.834+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:23:25 localhost libvirtd[1417]: 2018-04-25 13:23:25.666+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
分析：
- 从上述libvirtd服务的信息可以看到服务运行正常；
- 有一些error事件，仔细查看事件时间和内容，发现都是和firewalld服务相关。其中的org.fedoraproject.FirewallD1刚好是firewalld服务在系统dbus服务中注册的服务名称。
- 经过反复分析，证实了这些libvirtd的error事件实际上是因为我在重启firewalld服务时所引发的。因为libvirtd服务使用了firewalld服务，自然在firewalld服务不可用时，报出的一些error日志。所以从libvirtd服务中没有找到任何可以对排查firewall-cmd --list-all命令在执行时报错有帮助的信息。
（3）重新回到最初的报错信息，在google上以多种关键字组合进行搜索
Error: Action org.fedoraproject.FirewallD1.config.info is not registered对几十个搜索结果进行了对比分析后，发现完全相同的现象没有，故障现象接近的大概有两种。
- 一种是说，重新操作系统后，故障现象会消失。考虑到我们是生产服务器，这个方法显然行不通。
- 另一种说法是，这个问题是firewalld软件的一个bug。只是红帽网站上这个文章的时间已经在2015年，近4年前的更旧操作系统上更旧的firewalld版本中的问题。
与此同时，还排查了/var/log/message, /var/log/firewalld.log等日志文件。虽有一些值得注意的信息，但在深入分析、对照正常系统后，均排除掉了。
也对/usr/lib/systemd/system/目录下的systemd管理的firewalld服务相关的.service文件进行了反复的分析、关联分析。同样是没有任何线索。
3、问题的解决
考虑到在firewalld旧版本上曾发生过的一个bug，决定也升级一下firewalld的软件版本试试。
当前使用的是centos7.3系统，firewalld的版本信息如下所示：
# rpm -qa firewalld
firewalld-0.4.3.2-8.el7.noarch执行针对firewalld软件包的升级命令：[root@localhost log]# yum update firewalld
依赖关系解决
==================================================================================================================================================================================
Package 架构 版本 源 大小
==================================================================================================================================================================================
正在更新:
firewalld noarch 0.4.4.4-6.el7 base 416 k
selinux-policy noarch 3.13.1-166.el7_4.9 updates 437 k
为依赖而更新:
firewalld-filesystem noarch 0.4.4.4-6.el7 base 47 k
python-firewall noarch 0.4.4.4-6.el7 base 325 k
selinux-policy-targeted noarch 3.13.1-166.el7_4.9 updates 6.5 M
[root@localhost log]# rpm -qa firewalld
firewalld-0.4.4.4-6.el7.noarch# firewall-cmd --list-all
public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="123.123.123.123/32" port port="22" protocol="tcp" accept
rule family="ipv4" source address="172.17.10.1/32" port port="22" protocol="tcp" accept原来的故障现象消失了，在执行systemctl restart firewalld后再次使用firewall-cmd --list-all的命令查看防火墙的配置规则列表，一切正常。
该问题的根源原因，大概率上仍然集中在firewalld软件的bug上了，只是曾修复过的bug，怎么又到未来某个新版本中故地重游了呢，费解。