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.
2021-05-05 20:30:46 +03:00
%define min_rhel 8
2023-07-03 19:25:49 +03:00
%define min_fedora 37
2018-01-11 19:30:03 +03:00
2020-10-05 19:05:35 +03:00
%define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x
2020-10-05 19:56:50 +03:00
%if 0%{?rhel}
2021-05-14 14:49:19 +03:00
%if 0%{?rhel} > 8
%define arches_qemu_kvm x86_64 aarch64 s390x
%else
%define arches_qemu_kvm x86_64 %{power64} aarch64 s390x
%endif
2020-10-05 19:56:50 +03:00
%endif
2020-10-05 19:05:35 +03:00
%define arches_64bit x86_64 %{power64} aarch64 s390x riscv64
%define arches_x86 %{ix86} x86_64
%define arches_systemtap_64bit %{arches_64bit}
%define arches_dmidecode %{arches_x86}
%define arches_xen %{arches_x86} aarch64
2023-07-03 19:25:49 +03:00
%if 0%{?fedora}
2023-07-03 19:35:06 +03:00
%define arches_xen x86_64 aarch64
2022-06-11 23:17:27 +03:00
%endif
2020-10-05 19:05:35 +03:00
%define arches_vbox %{arches_x86}
%define arches_ceph %{arches_64bit}
%define arches_zfs %{arches_x86} %{power64} %{arm}
2021-08-19 17:24:43 +03:00
%define arches_numactl %{arches_x86} %{power64} aarch64 s390x
2020-10-05 19:05:35 +03:00
%define arches_numad %{arches_x86} %{power64} aarch64
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
2020-10-05 19:05:35 +03:00
%ifarch %{arches_qemu_kvm}
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
2020-10-05 19:56:50 +03:00
%define with_qemu_tcg %{with_qemu}
# RHEL disables TCG on all architectures
%if 0%{?rhel}
%define with_qemu_tcg 0
%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}
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}
2021-05-14 14:56:23 +03:00
%if 0%{?rhel}
# Glusterfs has been dropped in RHEL-9, and before that
# was only enabled on arches where KVM exists
%if 0%{?rhel} > 8
2019-11-29 16:58:01 +03:00
%define with_storage_gluster 0
2021-05-14 14:56:23 +03:00
%else
%ifnarch %{arches_qemu_kvm}
%define with_storage_gluster 0
2021-05-25 14:20:06 +03:00
%endif
2019-11-29 16:58:01 +03:00
%endif
%endif
2021-05-05 20:30:46 +03:00
# Fedora 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
2021-05-05 20:30:46 +03:00
%define with_storage_iscsi_direct 0%{!?_without_storage_iscsi_direct:1}
2021-06-24 11:18:17 +03:00
# libiscsi has been dropped in RHEL-9
%if 0%{?rhel} > 8
%define with_storage_iscsi_direct 0
%endif
2018-08-14 15:31:35 +03:00
2020-10-05 19:30:22 +03:00
# Other optional features
2020-10-05 19:40:22 +03:00
%define with_numactl 0%{!?_without_numactl:1}
2024-02-09 18:21:19 +03:00
%define with_userfaultfd_sysctl 0%{!?_without_userfaultfd_sysctl:1}
2020-10-05 19:30:22 +03:00
2009-09-16 19:02:38 +04:00
# A few optional bits off by default, we enable later
2020-10-29 13:00:37 +03:00
%define with_fuse 0
%define with_sanlock 0
%define with_numad 0
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
%define with_nbdkit 0
2023-11-08 22:14:50 +03:00
%define with_nbdkit_config_default 0
2020-10-29 13:00:37 +03:00
%define with_firewalld_zone 0
2021-01-17 22:27:20 +03:00
%define with_netcf 0
2020-10-29 13:00:37 +03:00
%define with_libssh2 0
%define with_wireshark 0
%define with_libssh 0
%define with_dmidecode 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 19:05:35 +03:00
# Architecture-dependent features
%ifnarch %{arches_xen}
2013-01-10 00:50:03 +04:00
%define with_libxl 0
2008-06-12 20:10:50 +04:00
%endif
2020-10-05 19:05:35 +03:00
%ifnarch %{arches_vbox}
2013-05-24 17:44:19 +04:00
%define with_vbox 0
%endif
2020-10-05 19:05:35 +03:00
%ifnarch %{arches_numactl}
2013-01-10 00:50:03 +04:00
%define with_numactl 0
2009-11-11 21:07:34 +03:00
%endif
2020-10-05 19:05:35 +03:00
%ifnarch %{arches_zfs}
2017-07-17 18:32:46 +03:00
%define with_storage_zfs 0
%endif
2020-10-05 19:05:35 +03:00
%ifnarch %{arches_ceph}
2020-08-21 14:29:02 +03:00
%define with_storage_rbd 0
2019-01-21 15:20:14 +03:00
%endif
2017-07-17 18:32:46 +03:00
2021-05-05 20:30:46 +03:00
# RHEL doesn't ship many hypervisor drivers
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
2021-05-05 20:30:46 +03:00
%define with_lxc 0
2009-09-16 19:02:38 +04:00
%endif
2021-05-05 20:30:46 +03:00
%define with_firewalld_zone 0%{!?_without_firewalld_zone:1}
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
2023-07-03 19:25:49 +03:00
%if 0%{?rhel} && 0%{?rhel} < 9
2021-01-17 22:27:20 +03:00
%define with_netcf 0%{!?_without_netcf: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}
2020-10-05 19:05:35 +03:00
%ifarch %{arches_qemu_kvm}
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
2021-05-05 20:30:46 +03:00
# Enable wireshark plugins for all distros
%define with_wireshark 0%{!?_without_wireshark:1}
%define wireshark_plugindir %(pkg-config --variable plugindir wireshark)/epan
2014-02-04 23:37:15 +04:00
2021-05-05 20:30:46 +03:00
# Enable libssh transport for all distros
%define with_libssh 0%{!?_without_libssh:1}
2016-11-09 17:28:37 +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.
2020-10-19 15:23:00 +03:00
%ifarch %{arches_numad}
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
2023-11-08 22:14:50 +03:00
# We want to build with nbdkit support, but should only enable nbdkit by
# default if the OS ships a SELinux policy that allows libvirt to launch it.
# Right now that's not the case anywhere, but things should be fine by the time
# Fedora 40 is released.
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
%if %{with_qemu}
2024-01-05 11:39:45 +03:00
# rhel-8 lacks pidfd_open
%if 0%{?fedora} || 0%{?rhel} >= 9
%define with_nbdkit 0%{!?_without_nbdkit:1}
# setting 'with_nbdkit_config_default' must be done only when compiling
# in nbdkit support
#
# TODO: add RHEL 9 once a minor release that contains the necessary SELinux
# bits exists (we only support the most recent minor release)
%if 0%{?fedora} >= 40
%define with_nbdkit_config_default 0%{!?_without_nbdkit_config_default:1}
%endif
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
%endif
%endif
2020-10-05 19:05:35 +03:00
%ifarch %{arches_dmidecode}
2020-10-05 19:43:32 +03:00
%define with_dmidecode 0%{!?_without_dmidecode:1}
%endif
2021-07-28 19:12:43 +03:00
%define with_modular_daemons 0
2023-07-03 19:25:49 +03:00
%if 0%{?fedora} || 0%{?rhel} >= 9
2021-08-02 18:52:20 +03:00
%define with_modular_daemons 1
2021-07-28 19:12:43 +03: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
2021-11-15 20:49:26 +03:00
# Locations for QEMU data
%define qemu_moddir %{_libdir}/qemu
%define qemu_datadir %{_datadir}/qemu
2023-11-02 18:56:54 +03:00
# Native / MinGW builds
%define with_native 0%{!?_without_native:1}
2023-11-02 14:24:21 +03:00
%define with_mingw32 0
%define with_mingw64 0
2022-08-08 18:40:56 +03:00
%if 0%{?fedora}
2023-11-02 14:24:21 +03:00
%if 0%{!?_without_mingw:1}
%define with_mingw32 0%{!?_without_mingw32:1}
%define with_mingw64 0%{!?_without_mingw64:1}
%endif
# These tell the other mingw macros whether to perform or
# skip the 32-bit and 64-bit specific steps respectively
%define mingw_build_win32 %{with_mingw32}
%define mingw_build_win64 %{with_mingw64}
2022-08-08 18:40:56 +03:00
%endif
2009-09-16 19:02:38 +04:00
2023-11-02 18:56:54 +03:00
%if !%{with_native}
# Building the debugsource package apparently only works if the
# native build is enabled. debuginfo packages don't have this
# problem and setting this doesn't disable them
%global debug_package %{nil}
%endif
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
2021-07-28 17:13:48 +03:00
%define enable_werror -Dwerror=false -Dgit_werror=disabled
2013-07-30 18:01:11 +04:00
%endif
2024-02-09 18:21:19 +03:00
# Fedora and RHEL-9 are new enough to support /dev/userfaultfd, which
# does not require enabling vm.unprivileged_userfaultfd sysctl.
%if 0%{?fedora} || 0%{?rhel} >= 9
%define with_userfaultfd_sysctl 0
%endif
2021-05-05 20:30:46 +03:00
%define tls_priority "@LIBVIRT,SYSTEM"
2016-06-06 18:02:22 +03:00
2022-01-12 13:45:08 +03:00
# libvirt 8.1.0 stops distributing any sysconfig files.
# If the user has customized their sysconfig file,
# the RPM upgrade path will rename it to .rpmsave
# because the file is no longer managed by RPM.
# To prevent a regression we rename it back after the
# transaction to preserve the user's modifications
%define libvirt_sysconfig_pre() \
for sc in %{?*} ; do \
test -f " %{_sysconfdir} / s y s c o n f i g / $ { s c } . r p m s a v e " || continue ; \
mv -v " %{_sysconfdir} / s y s c o n f i g / $ { s c } . r p m s a v e " " %{_sysconfdir} / s y s c o n f i g / $ { s c } . r p m s a v e . o l d " ; \
done \
%{nil}
%define libvirt_sysconfig_posttrans() \
for sc in %{?*} ; do \
test -f " %{_sysconfdir} / s y s c o n f i g / $ { s c } . r p m s a v e " || continue ; \
mv -v " %{_sysconfdir} / s y s c o n f i g / $ { s c } . r p m s a v e " " %{_sysconfdir} / s y s c o n f i g / $ { s c } " ; \
done \
%{nil}
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}
2023-01-16 16:16:57 +03:00
License : GPL-2.0-or-later AND LGPL-2.1-only AND LGPL-2.1-or-later AND OFL-1.1
2017-05-11 19:31:08 +03:00
URL : https://libvirt.org/
2011-03-23 19:20:14 +03:00
2024-02-16 17:15:55 +03:00
%if %(echo %{version} | grep "\.0$" >/dev/null; echo $?) == 1
2013-01-10 00:50:03 +04:00
%define mainturl stable_updates/
2012-05-06 22:09:22 +04:00
%endif
2023-03-14 11:32:30 +03:00
Source : https://download.libvirt.org/%{?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}
2023-09-06 12:22:40 +03:00
Requires : libvirt-client-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
2019-12-06 16:58:08 +03:00
BuildRequires : python3-docutils
2022-10-07 10:31:25 +03:00
BuildRequires : meson >= 0.56.0
2020-06-11 01:31:12 +03:00
BuildRequires : ninja-build
2014-11-21 20:09:36 +03:00
BuildRequires : git
2017-08-02 12:51:36 +03:00
BuildRequires : perl-interpreter
2019-12-03 19:29:12 +03:00
BuildRequires : python3
2022-12-19 20:48:06 +03:00
BuildRequires : python3-pytest
2023-11-02 18:48:03 +03:00
# For xmllint
BuildRequires : libxml2
2023-11-02 18:45:11 +03:00
# For xsltproc
BuildRequires : libxslt
BuildRequires : gettext
BuildRequires : systemd-rpm-macros
# Fedora build root suckage
BuildRequires : gawk
2023-11-02 18:56:54 +03:00
%if %{with_native}
2023-11-02 18:45:11 +03:00
BuildRequires : gcc
2023-11-02 18:56:54 +03:00
%if %{with_libxl}
2006-07-24 18:32:03 +04:00
BuildRequires : xen-devel
2023-11-02 18:56:54 +03:00
%endif
2021-03-02 01:57:05 +03:00
BuildRequires : glib2-devel >= 2.56
2006-02-23 14:35:37 +03:00
BuildRequires : libxml2-devel
2006-03-04 11:57:22 +03:00
BuildRequires : readline-devel
2017-11-02 16:41:53 +03:00
BuildRequires : bash-completion >= 2.0
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
2023-11-02 18:56:54 +03:00
%if %{with_sanlock}
2012-10-16 14:45:27 +04:00
BuildRequires : sanlock-devel >= 2.4
2023-11-02 18:56:54 +03:00
%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
2011-03-23 19:30:49 +03:00
BuildRequires : iptables
BuildRequires : ebtables
2023-11-02 18:33:15 +03:00
# For modprobe
2023-11-02 18:35:59 +03:00
BuildRequires : kmod
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
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2017-02-14 16:42:54 +03:00
# For managing ACLs
BuildRequires : libacl-devel
2023-05-05 20:42:59 +03:00
# From QEMU RPMs, used by virstoragetest
2008-02-20 18:42:30 +03:00
BuildRequires : /usr/bin/qemu-img
2023-11-02 18:56:54 +03:00
%endif
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
# nbdkit support requires libnbd
2023-11-02 18:56:54 +03:00
%if %{with_nbdkit}
2023-07-20 20:21:26 +03:00
BuildRequires : libnbd-devel
2023-11-02 18:56:54 +03: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
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_storage_rbd}
2019-12-11 16:24:22 +03:00
BuildRequires : librados-devel
BuildRequires : librbd-devel
2023-11-02 18:56:54 +03:00
%endif
%if %{with_storage_gluster}
2013-11-20 03:26:05 +04:00
BuildRequires : glusterfs-api-devel >= 3.4.1
BuildRequires : glusterfs-devel >= 3.4.1
2023-11-02 18:56:54 +03:00
%endif
%if %{with_numactl}
2008-11-28 14:20:27 +03:00
# For QEMU/LXC numa info
BuildRequires : numactl-devel
2023-11-02 18:56:54 +03:00
%endif
2009-07-28 21:30:20 +04:00
BuildRequires : libcap-ng-devel >= 0.5.0
2023-11-02 18:56:54 +03:00
%if %{with_fuse}
2012-11-12 11:02:23 +04:00
BuildRequires : fuse-devel >= 2.8.6
2023-11-02 18:56:54 +03:00
%endif
%if %{with_libssh2}
2012-10-12 18:50:42 +04:00
BuildRequires : libssh2-devel >= 1.3.0
2023-11-02 18:56:54 +03:00
%endif
%if %{with_netcf}
2012-08-25 01:57:42 +04:00
BuildRequires : netcf-devel >= 0.2.2
2023-11-02 18:56:54 +03:00
%endif
%if %{with_esx}
2010-05-04 18:13:55 +04:00
BuildRequires : libcurl-devel
2023-11-02 18:56:54 +03:00
%endif
%if %{with_hyperv}
2020-10-09 10:46:08 +03:00
BuildRequires : libwsman-devel >= 2.6.3
2023-11-02 18:56:54 +03:00
%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
2023-11-02 18:56:54 +03:00
%if %{with_numad}
2012-03-24 05:35:20 +04:00
BuildRequires : numad
2023-11-02 18:56:54 +03:00
%endif
%if %{with_wireshark}
2020-11-13 14:13:21 +03:00
BuildRequires : wireshark-devel
2023-11-02 18:56:54 +03:00
%endif
%if %{with_libssh}
2022-09-07 16:08:20 +03:00
BuildRequires : libssh-devel >= 0.8.1
2023-11-02 18:56:54 +03:00
%endif
2020-06-19 01:44:07 +03:00
BuildRequires : libtirpc-devel
2023-11-02 18:56:54 +03:00
%if %{with_firewalld_zone}
2020-10-08 17:34:37 +03:00
# Needed for the firewalld_reload macro
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
BuildRequires : firewalld-filesystem
2023-11-02 18:56:54 +03: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
%endif
2023-11-02 14:24:21 +03:00
%if %{with_mingw32}
2022-08-08 18:40:56 +03:00
BuildRequires : mingw32-filesystem
BuildRequires : mingw32-gcc
BuildRequires : mingw32-binutils
BuildRequires : mingw32-glib2 >= 2.48
BuildRequires : mingw32-gnutls
BuildRequires : mingw32-gettext
BuildRequires : mingw32-libxml2
BuildRequires : mingw32-portablexdr
BuildRequires : mingw32-dlfcn
BuildRequires : mingw32-libssh2
BuildRequires : mingw32-curl
2023-11-02 14:24:21 +03:00
%endif
%if %{with_mingw64}
2022-08-08 18:40:56 +03:00
BuildRequires : mingw64-filesystem
BuildRequires : mingw64-gcc
BuildRequires : mingw64-binutils
BuildRequires : mingw64-glib2 >= 2.48
BuildRequires : mingw64-gnutls
BuildRequires : mingw64-gettext
BuildRequires : mingw64-libxml2
BuildRequires : mingw64-portablexdr
BuildRequires : mingw64-dlfcn
BuildRequires : mingw64-libssh2
BuildRequires : mingw64-curl
%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.
2023-11-02 18:56:54 +03:00
%if %{with_native}
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
2022-12-02 03:08:38 +03:00
Requires : libvirt-libs = %{version} -%{release}
2022-12-14 03:30:59 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
2022-12-02 01:22:32 +03:00
Requires : libvirt-daemon-lock = %{version} -%{release}
2022-12-02 21:24:27 +03:00
Requires : libvirt-daemon-plugin-lockd = %{version} -%{release}
2022-12-02 02:08:22 +03:00
Requires : libvirt-daemon-log = %{version} -%{release}
2022-12-02 02:24:18 +03:00
Requires : libvirt-daemon-proxy = %{version} -%{release}
2022-12-14 03:30:59 +03: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-common
Summary : Files and utilities used by daemons
Requires : libvirt-libs = %{version} -%{release}
2022-11-03 19:11:19 +03:00
# The libvirt-guests.sh script requires virsh from libvirt-client subpackage,
# but not every deployment wants to use libvirt-guests service. Using
# Recommends here will install libvirt-client by default (if available), but
# RPM won't complain if the package is unavailable, masked, or removed later.
2022-12-02 03:08:38 +03:00
Recommends: libvirt-client = %{version} -%{release}
2021-05-05 20:30:46 +03:00
# for /sbin/ip
2012-04-03 14:44:59 +04:00
Requires : iproute
2021-05-05 20:30:46 +03:00
# for /sbin/tc
2018-06-01 14:40:42 +03:00
Requires : iproute-tc
2014-07-15 17:18:33 +04:00
Requires : polkit >= 0.112
2023-11-02 18:56:54 +03:00
%if %{with_dmidecode}
2012-04-03 14:44:59 +04:00
# For virConnectGetSysinfo
Requires : dmidecode
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:44:59 +04:00
# For service management
2023-07-05 19:48:32 +03:00
Requires(posttrans) : /usr/bin/systemctl
Requires(preun) : /usr/bin/systemctl
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
2021-04-19 19:29:25 +03:00
# Needed by /usr/libexec/libvirt-guests.sh script.
2023-11-02 18:56:54 +03:00
%if 0%{?fedora}
2022-08-25 10:56:50 +03:00
Requires : gettext-runtime
2023-11-02 18:56:54 +03:00
%else
2021-04-19 19:29:25 +03:00
Requires : gettext
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:44:59 +04:00
2021-04-19 19:23:12 +03:00
# Ensure smooth upgrades
Obsoletes : libvirt-admin < 7.3.0
2021-05-12 02:22:23 +03:00
Provides : libvirt-admin = %{version} -%{release}
2021-04-20 19:54:58 +03:00
Obsoletes : libvirt-bash-completion < 7.3.0
2021-04-19 19:23:12 +03:00
2022-12-14 03:30:59 +03:00
%description daemon-common
Miscellaneous files and utilities used by other libvirt daemons
2012-04-03 14:44:59 +04:00
2022-12-02 01:22:32 +03:00
%package daemon-lock
Summary : Server side daemon for managing locks
Requires : libvirt-libs = %{version} -%{release}
%description daemon-lock
Server side daemon used to manage locks held against virtual machine
resources
2022-12-02 21:24:27 +03:00
%package daemon-plugin-lockd
Summary : lockd client plugin for virtlockd
Requires : libvirt-libs = %{version} -%{release}
Requires : libvirt-daemon-lock = %{version} -%{release}
%description daemon-plugin-lockd
A client-side plugin that implements disk locking using POSIX fcntl advisory
locks via communication with the virtlockd daemon
2022-12-02 02:08:22 +03:00
%package daemon-log
Summary : Server side daemon for managing logs
Requires : libvirt-libs = %{version} -%{release}
%description daemon-log
Server side daemon used to manage logs from virtual machine consoles
2022-12-02 02:24:18 +03:00
%package daemon-proxy
Summary : Server side daemon providing libvirtd proxy
Requires : libvirt-libs = %{version} -%{release}
# netcat is needed on the server side so that clients that have
# libvirt < 6.9.0 can connect, but newer versions will prefer
# virt-ssh-helper. Making this a Recommends means that it gets
# installed by default, but can still be removed if compatibility
# with old clients is not required
Recommends: /usr/bin/nc
%description daemon-proxy
Server side daemon providing functionality previously provided by
the monolithic libvirtd
2012-04-03 14:44:59 +04:00
%package daemon-config-network
Summary : Default configuration files for the libvirtd daemon
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
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
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{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 : 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
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{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
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{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
Requires : mdevctl
2022-12-20 03:38:31 +03:00
# for modprobe of pci devices
Requires : module-init-tools
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
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
2018-07-09 18:45:45 +03:00
Requires : libvirt-libs = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%if %{with_netcf}
2013-10-29 15:27:45 +04:00
Requires : netcf-libs >= 0.2.2
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
%description daemon-driver-interface
The interface driver plugin for the libvirtd daemon, providing
2021-01-17 22:27:20 +03:00
an implementation of the host network interface APIs.
2012-04-02 23:53:43 +04:00
%package daemon-driver-secret
Summary : Secret driver plugin for the libvirtd daemon
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{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
2022-12-14 03:31:00 +03:00
Requires : libvirt-daemon-common = %{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
2023-11-30 20:22:54 +03:00
# For storage wiping with different algorithms
Requires : scrub
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2013-10-29 15:27:45 +04:00
# From QEMU RPMs
Requires : /usr/bin/qemu-img
2023-11-02 18:56:54 +03:00
%endif
%if !%{with_storage_rbd}
2022-09-27 12:11:24 +03:00
Obsoletes : libvirt-daemon-driver-storage-rbd < 5.2.0
2023-11-02 18:56:54 +03:00
%endif
2022-09-27 12:11:24 +03:00
Obsoletes : libvirt-daemon-driver-storage-sheepdog < 8.8.0
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.
2023-11-02 18:56:54 +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}
%description daemon-driver-storage-iscsi-direct
The storage driver backend adding implementation of the storage APIs for iscsi
volumes using libiscsi direct connection.
2023-11-02 18:56:54 +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.
2023-11-02 18:56:54 +03:00
%if %{with_storage_gluster}
2017-02-08 11:20:21 +03:00
%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}
2023-11-02 18:56:54 +03:00
%if 0%{?fedora}
2017-02-08 11:20:21 +03:00
Requires : glusterfs-client >= 2.0.1
2023-11-02 18:56:54 +03:00
%endif
%if 0%{?fedora} || 0%{?with_storage_gluster}
2017-02-08 11:20:21 +03:00
Requires : /usr/sbin/gluster
2023-11-02 18:56:54 +03:00
%endif
2017-02-08 11:20:21 +03:00
%description daemon-driver-storage-gluster
The storage driver backend adding implementation of the storage APIs for gluster
volumes using libgfapi.
2023-11-02 18:56:54 +03:00
%endif
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_rbd}
2017-02-08 11:20:21 +03:00
%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.
2023-11-02 18:56:54 +03:00
%endif
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_zfs}
2017-07-17 18:32:46 +03:00
%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.
2023-11-02 18:56:54 +03:00
%endif
2017-07-17 18:32:46 +03:00
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}
2023-11-02 18:56:54 +03:00
%if %{with_storage_iscsi_direct}
2018-08-14 15:31:35 +03:00
Requires : libvirt-daemon-driver-storage-iscsi-direct = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
%if %{with_storage_gluster}
2017-02-08 11:20:21 +03:00
Requires : libvirt-daemon-driver-storage-gluster = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
%if %{with_storage_rbd}
2017-02-08 11:20:21 +03:00
Requires : libvirt-daemon-driver-storage-rbd = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
%if %{with_storage_zfs}
2017-07-17 18:32:46 +03:00
Requires : libvirt-daemon-driver-storage-zfs = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%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.
2023-11-02 18:56:54 +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
2023-01-12 00:17:32 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-log = %{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
2016-07-12 17:57:39 +03:00
Requires : systemd-container
2021-01-04 21:03:24 +03:00
Requires : swtpm-tools
2023-11-02 18:56:54 +03:00
%if %{with_numad}
2022-12-20 07:18:26 +03:00
Requires : numad
2023-11-02 18:56:54 +03:00
%endif
%if 0%{?fedora} || 0%{?rhel} >= 9
2023-01-07 02:36:44 +03:00
Recommends: passt
2023-03-14 12:41:46 +03:00
Recommends: passt-selinux
2023-11-02 18:56:54 +03:00
%endif
%if %{with_nbdkit}
2023-07-20 20:21:26 +03:00
Recommends: nbdkit
Recommends: nbdkit-curl-plugin
Recommends: nbdkit-ssh-plugin
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +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
2023-01-12 00:17:32 +03:00
Requires : libvirt-daemon-common = %{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}
2016-07-12 17:57:39 +03:00
Requires : systemd-container
2022-12-20 03:38:31 +03:00
# for modprobe of nbd driver
Requires : module-init-tools
2023-11-02 18:56:54 +03:00
%if %{with_numad}
2022-12-20 07:18:26 +03:00
Requires : numad
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +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
2023-01-12 00:17:32 +03:00
Requires : libvirt-daemon-common = %{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
2023-11-02 18:56:54 +03:00
%endif
2013-05-17 16:31:59 +04:00
2023-11-02 18:56:54 +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
2023-01-12 00:17:32 +03:00
Requires : libvirt-daemon-common = %{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
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_modular_daemons}
2022-12-14 03:31:01 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-log = %{version} -%{release}
Requires : libvirt-daemon-lock = %{version} -%{release}
Requires : libvirt-daemon-plugin-lockd = %{version} -%{release}
Requires : libvirt-daemon-proxy = %{version} -%{release}
rpm: Recommend libvirt-daemon for with_modular_daemons distros
A default deployment on modern distros uses modular daemons but
switching back to the monolithic daemon, while not recommended,
is still considered a perfectly valid option.
For a monolithic daemon deployment, the upgrade to libvirt 9.2.0
or newer works as expected; a subsequent call to dnf autoremove,
however, results in the libvirt-daemon package being removed and
the deployment no longer working.
In order to avoid that situation, mark the libvirt-daemon as
recommended.
This will unfortunately result in it being included in most
installations despite not being necessary, but considering that
the alternative is breaking existing setups on upgrade it feels
like a reasonable tradeoff.
Moreover, since the dependency on libvirt-daemon is just a weak
one, it's still possible for people looking to minimize the
footprint of their installation to manually remove the package
after installation, mitigating the drawbacks of this approach.
https://bugzilla.redhat.com/show_bug.cgi?id=2232805
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-08-30 18:45:47 +03:00
Recommends: libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%else
2012-04-03 14:54:27 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
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
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_modular_daemons}
2022-12-14 03:31:01 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-log = %{version} -%{release}
Requires : libvirt-daemon-lock = %{version} -%{release}
Requires : libvirt-daemon-plugin-lockd = %{version} -%{release}
Requires : libvirt-daemon-proxy = %{version} -%{release}
rpm: Recommend libvirt-daemon for with_modular_daemons distros
A default deployment on modern distros uses modular daemons but
switching back to the monolithic daemon, while not recommended,
is still considered a perfectly valid option.
For a monolithic daemon deployment, the upgrade to libvirt 9.2.0
or newer works as expected; a subsequent call to dnf autoremove,
however, results in the libvirt-daemon package being removed and
the deployment no longer working.
In order to avoid that situation, mark the libvirt-daemon as
recommended.
This will unfortunately result in it being included in most
installations despite not being necessary, but considering that
the alternative is breaking existing setups on upgrade it feels
like a reasonable tradeoff.
Moreover, since the dependency on libvirt-daemon is just a weak
one, it's still possible for people looking to minimize the
footprint of their installation to manually remove the package
after installation, mitigating the drawbacks of this approach.
https://bugzilla.redhat.com/show_bug.cgi?id=2232805
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-08-30 18:45:47 +03:00
Recommends: libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%else
2012-04-03 14:54:27 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
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
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_modular_daemons}
2022-12-14 03:31:01 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-proxy = %{version} -%{release}
rpm: Recommend libvirt-daemon for with_modular_daemons distros
A default deployment on modern distros uses modular daemons but
switching back to the monolithic daemon, while not recommended,
is still considered a perfectly valid option.
For a monolithic daemon deployment, the upgrade to libvirt 9.2.0
or newer works as expected; a subsequent call to dnf autoremove,
however, results in the libvirt-daemon package being removed and
the deployment no longer working.
In order to avoid that situation, mark the libvirt-daemon as
recommended.
This will unfortunately result in it being included in most
installations despite not being necessary, but considering that
the alternative is breaking existing setups on upgrade it feels
like a reasonable tradeoff.
Moreover, since the dependency on libvirt-daemon is just a weak
one, it's still possible for people looking to minimize the
footprint of their installation to manually remove the package
after installation, mitigating the drawbacks of this approach.
https://bugzilla.redhat.com/show_bug.cgi?id=2232805
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-08-30 18:45:47 +03:00
Recommends: libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%else
2012-04-03 14:54:27 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
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
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_modular_daemons}
2022-12-14 03:31:01 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-lock = %{version} -%{release}
Requires : libvirt-daemon-plugin-lockd = %{version} -%{release}
Requires : libvirt-daemon-proxy = %{version} -%{release}
rpm: Recommend libvirt-daemon for with_modular_daemons distros
A default deployment on modern distros uses modular daemons but
switching back to the monolithic daemon, while not recommended,
is still considered a perfectly valid option.
For a monolithic daemon deployment, the upgrade to libvirt 9.2.0
or newer works as expected; a subsequent call to dnf autoremove,
however, results in the libvirt-daemon package being removed and
the deployment no longer working.
In order to avoid that situation, mark the libvirt-daemon as
recommended.
This will unfortunately result in it being included in most
installations despite not being necessary, but considering that
the alternative is breaking existing setups on upgrade it feels
like a reasonable tradeoff.
Moreover, since the dependency on libvirt-daemon is just a weak
one, it's still possible for people looking to minimize the
footprint of their installation to manually remove the package
after installation, mitigating the drawbacks of this approach.
https://bugzilla.redhat.com/show_bug.cgi?id=2232805
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-08-30 18:45:47 +03:00
Recommends: libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%else
2012-04-03 14:54:27 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
Requires : libvirt-daemon-driver-libxl = %{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 : xen
%description daemon-xen
Server side daemon and driver required to manage the virtualization
capabilities of XEN
2023-11-02 18:56:54 +03:00
%endif
2013-05-17 16:31:59 +04:00
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%if %{with_modular_daemons}
2022-12-14 03:31:01 +03:00
Requires : libvirt-daemon-common = %{version} -%{release}
Requires : libvirt-daemon-proxy = %{version} -%{release}
rpm: Recommend libvirt-daemon for with_modular_daemons distros
A default deployment on modern distros uses modular daemons but
switching back to the monolithic daemon, while not recommended,
is still considered a perfectly valid option.
For a monolithic daemon deployment, the upgrade to libvirt 9.2.0
or newer works as expected; a subsequent call to dnf autoremove,
however, results in the libvirt-daemon package being removed and
the deployment no longer working.
In order to avoid that situation, mark the libvirt-daemon as
recommended.
This will unfortunately result in it being included in most
installations despite not being necessary, but considering that
the alternative is breaking existing setups on upgrade it feels
like a reasonable tradeoff.
Moreover, since the dependency on libvirt-daemon is just a weak
one, it's still possible for people looking to minimize the
footprint of their installation to manually remove the package
after installation, mitigating the drawbacks of this approach.
https://bugzilla.redhat.com/show_bug.cgi?id=2232805
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-08-30 18:45:47 +03:00
Recommends: libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%else
2013-05-17 16:31:59 +04:00
Requires : libvirt-daemon = %{version} -%{release}
2023-11-02 18:56:54 +03:00
%endif
2013-05-17 16:31:59 +04:00
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
2023-11-02 18:56:54 +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
2022-12-02 03:08:38 +03:00
Requires : libvirt-libs = %{version} -%{release}
2011-02-21 20:43:29 +03:00
# Needed by virt-pki-validate script.
Requires : gnutls-utils
2021-04-20 19:54:58 +03:00
# Ensure smooth upgrades
Obsoletes : libvirt-bash-completion < 7.3.0
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).
tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
Libvirt provides QMP passthrough APIs for the QEMU driver and these are
exposed in virsh. It is not especially pleasant, however, using the raw
QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
exposes a human friendly interactive shell. It is not possible to use
this with libvirt managed guest, however, since only one client can
attach to the QMP socket at any point in time. While it would be
possible to configure a second QMP socket for a VM, it may not be
an known requirement at the time the guest is provisioned.
The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
socket and listens for incoming client connections, speaking QMP on
the connected socket. It will forward any QMP commands received onto
the running libvirt QEMU guest, and forward any replies back to the
QMP client. It will also forward back events.
$ virsh start demo
$ virt-qmp-proxy demo demo.qmp &
$ qmp-shell demo.qmp
Welcome to the QMP low-level shell!
Connected to QEMU 6.2.0
(QEMU) query-kvm
{
"return": {
"enabled": true,
"present": true
}
}
Note this tool of course has the same risks as the raw libvirt
QMP passthrough. It is safe to run query commands to fetch information
but commands which change the QEMU state risk disrupting libvirt's
management of QEMU, potentially resulting in data loss/corruption in
the worst case. Any use of this tool will cause the guest to be marked
as tainted as an warning that it could be in an unexpected state.
Since this tool introduces a python dependency it is not desirable
to include it in any of the existing RPMs in libvirt. This tool is
also QEMU specific, so isn't appropriate to bundle with the generic
tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to
contain additional QEMU specific tools, with extra external deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-27 12:34:47 +03:00
%package client-qemu
Summary : Additional client side utilities for QEMU
2022-12-02 03:08:38 +03:00
Requires : libvirt-libs = %{version} -%{release}
2022-11-02 14:42:26 +03:00
Requires : python3-libvirt >= 3.7.0
2023-02-16 17:57:56 +03:00
Requires : python3-cryptography
Requires : python3-lxml
tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
Libvirt provides QMP passthrough APIs for the QEMU driver and these are
exposed in virsh. It is not especially pleasant, however, using the raw
QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
exposes a human friendly interactive shell. It is not possible to use
this with libvirt managed guest, however, since only one client can
attach to the QMP socket at any point in time. While it would be
possible to configure a second QMP socket for a VM, it may not be
an known requirement at the time the guest is provisioned.
The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
socket and listens for incoming client connections, speaking QMP on
the connected socket. It will forward any QMP commands received onto
the running libvirt QEMU guest, and forward any replies back to the
QMP client. It will also forward back events.
$ virsh start demo
$ virt-qmp-proxy demo demo.qmp &
$ qmp-shell demo.qmp
Welcome to the QMP low-level shell!
Connected to QEMU 6.2.0
(QEMU) query-kvm
{
"return": {
"enabled": true,
"present": true
}
}
Note this tool of course has the same risks as the raw libvirt
QMP passthrough. It is safe to run query commands to fetch information
but commands which change the QEMU state risk disrupting libvirt's
management of QEMU, potentially resulting in data loss/corruption in
the worst case. Any use of this tool will cause the guest to be marked
as tainted as an warning that it could be in an unexpected state.
Since this tool introduces a python dependency it is not desirable
to include it in any of the existing RPMs in libvirt. This tool is
also QEMU specific, so isn't appropriate to bundle with the generic
tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to
contain additional QEMU specific tools, with extra external deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-27 12:34:47 +03:00
%description client-qemu
The additional client binaries are used to interact
with some QEMU specific features of libvirt.
2016-06-25 09:37:22 +03:00
%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
2023-11-02 18:56:54 +03:00
%if %{with_wireshark}
2014-02-04 23:37:15 +04:00
%package wireshark
Summary : Wireshark dissector plugin for libvirt RPC transactions
2020-11-13 14:13:21 +03:00
Requires : wireshark
2022-12-02 03:08:38 +03:00
Requires : libvirt-libs = %{version} -%{release}
2014-02-04 23:37:15 +04:00
%description wireshark
Wireshark dissector plugin for better analysis of libvirt RPC traffic.
2023-11-02 18:56:54 +03:00
%endif
2014-02-04 23:37:15 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2013-10-17 17:18:18 +04:00
%package login-shell
Summary : Login shell for connecting users to an LXC container
2022-12-02 03:08:38 +03:00
Requires : libvirt-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.
2023-11-02 18:56:54 +03:00
%endif
2013-10-17 17:18:18 +04:00
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
2022-12-02 03:08:38 +03:00
Requires : libvirt-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
2023-11-02 18:56:54 +03:00
%if %{with_sanlock}
2022-12-14 03:30:58 +03:00
%package daemon-plugin-sanlock
2011-01-18 21:37:45 +03:00
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
2022-12-02 03:08:38 +03:00
Requires : libvirt-libs = %{version} -%{release}
2022-12-14 03:30:58 +03:00
Obsoletes : libvirt-lock-sanlock < 9.1.0
Provides : libvirt-lock-sanlock = %{version} -%{release}
2011-01-18 21:37:45 +03:00
2022-12-14 03:30:58 +03:00
%description daemon-plugin-sanlock
2011-01-18 21:37:45 +03:00
Includes the Sanlock lock manager plugin for the QEMU
driver
2023-11-02 18:56:54 +03:00
%endif
2011-01-18 21:37:45 +03:00
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.
2023-11-02 18:56:54 +03:00
%endif
2016-02-16 11:41:30 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw32}
2022-08-08 18:40:56 +03:00
%package -n mingw32-libvirt
Summary : %{summary}
Obsoletes : mingw32-libvirt-static < 7.0.0
BuildArch : noarch
%description -n mingw32-libvirt
MinGW Windows libvirt virtualization library.
2023-11-02 14:24:21 +03:00
%{?mingw32_debug_package}
%endif
%if %{with_mingw64}
2022-08-08 18:40:56 +03:00
%package -n mingw64-libvirt
Summary : %{summary}
Obsoletes : mingw64-libvirt-static < 7.0.0
BuildArch : noarch
%description -n mingw64-libvirt
MinGW Windows libvirt virtualization library.
2023-11-02 18:10:35 +03:00
%{?mingw64_debug_package}
2022-08-08 18:40:56 +03:00
%endif
2015-04-15 17:16:24 +03:00
2005-11-02 18:37:34 +03:00
%prep
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
2021-05-11 18:16:36 +03:00
%if 0%{?fedora} >= %{min_fedora} || 0%{?rhel} >= %{min_rhel}
%define supported_platform 1
%else
%define supported_platform 0
%endif
2021-05-11 18:13:59 +03:00
%if ! %{supported_platform}
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} "
exit 1
2017-10-03 14:41:05 +03:00
%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-11-02 14:07:39 +03:00
%define arg_esx -Ddriver_esx=enabled -Dcurl=enabled
2016-05-04 18:50:55 +03:00
%else
2020-11-02 14:07:39 +03:00
%define arg_esx -Ddriver_esx=disabled -Dcurl=disabled
2009-09-16 19:02:38 +04:00
%endif
2016-05-04 18:50:55 +03:00
%if %{with_hyperv}
2020-11-02 14:07:39 +03:00
%define arg_hyperv -Ddriver_hyperv=enabled -Dopenwsman=enabled
2016-05-04 18:50:55 +03:00
%else
2020-11-02 14:07:39 +03:00
%define arg_hyperv -Ddriver_hyperv=disabled -Dopenwsman=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_gluster}
2020-11-02 14:07:39 +03:00
%define arg_storage_gluster -Dstorage_gluster=enabled -Dglusterfs=enabled
2016-05-04 18:50:55 +03:00
%else
2020-11-02 14:07:39 +03:00
%define arg_storage_gluster -Dstorage_gluster=disabled -Dglusterfs=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
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
%if %{with_nbdkit}
%define arg_nbdkit -Dnbdkit=enabled
%else
%define arg_nbdkit -Dnbdkit=disabled
%endif
2023-11-08 22:14:50 +03:00
%if %{with_nbdkit_config_default}
%define arg_nbdkit_config_default -Dnbdkit_config_default=enabled
%else
%define arg_nbdkit_config_default -Dnbdkit_config_default=disabled
%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
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
2021-01-17 22:27:20 +03:00
%if %{with_netcf}
%define arg_netcf -Dnetcf=enabled
%else
%define arg_netcf -Dnetcf=disabled
%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-11-02 14:07:39 +03:00
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=enabled -Dlibiscsi=enabled
2018-08-14 15:31:35 +03:00
%else
2020-11-02 14:07:39 +03:00
%define arg_storage_iscsi_direct -Dstorage_iscsi_direct=disabled -Dlibiscsi=disabled
2018-08-14 15:31:35 +03:00
%endif
2020-10-28 15:24:38 +03:00
%if %{with_libssh}
%define arg_libssh -Dlibssh=enabled
%else
%define arg_libssh -Dlibssh=disabled
%endif
%if %{with_libssh2}
%define arg_libssh2 -Dlibssh2=enabled
%else
%define arg_libssh2 -Dlibssh2=disabled
%endif
2021-08-02 18:52:20 +03:00
%if %{with_modular_daemons}
%define arg_remote_mode -Dremote_default_mode=direct
%else
%define arg_remote_mode -Dremote_default_mode=legacy
%endif
2024-02-09 18:21:19 +03:00
%if %{with_userfaultfd_sysctl}
%define arg_userfaultfd_sysctl -Duserfaultfd_sysctl=enabled
%else
%define arg_userfaultfd_sysctl -Duserfaultfd_sysctl=disabled
%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}"
%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
2022-12-02 03:08:38 +03:00
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir} /libvirt.spec)
2017-11-29 13:08:40 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_native}
2020-06-11 01:31:12 +03:00
%meson \
-Drunstatedir=%{_rundir} \
2023-04-29 19:52:24 +03:00
-Dinitconfdir=%{_sysconfdir} /sysconfig \
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 \
2021-05-27 21:57:57 +03:00
-Ddriver_remote=enabled \
-Ddriver_test=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 \
2021-05-12 20:01:31 +03:00
-Ddriver_ch=disabled \
2021-08-02 18:52:20 +03:00
%{?arg_remote_mode} \
2020-06-11 01:31:12 +03:00
-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_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} \
2021-01-17 22:27:20 +03:00
%{?arg_netcf} \
2023-11-02 19:30:06 +03:00
-Dnls=enabled \
2020-06-11 01:31:12 +03:00
-Dselinux=enabled \
2016-05-04 18:50:55 +03:00
%{?arg_selinux_mount} \
2020-06-11 01:31:12 +03:00
-Dapparmor=disabled \
2021-05-27 16:20:24 +03:00
-Dapparmor_profiles=disabled \
2020-06-11 01:31:12 +03:00
-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 \
meson: Improve nbdkit configurability
Currently, nbdkit support will automatically be enabled as long as
the pidfd_open(2) syscall is available. Optionally, libnbd is used
to generate more user-friendly error messages.
In theory this is all good, since use of nbdkit is supposed to be
transparent to the user. In practice, however, there is a problem:
if support for it is enabled at build time and the necessary
runtime components are installed, nbdkit will always be preferred,
with no way for the user to opt out.
This will arguably be fine in the long run, but right now none of
the platforms that we target ships with a SELinux policy that
allows libvirt to launch nbdkit, and the AppArmor policy that we
maintain ourselves hasn't been updated either.
So, in practice, as of today having nbdkit installed on the host
makes network disks completely unusable unless you're willing to
compromise the overall security of the system by disabling
SELinux/AppArmor.
In order to make the transition smoother, provide a convenient
way for users and distro packagers to disable nbdkit support at
compile time until SELinux and AppArmor are ready.
In the process, detection is completely overhauled. libnbd is
made mandatory when nbdkit support is enabled, since availability
across operating systems is comparable and offering users the
option to make error messages worse doesn't make a lot of sense;
we also make sure that an explicit request from the user to
enable/disable nbdkit support is either complied with, or results
in a build failure when that's not possible. Last but not least,
we avoid linking against libnbd when nbdkit support is disabled.
At the RPM level, we disable the feature when building against
anything older than Fedora 40, which still doesn't have the
necessary SELinux bits but will hopefully gain them by the time
it's released. We also allow nbdkit support to be disabled at
build time the same way as other optional features, that is, by
passing "--define '_without_nbdkit 1'" to rpmbuild. Finally, if
nbdkit support has been disabled, installing libvirt will no
longer drag it in as a (weak) dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2023-10-05 01:37:09 +03:00
%{?arg_nbdkit} \
2023-11-08 22:14:50 +03:00
%{?arg_nbdkit_config_default} \
2020-10-08 14:01:29 +03:00
-Dlibnl=enabled \
2020-06-11 01:31:12 +03:00
-Daudit=enabled \
-Ddtrace=enabled \
2020-10-05 19:31:37 +03:00
-Dfirewalld=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
%{?arg_firewalld_zone} \
2016-05-04 18:50:55 +03:00
%{?arg_wireshark} \
2020-10-28 15:24:38 +03:00
%{?arg_libssh} \
%{?arg_libssh2} \
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} \
2021-11-15 20:49:26 +03:00
-Dqemu_moddir=%{qemu_moddir} \
-Dqemu_datadir=%{qemu_datadir} \
2020-06-11 01:31:12 +03:00
-Dtls_priority=%{tls_priority} \
2024-02-14 21:00:08 +03:00
-Dsysctl_config=enabled \
2024-02-09 18:21:19 +03:00
%{?arg_userfaultfd_sysctl} \
2013-07-30 18:01:11 +04:00
%{?enable_werror} \
2020-06-11 01:31:12 +03:00
-Dexpensive_tests=enabled \
-Dinit_script=systemd \
2020-10-08 15:39:38 +03:00
-Ddocs=enabled \
2020-10-08 15:46:03 +03:00
-Dtests=enabled \
2020-10-13 13:11:49 +03:00
-Drpath=disabled \
2018-02-14 16:49:28 +03:00
%{?arg_login_shell}
2020-06-11 01:31:12 +03:00
%meson_build
2023-11-02 18:56:54 +03:00
%endif
2005-11-02 18:37:34 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw32} || %{with_mingw64}
2022-08-08 18:40:56 +03:00
%mingw_meson \
--auto-features=enabled \
-Ddriver_remote=enabled \
-Ddriver_test=enabled \
-Ddriver_esx=enabled \
-Dcurl=enabled \
-Ddocs=enabled \
-Dapparmor=disabled \
-Dapparmor_profiles=disabled \
-Dattr=disabled \
-Daudit=disabled \
-Dbash_completion=disabled \
-Dblkid=disabled \
-Dcapng=disabled \
-Ddriver_bhyve=disabled \
-Ddriver_hyperv=disabled \
-Ddriver_interface=disabled \
-Ddriver_libvirtd=disabled \
-Ddriver_libxl=disabled \
-Ddriver_lxc=disabled \
-Ddriver_network=disabled \
-Ddriver_openvz=disabled \
-Ddriver_qemu=disabled \
-Ddriver_secrets=disabled \
-Ddriver_vbox=disabled \
-Ddriver_vmware=disabled \
-Ddriver_vz=disabled \
-Ddtrace=disabled \
2023-11-02 18:15:50 +03:00
-Dexpensive_tests=disabled \
2022-08-08 18:40:56 +03:00
-Dfirewalld=disabled \
-Dfirewalld_zone=disabled \
-Dfuse=disabled \
-Dglusterfs=disabled \
-Dhost_validate=disabled \
-Dlibiscsi=disabled \
2023-10-23 05:34:52 +03:00
-Dnbdkit=disabled \
2024-01-05 11:39:45 +03:00
-Dnbdkit_config_default=disabled \
2022-08-08 18:40:56 +03:00
-Dlibnl=disabled \
-Dlibpcap=disabled \
-Dlibssh2=disabled \
-Dlibssh=disabled \
-Dlogin_shell=disabled \
-Dnetcf=disabled \
2023-11-02 19:30:06 +03:00
-Dnls=enabled \
2022-08-08 18:40:56 +03:00
-Dnss=disabled \
-Dnumactl=disabled \
-Dnumad=disabled \
-Dopenwsman=disabled \
-Dpciaccess=disabled \
-Dpm_utils=disabled \
-Dpolkit=disabled \
-Dreadline=disabled \
-Drpath=disabled \
-Dsanlock=disabled \
-Dsasl=disabled \
-Dsecdriver_apparmor=disabled \
-Dsecdriver_selinux=disabled \
-Dselinux=disabled \
-Dstorage_dir=disabled \
-Dstorage_disk=disabled \
-Dstorage_fs=disabled \
-Dstorage_gluster=disabled \
-Dstorage_iscsi_direct=disabled \
-Dstorage_iscsi=disabled \
-Dstorage_lvm=disabled \
-Dstorage_mpath=disabled \
-Dstorage_rbd=disabled \
-Dstorage_scsi=disabled \
-Dstorage_vstorage=disabled \
-Dstorage_zfs=disabled \
-Dsysctl_config=disabled \
2024-02-13 21:07:07 +03:00
-Duserfaultfd_sysctl=disabled \
2022-08-08 18:40:56 +03:00
-Dtests=disabled \
-Dudev=disabled \
-Dwireshark_dissector=disabled \
-Dyajl=disabled
2023-11-02 18:56:54 +03:00
%mingw_ninja
2022-08-08 18:40:56 +03:00
%endif
2005-11-02 18:37:34 +03:00
%install
rm -fr %{buildroot}
2022-12-02 03:08:38 +03:00
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir} /libvirt.spec)
2017-11-29 13:08:40 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_native}
2020-06-11 01:31:12 +03:00
%meson_install
2013-01-31 18:31:37 +04:00
2021-06-23 10:37:38 +03:00
# We don't want to install /etc/libvirt/qemu/networks in the main %%files list
2007-03-15 20:51:11 +03:00
# 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
2021-06-23 10:37:38 +03:00
# nwfilter files are installed in /usr/share/libvirt and copied to /etc in %%post
2017-04-12 22:36:01 +03:00
# 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
2023-11-02 18:56:54 +03: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
2024-02-02 21:59:44 +03:00
rm -f $RPM_BUILD_ROOT %{_sysusersdir} /libvirt-qemu.conf
2023-11-02 18:56:54 +03:00
%endif
2006-09-21 19:24:37 +04:00
%find_lang %{name}
2005-11-02 18:37:34 +03:00
2023-11-02 18:56:54 +03:00
%if ! %{with_sanlock}
2012-05-30 19:15:22 +04:00
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/libvirt_sanlock.aug
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/tests/test_libvirt_sanlock.aug
2023-11-02 18:56:54 +03:00
%endif
2012-05-30 19:15:22 +04:00
2023-11-02 18:56:54 +03:00
%if ! %{with_lxc}
2009-10-08 20:06:40 +04:00
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/libvirtd_lxc.aug
rm -f $RPM_BUILD_ROOT %{_datadir} /augeas/lenses/tests/test_libvirtd_lxc.aug
2023-11-02 18:56:54 +03:00
%endif
2009-10-08 20:06:40 +04:00
2023-11-02 18:56:54 +03:00
%if ! %{with_qemu}
2008-09-17 18:09:13 +04:00
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
2023-11-02 18:56:54 +03:00
%endif
%if ! %{with_lxc}
2009-10-08 19:40:14 +04:00
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
2023-11-02 18:56:54 +03:00
%endif
%if ! %{with_libxl}
2013-09-09 19:15:15 +04:00
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
2023-11-02 18:56:54 +03:00
%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
2023-11-02 18:56:54 +03:00
%ifarch %{arches_systemtap_64bit}
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
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03:00
%endif
2018-05-18 18:15:16 +03:00
%endif
2012-10-21 06:46:58 +04:00
%endif
2023-11-02 14:24:21 +03:00
%if %{with_mingw32} || %{with_mingw64}
2022-08-08 18:40:56 +03:00
%mingw_ninja_install
2023-11-02 14:24:21 +03:00
%endif
2022-08-08 18:40:56 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw32}
2022-08-08 18:40:56 +03:00
rm -rf $RPM_BUILD_ROOT %{mingw32_sysconfdir} /libvirt/nwfilter
rm -rf $RPM_BUILD_ROOT %{mingw32_datadir} /doc/*
rm -rf $RPM_BUILD_ROOT %{mingw32_datadir} /gtk-doc/*
rm -rf $RPM_BUILD_ROOT %{mingw32_libexecdir} /libvirt_iohelper.exe
rm -rf $RPM_BUILD_ROOT %{mingw32_libexecdir} /libvirt-guests.sh
2023-11-02 14:24:21 +03:00
%endif
%if %{with_mingw64}
rm -rf $RPM_BUILD_ROOT %{mingw64_sysconfdir} /libvirt/nwfilter
rm -rf $RPM_BUILD_ROOT %{mingw64_datadir} /doc/*
rm -rf $RPM_BUILD_ROOT %{mingw64_datadir} /gtk-doc/*
rm -rf $RPM_BUILD_ROOT %{mingw64_libexecdir} /libvirt_iohelper.exe
2022-08-08 18:40:56 +03:00
rm -rf $RPM_BUILD_ROOT %{mingw64_libexecdir} /libvirt-guests.sh
2023-11-02 14:24:21 +03:00
%endif
2022-08-08 18:40:56 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw32} || %{with_mingw64}
2022-08-08 18:40:56 +03:00
%mingw_debug_install_post
2022-12-12 13:52:49 +03:00
%mingw_find_lang %{name}
2022-08-08 18:40:56 +03:00
%endif
2010-04-12 22:39:00 +04:00
%check
2023-11-02 18:56:54 +03:00
%if %{with_native}
2021-01-22 00:54:45 +03:00
# Building on slow archs, like emulated s390x in Fedora copr, requires
# raising the test timeout
VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10
2023-11-02 18:56:54 +03:00
%endif
2010-04-12 22:39:00 +04:00
rpm: Introduce new macros for handling of systemd units
systemd provides a number of standard RPM macros but they don't
quite satisfy our requirements, as evidenced by the fact that we
have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're
already addressing with our custom ones:
* for some services (libvirtd, virtnetworkd, virtnwfilterd)
there are multiple conditions that might lead to a restart,
and we want to make sure that they're not needlessly
restarted several times per transaction;
* some services (virtlogd, virtlockd) must not be restarted
during upgrade, so we have to reload them instead.
Issues that neither the standard macros nor our custom ones
address:
* presets for units should be applied when the unit is first
installed, not when the package that contains it is.
The package split that happened in 9.1.0 highlighted why this
last point is so important: when virtproxyd and its sockets
were moved from libvirt-daemon to the new libvirt-daemon-proxy
package, upgrades from 9.0.0 caused presets for them to be
applied.
On a platform such as Fedora, where modular daemons are the
default, this has resulted in breaking existing deployments in
at least two scenarios.
The first one is machines that were configured to use the
monolithic daemon, either because the local admin had manually
changed the configuration or because the installation dated
back to before modular daemons had become the default. In this
case, virtproxyd.socket being enabled resulted in a silent
conflict with libvirtd.socket, which by design shares the same
path, and thus a completely broken setup.
The second one is machines where virtproxy-tls.socket, which is
disabled by default, had manually been enabled: in this case,
applying the presets resulted in it being disabled and thus a
loss of remote availability.
Note that these are just two concrete scenarios, but the problem
is more generic. For example, if we were to add more units to an
existing package, per the current approach they wouldn't have
their presets applied.
The new macros are designed to avoid all of the pitfalls
mentioned above. As a bonus, they're also simpler to use: where
the current approach requires restarts and other operations to
be handled separately, the new one integrates the two so that,
for each scriptlet, a single macro call is needed.
https://bugzilla.redhat.com/show_bug.cgi?id=2210058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-07-05 19:07:34 +03:00
%define libvirt_rpmstatedir %{_localstatedir}/lib/rpm-state/libvirt
# Mark units such that presets will later be applied to them. Meant
# to be called during %pre. Units that already exist on the system
# will not be marked, with the assumption that presets have already
# been applied at some point in the past. This makes it safe to call
# this macro for all units each time %pre runs.
%define libvirt_systemd_schedule_preset() \
mkdir -p %{libvirt_rpmstatedir} || : \
for unit in %{?*}; do \
if ! test -e %{_unitdir} /$unit; then \
touch %{libvirt_rpmstatedir} /preset-$unit || : \
fi \
done \
%{nil}
# Apply presets for units that have previously been marked. Meant to
# be called during %posttrans. Note that foo.service must be passed
# as the first argument, before all the various foo*.socket
# associated with it, for things to work correctly. This is necessary
# because Also=foo.socket is usually present in foo.service's
# [Install] section, and we want that configuration to take
# precedence over foo.socket's own presets.
%define libvirt_systemd_perform_preset() \
%{?7:%{error:Too many arguments}} \
for unit in %{?2} %{?3} %{?4} %{?5} %{?6} %1; do \
if test -e %{libvirt_rpmstatedir} /preset-$unit; then \
/usr/bin/systemctl --no-reload preset $unit || : \
fi \
rm -f %{libvirt_rpmstatedir} /preset-$unit \
done \
rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \
%{nil}
# Mark a single unit for restart. Meant to be called during %pre.
%define libvirt_systemd_schedule_restart() \
mkdir -p %{libvirt_rpmstatedir} || : \
touch %{libvirt_rpmstatedir} /restart-%1 || : \
%{nil}
# Restart a unit that was previously marked. Meant to be called
# during %posttrans. If systemd is not running, no action will be
# performed.
%define libvirt_systemd_perform_restart() \
if test -d /run/systemd/system && \
test -e %{libvirt_rpmstatedir} /restart-%1; then \
/usr/bin/systemctl try-restart %1 >/dev/null 2>&1 || : \
fi \
rm -f %{libvirt_rpmstatedir} /restart-%1 \
rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \
%{nil}
# Mark a single unit for reload. Meant to be called during %pre.
%define libvirt_systemd_schedule_reload() \
mkdir -p %{libvirt_rpmstatedir} || : \
touch %{libvirt_rpmstatedir} /reload-%1 || : \
%{nil}
# Reload a unit that was previously marked. Meant to be called during
# %posttrans. If systemd is not running, no action will be performed.
%define libvirt_systemd_perform_reload() \
if test -d /run/systemd/system && \
test -e %{libvirt_rpmstatedir} /reload-%1; then \
/usr/bin/systemctl try-reload-or-restart %1 >/dev/null 2>&1 || : \
fi \
rm -f %{libvirt_rpmstatedir} /reload-%1 \
rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \
%{nil}
# Disable a single unit, optionally stopping it if systemd is
# running. Meant to be called during %preun.
%define libvirt_systemd_disable() \
if test -d /run/systemd/system; then \
/usr/bin/systemctl --no-reload disable --now %{?*} || : \
else \
/usr/bin/systemctl --no-reload disable %{?*} || : \
fi \
%{nil}
# %pre implementation for services that should be restarted on
# upgrade. Note that foo.service must be passed as the first
# argument, before all the various foo*.socket associated with it.
%define libvirt_systemd_restart_pre() \
%libvirt_systemd_schedule_preset %{?*} \
%libvirt_systemd_schedule_restart %1 \
%{nil}
# %pre implementation for services that should be reloaded on
# upgrade. Note that foo.service must be passed as the first
# argument, before all the various foo*.socket associated with it.
%define libvirt_systemd_reload_pre() \
%libvirt_systemd_schedule_preset %{?*} \
%libvirt_systemd_schedule_reload %1 \
%{nil}
# %pre implementation for services that should be neither restarted
# nor reloaded on upgrade.
%define libvirt_systemd_noaction_pre() \
%libvirt_systemd_schedule_preset %{?*} \
%{nil}
# %posttrans implementation for all services. We can use a single
# macro to cover all scenarios, because each operation will only be
# performed if it had previously been scheduled. Note that
# foo.service must be passed as the first argument, before all the
# various foo*.socket associated with it.
%define libvirt_systemd_posttrans() \
%libvirt_systemd_perform_preset %{?*} \
%libvirt_systemd_perform_reload %1 \
%libvirt_systemd_perform_restart %1 \
%{nil}
# %preun implementation for all services.
%define libvirt_systemd_preun() \
if [ $1 -lt 1 ]; then \
%libvirt_systemd_disable %{?*} \
fi \
%{nil}
2021-12-14 19:21:44 +03:00
# For daemons with only UNIX sockets
2021-07-28 17:59:31 +03:00
rpm: Introduce new macros for handling of systemd units
systemd provides a number of standard RPM macros but they don't
quite satisfy our requirements, as evidenced by the fact that we
have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're
already addressing with our custom ones:
* for some services (libvirtd, virtnetworkd, virtnwfilterd)
there are multiple conditions that might lead to a restart,
and we want to make sure that they're not needlessly
restarted several times per transaction;
* some services (virtlogd, virtlockd) must not be restarted
during upgrade, so we have to reload them instead.
Issues that neither the standard macros nor our custom ones
address:
* presets for units should be applied when the unit is first
installed, not when the package that contains it is.
The package split that happened in 9.1.0 highlighted why this
last point is so important: when virtproxyd and its sockets
were moved from libvirt-daemon to the new libvirt-daemon-proxy
package, upgrades from 9.0.0 caused presets for them to be
applied.
On a platform such as Fedora, where modular daemons are the
default, this has resulted in breaking existing deployments in
at least two scenarios.
The first one is machines that were configured to use the
monolithic daemon, either because the local admin had manually
changed the configuration or because the installation dated
back to before modular daemons had become the default. In this
case, virtproxyd.socket being enabled resulted in a silent
conflict with libvirtd.socket, which by design shares the same
path, and thus a completely broken setup.
The second one is machines where virtproxy-tls.socket, which is
disabled by default, had manually been enabled: in this case,
applying the presets resulted in it being disabled and thus a
loss of remote availability.
Note that these are just two concrete scenarios, but the problem
is more generic. For example, if we were to add more units to an
existing package, per the current approach they wouldn't have
their presets applied.
The new macros are designed to avoid all of the pitfalls
mentioned above. As a bonus, they're also simpler to use: where
the current approach requires restarts and other operations to
be handled separately, the new one integrates the two so that,
for each scriptlet, a single macro call is needed.
https://bugzilla.redhat.com/show_bug.cgi?id=2210058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-07-05 19:07:34 +03:00
%define libvirt_systemd_unix_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket
%define libvirt_systemd_unix_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket
%define libvirt_systemd_unix_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket
2021-12-14 19:21:44 +03:00
# For daemons with UNIX and INET sockets
rpm: Introduce new macros for handling of systemd units
systemd provides a number of standard RPM macros but they don't
quite satisfy our requirements, as evidenced by the fact that we
have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're
already addressing with our custom ones:
* for some services (libvirtd, virtnetworkd, virtnwfilterd)
there are multiple conditions that might lead to a restart,
and we want to make sure that they're not needlessly
restarted several times per transaction;
* some services (virtlogd, virtlockd) must not be restarted
during upgrade, so we have to reload them instead.
Issues that neither the standard macros nor our custom ones
address:
* presets for units should be applied when the unit is first
installed, not when the package that contains it is.
The package split that happened in 9.1.0 highlighted why this
last point is so important: when virtproxyd and its sockets
were moved from libvirt-daemon to the new libvirt-daemon-proxy
package, upgrades from 9.0.0 caused presets for them to be
applied.
On a platform such as Fedora, where modular daemons are the
default, this has resulted in breaking existing deployments in
at least two scenarios.
The first one is machines that were configured to use the
monolithic daemon, either because the local admin had manually
changed the configuration or because the installation dated
back to before modular daemons had become the default. In this
case, virtproxyd.socket being enabled resulted in a silent
conflict with libvirtd.socket, which by design shares the same
path, and thus a completely broken setup.
The second one is machines where virtproxy-tls.socket, which is
disabled by default, had manually been enabled: in this case,
applying the presets resulted in it being disabled and thus a
loss of remote availability.
Note that these are just two concrete scenarios, but the problem
is more generic. For example, if we were to add more units to an
existing package, per the current approach they wouldn't have
their presets applied.
The new macros are designed to avoid all of the pitfalls
mentioned above. As a bonus, they're also simpler to use: where
the current approach requires restarts and other operations to
be handled separately, the new one integrates the two so that,
for each scriptlet, a single macro call is needed.
https://bugzilla.redhat.com/show_bug.cgi?id=2210058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-07-05 19:07:34 +03:00
%define libvirt_systemd_inet_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket
%define libvirt_systemd_inet_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket
%define libvirt_systemd_inet_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket
2021-12-14 19:21:44 +03:00
# For daemons with only UNIX sockets and no unprivileged read-only access
rpm: Introduce new macros for handling of systemd units
systemd provides a number of standard RPM macros but they don't
quite satisfy our requirements, as evidenced by the fact that we
have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're
already addressing with our custom ones:
* for some services (libvirtd, virtnetworkd, virtnwfilterd)
there are multiple conditions that might lead to a restart,
and we want to make sure that they're not needlessly
restarted several times per transaction;
* some services (virtlogd, virtlockd) must not be restarted
during upgrade, so we have to reload them instead.
Issues that neither the standard macros nor our custom ones
address:
* presets for units should be applied when the unit is first
installed, not when the package that contains it is.
The package split that happened in 9.1.0 highlighted why this
last point is so important: when virtproxyd and its sockets
were moved from libvirt-daemon to the new libvirt-daemon-proxy
package, upgrades from 9.0.0 caused presets for them to be
applied.
On a platform such as Fedora, where modular daemons are the
default, this has resulted in breaking existing deployments in
at least two scenarios.
The first one is machines that were configured to use the
monolithic daemon, either because the local admin had manually
changed the configuration or because the installation dated
back to before modular daemons had become the default. In this
case, virtproxyd.socket being enabled resulted in a silent
conflict with libvirtd.socket, which by design shares the same
path, and thus a completely broken setup.
The second one is machines where virtproxy-tls.socket, which is
disabled by default, had manually been enabled: in this case,
applying the presets resulted in it being disabled and thus a
loss of remote availability.
Note that these are just two concrete scenarios, but the problem
is more generic. For example, if we were to add more units to an
existing package, per the current approach they wouldn't have
their presets applied.
The new macros are designed to avoid all of the pitfalls
mentioned above. As a bonus, they're also simpler to use: where
the current approach requires restarts and other operations to
be handled separately, the new one integrates the two so that,
for each scriptlet, a single macro call is needed.
https://bugzilla.redhat.com/show_bug.cgi?id=2210058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-07-05 19:07:34 +03:00
%define libvirt_systemd_privileged_pre() %libvirt_systemd_reload_pre %1.service %1.socket %1-admin.socket
%define libvirt_systemd_privileged_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-admin.socket
%define libvirt_systemd_privileged_preun() %libvirt_systemd_preun %1.service %1.socket %1-admin.socket
# For one-shot daemons that have no associated sockets and should never be restarted
%define libvirt_systemd_oneshot_pre() %libvirt_systemd_noaction_pre %1.service
%define libvirt_systemd_oneshot_posttrans() %libvirt_systemd_posttrans %1.service
%define libvirt_systemd_oneshot_preun() %libvirt_systemd_preun %1.service
# For packages that install configuration for other daemons
%define libvirt_systemd_config_pre() %libvirt_systemd_schedule_restart %1.service
%define libvirt_systemd_config_posttrans() %libvirt_systemd_perform_restart %1.service
2023-11-02 18:56:54 +03:00
%if %{with_native}
2015-04-29 00:38:00 +03:00
%pre daemon
2022-12-14 03:30:59 +03:00
%libvirt_sysconfig_pre libvirtd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_pre libvirtd
2017-10-23 14:06:44 +03:00
%posttrans daemon
2022-12-14 03:30:59 +03:00
%libvirt_sysconfig_posttrans libvirtd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_posttrans libvirtd
2017-10-23 14:06:44 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_preun libvirtd
2023-07-05 19:49:17 +03:00
2022-12-14 03:30:59 +03:00
%pre daemon-common
%libvirt_sysconfig_pre libvirt-guests
2023-07-05 19:48:32 +03:00
%libvirt_systemd_oneshot_pre libvirt-guests
2022-12-14 03:30:59 +03:00
# 'libvirt' group is just to allow password-less polkit access to libvirt
# daemons. The uid number is irrelevant, so we use dynamic allocation.
getent group libvirt >/dev/null || groupadd -r libvirt
exit 0
2023-07-05 19:49:17 +03:00
%posttrans daemon-common
%libvirt_sysconfig_posttrans libvirt-guests
2023-07-05 19:48:32 +03:00
%libvirt_systemd_oneshot_posttrans libvirt-guests
2023-07-05 19:49:17 +03:00
2022-12-14 03:30:59 +03:00
%preun daemon-common
2023-07-05 19:48:32 +03:00
%libvirt_systemd_oneshot_preun libvirt-guests
2022-12-14 03:30:59 +03:00
2022-12-02 01:22:32 +03:00
%pre daemon-lock
%libvirt_sysconfig_pre virtlockd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_pre virtlockd
2022-12-02 01:22:32 +03:00
2023-07-05 19:49:17 +03:00
%posttrans daemon-lock
%libvirt_sysconfig_posttrans virtlockd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_posttrans virtlockd
2023-07-05 19:49:17 +03:00
2022-12-02 01:22:32 +03:00
%preun daemon-lock
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_preun virtlockd
2022-12-02 01:22:32 +03:00
2022-12-02 02:08:22 +03:00
%pre daemon-log
%libvirt_sysconfig_pre virtlogd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_pre virtlogd
2022-12-02 02:08:22 +03:00
2023-07-05 19:49:17 +03:00
%posttrans daemon-log
%libvirt_sysconfig_posttrans virtlogd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_posttrans virtlogd
2023-07-05 19:49:17 +03:00
2022-12-02 02:08:22 +03:00
%preun daemon-log
2023-07-05 19:48:32 +03:00
%libvirt_systemd_privileged_preun virtlogd
2022-12-02 02:08:22 +03:00
2022-12-02 02:24:18 +03:00
%pre daemon-proxy
%libvirt_sysconfig_pre virtproxyd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_pre virtproxyd
2022-12-02 02:24:18 +03:00
%posttrans daemon-proxy
%libvirt_sysconfig_posttrans virtproxyd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_posttrans virtproxyd
2022-12-02 02:24:18 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-proxy
2023-07-05 19:48:32 +03:00
%libvirt_systemd_inet_preun virtproxyd
2023-07-05 19:49:17 +03:00
2022-01-12 13:45:08 +03:00
%pre daemon-driver-network
%libvirt_sysconfig_pre virtnetworkd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtnetworkd
2022-01-12 13:45:08 +03:00
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
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03: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
2023-07-05 19:49:17 +03:00
%posttrans daemon-driver-network
%libvirt_sysconfig_posttrans virtnetworkd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtnetworkd
2023-07-05 19:49:17 +03:00
2021-12-21 14:22:42 +03:00
%preun daemon-driver-network
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtnetworkd
2021-07-28 19:12:43 +03:00
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
%postun daemon-driver-network
2023-11-02 18:56:54 +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
2023-11-02 18:56:54 +03: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
2022-01-12 13:45:08 +03:00
%pre daemon-driver-nwfilter
%libvirt_sysconfig_pre virtnwfilterd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtnwfilterd
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-nwfilter
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtnwfilterd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtnwfilterd
2021-07-28 18:53:16 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-driver-nwfilter
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtnwfilterd
2023-07-05 19:49:17 +03:00
2022-01-12 13:45:08 +03:00
%pre daemon-driver-nodedev
%libvirt_sysconfig_pre virtnodedevd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtnodedevd
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-nodedev
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtnodedevd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtnodedevd
2021-07-28 18:53:16 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-driver-nodedev
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtnodedevd
2023-07-05 19:49:17 +03:00
2022-01-12 13:45:08 +03:00
%pre daemon-driver-interface
%libvirt_sysconfig_pre virtinterfaced
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtinterfaced
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-interface
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtinterfaced
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtinterfaced
2021-07-28 18:53:16 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-driver-interface
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtinterfaced
2023-07-05 19:49:17 +03:00
2022-01-12 13:45:08 +03:00
%pre daemon-driver-secret
%libvirt_sysconfig_pre virtsecretd
2023-08-30 18:41:14 +03:00
%libvirt_systemd_unix_pre virtsecretd
2021-07-28 18:53:16 +03:00
2021-08-31 13:55:13 +03:00
%posttrans daemon-driver-secret
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtsecretd
2023-08-30 18:41:14 +03:00
%libvirt_systemd_unix_posttrans virtsecretd
2021-07-28 18:53:16 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-driver-secret
2023-08-30 18:41:14 +03:00
%libvirt_systemd_unix_preun virtsecretd
2023-07-05 19:49:17 +03:00
2022-01-19 15:41:28 +03:00
%pre daemon-driver-storage-core
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_pre virtstoraged
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtstoraged
2021-07-28 18:53:16 +03:00
2022-01-19 15:41:28 +03:00
%posttrans daemon-driver-storage-core
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtstoraged
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtstoraged
2021-07-28 18:53:16 +03:00
2023-07-05 19:49:17 +03:00
%preun daemon-driver-storage-core
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtstoraged
2023-07-05 19:49:17 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2021-12-21 14:22:43 +03:00
%pre daemon-driver-qemu
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_pre virtqemud
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtqemud
2024-02-02 21:59:44 +03:00
2021-12-21 14:22:43 +03:00
# We want soft static allocation of well-known ids, as disk images
2024-02-02 21:59:44 +03:00
# are commonly shared across NFS mounts by id rather than name.
# See https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
# We can not use the sysusers_create_compat macro here as we want to keep the
# specfile standalone and not relying on additionnal files.
getent group 'kvm' >/dev/null || groupadd -f -g '36' -r 'kvm' || :
getent group 'qemu' >/dev/null || groupadd -f -g '107' -r 'qemu' || :
if ! getent passwd 'qemu' >/dev/null; then
if ! getent passwd '107' >/dev/null; then
useradd -r -u '107' -g 'qemu' -G 'kvm' -d '/' -s '/sbin/nologin' -c 'qemu user' 'qemu' || :
2021-12-21 14:22:43 +03:00
else
2024-02-02 21:59:44 +03:00
useradd -r -g 'qemu' -G 'kvm' -d '/' -s '/sbin/nologin' -c 'qemu user' 'qemu' || :
2021-12-21 14:22:43 +03:00
fi
fi
exit 0
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-qemu
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtqemud
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtqemud
2023-07-05 19:49:17 +03:00
%preun daemon-driver-qemu
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtqemud
2023-11-02 18:56:54 +03:00
%endif
2021-07-28 18:53:16 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2022-01-12 13:45:08 +03:00
%pre daemon-driver-lxc
%libvirt_sysconfig_pre virtlxcd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtlxcd
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-lxc
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtlxcd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtlxcd
2023-07-05 19:49:17 +03:00
%preun daemon-driver-lxc
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtlxcd
2023-11-02 18:56:54 +03:00
%endif
2021-07-28 18:53:16 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_vbox}
2023-07-05 19:49:17 +03:00
%pre daemon-driver-vbox
%libvirt_sysconfig_pre virtvboxd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtvboxd
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-vbox
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtvboxd
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtvboxd
2023-07-05 19:49:17 +03:00
%preun daemon-driver-vbox
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtvboxd
2023-11-02 18:56:54 +03:00
%endif
2021-07-28 18:53:16 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_libxl}
2023-07-05 19:49:17 +03:00
%pre daemon-driver-libxl
%libvirt_sysconfig_pre virtxend
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_pre virtxend
2021-07-28 18:53:16 +03:00
%posttrans daemon-driver-libxl
2022-01-12 13:45:08 +03:00
%libvirt_sysconfig_posttrans virtxend
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_posttrans virtxend
2023-07-05 19:49:17 +03:00
%preun daemon-driver-libxl
2023-07-05 19:48:32 +03:00
%libvirt_systemd_unix_preun virtxend
2023-11-02 18:56:54 +03:00
%endif
2021-07-28 18:53:16 +03:00
2023-07-05 19:48:32 +03:00
%pre daemon-config-network
%libvirt_systemd_config_pre libvirtd
%libvirt_systemd_config_pre virtnetworkd
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
sed -e " s / $ { o r i g _ s u b } / $ { s u b } / g " \
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
2017-10-23 14:06:44 +03:00
fi
%posttrans daemon-config-network
2023-07-05 19:48:32 +03:00
%libvirt_systemd_config_posttrans libvirtd
%libvirt_systemd_config_posttrans virtnetworkd
%pre daemon-config-nwfilter
%libvirt_systemd_config_pre libvirtd
%libvirt_systemd_config_pre virtnwfilterd
2017-04-12 22:36:01 +03:00
%post daemon-config-nwfilter
2020-12-07 10:49:12 +03:00
for datadir_file in %{_datadir} /libvirt/nwfilter/*.xml; do
sysconfdir_file=%{_sysconfdir} /libvirt/nwfilter/$(basename " $ d a t a d i r _ f i l e " )
if [ ! -f " $ s y s c o n f d i r _ f i l e " ]; then
# libvirt saves these files with mode 600
install -m 0600 " $ d a t a d i r _ f i l e " " $ s y s c o n f d i r _ f i l e "
fi
done
2017-10-23 14:06:44 +03:00
%posttrans daemon-config-nwfilter
2023-07-05 19:48:32 +03:00
%libvirt_systemd_config_posttrans libvirtd
%libvirt_systemd_config_posttrans virtnwfilterd
2017-04-12 22:36:01 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2013-11-22 15:13:03 +04:00
%pre login-shell
getent group virtlogin >/dev/null || groupadd -r virtlogin
exit 0
2023-11-02 18:56:54 +03:00
%endif
2013-11-22 15:13:03 +04:00
%endif
2023-11-02 18:56:54 +03:00
%if %{with_native}
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
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
2007-10-12 23:54:15 +04:00
%config (noreplace) %{_sysconfdir} /libvirt/libvirtd.conf
2015-04-15 12:49:22 +03:00
%config (noreplace) %{_prefix} /lib/sysctl.d/60-libvirtd.conf
2011-03-03 10:26:22 +03:00
%config (noreplace) %{_sysconfdir} /logrotate.d/libvirtd
2022-12-14 03:30:59 +03:00
%{_datadir} /augeas/lenses/libvirtd.aug
%{_datadir} /augeas/lenses/tests/test_libvirtd.aug
%attr (0755, root, root) %{_sbindir} /libvirtd
%{_mandir} /man8/libvirtd.8*
%files daemon-common
%{_unitdir} /virt-guest-shutdown.target
%{_unitdir} /libvirt-guests.service
%config (noreplace) %{_sysconfdir} /sasl2/libvirt.conf
2007-03-15 20:51:11 +03:00
%dir %{_datadir} /libvirt/
2019-08-20 19:38:58 +03:00
%ghost %dir %{_rundir} /libvirt/
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/common/
2022-01-24 18:54:43 +03:00
%dir %attr (0755, root, root) %{_localstatedir} /lib/libvirt/
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/
2017-08-27 19:35:07 +03:00
%dir %attr (0755, root, root) %{_libdir} /libvirt/
%dir %attr (0755, root, root) %{_libdir} /libvirt/connection-driver/
2022-12-13 13:09:40 +03:00
%dir %attr (0755, root, root) %{_libdir} /libvirt/storage-backend/
%dir %attr (0755, root, root) %{_libdir} /libvirt/storage-file/
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
2009-07-28 22:07:51 +04:00
%dir %attr (0700, root, root) %{_localstatedir} /log/libvirt/
2011-03-30 04:54:23 +04:00
%attr (0755, root, root) %{_libexecdir} /libvirt_iohelper
2019-07-08 18:38:49 +03:00
%attr (0755, root, root) %{_bindir} /virt-ssh-helper
2021-04-19 19:29:25 +03:00
%attr (0755, root, root) %{_libexecdir} /libvirt-guests.sh
2021-04-19 19:23:12 +03:00
%{_mandir} /man1/virt-admin.1*
2021-04-19 19:29:25 +03:00
%{_mandir} /man1/virt-host-validate.1*
2022-01-13 16:42:21 +03:00
%{_mandir} /man8/virt-ssh-helper.8*
2022-01-08 00:35:10 +03:00
%{_mandir} /man8/libvirt-guests.8*
2021-04-19 19:29:25 +03:00
%{_bindir} /virt-host-validate
2021-04-19 19:23:12 +03:00
%{_bindir} /virt-admin
%{_datadir} /bash-completion/completions/virt-admin
2022-12-02 01:22:32 +03:00
%files daemon-lock
%{_unitdir} /virtlockd.service
%{_unitdir} /virtlockd.socket
%{_unitdir} /virtlockd-admin.socket
%config (noreplace) %{_sysconfdir} /libvirt/virtlockd.conf
%{_datadir} /augeas/lenses/virtlockd.aug
%{_datadir} /augeas/lenses/tests/test_virtlockd.aug
%{_datadir} /augeas/lenses/libvirt_lockd.aug
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2022-12-02 01:22:32 +03:00
%{_datadir} /augeas/lenses/tests/test_libvirt_lockd.aug
2023-11-02 18:56:54 +03:00
%endif
2022-12-02 01:22:32 +03:00
%attr (0755, root, root) %{_sbindir} /virtlockd
%{_mandir} /man8/virtlockd.8*
2022-12-02 21:24:27 +03:00
%files daemon-plugin-lockd
%dir %attr (0755, root, root) %{_libdir} /libvirt/lock-driver/
%attr (0755, root, root) %{_libdir} /libvirt/lock-driver/lockd.so
2022-12-02 02:08:22 +03:00
%files daemon-log
%{_unitdir} /virtlogd.service
%{_unitdir} /virtlogd.socket
%{_unitdir} /virtlogd-admin.socket
%config (noreplace) %{_sysconfdir} /libvirt/virtlogd.conf
%{_datadir} /augeas/lenses/virtlogd.aug
%{_datadir} /augeas/lenses/tests/test_virtlogd.aug
%attr (0755, root, root) %{_sbindir} /virtlogd
%{_mandir} /man8/virtlogd.8*
2022-12-02 02:24:18 +03:00
%files daemon-proxy
%{_unitdir} /virtproxyd.service
%{_unitdir} /virtproxyd.socket
%{_unitdir} /virtproxyd-ro.socket
%{_unitdir} /virtproxyd-admin.socket
%{_unitdir} /virtproxyd-tcp.socket
%{_unitdir} /virtproxyd-tls.socket
%config (noreplace) %{_sysconfdir} /libvirt/virtproxyd.conf
%{_datadir} /augeas/lenses/virtproxyd.aug
%{_datadir} /augeas/lenses/tests/test_virtproxyd.aug
%attr (0755, root, root) %{_sbindir} /virtproxyd
%{_mandir} /man8/virtproxyd.8*
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
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
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/interface/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_interface.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtinterfaced.8*
2012-04-02 23:53:43 +04:00
%files daemon-driver-network
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
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_network.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtnetworkd.8*
2023-11-02 18:56:54 +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
%{_prefix} /lib/firewalld/zones/libvirt.xml
2022-09-22 18:13:22 +03:00
%{_prefix} /lib/firewalld/zones/libvirt-routed.xml
2022-09-22 18:13:23 +03:00
%{_prefix} /lib/firewalld/policies/libvirt-routed-in.xml
%{_prefix} /lib/firewalld/policies/libvirt-routed-out.xml
%{_prefix} /lib/firewalld/policies/libvirt-to-host.xml
2023-11-02 18:56:54 +03: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
2012-04-02 23:53:43 +04:00
%files daemon-driver-nodedev
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
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/nodedev/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_nodedev.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtnodedevd.8*
2012-04-02 23:53:43 +04:00
%files daemon-driver-nwfilter
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/
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/nwfilter-binding/
%ghost %dir %{_rundir} /libvirt/nwfilter/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_nwfilter.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtnwfilterd.8*
2012-04-02 23:53:43 +04:00
%files daemon-driver-secret
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
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/secrets/
%ghost %dir %{_rundir} /libvirt/secrets/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_secret.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtsecretd.8*
2012-04-02 23:53:43 +04:00
%files daemon-driver-storage
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-core
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
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/storage/
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/storage/autostart/
%ghost %dir %{_rundir} /libvirt/storage/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_storage.so
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_fs.so
%{_libdir} /libvirt/storage-file/libvirt_storage_file_fs.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtstoraged.8*
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-disk
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_disk.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-logical
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_logical.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-scsi
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_scsi.so
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-iscsi
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_iscsi.so
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_iscsi_direct}
2018-08-09 02:43:25 +03:00
%files daemon-driver-storage-iscsi-direct
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_iscsi-direct.so
2023-11-02 18:56:54 +03:00
%endif
2018-08-09 02:43:25 +03:00
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-mpath
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_mpath.so
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_gluster}
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-gluster
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_gluster.so
%{_libdir} /libvirt/storage-file/libvirt_storage_file_gluster.so
2023-11-02 18:56:54 +03:00
%endif
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_rbd}
2017-02-08 11:20:21 +03:00
%files daemon-driver-storage-rbd
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_rbd.so
2023-11-02 18:56:54 +03:00
%endif
2017-02-08 11:20:21 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_storage_zfs}
2017-07-17 18:32:46 +03:00
%files daemon-driver-storage-zfs
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/storage-backend/libvirt_storage_backend_zfs.so
2023-11-02 18:56:54 +03:00
%endif
2017-07-17 18:32:46 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2012-04-02 23:53:43 +04:00
%files daemon-driver-qemu
2018-03-16 20:05:24 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/virtqemud.conf
2024-02-09 18:21:19 +03:00
%if %{with_userfaultfd_sysctl}
2021-12-02 17:43:27 +03:00
%config (noreplace) %{_prefix} /lib/sysctl.d/60-qemu-postcopy-migration.conf
2024-02-09 18:21:19 +03:00
%endif
2018-03-16 20:05:24 +03:00
%{_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/
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/qemu/autostart/
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/
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/qemu/dbus/
2023-01-07 02:36:44 +03:00
%ghost %dir %{_rundir} /libvirt/qemu/passt/
2022-01-24 21:05:44 +03:00
%ghost %dir %{_rundir} /libvirt/qemu/slirp/
2022-02-02 13:56:37 +03:00
%ghost %dir %{_rundir} /libvirt/qemu/swtpm/
2015-09-08 19:34:36 +03:00
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/
2022-01-24 21:05:44 +03:00
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/checkpoint/
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/dump/
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/nvram/
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/ram/
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/save/
%dir %attr (0751, %{qemu_user} , %{qemu_group} ) %{_localstatedir} /lib/libvirt/qemu/snapshot/
2021-10-11 14:47:20 +03:00
%dir %attr (0750, root, root) %{_localstatedir} /cache/libvirt/qemu/
2013-12-06 03:15:55 +04:00
%{_datadir} /augeas/lenses/libvirtd_qemu.aug
%{_datadir} /augeas/lenses/tests/test_libvirtd_qemu.aug
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_qemu.so
2017-04-04 19:22:31 +03:00
%dir %attr (0711, root, root) %{_localstatedir} /lib/libvirt/swtpm/
2021-01-04 21:03:55 +03:00
%dir %attr (0730, tss, tss) %{_localstatedir} /log/swtpm/libvirt/qemu/
2019-05-17 15:01:59 +03:00
%{_bindir} /virt-qemu-run
%{_mandir} /man1/virt-qemu-run.1*
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtqemud.8*
2024-02-02 21:59:44 +03:00
%{_sysusersdir} /libvirt-qemu.conf
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2012-04-02 23:53:43 +04:00
%files daemon-driver-lxc
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/
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/lxc/
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/lxc/autostart/
2013-12-06 03:15:55 +04:00
%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
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_lxc.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtlxcd.8*
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_libxl}
2012-04-02 23:53:43 +04:00
%files daemon-driver-libxl
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
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/libxl/
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/libxl/autostart/
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/
2022-01-24 21:05:44 +03:00
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/libxl/channel/
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/libxl/channel/target/
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/libxl/dump/
%dir %attr (0700, root, root) %{_localstatedir} /lib/libvirt/libxl/save/
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_libxl.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtxend.8*
2023-11-02 18:56:54 +03:00
%endif
2013-05-17 16:31:59 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%files daemon-driver-vbox
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
2022-12-02 03:08:38 +03:00
%{_libdir} /libvirt/connection-driver/libvirt_driver_vbox.so
2020-09-24 17:08:37 +03:00
%{_mandir} /man8/virtvboxd.8*
2023-11-02 18:56:54 +03:00
%endif
2012-04-02 23:53:43 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_qemu_tcg}
2012-04-03 14:54:27 +04:00
%files daemon-qemu
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_qemu_kvm}
2012-04-03 14:54:27 +04:00
%files daemon-kvm
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2012-04-03 14:54:27 +04:00
%files daemon-lxc
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 14:54:27 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_libxl}
2012-04-03 14:54:27 +04:00
%files daemon-xen
2023-11-02 18:56:54 +03:00
%endif
2013-05-17 16:31:59 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_vbox}
2013-05-17 16:31:59 +04:00
%files daemon-vbox
2023-11-02 18:56:54 +03:00
%endif
2012-04-03 13:52:12 +04:00
2023-11-02 18:56:54 +03:00
%if %{with_sanlock}
2022-12-14 03:30:58 +03:00
%files daemon-plugin-sanlock
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2011-06-14 12:20:49 +04:00
%config (noreplace) %{_sysconfdir} /libvirt/qemu-sanlock.conf
2023-11-02 18:56:54 +03:00
%endif
%if %{with_libxl}
2015-05-01 21:39:30 +03:00
%config (noreplace) %{_sysconfdir} /libvirt/libxl-sanlock.conf
2023-11-02 18:56:54 +03:00
%endif
2022-12-14 03:30:58 +03:00
%dir %attr (0755, root, root) %{_libdir} /libvirt/lock-driver/
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
2023-11-02 18:56:54 +03:00
%endif
2011-01-18 21:37:45 +03:00
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*
2021-12-09 20:36:34 +03:00
%{_mandir} /man1/virt-pki-query-dn.1*
2009-09-16 17:42:57 +04:00
%{_mandir} /man1/virt-pki-validate.1*
2022-01-27 17:20:31 +03:00
%{_mandir} /man7/virkey*.7*
2009-07-21 13:16:15 +04:00
%{_bindir} /virsh
%{_bindir} /virt-xml-validate
2021-11-11 17:35:38 +03:00
%{_bindir} /virt-pki-query-dn
2009-09-16 17:42:57 +04:00
%{_bindir} /virt-pki-validate
2018-01-24 18:42:00 +03:00
%{_datadir} /bash-completion/completions/virsh
2017-11-02 16:41:53 +03:00
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
Libvirt provides QMP passthrough APIs for the QEMU driver and these are
exposed in virsh. It is not especially pleasant, however, using the raw
QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
exposes a human friendly interactive shell. It is not possible to use
this with libvirt managed guest, however, since only one client can
attach to the QMP socket at any point in time. While it would be
possible to configure a second QMP socket for a VM, it may not be
an known requirement at the time the guest is provisioned.
The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
socket and listens for incoming client connections, speaking QMP on
the connected socket. It will forward any QMP commands received onto
the running libvirt QEMU guest, and forward any replies back to the
QMP client. It will also forward back events.
$ virsh start demo
$ virt-qmp-proxy demo demo.qmp &
$ qmp-shell demo.qmp
Welcome to the QMP low-level shell!
Connected to QEMU 6.2.0
(QEMU) query-kvm
{
"return": {
"enabled": true,
"present": true
}
}
Note this tool of course has the same risks as the raw libvirt
QMP passthrough. It is safe to run query commands to fetch information
but commands which change the QEMU state risk disrupting libvirt's
management of QEMU, potentially resulting in data loss/corruption in
the worst case. Any use of this tool will cause the guest to be marked
as tainted as an warning that it could be in an unexpected state.
Since this tool introduces a python dependency it is not desirable
to include it in any of the existing RPMs in libvirt. This tool is
also QEMU specific, so isn't appropriate to bundle with the generic
tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to
contain additional QEMU specific tools, with extra external deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-27 12:34:47 +03:00
%files client-qemu
%{_mandir} /man1/virt-qemu-qmp-proxy.1*
2021-12-09 23:33:22 +03:00
%{_mandir} /man1/virt-qemu-sev-validate.1*
tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
Libvirt provides QMP passthrough APIs for the QEMU driver and these are
exposed in virsh. It is not especially pleasant, however, using the raw
QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
exposes a human friendly interactive shell. It is not possible to use
this with libvirt managed guest, however, since only one client can
attach to the QMP socket at any point in time. While it would be
possible to configure a second QMP socket for a VM, it may not be
an known requirement at the time the guest is provisioned.
The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
socket and listens for incoming client connections, speaking QMP on
the connected socket. It will forward any QMP commands received onto
the running libvirt QEMU guest, and forward any replies back to the
QMP client. It will also forward back events.
$ virsh start demo
$ virt-qmp-proxy demo demo.qmp &
$ qmp-shell demo.qmp
Welcome to the QMP low-level shell!
Connected to QEMU 6.2.0
(QEMU) query-kvm
{
"return": {
"enabled": true,
"present": true
}
}
Note this tool of course has the same risks as the raw libvirt
QMP passthrough. It is safe to run query commands to fetch information
but commands which change the QEMU state risk disrupting libvirt's
management of QEMU, potentially resulting in data loss/corruption in
the worst case. Any use of this tool will cause the guest to be marked
as tainted as an warning that it could be in an unexpected state.
Since this tool introduces a python dependency it is not desirable
to include it in any of the existing RPMs in libvirt. This tool is
also QEMU specific, so isn't appropriate to bundle with the generic
tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to
contain additional QEMU specific tools, with extra external deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-27 12:34:47 +03:00
%{_bindir} /virt-qemu-qmp-proxy
2021-12-09 23:33:22 +03:00
%{_bindir} /virt-qemu-sev-validate
2023-11-02 18:56:54 +03:00
%endif
tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
Libvirt provides QMP passthrough APIs for the QEMU driver and these are
exposed in virsh. It is not especially pleasant, however, using the raw
QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
exposes a human friendly interactive shell. It is not possible to use
this with libvirt managed guest, however, since only one client can
attach to the QMP socket at any point in time. While it would be
possible to configure a second QMP socket for a VM, it may not be
an known requirement at the time the guest is provisioned.
The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
socket and listens for incoming client connections, speaking QMP on
the connected socket. It will forward any QMP commands received onto
the running libvirt QEMU guest, and forward any replies back to the
QMP client. It will also forward back events.
$ virsh start demo
$ virt-qmp-proxy demo demo.qmp &
$ qmp-shell demo.qmp
Welcome to the QMP low-level shell!
Connected to QEMU 6.2.0
(QEMU) query-kvm
{
"return": {
"enabled": true,
"present": true
}
}
Note this tool of course has the same risks as the raw libvirt
QMP passthrough. It is safe to run query commands to fetch information
but commands which change the QEMU state risk disrupting libvirt's
management of QEMU, potentially resulting in data loss/corruption in
the worst case. Any use of this tool will cause the guest to be marked
as tainted as an warning that it could be in an unexpected state.
Since this tool introduces a python dependency it is not desirable
to include it in any of the existing RPMs in libvirt. This tool is
also QEMU specific, so isn't appropriate to bundle with the generic
tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to
contain additional QEMU specific tools, with extra external deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-27 12:34:47 +03:00
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
2022-01-24 18:54:01 +03:00
%dir %attr (0700, root, root) %{_sysconfdir} /libvirt/
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/
2021-04-19 19:31:10 +03:00
%{_datadir} /systemtap/tapset/libvirt_probes*.stp
%{_datadir} /systemtap/tapset/libvirt_functions.stp
2023-11-02 18:56:54 +03:00
%if %{with_qemu}
2021-04-19 19:31:10 +03:00
%{_datadir} /systemtap/tapset/libvirt_qemu_probes*.stp
2023-11-02 18:56:54 +03:00
%endif
2020-10-08 09:16:20 +03:00
%{_datadir} /libvirt/schemas/*.rng
2018-08-16 14:39:39 +03:00
%{_datadir} /libvirt/cpu_map/*.xml
2016-12-06 15:45:18 +03:00
%{_datadir} /libvirt/test-screenshot.png
2023-11-02 18:56:54 +03:00
%if %{with_wireshark}
2014-02-04 23:37:15 +04:00
%files wireshark
2018-05-03 14:17:31 +03:00
%{wireshark_plugindir} /libvirt.so
2023-11-02 18:56:54 +03:00
%endif
2014-02-04 23:37:15 +04:00
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
2023-11-02 18:56:54 +03:00
%if %{with_lxc}
2013-10-17 17:18:18 +04:00
%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*
2023-11-02 18:56:54 +03:00
%endif
2013-10-17 17:18:18 +04:00
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
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
2023-11-02 18:56:54 +03:00
%endif
2016-04-13 17:37:42 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw32}
2022-12-12 13:52:49 +03:00
%files -n mingw32-libvirt -f mingw32-libvirt.lang
2022-08-08 18:40:56 +03:00
%dir %{mingw32_sysconfdir} /libvirt/
%config (noreplace) %{mingw32_sysconfdir} /libvirt/libvirt.conf
%config (noreplace) %{mingw32_sysconfdir} /libvirt/libvirt-admin.conf
%{mingw32_bindir} /libvirt-0.dll
%{mingw32_bindir} /virsh.exe
%{mingw32_bindir} /virt-admin.exe
%{mingw32_bindir} /virt-xml-validate
%{mingw32_bindir} /virt-pki-query-dn.exe
%{mingw32_bindir} /virt-pki-validate
%{mingw32_bindir} /libvirt-lxc-0.dll
%{mingw32_bindir} /libvirt-qemu-0.dll
%{mingw32_bindir} /libvirt-admin-0.dll
%{mingw32_libdir} /libvirt.dll.a
%{mingw32_libdir} /pkgconfig/libvirt.pc
%{mingw32_libdir} /pkgconfig/libvirt-qemu.pc
%{mingw32_libdir} /pkgconfig/libvirt-lxc.pc
%{mingw32_libdir} /pkgconfig/libvirt-admin.pc
%{mingw32_libdir} /libvirt-lxc.dll.a
%{mingw32_libdir} /libvirt-qemu.dll.a
%{mingw32_libdir} /libvirt-admin.dll.a
%dir %{mingw32_datadir} /libvirt/
%dir %{mingw32_datadir} /libvirt/schemas/
%{mingw32_datadir} /libvirt/schemas/*.rng
%dir %{mingw32_datadir} /libvirt/api/
%{mingw32_datadir} /libvirt/api/libvirt-api.xml
%{mingw32_datadir} /libvirt/api/libvirt-lxc-api.xml
%{mingw32_datadir} /libvirt/api/libvirt-qemu-api.xml
%{mingw32_datadir} /libvirt/api/libvirt-admin-api.xml
%{mingw32_datadir} /libvirt/cpu_map/*.xml
%{mingw32_datadir} /libvirt/test-screenshot.png
%dir %{mingw32_includedir} /libvirt
%{mingw32_includedir} /libvirt/libvirt.h
%{mingw32_includedir} /libvirt/libvirt-common.h
%{mingw32_includedir} /libvirt/libvirt-domain.h
%{mingw32_includedir} /libvirt/libvirt-domain-checkpoint.h
%{mingw32_includedir} /libvirt/libvirt-domain-snapshot.h
%{mingw32_includedir} /libvirt/libvirt-event.h
%{mingw32_includedir} /libvirt/libvirt-host.h
%{mingw32_includedir} /libvirt/libvirt-interface.h
%{mingw32_includedir} /libvirt/libvirt-network.h
%{mingw32_includedir} /libvirt/libvirt-nodedev.h
%{mingw32_includedir} /libvirt/libvirt-nwfilter.h
%{mingw32_includedir} /libvirt/libvirt-secret.h
%{mingw32_includedir} /libvirt/libvirt-storage.h
%{mingw32_includedir} /libvirt/libvirt-stream.h
%{mingw32_includedir} /libvirt/virterror.h
%{mingw32_includedir} /libvirt/libvirt-lxc.h
%{mingw32_includedir} /libvirt/libvirt-qemu.h
%{mingw32_includedir} /libvirt/libvirt-admin.h
%{mingw32_mandir} /man1/virsh.1*
%{mingw32_mandir} /man1/virt-admin.1*
%{mingw32_mandir} /man1/virt-xml-validate.1*
%{mingw32_mandir} /man1/virt-pki-query-dn.1*
%{mingw32_mandir} /man1/virt-pki-validate.1*
%{mingw32_mandir} /man7/virkey*.7*
2023-11-02 14:24:21 +03:00
%endif
2022-08-08 18:40:56 +03:00
2023-11-02 14:24:21 +03:00
%if %{with_mingw64}
2022-12-12 13:52:49 +03:00
%files -n mingw64-libvirt -f mingw64-libvirt.lang
2022-08-08 18:40:56 +03:00
%dir %{mingw64_sysconfdir} /libvirt/
%config (noreplace) %{mingw64_sysconfdir} /libvirt/libvirt.conf
%config (noreplace) %{mingw64_sysconfdir} /libvirt/libvirt-admin.conf
%{mingw64_bindir} /libvirt-0.dll
%{mingw64_bindir} /virsh.exe
%{mingw64_bindir} /virt-admin.exe
%{mingw64_bindir} /virt-xml-validate
%{mingw64_bindir} /virt-pki-query-dn.exe
%{mingw64_bindir} /virt-pki-validate
%{mingw64_bindir} /libvirt-lxc-0.dll
%{mingw64_bindir} /libvirt-qemu-0.dll
%{mingw64_bindir} /libvirt-admin-0.dll
%{mingw64_libdir} /libvirt.dll.a
%{mingw64_libdir} /pkgconfig/libvirt.pc
%{mingw64_libdir} /pkgconfig/libvirt-qemu.pc
%{mingw64_libdir} /pkgconfig/libvirt-lxc.pc
%{mingw64_libdir} /pkgconfig/libvirt-admin.pc
%{mingw64_libdir} /libvirt-lxc.dll.a
%{mingw64_libdir} /libvirt-qemu.dll.a
%{mingw64_libdir} /libvirt-admin.dll.a
%dir %{mingw64_datadir} /libvirt/
%dir %{mingw64_datadir} /libvirt/schemas/
%{mingw64_datadir} /libvirt/schemas/*.rng
%dir %{mingw64_datadir} /libvirt/api/
%{mingw64_datadir} /libvirt/api/libvirt-api.xml
%{mingw64_datadir} /libvirt/api/libvirt-lxc-api.xml
%{mingw64_datadir} /libvirt/api/libvirt-qemu-api.xml
%{mingw64_datadir} /libvirt/api/libvirt-admin-api.xml
%{mingw64_datadir} /libvirt/cpu_map/*.xml
%{mingw64_datadir} /libvirt/test-screenshot.png
%dir %{mingw64_includedir} /libvirt
%{mingw64_includedir} /libvirt/libvirt.h
%{mingw64_includedir} /libvirt/libvirt-common.h
%{mingw64_includedir} /libvirt/libvirt-domain.h
%{mingw64_includedir} /libvirt/libvirt-domain-checkpoint.h
%{mingw64_includedir} /libvirt/libvirt-domain-snapshot.h
%{mingw64_includedir} /libvirt/libvirt-event.h
%{mingw64_includedir} /libvirt/libvirt-host.h
%{mingw64_includedir} /libvirt/libvirt-interface.h
%{mingw64_includedir} /libvirt/libvirt-network.h
%{mingw64_includedir} /libvirt/libvirt-nodedev.h
%{mingw64_includedir} /libvirt/libvirt-nwfilter.h
%{mingw64_includedir} /libvirt/libvirt-secret.h
%{mingw64_includedir} /libvirt/libvirt-storage.h
%{mingw64_includedir} /libvirt/libvirt-stream.h
%{mingw64_includedir} /libvirt/virterror.h
%{mingw64_includedir} /libvirt/libvirt-lxc.h
%{mingw64_includedir} /libvirt/libvirt-qemu.h
%{mingw64_includedir} /libvirt/libvirt-admin.h
%{mingw64_mandir} /man1/virsh.1*
%{mingw64_mandir} /man1/virt-admin.1*
%{mingw64_mandir} /man1/virt-xml-validate.1*
%{mingw64_mandir} /man1/virt-pki-query-dn.1*
%{mingw64_mandir} /man1/virt-pki-validate.1*
%{mingw64_mandir} /man7/virkey*.7*
%endif
2005-12-07 16:45:20 +03:00
2005-11-02 18:37:34 +03:00
%changelog
