libvirt/libvirt.spec.in

1941 lines
60 KiB
RPMSpec
Raw Normal View History

# -*- rpm-spec -*-
# This spec file assumes you are building on a Fedora or RHEL version
# that's still supported by the vendor. It may work on other distros
# or versions, but no effort will be made to ensure that going forward.
%define min_rhel 7
%define min_fedora 31
%if (0%{?fedora} && 0%{?fedora} >= %{min_fedora}) || (0%{?rhel} && 0%{?rhel} >= %{min_rhel})
%define supported_platform 1
%else
%define supported_platform 0
%endif
# The hypervisor drivers that run in libvirtd
%define with_qemu 0%{!?_without_qemu:1}
%define with_lxc 0%{!?_without_lxc:1}
%define with_libxl 0%{!?_without_libxl:1}
%define with_vbox 0%{!?_without_vbox:1}
%define with_qemu_tcg %{with_qemu}
%define qemu_kvm_arches %{ix86} x86_64
%if 0%{?fedora}
%define qemu_kvm_arches %{ix86} x86_64 %{power64} s390x %{arm} aarch64
%endif
%if 0%{?rhel}
%define with_qemu_tcg 0
%define qemu_kvm_arches x86_64 %{power64} aarch64 s390x
%endif
# On RHEL 7 and older macro _vpath_builddir is not defined.
%if 0%{?rhel} && 0%{?rhel} <= 7
%define _vpath_builddir %{_target_platform}
%endif
%ifarch %{qemu_kvm_arches}
%define with_qemu_kvm %{with_qemu}
%else
%define with_qemu_kvm 0
%endif
%if ! %{with_qemu_tcg} && ! %{with_qemu_kvm}
%define with_qemu 0
%endif
# Then the hypervisor drivers that run outside libvirtd, in libvirt.so
%define with_openvz 0%{!?_without_openvz:1}
%define with_vmware 0%{!?_without_vmware:1}
%define with_esx 0%{!?_without_esx:1}
%define with_hyperv 0%{!?_without_hyperv:1}
# Then the secondary host drivers, which run inside libvirtd
%define with_storage_rbd 0%{!?_without_storage_rbd:1}
%if 0%{?fedora}
%define with_storage_sheepdog 0%{!?_without_storage_sheepdog:1}
%else
%define with_storage_sheepdog 0
%endif
%define with_storage_gluster 0%{!?_without_storage_gluster:1}
%ifnarch %{qemu_kvm_arches}
# gluster is only built where qemu driver is enabled on RHEL 8
%if 0%{?rhel} >= 8
%define with_storage_gluster 0
%endif
%endif
%define with_numactl 0%{!?_without_numactl:1}
# F25+ has zfs-fuse
%if 0%{?fedora}
%define with_storage_zfs 0%{!?_without_storage_zfs:1}
%else
%define with_storage_zfs 0
%endif
# We need a recent enough libiscsi (>= 1.18.0)
%if 0%{?fedora} || 0%{?rhel} > 7
%define with_storage_iscsi_direct 0%{!?_without_storage_iscsi_direct:1}
%else
%define with_storage_iscsi_direct 0
%endif
# A few optional bits off by default, we enable later
%define with_fuse 0%{!?_without_fuse:0}
%define with_sanlock 0%{!?_without_sanlock:0}
%define with_numad 0%{!?_without_numad:0}
network: use firewalld instead of iptables, when available * configure.ac, spec file: firewalld defaults to enabled if dbus is available, otherwise is disabled. If --with_firewalld is explicitly requested and dbus is not available, configure will fail. * bridge_driver: add dbus filters to get the FirewallD1.Reloaded signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1. When these are encountered, reload all the iptables reuls of all libvirt's virtual networks (similar to what happens when libvirtd is restarted). * iptables, ebtables: use firewall-cmd's direct passthrough interface when available, otherwise use iptables and ebtables commands. This decision is made once the first time libvirt calls iptables/ebtables, and that decision is maintained for the life of libvirtd. * Note that the nwfilter part of this patch was separated out into another patch by Stefan in V2, so that needs to be revised and re-reviewed as well. ================ All the configure.ac and specfile changes are unchanged from Thomas' V3. V3 re-ran "firewall-cmd --state" every time a new rule was added, which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set up a one-time initialization function. The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called vir(Ip|Eb)OnceInit(), which will then be called the first time that the static function vir(Ip|Eb)TablesInitialize() is called (that function is defined for you by the macro). This is thread-safe, so there is no chance of any race. IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init functions (one for iptables, on for ebtables) as VIR_WARN so that I don't have to turn on all the other debug message just to see these. Even if this patch doesn't need any other modification, those messages need to be changed to VIR_DEBUG before pushing. This one-time initialization works well. However, I've encountered problems with testing: 1) Whenever I have enabled the firewalld service, *all* attempts to call firewall-cmd from within libvirtd end with firewall-cmd hanging internally somewhere. This is *not* the case if firewall-cmd returns non-0 in response to "firewall-cmd --state" (i.e. *that* command runs and returns to libvirt successfully.) 2) If I start libvirtd while firewalld is stopped, then start firewalld later, this triggers libvirtd to reload its iptables rules, however it also spits out a *ton* of complaints about deletion failing (I suppose because firewalld has nuked all of libvirt's rules). I guess we need to suppress those messages (which is a more annoying problem to fix than you might think, but that's another story). 3) I noticed a few times during this long line of errors that firewalld made a complaint about "Resource Temporarily unavailable. Having libvirtd access iptables commands directly at the same time as firewalld is doing so is apparently problematic. 4) In general, I'm concerned about the "set it once and never change it" method - if firewalld is disabled at libvirtd startup, causing libvirtd to always use iptables/ebtables directly, this won't cause *terrible* problems, but if libvirtd decides to use firewall-cmd and firewalld is later disabled, libvirtd will not be able to recover.
2012-08-14 18:59:52 +00:00
%define with_firewalld 0%{!?_without_firewalld:0}
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%define with_firewalld_zone 0%{!?_without_firewalld_zone:0}
%define with_libssh2 0%{!?_without_libssh2:0}
%define with_wireshark 0%{!?_without_wireshark:0}
%define with_libssh 0%{!?_without_libssh:0}
%define with_bash_completion 0%{!?_without_bash_completion:0}
# Finally set the OS / architecture specific special cases
# Xen is available only on some architectures
%ifnarch %{ix86} x86_64 aarch64
%define with_libxl 0
%endif
# vbox is available only on i386 x86_64
%ifnarch %{ix86} x86_64
%define with_vbox 0
%endif
# Numactl is not available on many non-x86 archs
%ifarch s390 s390x %{arm} riscv64
%define with_numactl 0
%endif
# zfs-fuse is not available on some architectures
%ifarch s390 s390x aarch64 riscv64
%define with_storage_zfs 0
%endif
# Ceph dropped support for 32-bit hosts
%ifarch %{arm} %{ix86}
%define with_storage_rbd 0
%endif
# RHEL doesn't ship OpenVZ, VBox, PowerHypervisor,
# VMware, libxenlight (Xen 4.1 and newer),
# or HyperV.
%if 0%{?rhel}
%define with_openvz 0
%define with_vbox 0
%define with_vmware 0
%define with_libxl 0
%define with_hyperv 0
%define with_vz 0
%if 0%{?rhel} > 7
%define with_lxc 0
%endif
%endif
%define with_firewalld 1
network: use firewalld instead of iptables, when available * configure.ac, spec file: firewalld defaults to enabled if dbus is available, otherwise is disabled. If --with_firewalld is explicitly requested and dbus is not available, configure will fail. * bridge_driver: add dbus filters to get the FirewallD1.Reloaded signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1. When these are encountered, reload all the iptables reuls of all libvirt's virtual networks (similar to what happens when libvirtd is restarted). * iptables, ebtables: use firewall-cmd's direct passthrough interface when available, otherwise use iptables and ebtables commands. This decision is made once the first time libvirt calls iptables/ebtables, and that decision is maintained for the life of libvirtd. * Note that the nwfilter part of this patch was separated out into another patch by Stefan in V2, so that needs to be revised and re-reviewed as well. ================ All the configure.ac and specfile changes are unchanged from Thomas' V3. V3 re-ran "firewall-cmd --state" every time a new rule was added, which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set up a one-time initialization function. The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called vir(Ip|Eb)OnceInit(), which will then be called the first time that the static function vir(Ip|Eb)TablesInitialize() is called (that function is defined for you by the macro). This is thread-safe, so there is no chance of any race. IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init functions (one for iptables, on for ebtables) as VIR_WARN so that I don't have to turn on all the other debug message just to see these. Even if this patch doesn't need any other modification, those messages need to be changed to VIR_DEBUG before pushing. This one-time initialization works well. However, I've encountered problems with testing: 1) Whenever I have enabled the firewalld service, *all* attempts to call firewall-cmd from within libvirtd end with firewall-cmd hanging internally somewhere. This is *not* the case if firewall-cmd returns non-0 in response to "firewall-cmd --state" (i.e. *that* command runs and returns to libvirt successfully.) 2) If I start libvirtd while firewalld is stopped, then start firewalld later, this triggers libvirtd to reload its iptables rules, however it also spits out a *ton* of complaints about deletion failing (I suppose because firewalld has nuked all of libvirt's rules). I guess we need to suppress those messages (which is a more annoying problem to fix than you might think, but that's another story). 3) I noticed a few times during this long line of errors that firewalld made a complaint about "Resource Temporarily unavailable. Having libvirtd access iptables commands directly at the same time as firewalld is doing so is apparently problematic. 4) In general, I'm concerned about the "set it once and never change it" method - if firewalld is disabled at libvirtd startup, causing libvirtd to always use iptables/ebtables directly, this won't cause *terrible* problems, but if libvirtd decides to use firewall-cmd and firewalld is later disabled, libvirtd will not be able to recover.
2012-08-14 18:59:52 +00:00
%if 0%{?fedora} || 0%{?rhel} > 7
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%define with_firewalld_zone 0%{!?_without_firewalld_zone:1}
%endif
# fuse is used to provide virtualized /proc for LXC
%if %{with_lxc}
%define with_fuse 0%{!?_without_fuse:1}
%endif
# Enable sanlock library for lock management with QEMU
# Sanlock is available only on arches where kvm is available for RHEL
%if 0%{?fedora}
%define with_sanlock 0%{!?_without_sanlock:1}
%endif
%if 0%{?rhel}
%ifarch %{qemu_kvm_arches}
%define with_sanlock 0%{!?_without_sanlock:1}
%endif
%endif
# Enable libssh2 transport for new enough distros
%if 0%{?fedora}
%define with_libssh2 0%{!?_without_libssh2:1}
%endif
# Enable wireshark plugins for all distros shipping libvirt 1.2.2 or newer
%if 0%{?fedora}
%define with_wireshark 0%{!?_without_wireshark:1}
%define wireshark_plugindir %(pkg-config --variable plugindir wireshark)/epan
%endif
# Enable libssh transport for new enough distros
%if 0%{?fedora} || 0%{?rhel} > 7
%define with_libssh 0%{!?_without_libssh:1}
%endif
%define with_bash_completion 0%{!?_without_bash_completion:1}
%if %{with_qemu} || %{with_lxc}
# numad is used to manage the CPU and memory placement dynamically,
# it's not available on many non-x86 architectures.
%ifnarch s390 s390x %{arm} riscv64
%define with_numad 0%{!?_without_numad:1}
%endif
%endif
# Force QEMU to run as non-root
%define qemu_user qemu
%define qemu_group qemu
# RHEL releases provide stable tool chains and so it is safe to turn
# compiler warning into errors without being worried about frequent
# changes in reported warnings
%if 0%{?rhel}
%define enable_werror -Dwerror=true
%else
%define enable_werror -Dwerror=false
%endif
%if 0%{?rhel} == 7
%define tls_priority "NORMAL"
%else
%define tls_priority "@LIBVIRT,SYSTEM"
%endif
2010-11-11 17:21:28 +00:00
Summary: Library providing a simple virtualization API
Name: libvirt
Version: @VERSION@
Release: 1%{?dist}
License: LGPLv2+
URL: https://libvirt.org/
%if %(echo %{version} | grep -q "\.0$"; echo $?) == 1
%define mainturl stable_updates/
%endif
Source: https://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.xz
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-config-network = %{version}-%{release}
Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
%if %{with_libxl}
Requires: libvirt-daemon-driver-libxl = %{version}-%{release}
%endif
%if %{with_lxc}
Requires: libvirt-daemon-driver-lxc = %{version}-%{release}
%endif
%if %{with_qemu}
Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
%endif
# We had UML driver, but we've removed it.
Obsoletes: libvirt-daemon-driver-uml <= 5.0.0
Obsoletes: libvirt-daemon-uml <= 5.0.0
%if %{with_vbox}
Requires: libvirt-daemon-driver-vbox = %{version}-%{release}
%endif
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-client = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
# All build-time requirements. Run-time requirements are
# listed against each sub-RPM
BuildRequires: gettext-devel
%if 0%{?rhel} == 7
BuildRequires: python36-docutils
%else
BuildRequires: python3-docutils
%endif
BuildRequires: gcc
BuildRequires: meson >= 0.54.0
BuildRequires: ninja-build
BuildRequires: make
BuildRequires: git
%if 0%{?fedora} || 0%{?rhel} > 7
BuildRequires: perl-interpreter
%else
BuildRequires: perl
%endif
BuildRequires: python3
BuildRequires: systemd-units
%if %{with_libxl}
BuildRequires: xen-devel
%endif
BuildRequires: glib2-devel >= 2.48
BuildRequires: libxml2-devel
BuildRequires: libxslt
BuildRequires: readline-devel
%if %{with_bash_completion}
BuildRequires: bash-completion >= 2.0
%endif
BuildRequires: gettext
BuildRequires: libtasn1-devel
BuildRequires: gnutls-devel
BuildRequires: libattr-devel
# For pool-build probing for existing pools
BuildRequires: libblkid-devel >= 2.17
# for augparse, optionally used in testing
BuildRequires: augeas
BuildRequires: systemd-devel >= 185
BuildRequires: libpciaccess-devel >= 0.10.9
BuildRequires: yajl-devel
%if %{with_sanlock}
BuildRequires: sanlock-devel >= 2.4
%endif
BuildRequires: libpcap-devel >= 1.5.0
BuildRequires: libnl3-devel
2008-02-20 15:38:29 +00:00
BuildRequires: libselinux-devel
BuildRequires: dnsmasq >= 2.41
BuildRequires: iptables
BuildRequires: radvd
BuildRequires: ebtables
BuildRequires: module-init-tools
BuildRequires: cyrus-sasl-devel
BuildRequires: polkit >= 0.112
# For mount/umount in FS driver
BuildRequires: util-linux
%if %{with_qemu}
# For managing ACLs
BuildRequires: libacl-devel
# From QEMU RPMs
BuildRequires: /usr/bin/qemu-img
%endif
# For LVM drivers
BuildRequires: lvm2
# For pool type=iscsi
2008-02-20 15:49:25 +00:00
BuildRequires: iscsi-initiator-utils
%if %{with_storage_iscsi_direct}
# For pool type=iscsi-direct
BuildRequires: libiscsi-devel
%endif
# For disk driver
BuildRequires: parted-devel
# For Multipath support
BuildRequires: device-mapper-devel
# For XFS reflink clone support
BuildRequires: xfsprogs-devel
%if %{with_storage_rbd}
%if 0%{?fedora} || 0%{?rhel} > 7
BuildRequires: librados-devel
BuildRequires: librbd-devel
%else
BuildRequires: librados2-devel
BuildRequires: librbd1-devel
%endif
%endif
storage: initial support for linking with libgfapi We support gluster volumes in domain XML, so we also ought to support them as a storage pool. Besides, a future patch will want to take advantage of libgfapi to handle the case of a gluster device holding qcow2 rather than raw storage, and for that to work, we need a storage backend that can read gluster storage volume contents. This sets up the framework. Note that the new pool is named 'gluster' to match a <disk type='network'><source protocol='gluster'> image source already supported in a <domain>; it does NOT match the <pool type='netfs'><source><target type='glusterfs'>, since that uses a FUSE mount to a local file name rather than a network name. This and subsequent patches have been tested against glusterfs 3.4.1 (available on Fedora 19); there are likely bugs in older versions that may prevent decent use of gfapi, so this patch enforces the minimum version tested. A future patch may lower the minimum. On the other hand, I hit at least two bugs in 3.4.1 that will be fixed in 3.5/3.4.2, where it might be worth raising the minimum: glfs_readdir is nicer to use than glfs_readdir_r [1], and glfs_fini should only return failure on an actual failure [2]. [1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html [2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html * configure.ac (WITH_STORAGE_GLUSTER): New conditional. * m4/virt-gluster.m4: new file. * libvirt.spec.in (BuildRequires): Support gluster in spec file. * src/conf/storage_conf.h (VIR_STORAGE_POOL_GLUSTER): New pool type. * src/conf/storage_conf.c (poolTypeInfo): Treat similar to sheepdog and rbd. (virStoragePoolDefFormat): Don't output target for gluster. * src/storage/storage_backend_gluster.h: New file. * src/storage/storage_backend_gluster.c: Likewise. * po/POTFILES.in: Add new file. * src/storage/storage_backend.c (backends): Register new type. * src/Makefile.am (STORAGE_DRIVER_GLUSTER_SOURCES): Build new files. * src/storage/storage_backend.h (_virStorageBackend): Documet assumption. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-19 23:26:05 +00:00
%if %{with_storage_gluster}
BuildRequires: glusterfs-api-devel >= 3.4.1
BuildRequires: glusterfs-devel >= 3.4.1
%endif
%if %{with_storage_sheepdog}
BuildRequires: sheepdog
%endif
%if %{with_storage_zfs}
# Support any conforming implementation of zfs. On stock Fedora
# this is zfs-fuse, but could be zfsonlinux upstream RPMs
BuildRequires: /sbin/zfs
BuildRequires: /sbin/zpool
%endif
%if %{with_numactl}
# For QEMU/LXC numa info
BuildRequires: numactl-devel
%endif
BuildRequires: libcap-ng-devel >= 0.5.0
%if %{with_fuse}
BuildRequires: fuse-devel >= 2.8.6
%endif
%if %{with_libssh2}
BuildRequires: libssh2-devel >= 1.3.0
%endif
BuildRequires: netcf-devel >= 0.2.2
%if %{with_esx}
BuildRequires: libcurl-devel
%endif
%if %{with_hyperv}
BuildRequires: libwsman-devel >= 2.2.3
%endif
BuildRequires: audit-libs-devel
# we need /usr/sbin/dtrace
BuildRequires: systemtap-sdt-devel
# For mount/umount in FS driver
BuildRequires: util-linux
# For showmount in FS driver (netfs discovery)
BuildRequires: nfs-utils
# Fedora build root suckage
BuildRequires: gawk
# For storage wiping with different algorithms
BuildRequires: scrub
%if %{with_numad}
BuildRequires: numad
%endif
%if %{with_wireshark}
BuildRequires: wireshark-devel >= 2.4.0
%endif
%if %{with_libssh}
BuildRequires: libssh-devel >= 0.7.0
%endif
# On RHEL-7 rpcgen is still part of glibc-common package
%if 0%{?fedora} || 0%{?rhel} > 7
BuildRequires: rpcgen
%endif
BuildRequires: libtirpc-devel
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%if %{with_firewalld_zone}
BuildRequires: firewalld-filesystem
%endif
%description
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). The main package includes
the libvirtd server exporting the virtualization support.
%package docs
Summary: API reference and website documentation
%description docs
Includes the API reference for the libvirt C library, and a complete
copy of the libvirt.org website documentation.
%package daemon
Summary: Server side daemon and supporting files for libvirt library
# All runtime requirements for the libvirt package (runtime requrements
# for subpackages are listed later in those subpackages)
# The client side, i.e. shared libs are in a subpackage
Requires: %{name}-libs = %{version}-%{release}
# (client invokes 'nc' against the UNIX socket on the server)
Requires: /usr/bin/nc
# for modprobe of pci devices
Requires: module-init-tools
# for /sbin/ip & /sbin/tc
Requires: iproute
# tc is provided by iproute-tc since at least Fedora 26
%if 0%{?fedora} || 0%{?rhel} > 7
Requires: iproute-tc
%endif
Requires: polkit >= 0.112
%ifarch %{ix86} x86_64
# For virConnectGetSysinfo
Requires: dmidecode
%endif
# For service management
Requires(post): systemd-units
Requires(post): systemd-sysv
Requires(preun): systemd-units
Requires(postun): systemd-units
%if %{with_numad}
Requires: numad
%endif
# libvirtd depends on 'messagebus' service
Requires: dbus
# For uid creation during pre
Requires(pre): shadow-utils
%description daemon
Server side daemon required to manage the virtualization capabilities
of recent versions of Linux. Requires a hypervisor specific sub-RPM
for specific drivers.
%package daemon-config-network
Summary: Default configuration files for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
%description daemon-config-network
Default configuration files for setting up NAT based networking
%package daemon-config-nwfilter
Summary: Network filter configuration files for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
%description daemon-config-nwfilter
Network filter configuration files for cleaning guest traffic
%package daemon-driver-network
Summary: Network driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: dnsmasq >= 2.41
Requires: radvd
Requires: iptables
%description daemon-driver-network
The network driver plugin for the libvirtd daemon, providing
an implementation of the virtual network APIs using the Linux
bridge capabilities.
%package daemon-driver-nwfilter
Summary: Nwfilter driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: iptables
Requires: ebtables
%description daemon-driver-nwfilter
The nwfilter driver plugin for the libvirtd daemon, providing
an implementation of the firewall APIs using the ebtables,
iptables and ip6tables capabilities
%package daemon-driver-nodedev
Summary: Nodedev driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
# needed for device enumeration
Requires: systemd >= 185
# For managing persistent mediated devices
%if 0%{?fedora} || 0%{?rhel} > 7
Requires: mdevctl
%endif
%description daemon-driver-nodedev
The nodedev driver plugin for the libvirtd daemon, providing
an implementation of the node device APIs using the udev
capabilities.
%package daemon-driver-interface
Summary: Interface driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: netcf-libs >= 0.2.2
%description daemon-driver-interface
The interface driver plugin for the libvirtd daemon, providing
an implementation of the network interface APIs using the
netcf library
%package daemon-driver-secret
Summary: Secret driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
%description daemon-driver-secret
The secret driver plugin for the libvirtd daemon, providing
an implementation of the secret key APIs.
%package daemon-driver-storage-core
Summary: Storage driver plugin including base backends for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: nfs-utils
# For mkfs
Requires: util-linux
%if %{with_qemu}
# From QEMU RPMs
Requires: /usr/bin/qemu-img
%endif
%if !%{with_storage_rbd}
Obsoletes: libvirt-daemon-driver-storage-rbd < %{version}-%{release}
%endif
%description daemon-driver-storage-core
The storage driver plugin for the libvirtd daemon, providing
an implementation of the storage APIs using files, local disks, LVM, SCSI,
iSCSI, and multipath storage.
%package daemon-driver-storage-logical
Summary: Storage driver plugin for lvm volumes
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: lvm2
%description daemon-driver-storage-logical
The storage driver backend adding implementation of the storage APIs for block
volumes using lvm.
%package daemon-driver-storage-disk
Summary: Storage driver plugin for disk
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: parted
Requires: device-mapper
%description daemon-driver-storage-disk
The storage driver backend adding implementation of the storage APIs for block
volumes using the host disks.
%package daemon-driver-storage-scsi
Summary: Storage driver plugin for local scsi devices
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
%description daemon-driver-storage-scsi
The storage driver backend adding implementation of the storage APIs for scsi
host devices.
%package daemon-driver-storage-iscsi
Summary: Storage driver plugin for iscsi
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: iscsi-initiator-utils
%description daemon-driver-storage-iscsi
The storage driver backend adding implementation of the storage APIs for iscsi
volumes using the host iscsi stack.
%if %{with_storage_iscsi_direct}
%package daemon-driver-storage-iscsi-direct
Summary: Storage driver plugin for iscsi-direct
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: libiscsi
%description daemon-driver-storage-iscsi-direct
The storage driver backend adding implementation of the storage APIs for iscsi
volumes using libiscsi direct connection.
%endif
%package daemon-driver-storage-mpath
Summary: Storage driver plugin for multipath volumes
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: device-mapper
%description daemon-driver-storage-mpath
The storage driver backend adding implementation of the storage APIs for
multipath storage using device mapper.
%if %{with_storage_gluster}
%package daemon-driver-storage-gluster
Summary: Storage driver plugin for gluster
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
%if 0%{?fedora}
Requires: glusterfs-client >= 2.0.1
%endif
%if (0%{?fedora} || 0%{?with_storage_gluster})
Requires: /usr/sbin/gluster
%endif
%description daemon-driver-storage-gluster
The storage driver backend adding implementation of the storage APIs for gluster
volumes using libgfapi.
%endif
%if %{with_storage_rbd}
%package daemon-driver-storage-rbd
Summary: Storage driver plugin for rbd
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
%description daemon-driver-storage-rbd
The storage driver backend adding implementation of the storage APIs for rbd
volumes using the ceph protocol.
%endif
%if %{with_storage_sheepdog}
%package daemon-driver-storage-sheepdog
Summary: Storage driver plugin for sheepdog
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: sheepdog
%description daemon-driver-storage-sheepdog
The storage driver backend adding implementation of the storage APIs for
sheepdog volumes using.
%endif
%if %{with_storage_zfs}
%package daemon-driver-storage-zfs
Summary: Storage driver plugin for ZFS
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
# Support any conforming implementation of zfs
Requires: /sbin/zfs
Requires: /sbin/zpool
%description daemon-driver-storage-zfs
The storage driver backend adding implementation of the storage APIs for
ZFS volumes.
%endif
%package daemon-driver-storage
Summary: Storage driver plugin including all backends for the libvirtd daemon
Requires: libvirt-daemon-driver-storage-core = %{version}-%{release}
Requires: libvirt-daemon-driver-storage-disk = %{version}-%{release}
Requires: libvirt-daemon-driver-storage-logical = %{version}-%{release}
Requires: libvirt-daemon-driver-storage-scsi = %{version}-%{release}
Requires: libvirt-daemon-driver-storage-iscsi = %{version}-%{release}
Requires: libvirt-daemon-driver-storage-mpath = %{version}-%{release}
%if %{with_storage_iscsi_direct}
Requires: libvirt-daemon-driver-storage-iscsi-direct = %{version}-%{release}
%endif
%if %{with_storage_gluster}
Requires: libvirt-daemon-driver-storage-gluster = %{version}-%{release}
%endif
%if %{with_storage_rbd}
Requires: libvirt-daemon-driver-storage-rbd = %{version}-%{release}
%endif
%if %{with_storage_sheepdog}
Requires: libvirt-daemon-driver-storage-sheepdog = %{version}-%{release}
%endif
%if %{with_storage_zfs}
Requires: libvirt-daemon-driver-storage-zfs = %{version}-%{release}
%endif
%description daemon-driver-storage
The storage driver plugin for the libvirtd daemon, providing
an implementation of the storage APIs using LVM, iSCSI,
parted and more.
%if %{with_qemu}
%package daemon-driver-qemu
Summary: QEMU driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Requires: /usr/bin/qemu-img
# For image compression
Requires: gzip
Requires: bzip2
Requires: lzop
Requires: xz
%if 0%{?fedora} || 0%{?rhel} > 7
Requires: systemd-container
%endif
%description daemon-driver-qemu
The qemu driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
QEMU
%endif
%if %{with_lxc}
%package daemon-driver-lxc
Summary: LXC driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
# There really is a hard cross-driver dependency here
Requires: libvirt-daemon-driver-network = %{version}-%{release}
%if 0%{?fedora} || 0%{?rhel} > 7
Requires: systemd-container
%endif
%description daemon-driver-lxc
The LXC driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
the Linux kernel
%endif
%if %{with_vbox}
%package daemon-driver-vbox
Summary: VirtualBox driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
%description daemon-driver-vbox
The vbox driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
VirtualBox
%endif
%if %{with_libxl}
%package daemon-driver-libxl
Summary: Libxl driver plugin for the libvirtd daemon
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-libs = %{version}-%{release}
Obsoletes: libvirt-daemon-driver-xen < 4.3.0
%description daemon-driver-libxl
The Libxl driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
Libxl
%endif
%if %{with_qemu_tcg}
%package daemon-qemu
Summary: Server side daemon & driver required to run QEMU guests
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
Requires: qemu
%description daemon-qemu
Server side daemon and driver required to manage the virtualization
capabilities of the QEMU TCG emulators
%endif
%if %{with_qemu_kvm}
%package daemon-kvm
Summary: Server side daemon & driver required to run KVM guests
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
Requires: qemu-kvm
%description daemon-kvm
Server side daemon and driver required to manage the virtualization
capabilities of the KVM hypervisor
%endif
%if %{with_lxc}
%package daemon-lxc
Summary: Server side daemon & driver required to run LXC guests
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-lxc = %{version}-%{release}
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
%description daemon-lxc
Server side daemon and driver required to manage the virtualization
capabilities of LXC
%endif
%if %{with_libxl}
%package daemon-xen
Summary: Server side daemon & driver required to run XEN guests
Requires: libvirt-daemon = %{version}-%{release}
%if %{with_libxl}
Requires: libvirt-daemon-driver-libxl = %{version}-%{release}
%endif
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
Requires: xen
%description daemon-xen
Server side daemon and driver required to manage the virtualization
capabilities of XEN
%endif
%if %{with_vbox}
%package daemon-vbox
Summary: Server side daemon & driver required to run VirtualBox guests
Requires: libvirt-daemon = %{version}-%{release}
Requires: libvirt-daemon-driver-vbox = %{version}-%{release}
Requires: libvirt-daemon-driver-interface = %{version}-%{release}
Requires: libvirt-daemon-driver-network = %{version}-%{release}
Requires: libvirt-daemon-driver-nodedev = %{version}-%{release}
Requires: libvirt-daemon-driver-nwfilter = %{version}-%{release}
Requires: libvirt-daemon-driver-secret = %{version}-%{release}
Requires: libvirt-daemon-driver-storage = %{version}-%{release}
%description daemon-vbox
Server side daemon and driver required to manage the virtualization
capabilities of VirtualBox
%endif
%package client
Summary: Client side utilities of the libvirt library
Requires: %{name}-libs = %{version}-%{release}
# Needed by /usr/libexec/libvirt-guests.sh script.
Requires: gettext
# Needed by virt-pki-validate script.
Requires: gnutls-utils
%if %{with_bash_completion}
Requires: %{name}-bash-completion = %{version}-%{release}
%endif
%description client
The client binaries needed to access the virtualization
capabilities of recent versions of Linux (and other OSes).
%package libs
Summary: Client side libraries
# So remote clients can access libvirt over SSH tunnel
Requires: cyrus-sasl
# Needed by default sasl.conf - no onerous extra deps, since
# 100's of other things on a system already pull in krb5-libs
Requires: cyrus-sasl-gssapi
%description libs
Shared libraries for accessing the libvirt daemon.
%package admin
Summary: Set of tools to control libvirt daemon
Requires: %{name}-libs = %{version}-%{release}
%if %{with_bash_completion}
Requires: %{name}-bash-completion = %{version}-%{release}
%endif
%description admin
The client side utilities to control the libvirt daemon.
%if %{with_bash_completion}
%package bash-completion
Summary: Bash completion script
%description bash-completion
Bash completion script stub.
%endif
%if %{with_wireshark}
%package wireshark
Summary: Wireshark dissector plugin for libvirt RPC transactions
Requires: wireshark >= 2.4.0
Requires: %{name}-libs = %{version}-%{release}
%description wireshark
Wireshark dissector plugin for better analysis of libvirt RPC traffic.
%endif
%if %{with_lxc}
%package login-shell
Summary: Login shell for connecting users to an LXC container
Requires: %{name}-libs = %{version}-%{release}
%description login-shell
Provides the set-uid virt-login-shell binary that is used to
connect a user to an LXC container when they login, by switching
namespaces.
%endif
%package devel
Summary: Libraries, includes, etc. to compile with the libvirt library
Requires: %{name}-libs = %{version}-%{release}
Requires: pkgconfig
%description devel
Include header files & development libraries for the libvirt C library.
%if %{with_sanlock}
%package lock-sanlock
Summary: Sanlock lock manager plugin for QEMU driver
Requires: sanlock >= 2.4
#for virt-sanlock-cleanup require augeas
Requires: augeas
Requires: %{name}-daemon = %{version}-%{release}
Requires: %{name}-libs = %{version}-%{release}
%description lock-sanlock
Includes the Sanlock lock manager plugin for the QEMU
driver
%endif
%package nss
Summary: Libvirt plugin for Name Service Switch
Requires: libvirt-daemon-driver-network = %{version}-%{release}
%description nss
Libvirt plugin for NSS for translating domain names into IP addresses.
%prep
%autosetup -S git_am
%build
%if ! %{supported_platform}
echo "This RPM requires either Fedora >= %{min_fedora} or RHEL >= %{min_rhel}"
exit 1
%endif
%if %{with_qemu}
%define arg_qemu -Ddriver_qemu=enabled
%else
%define arg_qemu -Ddriver_qemu=disabled
%endif
%if %{with_openvz}
%define arg_openvz -Ddriver_openvz=enabled
%else
%define arg_openvz -Ddriver_openvz=disabled
2008-08-21 09:28:54 +00:00
%endif
%if %{with_lxc}
%define arg_lxc -Ddriver_lxc=enabled
%define arg_login_shell -Dlogin_shell=enabled
%else
%define arg_lxc -Ddriver_lxc=disabled
%define arg_login_shell -Dlogin_shell=disabled
2008-08-21 09:28:54 +00:00
%endif
%if %{with_vbox}
%define arg_vbox -Ddriver_vbox=enabled
%else
%define arg_vbox -Ddriver_vbox=disabled
%endif
%if %{with_libxl}
%define arg_libxl -Ddriver_libxl=enabled
%else
%define arg_libxl -Ddriver_libxl=disabled
%endif
%if %{with_esx}
%define arg_esx -Ddriver_esx=enabled
%else
%define arg_esx -Ddriver_esx=disabled
%endif
%if %{with_hyperv}
%define arg_hyperv -Ddriver_hyperv=enabled
%else
%define arg_hyperv -Ddriver_hyperv=disabled
%endif
%if %{with_vmware}
%define arg_vmware -Ddriver_vmware=enabled
%else
%define arg_vmware -Ddriver_vmware=disabled
%endif
%if %{with_storage_rbd}
%define arg_storage_rbd -Dstorage_rbd=enabled
%else
%define arg_storage_rbd -Dstorage_rbd=disabled
%endif
%if %{with_storage_sheepdog}
%define arg_storage_sheepdog -Dstorage_sheepdog=enabled
%else
%define arg_storage_sheepdog -Dstorage_sheepdog=disabled
%endif
%if %{with_storage_gluster}
%define arg_storage_gluster -Dstorage_gluster=enabled
%else
%define arg_storage_gluster -Dstorage_gluster=disabled
storage: initial support for linking with libgfapi We support gluster volumes in domain XML, so we also ought to support them as a storage pool. Besides, a future patch will want to take advantage of libgfapi to handle the case of a gluster device holding qcow2 rather than raw storage, and for that to work, we need a storage backend that can read gluster storage volume contents. This sets up the framework. Note that the new pool is named 'gluster' to match a <disk type='network'><source protocol='gluster'> image source already supported in a <domain>; it does NOT match the <pool type='netfs'><source><target type='glusterfs'>, since that uses a FUSE mount to a local file name rather than a network name. This and subsequent patches have been tested against glusterfs 3.4.1 (available on Fedora 19); there are likely bugs in older versions that may prevent decent use of gfapi, so this patch enforces the minimum version tested. A future patch may lower the minimum. On the other hand, I hit at least two bugs in 3.4.1 that will be fixed in 3.5/3.4.2, where it might be worth raising the minimum: glfs_readdir is nicer to use than glfs_readdir_r [1], and glfs_fini should only return failure on an actual failure [2]. [1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html [2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html * configure.ac (WITH_STORAGE_GLUSTER): New conditional. * m4/virt-gluster.m4: new file. * libvirt.spec.in (BuildRequires): Support gluster in spec file. * src/conf/storage_conf.h (VIR_STORAGE_POOL_GLUSTER): New pool type. * src/conf/storage_conf.c (poolTypeInfo): Treat similar to sheepdog and rbd. (virStoragePoolDefFormat): Don't output target for gluster. * src/storage/storage_backend_gluster.h: New file. * src/storage/storage_backend_gluster.c: Likewise. * po/POTFILES.in: Add new file. * src/storage/storage_backend.c (backends): Register new type. * src/Makefile.am (STORAGE_DRIVER_GLUSTER_SOURCES): Build new files. * src/storage/storage_backend.h (_virStorageBackend): Documet assumption. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-19 23:26:05 +00:00
%endif
%if %{with_storage_zfs}
%define arg_storage_zfs -Dstorage_zfs=enabled
%else
%define arg_storage_zfs -Dstorage_zfs=disabled
%endif
%if %{with_numactl}
%define arg_numactl -Dnumactl=enabled
%else
%define arg_numactl -Dnumactl=disabled
%endif
%if %{with_numad}
%define arg_numad -Dnumad=enabled
%else
%define arg_numad -Dnumad=disabled
%endif
%if %{with_fuse}
%define arg_fuse -Dfuse=enabled
%else
%define arg_fuse -Dfuse=disabled
%endif
%if %{with_sanlock}
%define arg_sanlock -Dsanlock=enabled
%else
%define arg_sanlock -Dsanlock=disabled
%endif
network: use firewalld instead of iptables, when available * configure.ac, spec file: firewalld defaults to enabled if dbus is available, otherwise is disabled. If --with_firewalld is explicitly requested and dbus is not available, configure will fail. * bridge_driver: add dbus filters to get the FirewallD1.Reloaded signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1. When these are encountered, reload all the iptables reuls of all libvirt's virtual networks (similar to what happens when libvirtd is restarted). * iptables, ebtables: use firewall-cmd's direct passthrough interface when available, otherwise use iptables and ebtables commands. This decision is made once the first time libvirt calls iptables/ebtables, and that decision is maintained for the life of libvirtd. * Note that the nwfilter part of this patch was separated out into another patch by Stefan in V2, so that needs to be revised and re-reviewed as well. ================ All the configure.ac and specfile changes are unchanged from Thomas' V3. V3 re-ran "firewall-cmd --state" every time a new rule was added, which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set up a one-time initialization function. The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called vir(Ip|Eb)OnceInit(), which will then be called the first time that the static function vir(Ip|Eb)TablesInitialize() is called (that function is defined for you by the macro). This is thread-safe, so there is no chance of any race. IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init functions (one for iptables, on for ebtables) as VIR_WARN so that I don't have to turn on all the other debug message just to see these. Even if this patch doesn't need any other modification, those messages need to be changed to VIR_DEBUG before pushing. This one-time initialization works well. However, I've encountered problems with testing: 1) Whenever I have enabled the firewalld service, *all* attempts to call firewall-cmd from within libvirtd end with firewall-cmd hanging internally somewhere. This is *not* the case if firewall-cmd returns non-0 in response to "firewall-cmd --state" (i.e. *that* command runs and returns to libvirt successfully.) 2) If I start libvirtd while firewalld is stopped, then start firewalld later, this triggers libvirtd to reload its iptables rules, however it also spits out a *ton* of complaints about deletion failing (I suppose because firewalld has nuked all of libvirt's rules). I guess we need to suppress those messages (which is a more annoying problem to fix than you might think, but that's another story). 3) I noticed a few times during this long line of errors that firewalld made a complaint about "Resource Temporarily unavailable. Having libvirtd access iptables commands directly at the same time as firewalld is doing so is apparently problematic. 4) In general, I'm concerned about the "set it once and never change it" method - if firewalld is disabled at libvirtd startup, causing libvirtd to always use iptables/ebtables directly, this won't cause *terrible* problems, but if libvirtd decides to use firewall-cmd and firewalld is later disabled, libvirtd will not be able to recover.
2012-08-14 18:59:52 +00:00
%if %{with_firewalld}
%define arg_firewalld -Dfirewalld=enabled
%else
%define arg_firewalld -Dfirewalld=disabled
network: use firewalld instead of iptables, when available * configure.ac, spec file: firewalld defaults to enabled if dbus is available, otherwise is disabled. If --with_firewalld is explicitly requested and dbus is not available, configure will fail. * bridge_driver: add dbus filters to get the FirewallD1.Reloaded signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1. When these are encountered, reload all the iptables reuls of all libvirt's virtual networks (similar to what happens when libvirtd is restarted). * iptables, ebtables: use firewall-cmd's direct passthrough interface when available, otherwise use iptables and ebtables commands. This decision is made once the first time libvirt calls iptables/ebtables, and that decision is maintained for the life of libvirtd. * Note that the nwfilter part of this patch was separated out into another patch by Stefan in V2, so that needs to be revised and re-reviewed as well. ================ All the configure.ac and specfile changes are unchanged from Thomas' V3. V3 re-ran "firewall-cmd --state" every time a new rule was added, which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set up a one-time initialization function. The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called vir(Ip|Eb)OnceInit(), which will then be called the first time that the static function vir(Ip|Eb)TablesInitialize() is called (that function is defined for you by the macro). This is thread-safe, so there is no chance of any race. IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init functions (one for iptables, on for ebtables) as VIR_WARN so that I don't have to turn on all the other debug message just to see these. Even if this patch doesn't need any other modification, those messages need to be changed to VIR_DEBUG before pushing. This one-time initialization works well. However, I've encountered problems with testing: 1) Whenever I have enabled the firewalld service, *all* attempts to call firewall-cmd from within libvirtd end with firewall-cmd hanging internally somewhere. This is *not* the case if firewall-cmd returns non-0 in response to "firewall-cmd --state" (i.e. *that* command runs and returns to libvirt successfully.) 2) If I start libvirtd while firewalld is stopped, then start firewalld later, this triggers libvirtd to reload its iptables rules, however it also spits out a *ton* of complaints about deletion failing (I suppose because firewalld has nuked all of libvirt's rules). I guess we need to suppress those messages (which is a more annoying problem to fix than you might think, but that's another story). 3) I noticed a few times during this long line of errors that firewalld made a complaint about "Resource Temporarily unavailable. Having libvirtd access iptables commands directly at the same time as firewalld is doing so is apparently problematic. 4) In general, I'm concerned about the "set it once and never change it" method - if firewalld is disabled at libvirtd startup, causing libvirtd to always use iptables/ebtables directly, this won't cause *terrible* problems, but if libvirtd decides to use firewall-cmd and firewalld is later disabled, libvirtd will not be able to recover.
2012-08-14 18:59:52 +00:00
%endif
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%if %{with_firewalld_zone}
%define arg_firewalld_zone -Dfirewalld_zone=enabled
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%else
%define arg_firewalld_zone -Dfirewalld_zone=disabled
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%endif
%if %{with_wireshark}
%define arg_wireshark -Dwireshark_dissector=enabled
%else
%define arg_wireshark -Dwireshark_dissector=disabled
%endif
%if %{with_storage_iscsi_direct}
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=enabled
%else
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=disabled
%endif
%define when %(date +"%%F-%%T")
%define where %(hostname)
%define who %{?packager}%{!?packager:Unknown}
%define arg_packager -Dpackager="%{who}, %{when}, %{where}"
%define arg_packager_version -Dpackager_version="%{release}"
%define arg_selinux_mount -Dselinux_mount="/sys/fs/selinux"
# place macros above and build commands below this comment
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec)
%meson \
-Drunstatedir=%{_rundir} \
%{?arg_qemu} \
%{?arg_openvz} \
%{?arg_lxc} \
%{?arg_vbox} \
%{?arg_libxl} \
-Dsasl=enabled \
-Dpolkit=enabled \
-Ddriver_libvirtd=enabled \
%{?arg_esx} \
%{?arg_hyperv} \
%{?arg_vmware} \
-Ddriver_vz=disabled \
-Ddriver_bhyve=disabled \
-Dremote_default_mode=legacy \
-Ddriver_interface=enabled \
-Ddriver_network=enabled \
-Dstorage_fs=enabled \
-Dstorage_lvm=enabled \
-Dstorage_iscsi=enabled \
%{?arg_storage_iscsi_direct} \
-Dstorage_scsi=enabled \
-Dstorage_disk=enabled \
-Dstorage_mpath=enabled \
%{?arg_storage_rbd} \
%{?arg_storage_sheepdog} \
%{?arg_storage_gluster} \
%{?arg_storage_zfs} \
-Dstorage_vstorage=disabled \
%{?arg_numactl} \
%{?arg_numad} \
-Dcapng=enabled \
%{?arg_fuse} \
-Dnetcf=enabled \
-Dselinux=enabled \
%{?arg_selinux_mount} \
-Dapparmor=disabled \
-Dsecdriver_apparmor=disabled \
-Dudev=enabled \
-Dyajl=enabled \
%{?arg_sanlock} \
-Dlibpcap=enabled \
-Daudit=enabled \
-Ddtrace=enabled \
%{?arg_firewalld} \
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%{?arg_firewalld_zone} \
%{?arg_wireshark} \
-Dpm_utils=disabled \
-Dnss=enabled \
%{arg_packager} \
%{arg_packager_version} \
-Dqemu_user=%{qemu_user} \
-Dqemu_group=%{qemu_group} \
-Dtls_priority=%{tls_priority} \
%{?enable_werror} \
-Dexpensive_tests=enabled \
-Dinit_script=systemd \
%{?arg_login_shell}
%meson_build
%install
rm -fr %{buildroot}
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec)
%meson_install
rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
rm -f $RPM_BUILD_ROOT%{_libdir}/*.a
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/lock-driver/*.la
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/lock-driver/*.a
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/connection-driver/*.la
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/connection-driver/*.a
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-backend/*.la
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-backend/*.a
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-file/*.la
rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-file/*.a
%if %{with_wireshark}
rm -f $RPM_BUILD_ROOT%{wireshark_plugindir}/libvirt.la
%endif
install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/lib/libvirt/dnsmasq/
# We don't want to install /etc/libvirt/qemu/networks in the main %files list
# because if the admin wants to delete the default network completely, we don't
# want to end up re-incarnating it on every RPM upgrade.
install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/
cp $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml \
$RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml
# libvirt saves this file with mode 0600
chmod 0600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml
# nwfilter files are installed in /usr/share/libvirt and copied to /etc in %post
# to avoid verification errors on changed files in /etc
install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/nwfilter/
cp -a $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter/*.xml \
$RPM_BUILD_ROOT%{_datadir}/libvirt/nwfilter/
# libvirt saves these files with mode 600
chmod 600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter/*.xml
2007-03-12 16:32:43 +00:00
# Strip auto-generated UUID - we need it generated per-install
sed -i -e "/<uuid>/d" $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml
%if ! %{with_qemu}
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_qemu.aug
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_qemu.aug
%endif
%find_lang %{name}
%if ! %{with_sanlock}
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirt_sanlock.aug
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirt_sanlock.aug
%endif
%if ! %{with_lxc}
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_lxc.aug
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_lxc.aug
%endif
%if ! %{with_qemu}
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu.conf
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.qemu
%endif
%if ! %{with_lxc}
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/lxc.conf
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.lxc
%endif
%if ! %{with_libxl}
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/libxl.conf
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.libxl
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_libxl.aug
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_libxl.aug
%endif
# Copied into libvirt-docs subpackage eventually
mv $RPM_BUILD_ROOT%{_datadir}/doc/libvirt libvirt-docs
%ifarch %{power64} s390x x86_64 aarch64 riscv64
mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_probes.stp \
$RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_probes-64.stp
%if %{with_qemu}
mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \
$RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes-64.stp
%endif
%endif
%check
VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check
%post libs
%if 0%{?rhel} == 7
/sbin/ldconfig
%endif
%postun libs
%if 0%{?rhel} == 7
/sbin/ldconfig
%endif
%pre daemon
# 'libvirt' group is just to allow password-less polkit access to
# libvirtd. The uid number is irrelevant, so we use dynamic allocation
# described at the above link.
getent group libvirt >/dev/null || groupadd -r libvirt
exit 0
%post daemon
%systemd_post virtlockd.socket virtlockd-admin.socket
%systemd_post virtlogd.socket virtlogd-admin.socket
%systemd_post libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
%systemd_post libvirtd-tcp.socket libvirtd-tls.socket
%systemd_post libvirtd.service
# request daemon restart in posttrans
mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || :
touch %{_localstatedir}/lib/rpm-state/libvirt/restart || :
%preun daemon
%systemd_preun libvirtd.service
%systemd_preun libvirtd-tcp.socket libvirtd-tls.socket
%systemd_preun libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
%systemd_preun virtlogd.socket virtlogd-admin.socket virtlogd.service
%systemd_preun virtlockd.socket virtlockd-admin.socket virtlockd.service
%postun daemon
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
/bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || :
/bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || :
fi
# In upgrade scenario we must explicitly enable virtlockd/virtlogd
# sockets, if libvirtd is already enabled and start them if
# libvirtd is running, otherwise you'll get failures to start
# guests
%triggerpostun daemon -- libvirt-daemon < 1.3.0
if [ $1 -ge 1 ] ; then
/bin/systemctl is-enabled libvirtd.service 1>/dev/null 2>&1 &&
/bin/systemctl enable virtlogd.socket virtlogd-admin.socket || :
/bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1 &&
/bin/systemctl start virtlogd.socket virtlogd-admin.socket || :
fi
%posttrans daemon
if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then
# See if user has previously modified their install to
# tell libvirtd to use --listen
grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1
if test $? = 0
then
# Then lets keep honouring --listen and *not* use
# systemd socket activation, because switching things
# might confuse mgmt tool like puppet/ansible that
# expect the old style libvirtd
/bin/systemctl mask libvirtd.socket >/dev/null 2>&1 || :
/bin/systemctl mask libvirtd-ro.socket >/dev/null 2>&1 || :
/bin/systemctl mask libvirtd-admin.socket >/dev/null 2>&1 || :
/bin/systemctl mask libvirtd-tls.socket >/dev/null 2>&1 || :
/bin/systemctl mask libvirtd-tcp.socket >/dev/null 2>&1 || :
else
# Old libvirtd owns the sockets and will delete them on
# shutdown. Can't use a try-restart as libvirtd will simply
# own the sockets again when it comes back up. Thus we must
# do this particular ordering, so that we get libvirtd
# running with socket activation in use
/bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1
if test $? = 0
then
/bin/systemctl stop libvirtd.service >/dev/null 2>&1 || :
/bin/systemctl try-restart libvirtd.socket >/dev/null 2>&1 || :
/bin/systemctl try-restart libvirtd-ro.socket >/dev/null 2>&1 || :
/bin/systemctl try-restart libvirtd-admin.socket >/dev/null 2>&1 || :
/bin/systemctl start libvirtd.service >/dev/null 2>&1 || :
fi
fi
fi
rm -rf %{_localstatedir}/lib/rpm-state/libvirt || :
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%post daemon-driver-network
%if %{with_firewalld_zone}
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%firewalld_reload
%endif
%postun daemon-driver-network
%if %{with_firewalld_zone}
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%firewalld_reload
%endif
%post daemon-config-network
if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then
network: try to eliminate default network conflict during package install Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its own networks). This patch attempts to catch the problem earlier - at install time. During the %post install script for libvirt-daemon-config-network, we use a case statement to look through the output of "ip route show" for a route that exactly matches 192.168.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.124.0/24) (note that the search starts with "124" instead of 123 because of reports of people already modifying their L1 host's network to 192.168.123.0/24 in an attempt to solve exactly the problem we are also trying to solve). When we find an available route, we just replace all occurrences of "122" in the default.xml that is being created with the newly found 192.168 subnet. This could obviously be made more complicated - examine the template defaul.xml to automatically determine the existing network address and mask rather than hard coding it in the specfile, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" occurrence of the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967
2014-09-10 17:10:45 +00:00
# see if the network used by default network creates a conflict,
# and try to resolve it
# NB: 192.168.122.0/24 is used in the default.xml template file;
# do not modify any of those values here without also modifying
# them in the template.
orig_sub=122
sub=${orig_sub}
nl='
'
routes="${nl}$(ip route show | cut -d' ' -f1)${nl}"
network: try to eliminate default network conflict during package install Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its own networks). This patch attempts to catch the problem earlier - at install time. During the %post install script for libvirt-daemon-config-network, we use a case statement to look through the output of "ip route show" for a route that exactly matches 192.168.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.124.0/24) (note that the search starts with "124" instead of 123 because of reports of people already modifying their L1 host's network to 192.168.123.0/24 in an attempt to solve exactly the problem we are also trying to solve). When we find an available route, we just replace all occurrences of "122" in the default.xml that is being created with the newly found 192.168 subnet. This could obviously be made more complicated - examine the template defaul.xml to automatically determine the existing network address and mask rather than hard coding it in the specfile, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" occurrence of the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967
2014-09-10 17:10:45 +00:00
case ${routes} in
*"${nl}192.168.${orig_sub}.0/24${nl}"*)
# there was a match, so we need to look for an unused subnet
for new_sub in $(seq 124 254); do
case ${routes} in
*"${nl}192.168.${new_sub}.0/24${nl}"*)
;;
*)
sub=$new_sub
break;
;;
esac
done
;;
*)
;;
esac
UUID=`/usr/bin/uuidgen`
network: try to eliminate default network conflict during package install Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its own networks). This patch attempts to catch the problem earlier - at install time. During the %post install script for libvirt-daemon-config-network, we use a case statement to look through the output of "ip route show" for a route that exactly matches 192.168.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.124.0/24) (note that the search starts with "124" instead of 123 because of reports of people already modifying their L1 host's network to 192.168.123.0/24 in an attempt to solve exactly the problem we are also trying to solve). When we find an available route, we just replace all occurrences of "122" in the default.xml that is being created with the newly found 192.168 subnet. This could obviously be made more complicated - examine the template defaul.xml to automatically determine the existing network address and mask rather than hard coding it in the specfile, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" occurrence of the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967
2014-09-10 17:10:45 +00:00
sed -e "s/${orig_sub}/${sub}/g" \
-e "s,</name>,</name>\n <uuid>$UUID</uuid>," \
< %{_datadir}/libvirt/networks/default.xml \
> %{_sysconfdir}/libvirt/qemu/networks/default.xml
ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
# libvirt saves this file with mode 0600
chmod 0600 %{_sysconfdir}/libvirt/qemu/networks/default.xml
# Make sure libvirt picks up the new network defininiton
mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || :
touch %{_localstatedir}/lib/rpm-state/libvirt/restart || :
fi
%posttrans daemon-config-network
if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then
/bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || :
fi
rm -rf %{_localstatedir}/lib/rpm-state/libvirt || :
%post daemon-config-nwfilter
cp %{_datadir}/libvirt/nwfilter/*.xml %{_sysconfdir}/libvirt/nwfilter/
# libvirt saves these files with mode 600
chmod 600 %{_sysconfdir}/libvirt/nwfilter/*.xml
# Make sure libvirt picks up the new nwfilter defininitons
mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || :
touch %{_localstatedir}/lib/rpm-state/libvirt/restart || :
%posttrans daemon-config-nwfilter
if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then
/bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || :
fi
rm -rf %{_localstatedir}/lib/rpm-state/libvirt || :
%if %{with_qemu}
%pre daemon-driver-qemu
# We want soft static allocation of well-known ids, as disk images
# are commonly shared across NFS mounts by id rather than name; see
# https://fedoraproject.org/wiki/Packaging:UsersAndGroups
getent group kvm >/dev/null || groupadd -f -g 36 -r kvm
getent group qemu >/dev/null || groupadd -f -g 107 -r qemu
if ! getent passwd qemu >/dev/null; then
if ! getent passwd 107 >/dev/null; then
useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu
else
useradd -r -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu
fi
fi
exit 0
%endif
%preun client
%systemd_preun libvirt-guests.service
%post client
%systemd_post libvirt-guests.service
%postun client
%systemd_postun libvirt-guests.service
%if %{with_lxc}
%pre login-shell
getent group virtlogin >/dev/null || groupadd -r virtlogin
exit 0
%endif
%files
Refactor the libvirt RPM daemon pieces There are a number of flaws with our packaging of the libvirtd daemon: - Installing 'libvirt' does not install 'qemu-kvm' or 'xen' etc which are required to actually run the hypervisor in question - Installing 'libvirt' pulls in the default configuration files which may not be wanted & cause problems if installed inside a guest - It is not possible to explicitly required all the peices required to manage a specific hypervisor This change takes the 'libvirt' RPM and and changes it thus - libvirt: just a virtual package with dep on libvirt-daemon, libvirt-daemon-config-network & libvirt-daemon-config-nwfilter - libvirt-daemon: the libvirt daemon and related pieces - libvirt-daemon-config-network: the default network config - libvirt-daemon-config-nwfilter: the network filter configs - libvirt-docs: the website HTML We then introduce some more virtual (empty) packages - libvirt-daemon-qemu: Deps on libvirt-daemon & 'qemu' - libvirt-daemon-kvm: Deps on libvirt-daemon & 'qemu-kvm' - libvirt-daemon-lxc: Deps on libvirt-daemon - libvirt-daemon-uml: Deps on libvirt-daemon - libvirt-daemon-xen: Deps on libvirt-daemon & 'xen' - libvirt-qemu: Deps on libvirt-daemon-qemu & libvirt-daemon-config-{network,nwfilter} - libvirt-kvm: Deps on libvirt-daemon-kvm & libvirt-daemon-config-{network,nwfilter} - libvirt-lxc: Deps on libvirt-daemon-lxc & libvirt-daemon-config-{network,nwfilter} - libvirt-uml: Deps on libvirt-daemon-uml & libvirt-daemon-config-{network,nwfilter} - libvirt-xen: Deps on libvirt-daemon-xen & libvirt-daemon-config-network My intent in the future is to turn on the driver modules by default, at which time 'libvirt-daemon' will cease to include any specific drivers, instead we'll get libvirt-daemon-driver-XXXX packages for each driver. The libvirt-daemon-XXX packages will then pull in each driver that they require. It is recommended that applications required a locally installed libvirtd daemon, use either 'Requires: libvirt-daemon-XXXX' or 'Requires: libvirt-XXX' and *not* "Requires: libvirt-daemon" or 'Requires: libvirt' * libvirt.spec.in: Refactor RPMs * docs/packaging.html.in, docs/sitemap.html.in: Document new RPM split rationale
2012-03-30 13:14:00 +00:00
%files docs
%doc AUTHORS.rst NEWS.rst README.rst
%doc libvirt-docs/*
%files daemon
2007-03-12 16:32:43 +00:00
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/
%{_unitdir}/libvirtd.service
%{_unitdir}/libvirtd.socket
%{_unitdir}/libvirtd-ro.socket
%{_unitdir}/libvirtd-admin.socket
%{_unitdir}/libvirtd-tcp.socket
%{_unitdir}/libvirtd-tls.socket
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
%{_unitdir}/virtproxyd.service
%{_unitdir}/virtproxyd.socket
%{_unitdir}/virtproxyd-ro.socket
%{_unitdir}/virtproxyd-admin.socket
%{_unitdir}/virtproxyd-tcp.socket
%{_unitdir}/virtproxyd-tls.socket
%{_unitdir}/virt-guest-shutdown.target
%{_unitdir}/virtlogd.service
%{_unitdir}/virtlogd.socket
%{_unitdir}/virtlogd-admin.socket
%{_unitdir}/virtlockd.service
%{_unitdir}/virtlockd.socket
%{_unitdir}/virtlockd-admin.socket
%config(noreplace) %{_sysconfdir}/sysconfig/libvirtd
%config(noreplace) %{_sysconfdir}/sysconfig/virtproxyd
%config(noreplace) %{_sysconfdir}/sysconfig/virtlogd
%config(noreplace) %{_sysconfdir}/sysconfig/virtlockd
%config(noreplace) %{_sysconfdir}/libvirt/libvirtd.conf
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
%config(noreplace) %{_sysconfdir}/libvirt/virtproxyd.conf
%config(noreplace) %{_sysconfdir}/libvirt/virtlogd.conf
%config(noreplace) %{_sysconfdir}/libvirt/virtlockd.conf
%config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf
%config(noreplace) %{_prefix}/lib/sysctl.d/60-libvirtd.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd
%dir %{_datadir}/libvirt/
%ghost %dir %{_rundir}/libvirt/
%dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/
%dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/
%dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/
%dir %attr(0711, root, root) %{_localstatedir}/cache/libvirt/
%dir %attr(0755, root, root) %{_libdir}/libvirt/
%dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/
%dir %attr(0755, root, root) %{_libdir}/libvirt/lock-driver
%attr(0755, root, root) %{_libdir}/libvirt/lock-driver/lockd.so
%{_datadir}/augeas/lenses/libvirtd.aug
%{_datadir}/augeas/lenses/tests/test_libvirtd.aug
%{_datadir}/augeas/lenses/virtlogd.aug
%{_datadir}/augeas/lenses/tests/test_virtlogd.aug
%{_datadir}/augeas/lenses/virtlockd.aug
%{_datadir}/augeas/lenses/tests/test_virtlockd.aug
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
%{_datadir}/augeas/lenses/virtproxyd.aug
%{_datadir}/augeas/lenses/tests/test_virtproxyd.aug
%{_datadir}/augeas/lenses/libvirt_lockd.aug
%if %{with_qemu}
%{_datadir}/augeas/lenses/tests/test_libvirt_lockd.aug
%endif
%{_datadir}/polkit-1/actions/org.libvirt.unix.policy
%{_datadir}/polkit-1/actions/org.libvirt.api.policy
%{_datadir}/polkit-1/rules.d/50-libvirt.rules
%dir %attr(0700, root, root) %{_localstatedir}/log/libvirt/
%attr(0755, root, root) %{_libexecdir}/libvirt_iohelper
%attr(0755, root, root) %{_bindir}/virt-ssh-helper
2007-06-26 23:04:49 +00:00
%attr(0755, root, root) %{_sbindir}/libvirtd
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
%attr(0755, root, root) %{_sbindir}/virtproxyd
%attr(0755, root, root) %{_sbindir}/virtlogd
%attr(0755, root, root) %{_sbindir}/virtlockd
%{_mandir}/man8/libvirtd.8*
%{_mandir}/man8/virtlogd.8*
%{_mandir}/man8/virtlockd.8*
%{_mandir}/man7/virkey*.7*
%files daemon-config-network
%dir %{_datadir}/libvirt/networks/
%{_datadir}/libvirt/networks/default.xml
%ghost %{_sysconfdir}/libvirt/qemu/networks/default.xml
%ghost %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
%files daemon-config-nwfilter
%dir %{_datadir}/libvirt/nwfilter/
%{_datadir}/libvirt/nwfilter/*.xml
%ghost %{_sysconfdir}/libvirt/nwfilter/*.xml
%files daemon-driver-interface
%config(noreplace) %{_sysconfdir}/sysconfig/virtinterfaced
%config(noreplace) %{_sysconfdir}/libvirt/virtinterfaced.conf
%{_datadir}/augeas/lenses/virtinterfaced.aug
%{_datadir}/augeas/lenses/tests/test_virtinterfaced.aug
%{_unitdir}/virtinterfaced.service
%{_unitdir}/virtinterfaced.socket
%{_unitdir}/virtinterfaced-ro.socket
%{_unitdir}/virtinterfaced-admin.socket
%attr(0755, root, root) %{_sbindir}/virtinterfaced
%{_libdir}/%{name}/connection-driver/libvirt_driver_interface.so
%files daemon-driver-network
%config(noreplace) %{_sysconfdir}/sysconfig/virtnetworkd
%config(noreplace) %{_sysconfdir}/libvirt/virtnetworkd.conf
%{_datadir}/augeas/lenses/virtnetworkd.aug
%{_datadir}/augeas/lenses/tests/test_virtnetworkd.aug
%{_unitdir}/virtnetworkd.service
%{_unitdir}/virtnetworkd.socket
%{_unitdir}/virtnetworkd-ro.socket
%{_unitdir}/virtnetworkd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtnetworkd
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/qemu/
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/qemu/networks/
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/qemu/networks/autostart
%ghost %dir %{_rundir}/libvirt/network/
%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/network/
%dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/dnsmasq/
%attr(0755, root, root) %{_libexecdir}/libvirt_leaseshelper
%{_libdir}/%{name}/connection-driver/libvirt_driver_network.so
configure: selectively install a firewalld 'libvirt' zone In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted. But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted. This causes pain because 1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.) 2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host). libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules). However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host). Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass and list specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP). But the same default accept policy that fixes forwarded traffic also causes *all* traffic from guest to host to be accepted. To close this new hole, the libvirt zone can take advantage of a new feature in firewalld (currently slated for firewalld-0.7.0) - priorities for rich rules - to add a low priority rule that rejects all local traffic (but leaves alone all forwarded traffic). So, our new zone will start with a list of services that are allowed (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld management application, or direct editing of the zone file in /etc/firewalld/zones/libvirt.xml), followed by a low priority <reject/> rule (to reject all other traffic from guest to host), and finally with a default policy of accept (to allow forwarded traffic). This patch only creates the zonefile for the new zone, and implements a configure.ac option to selectively enable/disable installation of the new zone. A separate patch contains the necessary code to actually place bridge interfaces in the libvirt zone. Why do we need a configure option to disable installation of the new libvirt zone? It uses a new firewalld attribute that sets the priority of a rich rule; this feature first appears in firewalld-0.7.0 (unless it has been backported to am earlier firewalld by a downstream maintainer). If the file were installed on a system with firewalld that didn't support rule priorities, firewalld would log an error every time it restarted, causing confusion and lots of extra bug reports. So we add two new configure.ac switches to avoid polluting the system logs with this error on systems that don't support rule priorities - "--with-firewalld-zone" and "--without-firewalld-zone". A package builder can use these to include/exclude the libvirt zone file in the installation. If firewalld is enabled (--with-firewalld), the default is --with-firewalld-zone, but it can be disabled during configure (using --without-firewalld-zone). Targets that are using a firewalld version too old to support the rule priority setting in the libvirt zone file can simply add --without-firewalld-zone to their configure commandline. These switches only affect whether or not the libvirt zone file is *installed* in /usr/lib/firewalld/zones, but have no effect on whether or not libvirt looks for a zone called libvirt and tries to use it. NB: firewalld zones can only be added to the permanent config of firewalld, and won't be loaded/enabled until firewalld is restarted, so at package install/upgrade time we have to restart firewalld. For rpm-based distros, this is done in the libvirt.spec file by calling the %firewalld_restart rpm macro, which is a part of the firewalld-filesystem package. (For distros that don't use rpm packages, the command "firewalld-cmd --reload" will have the same effect). Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
%if %{with_firewalld_zone}
%{_prefix}/lib/firewalld/zones/libvirt.xml
%endif
%files daemon-driver-nodedev
%config(noreplace) %{_sysconfdir}/sysconfig/virtnodedevd
%config(noreplace) %{_sysconfdir}/libvirt/virtnodedevd.conf
%{_datadir}/augeas/lenses/virtnodedevd.aug
%{_datadir}/augeas/lenses/tests/test_virtnodedevd.aug
%{_unitdir}/virtnodedevd.service
%{_unitdir}/virtnodedevd.socket
%{_unitdir}/virtnodedevd-ro.socket
%{_unitdir}/virtnodedevd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtnodedevd
%{_libdir}/%{name}/connection-driver/libvirt_driver_nodedev.so
%files daemon-driver-nwfilter
%config(noreplace) %{_sysconfdir}/sysconfig/virtnwfilterd
%config(noreplace) %{_sysconfdir}/libvirt/virtnwfilterd.conf
%{_datadir}/augeas/lenses/virtnwfilterd.aug
%{_datadir}/augeas/lenses/tests/test_virtnwfilterd.aug
%{_unitdir}/virtnwfilterd.service
%{_unitdir}/virtnwfilterd.socket
%{_unitdir}/virtnwfilterd-ro.socket
%{_unitdir}/virtnwfilterd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtnwfilterd
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/nwfilter/
%ghost %dir %{_rundir}/libvirt/network/
%{_libdir}/%{name}/connection-driver/libvirt_driver_nwfilter.so
%files daemon-driver-secret
%config(noreplace) %{_sysconfdir}/sysconfig/virtsecretd
%config(noreplace) %{_sysconfdir}/libvirt/virtsecretd.conf
%{_datadir}/augeas/lenses/virtsecretd.aug
%{_datadir}/augeas/lenses/tests/test_virtsecretd.aug
%{_unitdir}/virtsecretd.service
%{_unitdir}/virtsecretd.socket
%{_unitdir}/virtsecretd-ro.socket
%{_unitdir}/virtsecretd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtsecretd
%{_libdir}/%{name}/connection-driver/libvirt_driver_secret.so
%files daemon-driver-storage
%files daemon-driver-storage-core
%config(noreplace) %{_sysconfdir}/sysconfig/virtstoraged
%config(noreplace) %{_sysconfdir}/libvirt/virtstoraged.conf
%{_datadir}/augeas/lenses/virtstoraged.aug
%{_datadir}/augeas/lenses/tests/test_virtstoraged.aug
%{_unitdir}/virtstoraged.service
%{_unitdir}/virtstoraged.socket
%{_unitdir}/virtstoraged-ro.socket
%{_unitdir}/virtstoraged-admin.socket
%attr(0755, root, root) %{_sbindir}/virtstoraged
%attr(0755, root, root) %{_libexecdir}/libvirt_parthelper
%{_libdir}/%{name}/connection-driver/libvirt_driver_storage.so
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_fs.so
%{_libdir}/%{name}/storage-file/libvirt_storage_file_fs.so
%files daemon-driver-storage-disk
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_disk.so
%files daemon-driver-storage-logical
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_logical.so
%files daemon-driver-storage-scsi
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_scsi.so
%files daemon-driver-storage-iscsi
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_iscsi.so
%if %{with_storage_iscsi_direct}
%files daemon-driver-storage-iscsi-direct
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_iscsi-direct.so
%endif
%files daemon-driver-storage-mpath
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_mpath.so
%if %{with_storage_gluster}
%files daemon-driver-storage-gluster
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_gluster.so
%{_libdir}/%{name}/storage-file/libvirt_storage_file_gluster.so
%endif
%if %{with_storage_rbd}
%files daemon-driver-storage-rbd
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_rbd.so
%endif
%if %{with_storage_sheepdog}
%files daemon-driver-storage-sheepdog
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_sheepdog.so
%endif
%if %{with_storage_zfs}
%files daemon-driver-storage-zfs
%{_libdir}/%{name}/storage-backend/libvirt_storage_backend_zfs.so
%endif
%if %{with_qemu}
%files daemon-driver-qemu
%config(noreplace) %{_sysconfdir}/sysconfig/virtqemud
%config(noreplace) %{_sysconfdir}/libvirt/virtqemud.conf
%{_datadir}/augeas/lenses/virtqemud.aug
%{_datadir}/augeas/lenses/tests/test_virtqemud.aug
%{_unitdir}/virtqemud.service
%{_unitdir}/virtqemud.socket
%{_unitdir}/virtqemud-ro.socket
%{_unitdir}/virtqemud-admin.socket
%attr(0755, root, root) %{_sbindir}/virtqemud
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/qemu/
%dir %attr(0700, root, root) %{_localstatedir}/log/libvirt/qemu/
%config(noreplace) %{_sysconfdir}/libvirt/qemu.conf
%config(noreplace) %{_sysconfdir}/libvirt/qemu-lockd.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.qemu
%ghost %dir %{_rundir}/libvirt/qemu/
%dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/
%dir %attr(0750, %{qemu_user}, %{qemu_group}) %{_localstatedir}/cache/libvirt/qemu/
%{_datadir}/augeas/lenses/libvirtd_qemu.aug
%{_datadir}/augeas/lenses/tests/test_libvirtd_qemu.aug
%{_libdir}/%{name}/connection-driver/libvirt_driver_qemu.so
%dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/swtpm/
%dir %attr(0711, root, root) %{_localstatedir}/log/swtpm/libvirt/qemu/
qemu: introduce a new "virt-qemu-run" program The previous "QEMU shim" proof of concept was taking an approach of only caring about initial spawning of the QEMU process. It was then registered with the libvirtd daemon who took over management of it. The intent was that later libvirtd would be refactored so that the shim retained control over the QEMU monitor and libvirt just forwarded APIs to each shim as needed. This forwarding of APIs would require quite alot of significant refactoring of libvirtd to achieve. This impl thus takes a quite different approach, explicitly deciding to keep the VMs completely separate from those seen & managed by libvirtd. Instead it uses the new "qemu:///embed" URI scheme to embed the entire QEMU driver in the shim, running with a custom root directory. Once the driver is initialization, the shim starts a VM and then waits to shutdown automatically when QEMU shuts down, or should kill QEMU if it is terminated itself. This ought to use the AUTO_DESTROY feature but that is not yet available in embedded mode, so we rely on installing a few signal handlers to gracefully kill QEMU. This isn't reliable if we crash of course, but you can restart with the same root dir. Note this program does not expose any way to manage the QEMU process, since there's no RPC interface enabled. It merely starts the VM and cleans up when the guest shuts down at the end. This program is installed to /usr/bin/virt-qemu-run enabling direct use by end users. Most use cases will probably want to integrate the concept directly into their respective application codebases. This standalone binary serves as a nice demo though, and also provides a way to measure performance of the startup process quite simply. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-05-17 12:01:59 +00:00
%{_bindir}/virt-qemu-run
%{_mandir}/man1/virt-qemu-run.1*
%endif
%if %{with_lxc}
%files daemon-driver-lxc
%config(noreplace) %{_sysconfdir}/sysconfig/virtlxcd
%config(noreplace) %{_sysconfdir}/libvirt/virtlxcd.conf
%{_datadir}/augeas/lenses/virtlxcd.aug
%{_datadir}/augeas/lenses/tests/test_virtlxcd.aug
%{_unitdir}/virtlxcd.service
%{_unitdir}/virtlxcd.socket
%{_unitdir}/virtlxcd-ro.socket
%{_unitdir}/virtlxcd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtlxcd
%dir %attr(0700, root, root) %{_localstatedir}/log/libvirt/lxc/
%config(noreplace) %{_sysconfdir}/libvirt/lxc.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.lxc
%ghost %dir %{_rundir}/libvirt/lxc/
%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/lxc/
%{_datadir}/augeas/lenses/libvirtd_lxc.aug
%{_datadir}/augeas/lenses/tests/test_libvirtd_lxc.aug
%attr(0755, root, root) %{_libexecdir}/libvirt_lxc
%{_libdir}/%{name}/connection-driver/libvirt_driver_lxc.so
%endif
%if %{with_libxl}
%files daemon-driver-libxl
%config(noreplace) %{_sysconfdir}/sysconfig/virtxend
%config(noreplace) %{_sysconfdir}/libvirt/virtxend.conf
%{_datadir}/augeas/lenses/virtxend.aug
%{_datadir}/augeas/lenses/tests/test_virtxend.aug
%{_unitdir}/virtxend.service
%{_unitdir}/virtxend.socket
%{_unitdir}/virtxend-ro.socket
%{_unitdir}/virtxend-admin.socket
%attr(0755, root, root) %{_sbindir}/virtxend
%config(noreplace) %{_sysconfdir}/libvirt/libxl.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.libxl
%config(noreplace) %{_sysconfdir}/libvirt/libxl-lockd.conf
%{_datadir}/augeas/lenses/libvirtd_libxl.aug
%{_datadir}/augeas/lenses/tests/test_libvirtd_libxl.aug
%dir %attr(0700, root, root) %{_localstatedir}/log/libvirt/libxl/
%ghost %dir %{_rundir}/libvirt/libxl/
%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/libxl/
%{_libdir}/%{name}/connection-driver/libvirt_driver_libxl.so
%endif
%if %{with_vbox}
%files daemon-driver-vbox
%config(noreplace) %{_sysconfdir}/sysconfig/virtvboxd
%config(noreplace) %{_sysconfdir}/libvirt/virtvboxd.conf
%{_datadir}/augeas/lenses/virtvboxd.aug
%{_datadir}/augeas/lenses/tests/test_virtvboxd.aug
%{_unitdir}/virtvboxd.service
%{_unitdir}/virtvboxd.socket
%{_unitdir}/virtvboxd-ro.socket
%{_unitdir}/virtvboxd-admin.socket
%attr(0755, root, root) %{_sbindir}/virtvboxd
%{_libdir}/%{name}/connection-driver/libvirt_driver_vbox.so
%endif
%if %{with_qemu_tcg}
%files daemon-qemu
%endif
%if %{with_qemu_kvm}
%files daemon-kvm
%endif
%if %{with_lxc}
%files daemon-lxc
%endif
%if %{with_libxl}
%files daemon-xen
%endif
%if %{with_vbox}
%files daemon-vbox
%endif
%if %{with_sanlock}
%files lock-sanlock
%if %{with_qemu}
%config(noreplace) %{_sysconfdir}/libvirt/qemu-sanlock.conf
%endif
%if %{with_libxl}
%config(noreplace) %{_sysconfdir}/libvirt/libxl-sanlock.conf
%endif
%attr(0755, root, root) %{_libdir}/libvirt/lock-driver/sanlock.so
%{_datadir}/augeas/lenses/libvirt_sanlock.aug
%{_datadir}/augeas/lenses/tests/test_libvirt_sanlock.aug
%dir %attr(0770, root, sanlock) %{_localstatedir}/lib/libvirt/sanlock
Support automatic creation of leases for disks in sanlock The current sanlock plugin requires a central management application to manually add <lease> elements to each guest, to protect resources that are assigned to it (eg writable disks). This makes the sanlock plugin useless for usage in more ad hoc deployment environments where there is no central authority to associate disks with leases. This patch adds a mode where the sanlock plugin will automatically create leases for each assigned read-write disk, using a md5 checksum of the fully qualified disk path. This can work pretty well if guests are using stable disk paths for block devices eg /dev/disk/by-path/XXXX symlinks, or if all hosts have NFS volumes mounted in a consistent pattern. The plugin will create one lockspace for managing disks with filename /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__. For each VM disks, there will be another file to hold a lease /var/lib/libvirt/sanlock/5903e5d25e087e60a20fe4566fab41fd Each VM disk lease is usually 1 MB in size. The script virt-sanlock-cleanup should be run periodically to remove unused lease files from the lockspace directory. To make use of this capability the admin will need to do several tasks: - Mount an NFS volume (or other shared filesystem) on /var/lib/libvirt/sanlock - Configure 'host_id' in /etc/libvirt/qemu-sanlock.conf with a unique value for each host with the same NFS mount - Toggle the 'auto_disk_leases' parameter in qemu-sanlock.conf Technically the first step can be skipped, in which case sanlock will only protect against 2 vms on the same host using the same disk (or the same VM being started twice due to error by libvirt). * src/locking/libvirt_sanlock.aug, src/locking/sanlock.conf, src/locking/test_libvirt_sanlock.aug: Add config params for configuring auto lease setup * libvirt.spec.in: Add virt-sanlock-cleanup program, man page * tools/virt-sanlock-cleanup.in: Script to purge unused disk resource lease files
2011-06-14 08:29:00 +00:00
%{_sbindir}/virt-sanlock-cleanup
%{_mandir}/man8/virt-sanlock-cleanup.8*
%attr(0755, root, root) %{_libexecdir}/libvirt_sanlock_helper
%endif
%files client
%{_mandir}/man1/virsh.1*
%{_mandir}/man1/virt-xml-validate.1*
%{_mandir}/man1/virt-pki-validate.1*
%{_mandir}/man1/virt-host-validate.1*
%{_bindir}/virsh
%{_bindir}/virt-xml-validate
%{_bindir}/virt-pki-validate
%{_bindir}/virt-host-validate
%{_datadir}/systemtap/tapset/libvirt_probes*.stp
%{_datadir}/systemtap/tapset/libvirt_functions.stp
%if %{with_qemu}
%{_datadir}/systemtap/tapset/libvirt_qemu_probes*.stp
%endif
%if %{with_bash_completion}
%{_datadir}/bash-completion/completions/virsh
%endif
%{_unitdir}/libvirt-guests.service
%config(noreplace) %{_sysconfdir}/sysconfig/libvirt-guests
%attr(0755, root, root) %{_libexecdir}/libvirt-guests.sh
%files libs -f %{name}.lang
%license COPYING COPYING.LESSER
%config(noreplace) %{_sysconfdir}/libvirt/libvirt.conf
%config(noreplace) %{_sysconfdir}/libvirt/libvirt-admin.conf
%{_libdir}/libvirt.so.*
%{_libdir}/libvirt-qemu.so.*
%{_libdir}/libvirt-lxc.so.*
%{_libdir}/libvirt-admin.so.*
%dir %{_datadir}/libvirt/
%dir %{_datadir}/libvirt/schemas/
%dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/
%{_datadir}/libvirt/schemas/*.rng
%{_datadir}/libvirt/cpu_map/*.xml
%{_datadir}/libvirt/test-screenshot.png
%files admin
%{_mandir}/man1/virt-admin.1*
%{_bindir}/virt-admin
%if %{with_bash_completion}
%{_datadir}/bash-completion/completions/virt-admin
%endif
%if %{with_bash_completion}
%files bash-completion
%{_datadir}/bash-completion/completions/vsh
%endif
%if %{with_wireshark}
%files wireshark
%{wireshark_plugindir}/libvirt.so
%endif
%files nss
%{_libdir}/libnss_libvirt.so.2
%{_libdir}/libnss_libvirt_guest.so.2
%if %{with_lxc}
%files login-shell
%attr(4750, root, virtlogin) %{_bindir}/virt-login-shell
tools: split virt-login-shell into two binaries The virt-login-shell binary is a setuid program that takes no arguments. When invoked it looks at the invoking uid, resolves it to a username, and finds an LXC guest with the same name. It then starts the guest and runs the shell in side the namespaces of the container. Given this set of tasks the virt-login-shell binary needs to connect to libvirtd, make various other libvirt API calls. This is a problem for setuid binaries as various libraries that libvirt.so links to are not safe. For example, they have constructor functions which execute an unknown amount of code that can be influenced by env variables. For this reason virt-login-shell doesn't use libvirt.so, but instead links to a custom, cut down, set of source files sufficient to be a local client only. This introduces a problem for integrating glib2 into libvirt though, as once integrated, there would be no way to build virt-login-shell without an external dependancy on glib2 and this is definitely not setuid safe. To resolve this problem, we split the virt-login-shell binary into two parts. The first part is setuid and does almost nothing. It simply records the original uid+gid, and then invokes the virt-login-shell-helper binary. Crucially when it does this it completes scrubs all environment variables. It is thus safe for virt-login-shell-helper to link to the normal libvirt.so. Any things that constructor functions do cannot be influenced by user control env vars or cli args. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-01 09:58:31 +00:00
%{_libexecdir}/virt-login-shell-helper
%config(noreplace) %{_sysconfdir}/libvirt/virt-login-shell.conf
%{_mandir}/man1/virt-login-shell.1*
%endif
%files devel
%{_libdir}/libvirt.so
%{_libdir}/libvirt-admin.so
%{_libdir}/libvirt-qemu.so
%{_libdir}/libvirt-lxc.so
%dir %{_includedir}/libvirt
%{_includedir}/libvirt/virterror.h
%{_includedir}/libvirt/libvirt.h
%{_includedir}/libvirt/libvirt-admin.h
%{_includedir}/libvirt/libvirt-common.h
%{_includedir}/libvirt/libvirt-domain.h
backup: Introduce virDomainCheckpoint APIs Introduce a bunch of new public APIs related to backup checkpoints. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time. We may have a future hypervisor that can completely manage checkpoints without libvirt metadata, but the first two planned hypervisors (qemu and test) both always use libvirt for tracking metadata relations between checkpoints, so for now, I've deferred the counterpart of virDomainSnapshotHasMetadata for a separate API addition at a later date if there is ever a need for it. Note that until we allow snapshots and checkpoints to exist simultaneously on the same domain (although the actual prevention of this will be in a separate patch for the sake of an easier revert down the road), that it is not possible to branch out to create more than one checkpoint child to a given parent, although it may become possible later when we revert to a snapshot that coincides with a checkpoint. This also means that for now, the decision of which checkpoint becomes the parent of a newly created one is the only checkpoint with no child (so while there are APIs for dealing with a current snapshot, we do not need those for checkpoints). We may end up exposing a notion of a current checkpoint later, but it's easier to add stuff when proven needed than to blindly support it now and wish we hadn't exposed it. The following map shows the API relations to snapshots, with new APIs on the right: Operate on a domain object to create/redefine a child: virDomainSnapshotCreateXML virDomainCheckpointCreateXML Operate on a child object for lifetime management: virDomainSnapshotDelete virDomainCheckpointDelete virDomainSnapshotFree virDomainCheckpointFree virDomainSnapshotRef virDomainCheckpointRef Operate on a child object to learn more about it: virDomainSnapshotGetXMLDesc virDomainCheckpointGetXMLDesc virDomainSnapshotGetConnect virDomainCheckpointGetConnect virDomainSnapshotGetDomain virDomainCheckpointGetDomain virDomainSnapshotGetName virDomainCheckpiontGetName virDomainSnapshotGetParent virDomainCheckpiontGetParent virDomainSnapshotHasMetadata (deferred for later) virDomainSnapshotIsCurrent (no counterpart, see note above) Operate on a domain object to list all children: virDomainSnapshotNum (no counterparts, these are the old virDomainSnapshotListNames racy interfaces) virDomainSnapshotListAllSnapshots virDomainListAllCheckpoints Operate on a child object to list descendents: virDomainSnapshotNumChildren (no counterparts, these are the old virDomainSnapshotListChildrenNames racy interfaces) virDomainSnapshotListAllChildren virDomainCheckpointListAllChildren Operate on a domain to locate a particular child: virDomainSnapshotLookupByName virDomainCheckpointLookupByName virDomainSnapshotCurrent (no counterpart, see note above) virDomainHasCurrentSnapshot (no counterpart, old racy interface) Operate on a snapshot to roll back to earlier state: virDomainSnapshotRevert (no counterpart, instead checkpoints are used in incremental backups via XML to virDomainBackupBegin) Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-13 19:35:26 +00:00
%{_includedir}/libvirt/libvirt-domain-checkpoint.h
%{_includedir}/libvirt/libvirt-domain-snapshot.h
%{_includedir}/libvirt/libvirt-event.h
%{_includedir}/libvirt/libvirt-host.h
%{_includedir}/libvirt/libvirt-interface.h
%{_includedir}/libvirt/libvirt-network.h
%{_includedir}/libvirt/libvirt-nodedev.h
%{_includedir}/libvirt/libvirt-nwfilter.h
%{_includedir}/libvirt/libvirt-secret.h
%{_includedir}/libvirt/libvirt-storage.h
%{_includedir}/libvirt/libvirt-stream.h
%{_includedir}/libvirt/libvirt-qemu.h
%{_includedir}/libvirt/libvirt-lxc.h
%{_libdir}/pkgconfig/libvirt.pc
%{_libdir}/pkgconfig/libvirt-admin.pc
%{_libdir}/pkgconfig/libvirt-qemu.pc
%{_libdir}/pkgconfig/libvirt-lxc.pc
%dir %{_datadir}/libvirt/api/
%{_datadir}/libvirt/api/libvirt-api.xml
%{_datadir}/libvirt/api/libvirt-admin-api.xml
%{_datadir}/libvirt/api/libvirt-qemu-api.xml
%{_datadir}/libvirt/api/libvirt-lxc-api.xml
%changelog