From nobody Sun May 5 13:06:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1588533319; cv=none; d=zohomail.com; s=zohoarc; b=XttdQtCh8PcnNI2204ERtw5Yc6D9bO72V51bftEBqolgi5oV846zw93NIT/n7bqm5IUCKWBdDO7Kp2A4Upmkr7yLSZ+iQ/jrXbhfe+mOiY63fJlqoETiYC5gnAurb/u0owxnHg/36wzMLEMyh3EZRnrdI0vF1UQmC/cpyAO/95Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1588533319; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=Ohp7oix3XJhjOD3foNid7aCMgn/4QoUqLFlbQ6emAmo=; b=XYQafZa+5nuFtTa1phb2RyIyshX700U/cFhj8ziUwNJ6YdZIlY0+YLGGKeioTZ5pZKqbuJTGGj2xXu3C2WK3SR2VBX7zHi4WEqPEXWnOOnTs566nVX8lhPf8JyvRGI2BbrKd3E3IcHhdZXQtZjx+POpelhMZgnInYk6kxenuP7I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1588533319959600.0492400872382; Sun, 3 May 2020 12:15:19 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-33-RxRpflI3NpWdDmNprcrYwA-1; Sun, 03 May 2020 15:15:11 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28CF080B713; Sun, 3 May 2020 19:15:03 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF8081001B0B; Sun, 3 May 2020 19:15:00 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id EF0061809542; Sun, 3 May 2020 19:14:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 043JErBm029978 for ; Sun, 3 May 2020 15:14:53 -0400 Received: by smtp.corp.redhat.com (Postfix) id DA2EC1001B0B; Sun, 3 May 2020 19:14:53 +0000 (UTC) Received: from vhost2.laine.org (ovpn-112-130.phx2.redhat.com [10.3.112.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9622E10016EB for ; Sun, 3 May 2020 19:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588533318; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Ohp7oix3XJhjOD3foNid7aCMgn/4QoUqLFlbQ6emAmo=; b=PKgtn37T3IvXqG77TFG/AYX/eAP3Q/UJbdjTV2ItdDxtdZrkSs1ypcCI6j9X3esVQs1R+H UgGhVSJGvXR9li94AXrlpOH58zf8JOh5LoObHv4YeOQiCu8qyYdK0UOKAN2BckExHMpUx+ Rm/zKFkRAN/Mn4Q1pWXrpLB+6jmZMgg= X-MC-Unique: RxRpflI3NpWdDmNprcrYwA-1 From: Laine Stump To: libvir-list@redhat.com Subject: [PATCH] systemd: start libvirtd after firewalld/iptables services Date: Sun, 3 May 2020 15:14:46 -0400 Message-Id: <20200503191446.68778-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" When a system has enabled the iptables/ip6tables services rather than firewalld, there is no explicit ordering of the start of those services vs. libvirtd. This creates a problem when libvirtd.service is started before ip[6]tables, as the latter, when it finally is started, will remove all of the iptables rules that had previously been added by libvirt, including the custom chains where libvirt's rules are kept. This results in an error message similar to the following when a user subsequently tries to start a new libvirt network: "Error while activating network: Call to virNetworkCreate failed: internal error: Failed to apply firewall rules /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \ --in-interface virbr2 --jump REJECT: ip6tables: No chain/target/match by that name." (Prior to logging this error, it also would have caused failure to forward (or block) traffic in some cases, e.g. for guests on a NATed network, since libvirt's rules to forward/block had all been deleted and libvirt didn't know about it, so it couldn't fix the problem) When this happens, the problem can be remedied by simply restarting libvirtd.service (which has the side-effect of reloading all libvirt-generated firewall rules) Instead, we can just explicitly stating in the libvirtd.service file that libvirtd.service should start after ip6tables.service and ip6tables.service, eliminating the race condition that leads to the error. There is also nothing (that I can see) in the systemd .service files to guarantee that firewalld.service will be started (if enabled) prior to libvirtd.service. The same error scenario given above would occur if libvirtd.service started before firewalld.service. Even before that, though libvirtd would have detected that firewalld.service was disabled, and then turn off all firewalld support. So, for example, firewalld's libvirt zone wouldn't be used, and most likely traffic from guests would therefore be blocked (all with no external indication of the source of the problem other than a debug-level log when libvirtd was started saying that firewalld wasn't in use); also libvirtd wouldn't notice when firewalld reloaded its rules (which also simultaneously deletes all of libvirt's rules). I'm not aware of any reports that have been traced back to libvirtd.service starting before firewalld.service, but have seen that error reported multiple times, and also don't see an existing dependency that would guarantee firewalld.service starts before libvirtd.service, so it's possible it's been happening and we just haven't gotten to the bottom of it. This patch adds an After=3D line to the libvirtd.service file for each of iptables.service, ip6tables.service, and firewalld.servicee, which should guarantee that libvirtd.service isn't started until systemd has started whichever of the others is enabled. This race was diagnosed, and patch proposed, by Jason Montleon in https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb agreed with him that this change to libvirtd.service was a reasonable thing to do, but I guess everyone thought someone else was going to post a patch, so in the end nobody did. Signed-off-by: Laine Stump Reviewed-by: Michal Privoznik --- src/remote/libvirtd.service.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in index 90b2cad5b0..cc0d4e3693 100644 --- a/src/remote/libvirtd.service.in +++ b/src/remote/libvirtd.service.in @@ -11,6 +11,9 @@ Wants=3Dlibvirtd-admin.socket Wants=3Dsystemd-machined.service Before=3Dlibvirt-guests.service After=3Dnetwork.target +After=3Dfirewalld.service +After=3Diptables.service +After=3Dip6tables.service After=3Ddbus.service After=3Discsid.service After=3Dapparmor.service --=20 2.25.4