2006-09-21 19:24:37 +04:00
# -*- rpm-spec -*-
2016-10-19 17:49:17 +03:00
# This spec file assumes you are building on a Fedora or RHEL version
2018-01-11 19:30:03 +03:00
# 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.
2018-07-20 13:50:01 +03:00
%define min_rhel 7
2020-06-17 11:02:09 +03:00
%define min_fedora 31
2018-01-11 19:30:03 +03:00
%if (0%{?fedora} && 0%{?fedora} >= %{min_fedora}) || (0%{?rhel} && 0%{?rhel} >= %{min_rhel})
2016-05-11 21:03:57 +03:00
%define supported_platform 1
2016-05-04 17:43:08 +03:00
%else
2016-05-11 21:03:57 +03:00
%define supported_platform 0
2011-03-16 20:50:44 +03:00
%endif
2016-05-04 18:21:42 +03:00
# The hypervisor drivers that run in libvirtd
2016-05-04 17:44:57 +03:00
%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}
2009-09-16 19:02:38 +04:00
2012-04-03 14:54:27 +04:00
%define with_qemu_tcg %{with_qemu}
2014-07-17 17:48:37 +04:00
%define qemu_kvm_arches %{ix86} x86_64
%if 0%{?fedora}
2016-05-04 17:43:08 +03:00
%define qemu_kvm_arches %{ix86} x86_64 %{power64} s390x %{arm} aarch64
2014-07-17 17:48:37 +04:00
%endif
%if 0%{?rhel}
%define with_qemu_tcg 0
2018-07-20 13:50:01 +03:00
%define qemu_kvm_arches x86_64 %{power64} aarch64 s390x
2012-11-16 21:50:20 +04:00
%endif
2019-11-11 17:22:45 +03:00
# On RHEL 7 and older macro _vpath_builddir is not defined.
2020-08-30 03:09:18 +03:00
%if 0%{?rhel} && 0%{?rhel} <= 7
2019-11-11 17:22:45 +03:00
%define _vpath_builddir %{_target_platform}
%endif
2012-11-16 21:50:20 +04:00
%ifarch %{qemu_kvm_arches}
2013-01-10 00:50:03 +04:00
%define with_qemu_kvm %{with_qemu}
2012-04-03 14:54:27 +04:00
%else
2013-01-10 00:50:03 +04:00
%define with_qemu_kvm 0
2012-04-03 14:54:27 +04:00
%endif
2014-07-17 17:48:37 +04:00
%if ! %{with_qemu_tcg} && ! %{with_qemu_kvm}
%define with_qemu 0
%endif
2012-04-03 15:05:32 +04:00
# 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}
2009-09-16 19:02:38 +04:00
%define with_esx 0%{!?_without_esx:1}
2011-07-13 18:05:18 +04:00
%define with_hyperv 0%{!?_without_hyperv:1}
2009-09-16 19:02:38 +04:00
2012-04-03 15:05:32 +04:00
# Then the secondary host drivers, which run inside libvirtd
2018-07-20 13:50:01 +03:00
%define with_storage_rbd 0%{!?_without_storage_rbd:1}
2016-05-04 17:43:08 +03:00
%if 0%{?fedora}
2016-05-04 17:44:57 +03:00
%define with_storage_sheepdog 0%{!?_without_storage_sheepdog:1}
2012-07-18 23:06:58 +04:00
%else
2013-01-10 00:50:03 +04:00
%define with_storage_sheepdog 0
2012-07-18 23:06:58 +04:00
%endif
2019-11-29 16:58:01 +03:00
2016-05-04 17:44:57 +03:00
%define with_storage_gluster 0%{!?_without_storage_gluster:1}
2019-11-29 16:58:01 +03:00
%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
2016-05-04 17:44:57 +03:00
%define with_numactl 0%{!?_without_numactl:1}
2009-09-16 19:02:38 +04:00
2017-07-17 18:32:46 +03:00
# F25+ has zfs-fuse
2018-02-09 16:02:00 +03:00
%if 0%{?fedora}
2017-07-17 18:32:46 +03:00
%define with_storage_zfs 0%{!?_without_storage_zfs:1}
%else
%define with_storage_zfs 0
%endif
2018-08-14 15:31:35 +03:00
# We need a recent enough libiscsi (>= 1.18.0)
2018-11-08 15:10:14 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2018-08-14 15:31:35 +03:00
%define with_storage_iscsi_direct 0%{!?_without_storage_iscsi_direct:1}
%else
%define with_storage_iscsi_direct 0
%endif
2009-09-16 19:02:38 +04:00
# A few optional bits off by default, we enable later
2012-11-12 11:02:23 +04:00
%define with_fuse 0%{!?_without_fuse:0}
2011-01-18 21:37:45 +03:00
%define with_sanlock 0%{!?_without_sanlock:0}
2012-03-24 05:35:20 +04:00
%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 22:59:52 +04: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 07:52:37 +03:00
%define with_firewalld_zone 0%{!?_without_firewalld_zone:0}
2013-01-09 01:47:55 +04:00
%define with_libssh2 0%{!?_without_libssh2:0}
2014-02-04 23:37:15 +04:00
%define with_wireshark 0%{!?_without_wireshark:0}
2016-11-09 17:28:37 +03:00
%define with_libssh 0%{!?_without_libssh:0}
2018-01-17 12:21:31 +03:00
%define with_bash_completion 0%{!?_without_bash_completion:0}
2009-07-29 13:05:39 +04:00
2009-09-16 19:02:38 +04:00
# Finally set the OS / architecture specific special cases
2020-10-05 05:16:57 +03:00
# Xen is available only on some architectures
%ifnarch %{ix86} x86_64 aarch64
2013-01-10 00:50:03 +04:00
%define with_libxl 0
2008-06-12 20:10:50 +04:00
%endif
2013-05-24 17:44:19 +04:00
# vbox is available only on i386 x86_64
%ifnarch %{ix86} x86_64
%define with_vbox 0
%endif
2018-10-05 15:59:31 +03:00
# Numactl is not available on many non-x86 archs
%ifarch s390 s390x %{arm} riscv64
2013-01-10 00:50:03 +04:00
%define with_numactl 0
2009-11-11 21:07:34 +03:00
%endif
2015-03-05 13:40:54 +03:00
2017-07-17 18:32:46 +03:00
# zfs-fuse is not available on some architectures
2018-10-05 15:59:31 +03:00
%ifarch s390 s390x aarch64 riscv64
2017-07-17 18:32:46 +03:00
%define with_storage_zfs 0
%endif
2020-08-21 14:29:02 +03:00
# Ceph dropped support for 32-bit hosts
%ifarch %{arm} %{ix86}
%define with_storage_rbd 0
2019-01-21 15:20:14 +03:00
%endif
2017-07-17 18:32:46 +03:00
2018-12-14 16:45:07 +03:00
# RHEL doesn't ship OpenVZ, VBox, PowerHypervisor,
2019-09-03 07:24:00 +03:00
# VMware, libxenlight (Xen 4.1 and newer),
2011-09-27 00:28:47 +04:00
# or HyperV.
2009-09-16 19:02:38 +04:00
%if 0%{?rhel}
2013-01-10 00:50:03 +04:00
%define with_openvz 0
%define with_vbox 0
%define with_vmware 0
%define with_libxl 0
%define with_hyperv 0
2015-06-10 10:50:00 +03:00
%define with_vz 0
2018-02-09 16:08:45 +03:00
%if 0%{?rhel} > 7
%define with_lxc 0
%endif
2009-09-16 19:02:38 +04:00
%endif
2018-07-20 13:50:01 +03:00
%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 22:59:52 +04:00
2020-07-19 00:46:09 +03: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 07:52:37 +03:00
%define with_firewalld_zone 0%{!?_without_firewalld_zone:1}
%endif
2012-11-12 11:02:23 +04:00
# fuse is used to provide virtualized /proc for LXC
2018-07-20 13:50:01 +03:00
%if %{with_lxc}
2013-01-10 00:50:03 +04:00
%define with_fuse 0%{!?_without_fuse:1}
2012-11-12 11:02:23 +04:00
%endif
2011-01-18 21:37:45 +03:00
# Enable sanlock library for lock management with QEMU
2014-07-23 11:04:22 +04:00
# Sanlock is available only on arches where kvm is available for RHEL
2016-05-04 17:43:08 +03:00
%if 0%{?fedora}
2016-05-04 17:44:57 +03:00
%define with_sanlock 0%{!?_without_sanlock:1}
2011-12-05 21:37:33 +04:00
%endif
2016-05-04 17:43:08 +03:00
%if 0%{?rhel}
2014-07-23 11:04:22 +04:00
%ifarch %{qemu_kvm_arches}
2016-05-04 17:44:57 +03:00
%define with_sanlock 0%{!?_without_sanlock:1}
2013-01-10 00:50:03 +04:00
%endif
2011-01-18 21:37:45 +03:00
%endif
2012-10-12 18:50:42 +04:00
# Enable libssh2 transport for new enough distros
2016-05-04 17:43:08 +03:00
%if 0%{?fedora}
2013-01-10 00:50:03 +04:00
%define with_libssh2 0%{!?_without_libssh2:1}
2012-10-12 18:50:42 +04:00
%endif
2014-02-04 23:37:15 +04:00
# Enable wireshark plugins for all distros shipping libvirt 1.2.2 or newer
2016-10-19 17:49:17 +03:00
%if 0%{?fedora}
2014-02-04 23:37:15 +04:00
%define with_wireshark 0%{!?_without_wireshark:1}
2019-02-08 12:47:42 +03:00
%define wireshark_plugindir %(pkg-config --variable plugindir wireshark)/epan
2018-05-03 14:17:31 +03:00
%endif
2014-02-04 23:37:15 +04:00
2016-11-09 17:28:37 +03:00
# Enable libssh transport for new enough distros
2018-05-25 10:45:15 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2016-11-09 17:28:37 +03:00
%define with_libssh 0%{!?_without_libssh:1}
%endif
2018-07-20 13:50:01 +03:00
%define with_bash_completion 0%{!?_without_bash_completion:1}
2018-01-17 12:21:31 +03:00
2018-12-14 16:45:07 +03:00
%if %{with_qemu} || %{with_lxc}
2012-05-09 08:26:36 +04:00
# numad is used to manage the CPU and memory placement dynamically,
2018-10-05 15:59:31 +03:00
# it's not available on many non-x86 architectures.
%ifnarch s390 s390x %{arm} riscv64
2016-05-04 17:44:57 +03:00
%define with_numad 0%{!?_without_numad:1}
2013-01-10 00:50:03 +04:00
%endif
2010-05-25 23:31:38 +04:00
%endif
2009-09-16 19:02:38 +04:00
# Force QEMU to run as non-root
2016-05-04 17:43:08 +03:00
%define qemu_user qemu
%define qemu_group qemu
2009-07-16 01:25:01 +04:00
2009-09-16 19:02:38 +04:00
2013-07-30 18:01:11 +04:00
# 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}
2020-06-11 01:31:12 +03:00
%define enable_werror -Dwerror=true
2014-12-16 11:21:40 +03:00
%else
2020-06-11 01:31:12 +03:00
%define enable_werror -Dwerror=false
2013-07-30 18:01:11 +04:00
%endif
2018-09-27 17:00:15 +03:00
%if 0%{?rhel} == 7
2018-02-09 16:02:00 +03:00
%define tls_priority "NORMAL"
2018-09-27 17:00:15 +03:00
%else
%define tls_priority "@LIBVIRT,SYSTEM"
2016-06-06 18:02:22 +03:00
%endif
2013-07-30 18:01:11 +04:00
2010-11-11 20:21:28 +03:00
Summary : Library providing a simple virtualization API
2006-02-09 20:45:11 +03:00
Name : libvirt
2005-11-02 18:37:34 +03:00
Version : @VERSION@
2019-01-21 15:55:15 +03:00
Release : 1%{?dist}
2008-08-08 18:27:05 +04:00
License : LGPLv2+
2017-05-11 19:31:08 +03:00
URL : https://libvirt.org/
2011-03-23 19:20:14 +03:00
2017-05-05 03:08:55 +03:00
%if %(echo %{version} | grep -q "\.0$"; echo $?) == 1
2013-01-10 00:50:03 +04:00
%define mainturl stable_updates/
2012-05-06 22:09:22 +04:00
%endif
2017-05-11 19:31:08 +03:00
Source : https://libvirt.org/sources/%{?mainturl} libvirt-%{version} .tar.xz
2012-05-06 22:09:22 +04:00
2012-04-03 14:44:59 +04:00
Requires : libvirt-daemon = %{version} -%{release}
Requires : libvirt-daemon-config-network = %{version} -%{release}
Requires : libvirt-daemon-config-nwfilter = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%if %{with_libxl}
2012-07-18 20:27:03 +04:00
Requires : libvirt-daemon-driver-libxl = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%endif
%if %{with_lxc}
2012-07-18 20:27:03 +04:00
Requires : libvirt-daemon-driver-lxc = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%endif
%if %{with_qemu}
2012-07-18 20:27:03 +04:00
Requires : libvirt-daemon-driver-qemu = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%endif
2018-12-14 16:45:07 +03:00
# We had UML driver, but we've removed it.
Obsoletes : libvirt-daemon-driver-uml <= 5.0.0
Obsoletes : libvirt-daemon-uml <= 5.0.0
2016-05-04 18:20:58 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
Requires : libvirt-daemon-driver-vbox = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%endif
2013-12-06 01:43:28 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-07-18 20:27:03 +04:00
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}
2012-04-03 14:44:59 +04:00
Requires : libvirt-client = %{version} -%{release}
2016-06-25 09:37:22 +03:00
Requires : libvirt-libs = %{version} -%{release}
2011-03-23 19:20:14 +03:00
2012-04-03 14:44:59 +04:00
# All build-time requirements. Run-time requirements are
# listed against each sub-RPM
2011-12-05 21:22:10 +04:00
BuildRequires : gettext-devel
2019-12-06 16:58:08 +03:00
%if 0%{?rhel} == 7
BuildRequires : python36-docutils
%else
BuildRequires : python3-docutils
%endif
2018-03-08 11:05:05 +03:00
BuildRequires : gcc
2020-06-11 01:31:12 +03:00
BuildRequires : meson >= 0.54.0
BuildRequires : ninja-build
2020-06-24 12:07:19 +03:00
BuildRequires : make
2014-11-21 20:09:36 +03:00
BuildRequires : git
2018-11-08 15:10:14 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2017-08-02 12:51:36 +03:00
BuildRequires : perl-interpreter
%else
2014-08-14 07:37:45 +04:00
BuildRequires : perl
2017-08-02 12:51:36 +03:00
%endif
2019-12-03 19:29:12 +03:00
BuildRequires : python3
2011-07-07 17:45:07 +04:00
BuildRequires : systemd-units
2018-03-29 02:57:10 +03:00
%if %{with_libxl}
2006-07-24 18:32:03 +04:00
BuildRequires : xen-devel
2008-06-12 20:10:50 +04:00
%endif
2019-07-30 12:13:36 +03:00
BuildRequires : glib2-devel >= 2.48
2006-02-23 14:35:37 +03:00
BuildRequires : libxml2-devel
2011-03-23 19:30:49 +03:00
BuildRequires : libxslt
2006-03-04 11:57:22 +03:00
BuildRequires : readline-devel
2018-01-17 12:21:31 +03:00
%if %{with_bash_completion}
2017-11-02 16:41:53 +03:00
BuildRequires : bash-completion >= 2.0
2018-01-17 12:21:31 +03:00
%endif
2006-09-21 19:24:37 +04:00
BuildRequires : gettext
2011-07-25 21:17:57 +04:00
BuildRequires : libtasn1-devel
2007-06-11 17:24:45 +04:00
BuildRequires : gnutls-devel
2012-09-19 17:00:34 +04:00
BuildRequires : libattr-devel
2013-05-02 00:16:10 +04:00
# For pool-build probing for existing pools
BuildRequires : libblkid-devel >= 2.17
2011-03-23 19:30:49 +03:00
# for augparse, optionally used in testing
BuildRequires : augeas
2012-06-06 22:03:47 +04:00
BuildRequires : systemd-devel >= 185
2016-05-04 18:25:37 +03:00
BuildRequires : libpciaccess-devel >= 0.10.9
2018-08-13 14:40:18 +03:00
BuildRequires : yajl-devel
2011-01-18 21:37:45 +03:00
%if %{with_sanlock}
2012-10-16 14:45:27 +04:00
BuildRequires : sanlock-devel >= 2.4
%endif
2020-01-30 15:05:54 +03:00
BuildRequires : libpcap-devel >= 1.5.0
2012-08-25 01:57:42 +04:00
BuildRequires : libnl3-devel
2008-02-20 18:38:29 +03:00
BuildRequires : libselinux-devel
2010-08-11 22:25:09 +04:00
BuildRequires : dnsmasq >= 2.41
2011-03-23 19:30:49 +03:00
BuildRequires : iptables
2016-05-04 18:36:17 +03:00
BuildRequires : radvd
2011-03-23 19:30:49 +03:00
BuildRequires : ebtables
BuildRequires : module-init-tools
2008-06-12 20:10:50 +04:00
BuildRequires : cyrus-sasl-devel
2015-07-14 21:42:28 +03:00
BuildRequires : polkit >= 0.112
2008-02-20 18:42:30 +03:00
# For mount/umount in FS driver
BuildRequires : util-linux
%if %{with_qemu}
2017-02-14 16:42:54 +03:00
# For managing ACLs
BuildRequires : libacl-devel
2008-02-20 18:42:30 +03:00
# From QEMU RPMs
BuildRequires : /usr/bin/qemu-img
2008-06-12 20:10:50 +04:00
%endif
2008-02-20 18:45:33 +03:00
# For LVM drivers
BuildRequires : lvm2
2018-08-09 02:43:25 +03:00
# For pool type=iscsi
2008-02-20 18:49:25 +03:00
BuildRequires : iscsi-initiator-utils
2018-08-14 15:31:35 +03:00
%if %{with_storage_iscsi_direct}
2018-08-09 02:43:25 +03:00
# For pool type=iscsi-direct
2018-08-14 14:39:51 +03:00
BuildRequires : libiscsi-devel
2018-08-14 15:31:35 +03:00
%endif
2008-02-20 18:52:17 +03:00
# For disk driver
BuildRequires : parted-devel
2009-09-08 18:07:54 +04:00
# For Multipath support
BuildRequires : device-mapper-devel
2019-02-05 15:12:40 +03:00
# For XFS reflink clone support
BuildRequires : xfsprogs-devel
2014-02-25 23:28:53 +04:00
%if %{with_storage_rbd}
2019-12-11 16:09:53 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2019-12-11 16:24:22 +03:00
BuildRequires : librados-devel
BuildRequires : librbd-devel
2019-12-11 16:09:53 +03:00
%else
2019-12-11 16:24:22 +03:00
BuildRequires : librados2-devel
BuildRequires : librbd1-devel
2019-12-11 16:09:53 +03:00
%endif
2019-12-07 18:35:24 +03:00
%endif
2013-11-20 03:26:05 +04:00
%if %{with_storage_gluster}
BuildRequires : glusterfs-api-devel >= 3.4.1
BuildRequires : glusterfs-devel >= 3.4.1
%endif
2016-05-11 18:41:34 +03:00
%if %{with_storage_sheepdog}
BuildRequires : sheepdog
%endif
2017-07-17 18:32:46 +03:00
%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
2009-03-31 16:45:07 +04:00
%if %{with_numactl}
2008-11-28 14:20:27 +03:00
# For QEMU/LXC numa info
BuildRequires : numactl-devel
2009-03-31 16:45:07 +04:00
%endif
2009-07-28 21:30:20 +04:00
BuildRequires : libcap-ng-devel >= 0.5.0
2012-11-12 11:02:23 +04:00
%if %{with_fuse}
BuildRequires : fuse-devel >= 2.8.6
%endif
2019-12-18 18:23:34 +03:00
%if %{with_libssh2}
2012-10-12 18:50:42 +04:00
BuildRequires : libssh2-devel >= 1.3.0
%endif
2012-08-25 01:57:42 +04:00
BuildRequires : netcf-devel >= 0.2.2
2010-05-04 18:13:55 +04:00
%if %{with_esx}
BuildRequires : libcurl-devel
%endif
2011-07-13 18:05:18 +04:00
%if %{with_hyperv}
BuildRequires : libwsman-devel >= 2.2.3
%endif
2010-09-15 17:44:11 +04:00
BuildRequires : audit-libs-devel
2010-11-30 21:52:25 +03:00
# we need /usr/sbin/dtrace
BuildRequires : systemtap-sdt-devel
2011-03-23 19:20:14 +03:00
# For mount/umount in FS driver
BuildRequires : util-linux
# For showmount in FS driver (netfs discovery)
BuildRequires : nfs-utils
2008-06-12 20:10:50 +04:00
# Fedora build root suckage
BuildRequires : gawk
2005-11-02 18:37:34 +03:00
2012-02-14 14:09:42 +04:00
# For storage wiping with different algorithms
BuildRequires : scrub
2012-03-24 05:35:20 +04:00
%if %{with_numad}
BuildRequires : numad
%endif
2014-02-04 23:37:15 +04:00
%if %{with_wireshark}
2019-02-08 14:05:23 +03:00
BuildRequires : wireshark-devel >= 2.4.0
2014-02-04 23:37:15 +04:00
%endif
2016-11-09 17:28:37 +03:00
%if %{with_libssh}
BuildRequires : libssh-devel >= 0.7.0
%endif
2020-06-19 01:44:07 +03:00
# On RHEL-7 rpcgen is still part of glibc-common package
2018-11-08 15:10:14 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2018-04-03 15:41:46 +03:00
BuildRequires : rpcgen
%endif
2020-06-19 01:44:07 +03:00
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 07:52:37 +03:00
%if %{with_firewalld_zone}
BuildRequires : firewalld-filesystem
%endif
2005-11-02 18:37:34 +03:00
%description
2008-01-24 13:15:13 +03:00
Libvirt is a C toolkit to interact with the virtualization capabilities
2009-07-21 13:16:15 +04:00
of recent versions of Linux (and other OSes). The main package includes
the libvirtd server exporting the virtualization support.
2012-04-03 13:52:12 +04:00
%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.
2012-04-03 14:44:59 +04:00
%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)
2016-06-25 09:37:22 +03:00
# The client side, i.e. shared libs are in a subpackage
Requires : %{name} -libs = %{version} -%{release}
2012-04-03 14:44:59 +04:00
2019-08-20 12:15:47 +03:00
# (client invokes 'nc' against the UNIX socket on the server)
Requires : /usr/bin/nc
2012-04-03 14:44:59 +04:00
# for modprobe of pci devices
Requires : module-init-tools
2018-06-01 14:40:42 +03:00
2012-04-03 14:44:59 +04:00
# for /sbin/ip & /sbin/tc
Requires : iproute
2018-06-01 14:40:42 +03:00
# tc is provided by iproute-tc since at least Fedora 26
%if 0%{?fedora} || 0%{?rhel} > 7
Requires : iproute-tc
%endif
2014-07-15 17:18:33 +04:00
Requires : polkit >= 0.112
2020-10-05 15:17:02 +03:00
%ifarch %{ix86} x86_64
2012-04-03 14:44:59 +04:00
# For virConnectGetSysinfo
Requires : dmidecode
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:44:59 +04:00
# For service management
Requires(post) : systemd-units
Requires(post) : systemd-sysv
Requires(preun) : systemd-units
Requires(postun) : systemd-units
2016-05-04 18:20:58 +03:00
%if %{with_numad}
2012-04-03 14:44:59 +04:00
Requires : numad
2016-05-04 18:20:58 +03:00
%endif
2012-12-05 07:43:05 +04:00
# libvirtd depends on 'messagebus' service
Requires : dbus
2013-05-02 00:28:43 +04:00
# For uid creation during pre
Requires(pre) : shadow-utils
2012-04-03 14:44:59 +04:00
%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}
2014-02-11 14:35:20 +04:00
Requires : libvirt-daemon-driver-network = %{version} -%{release}
2012-04-03 14:44:59 +04:00
%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}
2014-02-13 01:33:16 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-04-03 14:44:59 +04:00
%description daemon-config-nwfilter
Network filter configuration files for cleaning guest traffic
2012-04-03 14:54:27 +04:00
2012-04-02 23:53:43 +04:00
%package daemon-driver-network
Summary : Network driver plugin for the libvirtd daemon
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
Requires : dnsmasq >= 2.41
Requires : radvd
Requires : iptables
2012-04-02 23:53:43 +04:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
Requires : iptables
Requires : ebtables
2012-04-02 23:53:43 +04:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
# needed for device enumeration
Requires : systemd >= 185
2020-06-19 00:05:59 +03:00
# For managing persistent mediated devices
2020-07-19 01:43:08 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2020-06-19 00:05:59 +03:00
Requires : mdevctl
2020-07-19 01:43:08 +03:00
%endif
2012-04-02 23:53:43 +04:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
Requires : netcf-libs >= 0.2.2
2012-04-02 23:53:43 +04:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2012-04-02 23:53:43 +04:00
%description daemon-driver-secret
The secret driver plugin for the libvirtd daemon, providing
an implementation of the secret key APIs.
2017-02-08 11:20:21 +03:00
%package daemon-driver-storage-core
Summary : Storage driver plugin including base backends for the libvirtd daemon
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
Requires : nfs-utils
# For mkfs
Requires : util-linux
2016-05-04 18:40:08 +03:00
%if %{with_qemu}
2013-10-29 15:27:45 +04:00
# From QEMU RPMs
Requires : /usr/bin/qemu-img
2016-05-04 18:40:08 +03:00
%endif
2019-03-19 18:59:36 +03:00
%if !%{with_storage_rbd}
Obsoletes : libvirt-daemon-driver-storage-rbd < %{version} -%{release}
%endif
2012-04-02 23:53:43 +04:00
2017-02-08 11:20:21 +03:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
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.
2018-08-14 15:31:35 +03:00
%if %{with_storage_iscsi_direct}
2018-08-09 02:43:25 +03:00
%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}
2018-08-14 15:31:35 +03:00
Requires : libiscsi
2018-08-09 02:43:25 +03:00
%description daemon-driver-storage-iscsi-direct
The storage driver backend adding implementation of the storage APIs for iscsi
volumes using libiscsi direct connection.
2018-08-14 15:31:35 +03:00
%endif
2018-08-09 02:43:25 +03:00
2017-02-08 11:20:21 +03:00
%package daemon-driver-storage-mpath
Summary : Storage driver plugin for multipath volumes
Requires : libvirt-daemon-driver-storage-core = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
%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}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-02-08 11:20:21 +03:00
Requires : sheepdog
%description daemon-driver-storage-sheepdog
The storage driver backend adding implementation of the storage APIs for
sheepdog volumes using.
%endif
2017-07-17 18:32:46 +03:00
%if %{with_storage_zfs}
%package daemon-driver-storage-zfs
Summary : Storage driver plugin for ZFS
Requires : libvirt-daemon-driver-storage-core = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2017-07-17 18:32:46 +03:00
# 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
2017-02-08 11:20:21 +03:00
%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}
2018-08-14 15:31:35 +03:00
%if %{with_storage_iscsi_direct}
Requires : libvirt-daemon-driver-storage-iscsi-direct = %{version} -%{release}
%endif
2017-02-08 11:20:21 +03:00
%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
2017-07-17 18:32:46 +03:00
%if %{with_storage_zfs}
Requires : libvirt-daemon-driver-storage-zfs = %{version} -%{release}
%endif
2017-02-08 11:20:21 +03:00
2012-04-02 23:53:43 +04:00
%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.
2016-05-04 18:20:58 +03:00
%if %{with_qemu}
2012-04-02 23:53:43 +04:00
%package daemon-driver-qemu
2017-03-07 20:09:58 +03:00
Summary : QEMU driver plugin for the libvirtd daemon
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-10-29 15:27:45 +04:00
Requires : /usr/bin/qemu-img
# For image compression
Requires : gzip
Requires : bzip2
Requires : lzop
Requires : xz
2018-02-09 16:08:45 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2016-07-12 17:57:39 +03:00
Requires : systemd-container
2016-07-13 20:01:14 +03:00
%endif
2012-04-02 23:53:43 +04:00
%description daemon-driver-qemu
The qemu driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
QEMU
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_lxc}
2012-04-02 23:53:43 +04:00
%package daemon-driver-lxc
Summary : LXC driver plugin for the libvirtd daemon
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2012-04-02 23:53:43 +04:00
# There really is a hard cross-driver dependency here
2012-05-25 11:10:56 +04:00
Requires : libvirt-daemon-driver-network = %{version} -%{release}
2018-02-09 16:08:45 +03:00
%if 0%{?fedora} || 0%{?rhel} > 7
2016-07-12 17:57:39 +03:00
Requires : systemd-container
2016-07-13 20:01:14 +03:00
%endif
2012-04-02 23:53:43 +04:00
%description daemon-driver-lxc
The LXC driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
the Linux kernel
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%package daemon-driver-vbox
Summary : VirtualBox driver plugin for the libvirtd daemon
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2013-05-17 16:31:59 +04:00
%description daemon-driver-vbox
The vbox driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
VirtualBox
2016-05-04 18:20:58 +03:00
%endif
2013-05-17 16:31:59 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_libxl}
2012-04-02 23:53:43 +04:00
%package daemon-driver-libxl
Summary : Libxl driver plugin for the libvirtd daemon
Requires : libvirt-daemon = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2018-05-03 13:18:42 +03:00
Obsoletes : libvirt-daemon-driver-xen < 4.3.0
2012-04-02 23:53:43 +04:00
%description daemon-driver-libxl
The Libxl driver plugin for the libvirtd daemon, providing
an implementation of the hypervisor driver APIs using
Libxl
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2012-04-03 14:54:27 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_qemu_tcg}
2012-04-03 14:54:27 +04:00
%package daemon-qemu
Summary : Server side daemon & driver required to run QEMU guests
Requires : libvirt-daemon = %{version} -%{release}
2012-04-02 23:53:43 +04:00
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}
2012-05-25 11:10:56 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-secret = %{version} -%{release}
Requires : libvirt-daemon-driver-storage = %{version} -%{release}
2012-04-03 14:54:27 +04:00
Requires : qemu
%description daemon-qemu
Server side daemon and driver required to manage the virtualization
capabilities of the QEMU TCG emulators
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_qemu_kvm}
2012-04-03 14:54:27 +04:00
%package daemon-kvm
Summary : Server side daemon & driver required to run KVM guests
Requires : libvirt-daemon = %{version} -%{release}
2012-04-02 23:53:43 +04:00
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}
2012-05-25 11:10:56 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-secret = %{version} -%{release}
Requires : libvirt-daemon-driver-storage = %{version} -%{release}
2012-04-03 14:54:27 +04:00
Requires : qemu-kvm
%description daemon-kvm
Server side daemon and driver required to manage the virtualization
capabilities of the KVM hypervisor
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_lxc}
2012-04-03 14:54:27 +04:00
%package daemon-lxc
Summary : Server side daemon & driver required to run LXC guests
Requires : libvirt-daemon = %{version} -%{release}
2012-04-02 23:53:43 +04:00
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}
2012-05-25 11:10:56 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-secret = %{version} -%{release}
Requires : libvirt-daemon-driver-storage = %{version} -%{release}
2012-04-03 14:54:27 +04:00
%description daemon-lxc
Server side daemon and driver required to manage the virtualization
capabilities of LXC
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2018-03-29 02:57:10 +03:00
%if %{with_libxl}
2012-04-03 14:54:27 +04:00
%package daemon-xen
Summary : Server side daemon & driver required to run XEN guests
Requires : libvirt-daemon = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%if %{with_libxl}
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-libxl = %{version} -%{release}
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-interface = %{version} -%{release}
Requires : libvirt-daemon-driver-network = %{version} -%{release}
Requires : libvirt-daemon-driver-nodedev = %{version} -%{release}
2012-05-25 11:10:56 +04:00
Requires : libvirt-daemon-driver-nwfilter = %{version} -%{release}
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-secret = %{version} -%{release}
Requires : libvirt-daemon-driver-storage = %{version} -%{release}
2012-04-03 14:54:27 +04:00
Requires : xen
%description daemon-xen
Server side daemon and driver required to manage the virtualization
capabilities of XEN
2016-05-04 18:20:58 +03:00
%endif
2013-05-17 16:31:59 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%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
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:44:59 +04:00
2009-07-21 13:16:15 +04:00
%package client
2016-06-25 09:37:22 +03:00
Summary : Client side utilities of the libvirt library
Requires : %{name} -libs = %{version} -%{release}
2013-05-15 06:14:34 +04:00
# Needed by /usr/libexec/libvirt-guests.sh script.
2011-02-18 08:45:13 +03:00
Requires : gettext
2011-02-21 20:43:29 +03:00
# Needed by virt-pki-validate script.
Requires : gnutls-utils
2018-01-24 18:42:00 +03:00
%if %{with_bash_completion}
Requires : %{name} -bash-completion = %{version} -%{release}
%endif
2016-06-25 09:37:22 +03:00
%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
2009-07-21 13:16:15 +04:00
Requires : cyrus-sasl
2017-03-13 15:15:57 +03:00
# 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
2009-07-21 13:16:15 +04:00
2016-06-25 09:37:22 +03:00
%description libs
Shared libraries for accessing the libvirt daemon.
2005-11-02 18:37:34 +03:00
2016-06-27 11:15:21 +03:00
%package admin
Summary : Set of tools to control libvirt daemon
Requires : %{name} -libs = %{version} -%{release}
2018-01-24 18:42:00 +03:00
%if %{with_bash_completion}
Requires : %{name} -bash-completion = %{version} -%{release}
%endif
2016-06-27 11:15:21 +03:00
%description admin
The client side utilities to control the libvirt daemon.
2018-01-24 18:42:00 +03:00
%if %{with_bash_completion}
%package bash-completion
Summary : Bash completion script
%description bash-completion
Bash completion script stub.
%endif
2014-02-04 23:37:15 +04:00
%if %{with_wireshark}
%package wireshark
Summary : Wireshark dissector plugin for libvirt RPC transactions
2019-02-08 14:05:23 +03:00
Requires : wireshark >= 2.4.0
2016-06-25 09:37:22 +03:00
Requires : %{name} -libs = %{version} -%{release}
2014-02-04 23:37:15 +04:00
%description wireshark
Wireshark dissector plugin for better analysis of libvirt RPC traffic.
%endif
2013-10-17 17:18:18 +04:00
%if %{with_lxc}
%package login-shell
Summary : Login shell for connecting users to an LXC container
2016-06-25 09:37:22 +03:00
Requires : %{name} -libs = %{version} -%{release}
2013-10-17 17:18:18 +04:00
%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
2005-11-02 18:37:34 +03:00
%package devel
2006-02-09 20:45:11 +03:00
Summary : Libraries, includes, etc. to compile with the libvirt library
2016-06-25 09:37:22 +03:00
Requires : %{name} -libs = %{version} -%{release}
2006-11-07 19:28:16 +03:00
Requires : pkgconfig
2005-11-02 18:37:34 +03:00
%description devel
2012-04-03 13:52:12 +04:00
Include header files & development libraries for the libvirt C library.
2005-11-02 18:37:34 +03:00
2011-01-18 21:37:45 +03:00
%if %{with_sanlock}
%package lock-sanlock
Summary : Sanlock lock manager plugin for QEMU driver
2012-10-17 01:54:18 +04:00
Requires : sanlock >= 2.4
2011-09-15 18:55:36 +04:00
#for virt-sanlock-cleanup require augeas
Requires : augeas
2012-05-21 22:36:30 +04:00
Requires : %{name} -daemon = %{version} -%{release}
2016-06-25 09:37:22 +03:00
Requires : %{name} -libs = %{version} -%{release}
2011-01-18 21:37:45 +03:00
%description lock-sanlock
Includes the Sanlock lock manager plugin for the QEMU
driver
%endif
2016-02-16 11:41:30 +03:00
%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.
2015-04-15 17:16:24 +03:00
2005-11-02 18:37:34 +03:00
%prep
2016-05-04 17:43:08 +03:00
2018-08-03 12:34:32 +03:00
%autosetup -S git_am
2014-11-21 20:09:36 +03:00
2005-11-02 18:37:34 +03:00
%build
2017-10-03 14:41:05 +03:00
%if ! %{supported_platform}
2018-01-11 19:30:03 +03:00
echo " T h i s R P M r e q u i r e s e i t h e r F e d o r a > = %{min_fedora} o r R H E L > = %{min_rhel} "
2017-10-03 14:41:05 +03:00
exit 1
%endif
2016-05-04 18:50:55 +03:00
%if %{with_qemu}
2020-06-11 01:31:12 +03:00
%define arg_qemu -Ddriver_qemu=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_qemu -Ddriver_qemu=disabled
2008-06-12 20:10:50 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_openvz}
2020-06-11 01:31:12 +03:00
%define arg_openvz -Ddriver_openvz=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_openvz -Ddriver_openvz=disabled
2008-08-21 13:28:54 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_lxc}
2020-06-11 01:31:12 +03:00
%define arg_lxc -Ddriver_lxc=enabled
%define arg_login_shell -Dlogin_shell=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_lxc -Ddriver_lxc=disabled
%define arg_login_shell -Dlogin_shell=disabled
2008-08-21 13:28:54 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_vbox}
2020-06-11 01:31:12 +03:00
%define arg_vbox -Ddriver_vbox=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_vbox -Ddriver_vbox=disabled
2009-07-28 20:59:34 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_libxl}
2020-06-11 01:31:12 +03:00
%define arg_libxl -Ddriver_libxl=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_libxl -Ddriver_libxl=disabled
2011-02-11 01:42:34 +03:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_esx}
2020-06-11 01:31:12 +03:00
%define arg_esx -Ddriver_esx=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_esx -Ddriver_esx=disabled
2009-09-16 19:02:38 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_hyperv}
2020-06-11 01:31:12 +03:00
%define arg_hyperv -Ddriver_hyperv=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_hyperv -Ddriver_hyperv=disabled
2011-07-13 18:05:18 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_vmware}
2020-06-11 01:31:12 +03:00
%define arg_vmware -Ddriver_vmware=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_vmware -Ddriver_vmware=disabled
2010-12-21 20:13:50 +03:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_storage_rbd}
2020-06-11 01:31:12 +03:00
%define arg_storage_rbd -Dstorage_rbd=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_storage_rbd -Dstorage_rbd=disabled
2012-05-14 13:06:42 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_storage_sheepdog}
2020-06-11 01:31:12 +03:00
%define arg_storage_sheepdog -Dstorage_sheepdog=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_storage_sheepdog -Dstorage_sheepdog=disabled
2012-07-18 23:06:58 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_storage_gluster}
2020-06-11 01:31:12 +03:00
%define arg_storage_gluster -Dstorage_gluster=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_storage_gluster -Dstorage_gluster=disabled
2013-11-20 03:26:05 +04:00
%endif
2017-07-17 18:32:46 +03:00
%if %{with_storage_zfs}
2020-06-11 01:31:12 +03:00
%define arg_storage_zfs -Dstorage_zfs=enabled
2017-07-17 18:32:46 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_storage_zfs -Dstorage_zfs=disabled
2017-07-17 18:32:46 +03:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_numactl}
2020-06-11 01:31:12 +03:00
%define arg_numactl -Dnumactl=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_numactl -Dnumactl=disabled
2009-03-31 16:45:07 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_numad}
2020-06-11 01:31:12 +03:00
%define arg_numad -Dnumad=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_numad -Dnumad=disabled
2012-03-24 05:35:20 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_fuse}
2020-06-11 01:31:12 +03:00
%define arg_fuse -Dfuse=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_fuse -Dfuse=disabled
2012-11-12 11:02:23 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_sanlock}
2020-06-11 01:31:12 +03:00
%define arg_sanlock -Dsanlock=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_sanlock -Dsanlock=disabled
2011-01-18 21:37:45 +03:00
%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 22:59:52 +04:00
%if %{with_firewalld}
2020-06-11 01:31:12 +03:00
%define arg_firewalld -Dfirewalld=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%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 22:59:52 +04: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 07:52:37 +03:00
%if %{with_firewalld_zone}
2020-06-11 01:31:12 +03:00
%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 07:52:37 +03:00
%else
2020-06-11 01:31:12 +03:00
%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 07:52:37 +03:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_wireshark}
2020-06-11 01:31:12 +03:00
%define arg_wireshark -Dwireshark_dissector=enabled
2016-05-04 18:50:55 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_wireshark -Dwireshark_dissector=disabled
2014-02-04 23:37:15 +04:00
%endif
2018-08-14 15:31:35 +03:00
%if %{with_storage_iscsi_direct}
2020-06-11 01:31:12 +03:00
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=enabled
2018-08-14 15:31:35 +03:00
%else
2020-06-11 01:31:12 +03:00
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=disabled
2018-08-14 15:31:35 +03:00
%endif
Imprint all logs with version + package build information
The logging functions are enhanced so that immediately prior to
the first log message being printed to any output channel, the
libvirt package version will be printed.
eg
$ LIBVIRT_DEBUG=1 virsh
18:13:28.013: 17536: info : libvirt version: 0.8.7
18:13:28.013: 17536: debug : virInitialize:361 : register drivers
...
The 'configure' script gains two new arguments which can be
used as
--with-packager="Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10"
--with-packager-version="1.fc14"
to allow distros to append a custom string with package specific
data.
The RPM specfile is modified so that it appends the RPM version,
the build host, the build date and the packager name.
eg
$ LIBVIRT_DEBUG=1 virsh
18:14:52.086: 17551: info : libvirt version: 0.8.7, package: 1.fc13 (Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10)
18:14:52.086: 17551: debug : virInitialize:361 : register drivers
Thus when distro packagers receive bug reports they can clearly
see what version was in use, even if the bug reporter mistakenly
or intentionally lies about version/builds
* src/util/logging.c: Output version data prior to first log message
* libvirt.spec.in: Include RPM release, date, hostname & packager
* configure.ac: Add --with-packager & --with-packager-version args
2011-01-27 21:11:16 +03:00
%define when %(date +"%%F-%%T")
%define where %(hostname)
%define who %{?packager}%{!?packager:Unknown}
2020-06-11 01:31:12 +03:00
%define arg_packager -Dpackager="%{who}, %{when}, %{where}"
%define arg_packager_version -Dpackager_version="%{release}"
Imprint all logs with version + package build information
The logging functions are enhanced so that immediately prior to
the first log message being printed to any output channel, the
libvirt package version will be printed.
eg
$ LIBVIRT_DEBUG=1 virsh
18:13:28.013: 17536: info : libvirt version: 0.8.7
18:13:28.013: 17536: debug : virInitialize:361 : register drivers
...
The 'configure' script gains two new arguments which can be
used as
--with-packager="Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10"
--with-packager-version="1.fc14"
to allow distros to append a custom string with package specific
data.
The RPM specfile is modified so that it appends the RPM version,
the build host, the build date and the packager name.
eg
$ LIBVIRT_DEBUG=1 virsh
18:14:52.086: 17551: info : libvirt version: 0.8.7, package: 1.fc13 (Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10)
18:14:52.086: 17551: debug : virInitialize:361 : register drivers
Thus when distro packagers receive bug reports they can clearly
see what version was in use, even if the bug reporter mistakenly
or intentionally lies about version/builds
* src/util/logging.c: Output version data prior to first log message
* libvirt.spec.in: Include RPM release, date, hostname & packager
* configure.ac: Add --with-packager & --with-packager-version args
2011-01-27 21:11:16 +03:00
2020-06-11 01:31:12 +03:00
%define arg_selinux_mount -Dselinux_mount="/sys/fs/selinux"
2012-09-06 18:22:27 +04:00
2013-07-30 18:04:48 +04:00
# place macros above and build commands below this comment
2017-11-29 13:08:40 +03:00
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir} /%{name} .spec)
2020-06-11 01:31:12 +03:00
%meson \
-Drunstatedir=%{_rundir} \
2019-08-20 19:38:58 +03:00
%{?arg_qemu} \
2016-05-04 18:50:55 +03:00
%{?arg_openvz} \
%{?arg_lxc} \
%{?arg_vbox} \
%{?arg_libxl} \
2020-06-11 01:31:12 +03:00
-Dsasl=enabled \
-Dpolkit=enabled \
-Ddriver_libvirtd=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_esx} \
%{?arg_hyperv} \
%{?arg_vmware} \
2020-06-11 01:31:12 +03:00
-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 \
2018-08-14 15:31:35 +03:00
%{?arg_storage_iscsi_direct} \
2020-06-11 01:31:12 +03:00
-Dstorage_scsi=enabled \
-Dstorage_disk=enabled \
-Dstorage_mpath=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_storage_rbd} \
%{?arg_storage_sheepdog} \
%{?arg_storage_gluster} \
2017-07-17 18:32:46 +03:00
%{?arg_storage_zfs} \
2020-06-11 01:31:12 +03:00
-Dstorage_vstorage=disabled \
2016-05-04 18:50:55 +03:00
%{?arg_numactl} \
%{?arg_numad} \
2020-06-11 01:31:12 +03:00
-Dcapng=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_fuse} \
2020-06-11 01:31:12 +03:00
-Dnetcf=enabled \
-Dselinux=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_selinux_mount} \
2020-06-11 01:31:12 +03:00
-Dapparmor=disabled \
-Dsecdriver_apparmor=disabled \
-Dudev=enabled \
-Dyajl=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_sanlock} \
2020-06-11 01:31:12 +03:00
-Dlibpcap=enabled \
-Daudit=enabled \
-Ddtrace=enabled \
2016-05-04 18:50:55 +03:00
%{?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 07:52:37 +03:00
%{?arg_firewalld_zone} \
2016-05-04 18:50:55 +03:00
%{?arg_wireshark} \
2020-06-11 01:31:12 +03:00
-Dpm_utils=disabled \
-Dnss=enabled \
2016-05-04 18:50:55 +03:00
%{arg_packager} \
%{arg_packager_version} \
2020-06-11 01:31:12 +03:00
-Dqemu_user=%{qemu_user} \
-Dqemu_group=%{qemu_group} \
-Dtls_priority=%{tls_priority} \
2013-07-30 18:01:11 +04:00
%{?enable_werror} \
2020-06-11 01:31:12 +03:00
-Dexpensive_tests=enabled \
-Dinit_script=systemd \
2018-02-14 16:49:28 +03:00
%{?arg_login_shell}
2020-06-11 01:31:12 +03:00
%meson_build
2005-11-02 18:37:34 +03:00
%install
rm -fr %{buildroot}
2017-11-29 13:08:40 +03:00
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir} /%{name} .spec)
2020-06-11 01:31:12 +03:00
%meson_install
2013-01-31 18:31:37 +04:00
2005-11-02 18:37:34 +03:00
rm -f $RPM_BUILD_ROOT %{_libdir} /*.la
2005-12-16 16:27:23 +03:00
rm -f $RPM_BUILD_ROOT %{_libdir} /*.a
2011-01-18 21:37:45 +03:00
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/lock-driver/*.la
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/lock-driver/*.a
2012-04-02 23:53:43 +04:00
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/connection-driver/*.la
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/connection-driver/*.a
2017-02-07 21:40:29 +03:00
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/storage-backend/*.la
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/storage-backend/*.a
2018-04-25 16:37:07 +03:00
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/storage-file/*.la
rm -f $RPM_BUILD_ROOT %{_libdir} /libvirt/storage-file/*.a
2014-02-04 23:37:15 +04:00
%if %{with_wireshark}
2018-05-03 14:17:31 +03:00
rm -f $RPM_BUILD_ROOT %{wireshark_plugindir} /libvirt.la
2014-02-04 23:37:15 +04:00
%endif
2007-03-15 20:51:11 +03:00
2010-04-28 17:38:47 +04:00
install -d -m 0755 $RPM_BUILD_ROOT %{_datadir} /lib/libvirt/dnsmasq/
2007-03-15 20:51:11 +03:00
# 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
2019-05-27 13:56:04 +03:00
# libvirt saves this file with mode 0600
chmod 0600 $RPM_BUILD_ROOT %{_sysconfdir} /libvirt/qemu/networks/default.xml
2017-04-12 22:36:01 +03:00
# 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/
2018-05-29 23:30:33 +03:00
# libvirt saves these files with mode 600
chmod 600 $RPM_BUILD_ROOT %{_sysconfdir} /libvirt/nwfilter/*.xml
2017-04-12 22:36:01 +03:00
2007-03-12 19:32:43 +03:00
# Strip auto-generated UUID - we need it generated per-install
2007-03-15 20:51:11 +03:00
sed -i -e " / < u u i d > / d " $RPM_BUILD_ROOT %{_datadir} /libvirt/networks/default.xml
2009-09-16 19:02:38 +04:00
%if ! %{with_qemu}
2008-11-26 17:46:49 +03:00
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/libvirtd_qemu.aug
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/tests/test_libvirtd_qemu.aug
2008-09-17 18:09:13 +04:00
%endif
2006-09-21 19:24:37 +04:00
%find_lang %{name}
2005-11-02 18:37:34 +03:00
2012-05-30 19:15:22 +04:00
%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
2009-10-08 20:06:40 +04:00
%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
2009-10-13 18:18:45 +04:00
%endif
2009-10-08 20:06:40 +04:00
2008-09-17 18:09:13 +04:00
%if ! %{with_qemu}
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /libvirt/qemu.conf
2010-03-18 15:50:08 +03:00
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /logrotate.d/libvirtd.qemu
2008-09-17 18:09:13 +04:00
%endif
2009-10-08 19:40:14 +04:00
%if ! %{with_lxc}
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /libvirt/lxc.conf
2010-04-13 12:40:21 +04:00
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /logrotate.d/libvirtd.lxc
2010-03-18 15:50:08 +03:00
%endif
2013-09-09 19:15:15 +04:00
%if ! %{with_libxl}
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /libvirt/libxl.conf
2015-05-01 00:16:49 +03:00
rm -rf $RPM_BUILD_ROOT %{_sysconfdir} /logrotate.d/libvirtd.libxl
2013-09-09 19:15:15 +04:00
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
2008-09-17 18:09:13 +04:00
2013-11-20 16:58:24 +04:00
# Copied into libvirt-docs subpackage eventually
2019-05-10 17:22:11 +03:00
mv $RPM_BUILD_ROOT %{_datadir} /doc/libvirt libvirt-docs
2012-04-03 13:52:12 +04:00
2020-10-05 15:53:33 +03:00
%ifarch %{power64} s390x x86_64 aarch64 riscv64
2012-10-21 06:46:58 +04:00
mv $RPM_BUILD_ROOT %{_datadir} /systemtap/tapset/libvirt_probes.stp \
$RPM_BUILD_ROOT %{_datadir} /systemtap/tapset/libvirt_probes-64.stp
2018-05-18 18:15:16 +03:00
%if %{with_qemu}
2012-10-21 06:46:58 +04:00
mv $RPM_BUILD_ROOT %{_datadir} /systemtap/tapset/libvirt_qemu_probes.stp \
$RPM_BUILD_ROOT %{_datadir} /systemtap/tapset/libvirt_qemu_probes-64.stp
2018-05-18 18:15:16 +03:00
%endif
2012-10-21 06:46:58 +04:00
%endif
2010-04-12 22:39:00 +04:00
%check
2020-06-11 01:31:12 +03:00
VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check
2010-04-12 22:39:00 +04:00
2019-03-25 12:51:05 +03:00
%post libs
%if 0%{?rhel} == 7
/sbin/ldconfig
%endif
%postun libs
%if 0%{?rhel} == 7
/sbin/ldconfig
%endif
2015-04-29 00:38:00 +03:00
%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
2012-04-03 14:44:59 +04:00
%post daemon
2007-03-15 20:51:11 +03:00
2018-07-20 13:54:37 +03:00
%systemd_post virtlockd.socket virtlockd-admin.socket
%systemd_post virtlogd.socket virtlogd-admin.socket
2019-04-30 18:41:10 +03:00
%systemd_post libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
%systemd_post libvirtd-tcp.socket libvirtd-tls.socket
2018-07-20 13:54:37 +03:00
%systemd_post libvirtd.service
2007-03-15 20:51:11 +03:00
2017-10-23 14:06:44 +03:00
# request daemon restart in posttrans
mkdir -p %{_localstatedir} /lib/rpm-state/libvirt || :
touch %{_localstatedir} /lib/rpm-state/libvirt/restart || :
2012-04-03 14:44:59 +04:00
%preun daemon
2018-07-20 13:54:37 +03:00
%systemd_preun libvirtd.service
2019-04-30 18:41:10 +03:00
%systemd_preun libvirtd-tcp.socket libvirtd-tls.socket
%systemd_preun libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
2018-07-20 13:54:37 +03:00
%systemd_preun virtlogd.socket virtlogd-admin.socket virtlogd.service
%systemd_preun virtlockd.socket virtlockd-admin.socket virtlockd.service
2011-07-07 17:45:07 +04:00
2012-04-03 14:44:59 +04:00
%postun daemon
2011-07-07 17:45:07 +04:00
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
2013-12-09 10:23:30 +04:00
/bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || :
2015-02-09 19:35:05 +03:00
/bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || :
2011-07-07 17:45:07 +04:00
fi
2013-12-09 10:23:30 +04:00
2015-12-07 15:48:04 +03:00
# 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
2018-02-14 14:09:32 +03:00
/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 || :
2015-12-07 15:48:04 +03:00
fi
2017-10-23 14:06:44 +03:00
%posttrans daemon
if [ -f %{_localstatedir} /lib/rpm-state/libvirt/restart ]; then
2019-08-23 15:13:40 +03:00
# 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
2019-04-30 18:41:10 +03:00
fi
2017-10-23 14:06:44 +03:00
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 07:52:37 +03:00
%post daemon-driver-network
2019-04-30 17:39:31 +03:00
%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 07:52:37 +03:00
%firewalld_reload
%endif
%postun daemon-driver-network
2019-04-30 17:39:31 +03:00
%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 07:52:37 +03:00
%firewalld_reload
%endif
2012-04-03 14:44:59 +04:00
%post daemon-config-network
if test $1 -eq 1 && test ! -f %{_sysconfdir} /libvirt/qemu/networks/default.xml ; then
2014-09-10 21:10:45 +04: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='
'
2014-09-15 21:30:08 +04:00
routes=" $ { n l } $ ( i p r o u t e s h o w | c u t - d ' ' - f 1 ) $ { n l } "
2014-09-10 21:10:45 +04:00
case ${routes} in
*" $ { n l } 1 9 2 . 1 6 8 . $ { o r i g _ s u b } . 0 / 2 4 $ { n l } " *)
# there was a match, so we need to look for an unused subnet
for new_sub in $(seq 124 254); do
case ${routes} in
*" $ { n l } 1 9 2 . 1 6 8 . $ { n e w _ s u b } . 0 / 2 4 $ { n l } " *)
;;
*)
sub=$new_sub
break;
;;
esac
done
;;
*)
;;
esac
2012-04-03 14:44:59 +04:00
UUID=`/usr/bin/uuidgen`
2014-09-10 21:10:45 +04:00
sed -e " s / $ { o r i g _ s u b } / $ { s u b } / g " \
-e " s , < / n a m e > , < / n a m e > \n < u u i d > $ U U I D < / u u i d > , " \
2012-04-03 14:44:59 +04:00
< %{_datadir} /libvirt/networks/default.xml \
> %{_sysconfdir} /libvirt/qemu/networks/default.xml
ln -s ../default.xml %{_sysconfdir} /libvirt/qemu/networks/autostart/default.xml
2019-05-27 13:56:04 +03:00
# libvirt saves this file with mode 0600
chmod 0600 %{_sysconfdir} /libvirt/qemu/networks/default.xml
2015-04-16 22:42:05 +03:00
# Make sure libvirt picks up the new network defininiton
2017-10-23 14:06:44 +03:00
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 || :
2012-04-03 14:44:59 +04:00
fi
2017-10-23 14:06:44 +03:00
rm -rf %{_localstatedir} /lib/rpm-state/libvirt || :
2017-04-12 22:36:01 +03:00
%post daemon-config-nwfilter
cp %{_datadir} /libvirt/nwfilter/*.xml %{_sysconfdir} /libvirt/nwfilter/
2019-05-23 15:31:37 +03:00
# libvirt saves these files with mode 600
chmod 600 %{_sysconfdir} /libvirt/nwfilter/*.xml
2017-04-12 22:36:01 +03:00
# Make sure libvirt picks up the new nwfilter defininitons
2017-10-23 14:06:44 +03:00
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 || :
2017-04-12 22:36:01 +03:00
2016-05-04 18:20:58 +03:00
%if %{with_qemu}
2013-12-06 03:15:55 +04:00
%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 " q e m u u s e r " qemu
else
useradd -r -g qemu -G kvm -d / -s /sbin/nologin -c " q e m u u s e r " qemu
fi
fi
exit 0
2016-05-04 18:20:58 +03:00
%endif
2005-11-02 18:37:34 +03:00
2010-05-27 16:47:11 +04:00
%preun client
2018-07-20 13:54:37 +03:00
%systemd_preun libvirt-guests.service
2010-05-27 16:47:11 +04:00
%post client
2018-07-20 13:54:37 +03:00
%systemd_post libvirt-guests.service
2009-07-29 12:55:43 +04:00
2012-12-18 03:34:25 +04:00
%postun client
2018-07-20 13:54:37 +03:00
%systemd_postun libvirt-guests.service
2013-11-22 15:13:03 +04:00
%if %{with_lxc}
%pre login-shell
getent group virtlogin >/dev/null || groupadd -r virtlogin
exit 0
%endif
2012-04-03 10:26:41 +04:00
%files
2012-03-30 17:14:00 +04:00
2012-04-03 14:44:59 +04:00
%files docs
2020-08-25 18:52:24 +03:00
%doc AUTHORS.rst NEWS.rst README.rst
2020-06-11 01:31:12 +03:00
%doc libvirt-docs/*
2012-04-03 14:44:59 +04:00
%files daemon
2007-03-12 19:32:43 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/
2008-09-17 18:09:13 +04:00
2011-07-07 17:45:07 +04:00
%{_unitdir} /libvirtd.service
2019-04-30 18:41:10 +03:00
%{_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 14:33:23 +03:00
%{_unitdir} /virtproxyd.service
%{_unitdir} /virtproxyd.socket
%{_unitdir} /virtproxyd-ro.socket
%{_unitdir} /virtproxyd-admin.socket
%{_unitdir} /virtproxyd-tcp.socket
%{_unitdir} /virtproxyd-tls.socket
2016-10-14 10:13:48 +03:00
%{_unitdir} /virt-guest-shutdown.target
2015-02-09 19:35:05 +03:00
%{_unitdir} /virtlogd.service
%{_unitdir} /virtlogd.socket
2018-02-06 18:57:25 +03:00
%{_unitdir} /virtlogd-admin.socket
2011-07-07 18:02:32 +04:00
%{_unitdir} /virtlockd.service
%{_unitdir} /virtlockd.socket
2018-02-06 18:51:08 +03:00
%{_unitdir} /virtlockd-admin.socket
2007-06-27 03:48:46 +04:00
%config (noreplace) %{_sysconfdir} /sysconfig/libvirtd
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtproxyd
2015-02-09 19:35:05 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtlogd
2012-08-02 23:06:50 +04:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtlockd
2007-10-12 23:54:15 +04:00
%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 14:33:23 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/virtproxyd.conf
2015-02-09 19:35:05 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/virtlogd.conf
2013-08-08 19:06:31 +04:00
%config (noreplace) %{_sysconfdir} /libvirt/virtlockd.conf
2018-06-21 17:14:48 +03:00
%config (noreplace) %{_sysconfdir} /sasl2/libvirt.conf
2015-04-15 12:49:22 +03:00
%config (noreplace) %{_prefix} /lib/sysctl.d/60-libvirtd.conf
2008-09-17 18:09:13 +04:00
2011-03-03 10:26:22 +03:00
%config (noreplace) %{_sysconfdir} /logrotate.d/libvirtd
2007-03-15 20:51:11 +03:00
%dir %{_datadir} /libvirt/
2009-09-16 19:02:38 +04:00
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/
2009-01-21 01:36:10 +03:00
2009-07-31 12:49:08 +04:00
%dir %attr (0711, root, root) %{_localstatedir} /lib/libvirt/images/
2011-11-01 15:21:21 +04:00
%dir %attr (0711, root, root) %{_localstatedir} /lib/libvirt/filesystems/
2009-08-06 18:20:36 +04:00
%dir %attr (0711, root, root) %{_localstatedir} /lib/libvirt/boot/
2011-05-20 19:18:11 +04:00
%dir %attr (0711, root, root) %{_localstatedir} /cache/libvirt/
2008-09-17 18:09:13 +04:00
2009-01-21 01:36:10 +03:00
2017-08-27 19:35:07 +03:00
%dir %attr (0755, root, root) %{_libdir} /libvirt/
%dir %attr (0755, root, root) %{_libdir} /libvirt/connection-driver/
2012-08-02 23:06:50 +04:00
%dir %attr (0755, root, root) %{_libdir} /libvirt/lock-driver
2012-12-14 14:57:27 +04:00
%attr (0755, root, root) %{_libdir} /libvirt/lock-driver/lockd.so
2012-08-02 23:06:50 +04:00
2008-09-17 18:09:13 +04:00
%{_datadir} /augeas/lenses/libvirtd.aug
%{_datadir} /augeas/lenses/tests/test_libvirtd.aug
2015-02-09 19:35:05 +03:00
%{_datadir} /augeas/lenses/virtlogd.aug
%{_datadir} /augeas/lenses/tests/test_virtlogd.aug
2013-08-08 19:06:31 +04:00
%{_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 14:33:23 +03:00
%{_datadir} /augeas/lenses/virtproxyd.aug
%{_datadir} /augeas/lenses/tests/test_virtproxyd.aug
2012-12-14 14:57:27 +04:00
%{_datadir} /augeas/lenses/libvirt_lockd.aug
2016-05-04 18:20:58 +03:00
%if %{with_qemu}
2012-12-14 14:57:27 +04:00
%{_datadir} /augeas/lenses/tests/test_libvirt_lockd.aug
2016-05-04 18:20:58 +03:00
%endif
2008-09-17 18:09:13 +04:00
2009-08-06 16:54:08 +04:00
%{_datadir} /polkit-1/actions/org.libvirt.unix.policy
2013-06-25 15:44:47 +04:00
%{_datadir} /polkit-1/actions/org.libvirt.api.policy
2015-04-29 00:38:00 +03:00
%{_datadir} /polkit-1/rules.d/50-libvirt.rules
2008-09-17 18:09:13 +04:00
2009-07-28 22:07:51 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /log/libvirt/
2008-09-17 18:09:13 +04:00
2011-03-30 04:54:23 +04:00
%attr (0755, root, root) %{_libexecdir} /libvirt_iohelper
2013-07-30 15:04:55 +04:00
2019-07-08 18:38:49 +03:00
%attr (0755, root, root) %{_bindir} /virt-ssh-helper
2007-06-27 03:04:49 +04: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 14:33:23 +03:00
%attr (0755, root, root) %{_sbindir} /virtproxyd
2015-02-09 19:35:05 +03:00
%attr (0755, root, root) %{_sbindir} /virtlogd
2012-08-02 23:06:50 +04:00
%attr (0755, root, root) %{_sbindir} /virtlockd
2008-09-17 18:09:13 +04:00
2010-07-12 23:33:35 +04:00
%{_mandir} /man8/libvirtd.8*
2015-02-09 19:35:05 +03:00
%{_mandir} /man8/virtlogd.8*
2013-08-08 18:10:38 +04:00
%{_mandir} /man8/virtlockd.8*
2017-03-03 15:43:51 +03:00
%{_mandir} /man7/virkey*.7*
2005-11-02 18:37:34 +03:00
2012-04-03 14:44:59 +04:00
%files daemon-config-network
2014-03-06 06:46:45 +04:00
%dir %{_datadir} /libvirt/networks/
%{_datadir} /libvirt/networks/default.xml
2019-05-27 13:56:04 +03:00
%ghost %{_sysconfdir} /libvirt/qemu/networks/default.xml
%ghost %{_sysconfdir} /libvirt/qemu/networks/autostart/default.xml
2012-04-03 13:52:12 +04:00
2012-04-03 14:44:59 +04:00
%files daemon-config-nwfilter
2017-04-12 22:36:01 +03:00
%dir %{_datadir} /libvirt/nwfilter/
%{_datadir} /libvirt/nwfilter/*.xml
%ghost %{_sysconfdir} /libvirt/nwfilter/*.xml
2012-04-03 14:54:27 +04:00
2012-04-02 23:53:43 +04:00
%files daemon-driver-interface
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtinterfaced
2018-03-16 20:05:24 +03:00
%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
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_interface.so
%files daemon-driver-network
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtnetworkd
2018-03-16 20:05:24 +03:00
%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
2013-12-13 19:03:26 +04:00
%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
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/network/
2013-12-13 19:03:26 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/network/
%dir %attr (0755, root, root) %{_localstatedir} /lib/libvirt/dnsmasq/
Add helper program to create custom leases
Introduce helper program to catch events from dnsmasq and maintain a custom
lease file per network. It supports dhcpv4 and dhcpv6. The file is saved as
"<interface-name>.status".
Each lease contains the following info:
<expiry-time (epoch time)> <mac> <iaid> <ip-address> <hostname> <clientid>
Example of custom leases file content:
[
{
"iaid": "1221229",
"ip-address": "2001:db8:ca2:2:1::95",
"mac-address": "52:54:00:12:a2:6d",
"hostname": "Fedora20",
"client-id": "00:04:1a:c1:d9:6b:5a:0a:e2:bc:f8:4b:1e:37:2e:38:22:55",
"expiry-time": 1393244216
},
{
"ip-address": "192.168.150.208",
"mac-address": "52:54:00:11:56:b3",
"hostname": "Wani-PC",
"client-id": "01:52:54:00:11:56:b3",
"expiry-time": 1393244248
}
]
src/Makefile.am:
* Add options to compile the helper program
src/network/bridge_driver.c:
* Introduce networkDnsmasqLeaseFileNameCustom()
* Invoke helper program along with dnsmasq
* Delete the .status file when corresponding n/w is destroyed.
src/network/leaseshelper.c
* Helper program to create the custom lease file
2014-06-02 14:19:26 +04:00
%attr (0755, root, root) %{_libexecdir} /libvirt_leaseshelper
2012-04-02 23:53:43 +04:00
%{_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 07:52:37 +03:00
%if %{with_firewalld_zone}
%{_prefix} /lib/firewalld/zones/libvirt.xml
%endif
2012-04-02 23:53:43 +04:00
%files daemon-driver-nodedev
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtnodedevd
2018-03-16 20:05:24 +03:00
%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
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_nodedev.so
%files daemon-driver-nwfilter
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtnwfilterd
2018-03-16 20:05:24 +03:00
%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
2014-03-06 06:46:45 +04:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/nwfilter/
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/network/
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_nwfilter.so
%files daemon-driver-secret
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtsecretd
2019-07-23 14:22:41 +03:00
%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
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_secret.so
%files daemon-driver-storage
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-core
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtstoraged
2018-03-16 20:05:24 +03:00
%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
2013-12-06 03:15:55 +04:00
%attr (0755, root, root) %{_libexecdir} /libvirt_parthelper
2016-05-04 18:20:58 +03:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_storage.so
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_fs.so
2018-04-25 16:37:07 +03:00
%{_libdir} /%{name} /storage-file/libvirt_storage_file_fs.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-disk
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_disk.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-logical
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_logical.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-scsi
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_scsi.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-iscsi
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_iscsi.so
2017-02-08 11:20:21 +03:00
2018-08-14 15:31:35 +03:00
%if %{with_storage_iscsi_direct}
2018-08-09 02:43:25 +03:00
%files daemon-driver-storage-iscsi-direct
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_iscsi-direct.so
2018-08-14 15:31:35 +03:00
%endif
2018-08-09 02:43:25 +03:00
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-mpath
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_mpath.so
2017-02-08 11:20:21 +03:00
2017-02-07 21:40:29 +03:00
%if %{with_storage_gluster}
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-gluster
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_gluster.so
2018-04-25 16:37:07 +03:00
%{_libdir} /%{name} /storage-file/libvirt_storage_file_gluster.so
2017-02-07 21:40:29 +03:00
%endif
2017-02-08 11:20:21 +03:00
2017-02-07 21:40:29 +03:00
%if %{with_storage_rbd}
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-rbd
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_rbd.so
%endif
2017-02-08 11:20:21 +03:00
2017-02-07 21:40:29 +03:00
%if %{with_storage_sheepdog}
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-sheepdog
2017-02-07 21:40:29 +03:00
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_sheepdog.so
%endif
2012-04-02 23:53:43 +04:00
2017-07-17 18:32:46 +03:00
%if %{with_storage_zfs}
%files daemon-driver-storage-zfs
%{_libdir} /%{name} /storage-backend/libvirt_storage_backend_zfs.so
%endif
2016-05-04 18:20:58 +03:00
%if %{with_qemu}
2012-04-02 23:53:43 +04:00
%files daemon-driver-qemu
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtqemud
2018-03-16 20:05:24 +03:00
%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
2014-03-06 06:46:45 +04:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/qemu/
2013-12-06 03:15:55 +04:00
%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
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/qemu/
2015-09-08 19:34:36 +03:00
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/
2013-12-06 03:15:55 +04:00
%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
2013-12-12 17:35:40 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_qemu.so
2017-04-04 19:22:31 +03:00
%dir %attr (0711, root, root) %{_localstatedir} /lib/libvirt/swtpm/
%dir %attr (0711, root, root) %{_localstatedir} /log/swtpm/libvirt/qemu/
2019-05-17 15:01:59 +03:00
%{_bindir} /virt-qemu-run
%{_mandir} /man1/virt-qemu-run.1*
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_lxc}
2012-04-02 23:53:43 +04:00
%files daemon-driver-lxc
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtlxcd
2018-03-16 20:05:24 +03:00
%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
2013-12-06 03:15:55 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /log/libvirt/lxc/
%config (noreplace) %{_sysconfdir} /libvirt/lxc.conf
%config (noreplace) %{_sysconfdir} /logrotate.d/libvirtd.lxc
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/lxc/
2013-12-06 03:15:55 +04:00
%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
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_lxc.so
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_libxl}
2012-04-02 23:53:43 +04:00
%files daemon-driver-libxl
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtxend
2018-03-16 20:05:24 +03:00
%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
2015-04-22 22:43:38 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/libxl.conf
2015-05-01 00:16:49 +03:00
%config (noreplace) %{_sysconfdir} /logrotate.d/libvirtd.libxl
2015-04-30 18:18:59 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/libxl-lockd.conf
2015-04-22 22:43:38 +03:00
%{_datadir} /augeas/lenses/libvirtd_libxl.aug
%{_datadir} /augeas/lenses/tests/test_libvirtd_libxl.aug
2013-12-06 03:15:55 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /log/libvirt/libxl/
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/libxl/
2013-12-06 03:15:55 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/libxl/
2012-04-02 23:53:43 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_libxl.so
2016-05-04 18:20:58 +03:00
%endif
2013-05-17 16:31:59 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%files daemon-driver-vbox
2020-04-01 20:59:14 +03:00
%config (noreplace) %{_sysconfdir} /sysconfig/virtvboxd
2018-03-16 20:05:24 +03:00
%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
2013-05-17 16:31:59 +04:00
%{_libdir} /%{name} /connection-driver/libvirt_driver_vbox.so
2016-05-04 18:20:58 +03:00
%endif
2012-04-02 23:53:43 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_qemu_tcg}
2012-04-03 14:54:27 +04:00
%files daemon-qemu
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_qemu_kvm}
2012-04-03 14:54:27 +04:00
%files daemon-kvm
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_lxc}
2012-04-03 14:54:27 +04:00
%files daemon-lxc
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 14:54:27 +04:00
2018-03-29 02:57:10 +03:00
%if %{with_libxl}
2012-04-03 14:54:27 +04:00
%files daemon-xen
2016-05-04 18:20:58 +03:00
%endif
2013-05-17 16:31:59 +04:00
2016-05-04 18:20:58 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%files daemon-vbox
2016-05-04 18:20:58 +03:00
%endif
2012-04-03 13:52:12 +04:00
2011-01-18 21:37:45 +03:00
%if %{with_sanlock}
%files lock-sanlock
2013-01-10 00:50:03 +04:00
%if %{with_qemu}
2011-06-14 12:20:49 +04:00
%config (noreplace) %{_sysconfdir} /libvirt/qemu-sanlock.conf
2013-01-10 00:50:03 +04:00
%endif
2015-05-01 21:39:30 +03:00
%if %{with_libxl}
%config (noreplace) %{_sysconfdir} /libvirt/libxl-sanlock.conf
%endif
2011-01-18 21:37:45 +03:00
%attr (0755, root, root) %{_libdir} /libvirt/lock-driver/sanlock.so
2011-06-14 12:20:49 +04:00
%{_datadir} /augeas/lenses/libvirt_sanlock.aug
%{_datadir} /augeas/lenses/tests/test_libvirt_sanlock.aug
2019-05-21 14:09:22 +03:00
%dir %attr (0770, root, sanlock) %{_localstatedir} /lib/libvirt/sanlock
2011-06-14 12:29:00 +04:00
%{_sbindir} /virt-sanlock-cleanup
%{_mandir} /man8/virt-sanlock-cleanup.8*
2012-09-18 15:41:26 +04:00
%attr (0755, root, root) %{_libexecdir} /libvirt_sanlock_helper
2011-01-18 21:37:45 +03:00
%endif
2016-06-25 09:37:22 +03:00
%files client
2009-07-21 13:16:15 +04:00
%{_mandir} /man1/virsh.1*
%{_mandir} /man1/virt-xml-validate.1*
2009-09-16 17:42:57 +04:00
%{_mandir} /man1/virt-pki-validate.1*
2012-01-10 21:31:21 +04:00
%{_mandir} /man1/virt-host-validate.1*
2009-07-21 13:16:15 +04:00
%{_bindir} /virsh
%{_bindir} /virt-xml-validate
2009-09-16 17:42:57 +04:00
%{_bindir} /virt-pki-validate
2012-01-10 21:31:21 +04:00
%{_bindir} /virt-host-validate
2009-07-21 13:16:15 +04:00
2012-10-21 06:46:58 +04:00
%{_datadir} /systemtap/tapset/libvirt_probes*.stp
2012-03-31 15:55:41 +04:00
%{_datadir} /systemtap/tapset/libvirt_functions.stp
2018-05-18 18:15:16 +03:00
%if %{with_qemu}
%{_datadir} /systemtap/tapset/libvirt_qemu_probes*.stp
%endif
2012-03-31 15:55:41 +04:00
2018-01-17 12:21:31 +03:00
%if %{with_bash_completion}
2018-01-24 18:42:00 +03:00
%{_datadir} /bash-completion/completions/virsh
2018-01-17 12:21:31 +03:00
%endif
2017-11-02 16:41:53 +03:00
2016-06-25 09:37:22 +03:00
%{_unitdir} /libvirt-guests.service
%config (noreplace) %{_sysconfdir} /sysconfig/libvirt-guests
%attr (0755, root, root) %{_libexecdir} /libvirt-guests.sh
2020-06-11 01:31:12 +03:00
%files libs -f %{name}.lang
2017-09-15 00:21:29 +03:00
%license COPYING COPYING.LESSER
2016-06-25 09:37:22 +03:00
%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.*
2009-07-21 13:16:15 +04:00
%dir %{_datadir} /libvirt/
%dir %{_datadir} /libvirt/schemas/
2016-06-25 09:37:22 +03:00
%dir %attr (0755, root, root) %{_localstatedir} /lib/libvirt/
2009-07-21 13:16:15 +04:00
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/basictypes.rng
%{_datadir} /libvirt/schemas/capability.rng
2016-09-27 14:27:52 +03:00
%{_datadir} /libvirt/schemas/cputypes.rng
2009-07-21 13:16:15 +04:00
%{_datadir} /libvirt/schemas/domain.rng
2019-08-22 04:42:41 +03:00
%{_datadir} /libvirt/schemas/domainbackup.rng
2014-06-25 15:24:53 +04:00
%{_datadir} /libvirt/schemas/domaincaps.rng
2018-06-12 06:12:21 +03:00
%{_datadir} /libvirt/schemas/domaincheckpoint.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/domaincommon.rng
2010-05-27 01:03:47 +04:00
%{_datadir} /libvirt/schemas/domainsnapshot.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/interface.rng
2009-07-21 13:16:15 +04:00
%{_datadir} /libvirt/schemas/network.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/networkcommon.rng
2018-08-31 17:21:34 +03:00
%{_datadir} /libvirt/schemas/networkport.rng
2009-07-21 13:16:15 +04:00
%{_datadir} /libvirt/schemas/nodedev.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/nwfilter.rng
2018-06-27 11:42:52 +03:00
%{_datadir} /libvirt/schemas/nwfilter_params.rng
%{_datadir} /libvirt/schemas/nwfilterbinding.rng
2009-07-28 04:39:48 +04:00
%{_datadir} /libvirt/schemas/secret.rng
2014-04-12 05:33:45 +04:00
%{_datadir} /libvirt/schemas/storagecommon.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/storagepool.rng
2019-02-07 20:29:15 +03:00
%{_datadir} /libvirt/schemas/storagepoolcaps.rng
2011-08-13 05:33:15 +04:00
%{_datadir} /libvirt/schemas/storagevol.rng
2009-07-21 13:16:15 +04:00
2018-08-16 14:39:39 +03:00
%{_datadir} /libvirt/cpu_map/*.xml
2009-12-23 16:28:42 +03:00
2016-12-06 15:45:18 +03:00
%{_datadir} /libvirt/test-screenshot.png
2016-06-27 11:15:21 +03:00
%files admin
%{_mandir} /man1/virt-admin.1*
%{_bindir} /virt-admin
2018-01-24 18:42:00 +03:00
%if %{with_bash_completion}
%{_datadir} /bash-completion/completions/virt-admin
%endif
2016-06-27 11:15:21 +03:00
2018-01-24 18:42:00 +03:00
%if %{with_bash_completion}
%files bash-completion
%{_datadir} /bash-completion/completions/vsh
%endif
2016-06-27 11:15:21 +03:00
2014-02-04 23:37:15 +04:00
%if %{with_wireshark}
%files wireshark
2018-05-03 14:17:31 +03:00
%{wireshark_plugindir} /libvirt.so
2014-02-04 23:37:15 +04:00
%endif
2016-02-16 11:41:30 +03:00
%files nss
%{_libdir} /libnss_libvirt.so.2
2016-12-08 17:25:17 +03:00
%{_libdir} /libnss_libvirt_guest.so.2
2016-02-16 11:41:30 +03:00
2013-10-17 17:18:18 +04:00
%if %{with_lxc}
%files login-shell
2013-11-22 15:13:03 +04:00
%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 12:58:31 +03:00
%{_libexecdir} /virt-login-shell-helper
2013-10-17 17:18:18 +04:00
%config (noreplace) %{_sysconfdir} /libvirt/virt-login-shell.conf
%{_mandir} /man1/virt-login-shell.1*
%endif
2005-11-02 18:37:34 +03:00
%files devel
2014-06-20 20:47:15 +04:00
%{_libdir} /libvirt.so
2016-06-24 20:50:10 +03:00
%{_libdir} /libvirt-admin.so
2014-06-20 20:47:15 +04:00
%{_libdir} /libvirt-qemu.so
%{_libdir} /libvirt-lxc.so
2007-03-28 12:48:52 +04:00
%dir %{_includedir} /libvirt
2014-06-20 20:47:15 +04:00
%{_includedir} /libvirt/virterror.h
%{_includedir} /libvirt/libvirt.h
2016-06-24 20:50:10 +03:00
%{_includedir} /libvirt/libvirt-admin.h
2015-12-01 13:07:59 +03:00
%{_includedir} /libvirt/libvirt-common.h
2014-10-23 14:28:16 +04:00
%{_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 22:35:26 +03:00
%{_includedir} /libvirt/libvirt-domain-checkpoint.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-domain-snapshot.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-event.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-host.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-interface.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-network.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-nodedev.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-nwfilter.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-secret.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-storage.h
2014-10-23 14:28:16 +04:00
%{_includedir} /libvirt/libvirt-stream.h
2014-06-20 20:47:15 +04:00
%{_includedir} /libvirt/libvirt-qemu.h
%{_includedir} /libvirt/libvirt-lxc.h
2006-02-09 20:45:11 +03:00
%{_libdir} /pkgconfig/libvirt.pc
2016-06-24 20:50:10 +03:00
%{_libdir} /pkgconfig/libvirt-admin.pc
2014-06-20 20:47:15 +04:00
%{_libdir} /pkgconfig/libvirt-qemu.pc
%{_libdir} /pkgconfig/libvirt-lxc.pc
2005-11-02 18:37:34 +03:00
2012-02-15 15:29:38 +04:00
%dir %{_datadir} /libvirt/api/
%{_datadir} /libvirt/api/libvirt-api.xml
2016-06-24 20:50:10 +03:00
%{_datadir} /libvirt/api/libvirt-admin-api.xml
2012-02-15 15:29:38 +04:00
%{_datadir} /libvirt/api/libvirt-qemu-api.xml
Introduce an LXC specific public API & library
This patch introduces support for LXC specific public APIs. In
common with what was done for QEMU, this creates a libvirt_lxc.so
library and libvirt/libvirt-lxc.h header file.
The actual APIs are
int virDomainLxcOpenNamespace(virDomainPtr domain,
int **fdlist,
unsigned int flags);
int virDomainLxcEnterNamespace(virDomainPtr domain,
unsigned int nfdlist,
int *fdlist,
unsigned int *noldfdlist,
int **oldfdlist,
unsigned int flags);
which provide a way to use the setns() system call to move the
calling process into the container's namespace. It is not
practical to write in a generically applicable manner. The
nearest that we could get to such an API would be an API which
allows to pass a command + argv to be executed inside a
container. Even if we had such a generic API, this LXC specific
API is still useful, because it allows the caller to maintain
the current process context, in particular any I/O streams they
have open.
NB the virDomainLxcEnterNamespace() API is special in that it
runs client side, so does not involve the internal driver API.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-21 17:15:19 +04:00
%{_datadir} /libvirt/api/libvirt-lxc-api.xml
2016-04-13 17:37:42 +03:00
2005-12-07 16:45:20 +03:00
2005-11-02 18:37:34 +03:00
%changelog
