The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.
In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.
We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.
It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.
Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.
Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).
We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages
- We can make virtproxyd and the virtXXXd per-driver daemons all
have "Conflicts: libvirtd.service" in their systemd unit files.
This will guarantee that libvirtd is never started at the same
time, as this would result in two daemons running the same driver.
Fortunately drivers use locking to protect themselves, but it is
better to avoid starting a daemon we know will conflict.
- It allows us to break CLI compat to remove the --listen parameter.
Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
will default to zero. Either TLS or TCP can be enabled exclusively
though virtd.conf without requiring the extra step of adding --listen.
- It allows us to set a strict SELinux policy over virtproxyd. For
back compat the libvirtd policy must continue to allow all drivers
to run. We can't easily give a second policy to libvirtd which
locks it down. By introducing a new virtproxyd we can set a strict
policy for that daemon only.
- It gets rid of the weird naming of having a daemon with "lib" in
its name. Now all normal daemons libvirt ships will have "virt"
as their prefix not "libvirt".
- Distros can more easily choose their upgrade path. They can
ship both sets of daemons in their packages, and choose to
either enable libvirtd, or enable the per-driver daemons and
virtproxyd out of the box. Users can easily override this if
desired by just tweaking which systemd units are active.
After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.
The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.
The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.
The aggressive option is to disable libvirtd if already running
and activate all the new daemons.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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>
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>
Prepare for new checkpoint APIs by describing the XML that will
represent a checkpoint. The checkpoint XML is modeled heavily after
virDomainSnapshotPtr. See the docs for more details.
Add testsuite coverage for some minimal uses of the XML (bare minimum,
the sample from html, and a full dumpxml, and some counter-examples
that should fail schema validation). Although use of the REDEFINE flag
will require the <domain> subelement to be present, it is easier for
most of the tests to provide counterpart output produced with the
NO_DOMAIN flag (particularly since synthesizing a valid <domain>
during testing is not trivial).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We don't do socket activation of libvirtd, since we need to
unconditionally start libvirtd in order to perform autostart. This
doesn't mean we can't have systemd socket units. Some use cases will
not need libvirt's autostart & are thus free to use activation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirtd has long had integration with avahi for advertising libvirtd
using mDNS when TCP/TLS listening is enabled. For a long time the
virt-manager application had support for auto-detecting libvirtds
on the local network using mDNS, but this was removed last year
commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
Author: Cole Robinson <crobinso@redhat.com>
Date: Sat Oct 6 20:55:31 2018 -0400
connect: Drop avahi support
Libvirtd can advertise itself over avahi. The feature is disabled by
default though and in practice I hear of no one actually using it
and frankly I don't think it's all that useful
The 'Open Connection' wizard has a disproportionate amount of code
devoted to this feature, but I don't think it's useful or worth
maintaining, so let's drop it
I've never heard of any other applications having support for using
mDNS to detect libvirtd instances. Though it is theoretically possible
something exists out there, it is clearly going to be a niche use case
in the virt ecosystem as a whole.
By removing avahi integration we can cut down the dependency chain for
the basic libvirtd install and reduce our code maint burden.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a virNetworkPortDefPtr struct to represent the data associated
with a virtual network port. Add APIs for parsing/formatting XML docs
with the data.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Right now we install the files in RPMs only, and we include
them in the -daemon package which is probably not the best
option either. Start installing them via autotools; the RPMs
will get them automatically in the -docs package.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
We already install the file, along with its driver-specific
counterparts, into ${datadir}/libvirt/api/ where language
bindings will actually look for them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
This is exactly how we already treat nwfilters, which require
the same kind of care (aka nasty hacks) as the default network,
because in both cases the UUID is generated and written to
disk the first time libvirtd is started after installing the
corresponding subpackage.
After this patch, RPM will be aware of the fact that the
libvirt-daemon-config-network subpackage owns the default
network.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
While libvirtd creates this directory with the default 0755 mode, the
spec file stores 0700 in the RPM database. Thus RPM verification always
complains about this directory. Let's fix the spec file to match
reality.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The nwfilter XML files stored in /etc/libvirt/nwfilter are copied in a
%post scriptlet from /usr/share/libvirt/nwfilter/*.xml. While the files
in /usr/share are created with mode 0644, libvirt creates the files in
/etc/libvirt/nwfilter with mode 0600. Since 0600 is also stored in the
RPM database, we need to chmod the files copied from /usr/share to make
sure RPM verification does not complain about changed permissions.
https://bugzilla.redhat.com/show_bug.cgi?id=1628475
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The libvirt-lock-sanlock subpackage requires sanlock to be installed
first and the sanlock package creates the sanlock group on all distros
we care about in the spec file (Fedora and RHEL >= 7). Thus instead of
setting the ownership and permissions in a post scriptlet only when the
sanlock group exists we can just install the directory with the
appropriate metadata.
https://bugzilla.redhat.com/show_bug.cgi?id=1702758
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
The libvirt-daemon-driver-qemu RPM has historically had a hard
dependency on the libvirt-daemon-driver-network and
libvirt-daemon-driver-storage-core packages. This was because the QEMU
driver would directly call into APIs that were part of these drivers.
The dependency to the storage driver was eliminated in
commit 064fec69be
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Jan 25 09:35:46 2018 +0000
storage: move storage file backend framework into util directory
The dependency to the network driver was eliminated in
commit 5b13570ab8
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Jan 25 09:35:47 2018 +0000
conf: introduce callback registration for domain net device allocation
commit 1438aea4ee
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Jan 25 09:35:48 2018 +0000
conf: expand network device callbacks to cover bandwidth updates
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Our build system doesn't currently install the various
example programs provided along libvirt; however, both the
upstream .spec file and the Debian packaging go out of
their way to make sure these useful demos are included in
the respective documentation packages.
Moreover, doing so without help from the upstream build
system is easy to get wrong: the libvirt-docs RPM package,
for example, ends up missing one of the examples and
including a bunch of empty .deps/ directories.
Install the examples in $(docdir) as part of our regular
procedure, so that users and downstreams don't have to do
anything special about them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
At the moment we allow the user to specify exactly where
they want the HTML documentation to be installed with an
extreme level of precision through the --with-html-dir and
--with-html-subdir configure options.
Most of the time, of course, the user will stick with the
default, that is $(datadir)/doc/$(PACKAGE)-$(VERSION)/html.
So close to $(docdir)! Including the version number in
the path, specifically, seems entirely unnecessary since
different releases of libvirt are not going to be able to
coexist on the same system anyway.
Drop all these custom flexibilty for flexibilty's sake
shenaningans in favor of the standard, well understood
$(docdir).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Fedora 30 is out, which means that Fedora 28 is going to be
EOL very soon. Let's get ahead of the game and drop support
for it right now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 3b71f2e42d added spec handling for with_firewalld_zone. We
now call %firewalld_reload if with_firewalld is set. But the matching
'BuildRequires: firewalld-filesystem' is only applied if
with_firewalld_zone is set.
Fix the former bit to use with_firewalld_zone
Reviewed-by: Laine Stump <laine@laine.org>
Reported-by: Yuval Turgeman <yturgema@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The firewalld package in Fedora 30 didn't get support for rich rule
priorities, which is required by the libvirt zonefile that's installed
when the build is configured with --with-firewalld-zone, so we need to
set --without-firewalld-zone for that version of Fedora. The needed
feature is already upstream in firewalld, so it just needs another
upstream release to be there. Let's be optimistic and assume that will
happen prior to F31.
Resolves: https://bugzilla.redhat.com/1699051
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Eric Garver <eric@garver.life>
ldconfig needs to be called after installing or uninstalling
shared libraries.
For a very long time, libvirt didn't have a separate package
containing just the shared libraries, and so it shipped them
in the same one as the clients.
Since commit 70b4f0e719, however, shared libraries have been
moved from -client to their own -libs package; unfortunately,
the corresponding ldconfig calls were not moved at the same
time, which is what this commit takes care of.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
These blocks are only triggered when updating from a libvirt version
less than 0.9.4, which was released in August 2011. I think it's been
long enough that we can say this upgrade path is unsupported without
an intermediate step.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Since Fedora 28 (our minimum supported build), ldconfig is called
automatically for us:
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
These changes appear to be implemented for RHEL > 7 as well, so only
run ldconfig on RHEL7
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We previously had to disable RBD on 32-bit platforms since Ceph has
dropped all support for 32-bit. Unfortunately anyone with the RPM
libvirt-daemon-driver-storage-rbd installed on 32-bit now has a
broken upgrade path.
To fix this we must make libvirt-daemon-driver-storage-core
have an Obsoletes: libvirt-daemon-driver-storage-rbd < $VER-$REL
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Support for XFS reflink clone was added in:
commit 8ed874b39b
Author: Julio Faracco <jcfaracco@gmail.com>
Date: Fri Jul 6 10:43:01 2018 -0300
storage: Rename btrfsCloneFile to support other filesystems.
commit 2e11298f93
Author: Julio Faracco <jcfaracco@gmail.com>
Date: Fri Jul 6 10:43:00 2018 -0300
configure: Adding XFS library/headers check.
But these patches missed that the xfs/xfs.h header is not installed
unless you have xfsprogs-devel present.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Define a schema for the storage pool capabilities along with
a test to show the general format.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
The wireshark-2.4.0 is almost 2 years old now. Assuming anybody
interested in running latest libvirt doesn't run old wireshark,
it is safe to do this. It also simplifies the code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since wirshark-2.5.0 toplevel plugins are no longer loaded. Only
plugins from epan/, wiretap/ or codecs/ subdirs are. Update the
plugin dir we generate. This is safe to do even for older
wiresharks, since they load plugins from there too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
The %{extra_release} field was previously populated by data from the old
autobuild.sh file but is no longer used.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ceph in upstream and Fedora has dropped support for building on host
architectures which are 32-bit.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The driver is unmaintained, untested and severely broken for
quite some time now. Since nobody even reported any issue with it
let us drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In accordance with our platform support policy, now that
Fedora 29 is out we no longer support building on Fedora 27.
This allows us to remove a few version checks.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Both ceph and gluster have been built on RHEL on all architectures for
some time, there's no need to limit them to x86_64.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
RHEL-7 is the only system where gnutls is too old to support @LIBVIRT
specifier.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In preparation for splitting up the CPU map data file, move it into a
dedicated directory of its own.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Most distributions we build RPMs on don't ship a
recent enough version of libiscsi, so we can't enable
the driver unconditionally. Add an explicit dependency
on the runtime package while at it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit 34a6962c41 added a BuildRequires for the
iscsi-direct backend, but we need the headers rather
than the runtime package to be available in order to
link against the library.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This reverts commit 9cf38263d0.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit ce3c6ef684.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The distros we support for RPM builds all have %autosetup support so we
can ditch the convoluted code for running git manually and use the RPM
defaults.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It's on RHEL7, saves a bit of typing, and lets us drop the comment
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The jansson and json-glib libraries both export symbols with a json_
name prefix and json_object_iter_next() clashes between them.
Unfortunately json-glib is linked in by GTK, so any app using GTK and
libvirt will get a clash, resulting in SEGV. This also affects the NSS
module provided by libvirt
Instead of directly linking to jansson, use dlopen() with the RTLD_LOCAL
flag which allows us to hide the symbols from the application that loads
libvirt or the NSS module.
Some preprocessor black magic and wrapper functions are used to redirect
calls into the dlopen resolved symbols.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All our supported RHEL and Fedora versions include systemd, so we can
assume it is always present in the spec.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We no longer build on RHEL-6, so can bump min required RHEL to 7
removing many conditions.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Yajl has not seen much activity upstream recently.
Switch to using Jansson >= 2.5.
All the platforms we target on https://libvirt.org/platforms.html
have a version >= 2.7 listed on the sites below:
https://repology.org/metapackage/jansson/versionshttps://build.opensuse.org/package/show/devel:libraries:c_c++/libjansson
Additionally, Ubuntu 14.04 on Travis-CI has 2.5. Set the requirement
to 2.5 since we don't use anything from newer versions.
Implement virJSONValue{From,To}String using Jansson, delete the yajl
code (and the related virJSONParser structure) and report an error
if someone explicitly specifies --with-yajl.
Also adjust the test data to account for Jansson's different whitespace
usage for empty arrays and tune up the specfile to keep 'make rpm'
working when bisecting.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
RHEL-6/CentOS-6 is no longer supported, let's remove dependency on
libcgroup and code that enables/starts cgconfig service.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1602407
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
All drivers now link directly to libvirt.so rather than getting the
symbols from the daemon. Let's explicitly mention this dependency in the
spec file instead of relying on transitive dependency from
libvirt-daemon.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit <41d619e99c2015eab2d56bea874e23ba9f52f829> introduced new RNG
schema files for nwfilter but forgot to update spec file.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
SASL authentication is configured server-side, so the sample
configuration file should be shipped along with the daemon
rather than with the libraries.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Extend qemu_conf with user and group for running the tpm-emulator
and add directories to the configuration for the locations of the
log, state, and socket of the tpm-emulator.
Also add these new directories to the QEMU Makefile.inc.am and
the RPM spec file libvirt.spec.in.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At least since Fedora 26 (maybe earlier, but we don't support older
Fedora releases), the "tc" tool is provided by a separate iproute-tc
package.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The nwfilter XMLs in /etc are defined as %ghost in the spec file, which
means rpm will not install them, but it will record its existence and
permissions in the database. During installation the files are copied in
a %post scriptlet from /usr/share/libvirt/nwfilter, but once libvirtd is
restarted, it will rewrite the files to add generated UUIDs.
While RPM recorded 644 mode for the XMLs, libvirt saves them with 600
and thus any future attempt to verify the libvirt-daemon-config-nwfilter
package would fail. We need to tell RPM the ghost files are supposed to
have 600 permissions.
https://bugzilla.redhat.com/show_bug.cgi?id=1559284
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
It's only required on el5 which we don't support anymore. Everywhere
else it's not used for anything useful
https://fedoraproject.org/wiki/RPMGroups
Signed-off-by: Cole Robinson <crobinso@redhat.com>
None of currently supported distributions need that.
Last one was EL5 which is EOL for a while.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
None of currently supported distributions need that.
It was needed last for EL5 which is EOL now
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The storage file drivers are currently loaded as a side effect of
loading the storage driver. This is a bogus dependancy because the
storage file code has no interaction with the storage drivers, and
even ultimately be running in a completely separate daemon.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The wireshark plugin directory moved again in Fedora 29, and will
move again every time wireshark do a new minor release. Call out
to pkg-config to find the right directory to use in the RPM file
list.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Snce the xen driver was deleted we need to ensure that the old
libvirt-daemon-driver-xen sub-RPM gets removed on upgrade. We
achieve this my making libvirt-daemon-driver-libxl obsolete it.
We don't add a Provides: too, because libvirt-daemon-driver-libxl
is not a functionally identical replacement, since we don't want
to satisfy deps for 3rd party apps that have a Requires on the
libvirt-daemon-driver-xen RPM.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since RPC support moved out of glibc we need to have explicit deps on
the new packages providing this functionality
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Macros in RPMs are expanded before line continuations, so when we write
%systemd_preun foo \
bar
What happens is that it expands to
if [ $1 -eq 0 ] ; then
# Package removal, not upgrade
systemctl --no-reload disable --now foo \ > /dev/null 2>&1 || :
fi
bar
which is obviously complete garbage and not what we expected. It is
simply not safe to ever use line continuations in combination with
macros.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
While RHEL / CentOS are still using Python 2 for the time being,
Fedora has already switched to Python 3 as the default Python
interpreter a while ago, so on that OS it doesn't make sense to
drag in Python 2 anymore; the same applies to future RHEL versions.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Fedora requires packages to depend on "python2" RPM, not the unversioned
"python" name. Fortunately even though RHEL-6 ships a "python" RPM, it
has a virtual Provides for the "python2" name, so we don't need to
conditionalize this.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As of 2499d1a095 we don't link against libpolkit anymore, so
we only need the polkit package to be available during build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, for rpm we are building libvirt with
--init-script=systemd or --init-script=redhat. So upstart is
never enabled. And only due to a bug we installed
libvirtd.upstart file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Fuse was recently enabled whereever LXC is enabled:
commit 34783a9e6b
Author: Jiri Denemark <jdenemar@redhat.com>
Date: Fri Feb 9 13:42:50 2018 +0100
spec: Enable fuse only if LXC is enabled
Unfortunately the version of Fuse in RHEL-6 is too old for libvirt's
needs, but we still have LXC enabled there.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The postun trigger for libvirt-daemon was defined twice for overlapping
ranges of package verions if systemd support was switched off (which
happens when building on something ancient, such as RHEL-6).
Let's combine the two triggers into the one which is called when
libvirt-daemon < 1.3.0 is uninstalled. As a side effect, virtlockd and
virtlogd might be reloaded twice after an upgrade from libvirt newer
than 1.2.1 and older than 1.3.0 (by postun script from the old libvirt
and postun trigger from the new libvirt).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The oldest Fedora release supported by the spec file is 26. Checking for
anything older makes no sense.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Building virt-login-shell doesn't really make any sense without LXC and
doing so even breaks "make rpm" since the associated files are installed
but unpackaged (the login-shell sub package already depends on LXC).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Enabling fuse without LXC does not make a lot of sense because fuse is
used only by LXC.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit id 'ce7ae55e' added support for the lockd admin socket, but
forgot to add the socket to the make and spec files for installation
purposes.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Commit id '85d45ff0' added support for the logd admin socket, but
forgot to add the socket to the make and spec files for installation
purposes.
NB: Includes breaking up the long %systemd_ lists across multiple lines
for ease of reading
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
The bash-completion project documents that only those scripts
from $BASH_COMPLETIONS_DIR that share name with the current
command for which <TAB> was hit are loaded [1]. This means, that
vsh script we have there is not loaded. We have to create
symlinks for virsh and virt-admin.
At the same time, we have to create new RPM package because
virt-admin and client packages are independent. That means we
cannot place the vsh script in either of them. What we can do is
to have a different package that contains the completion script
and then virt-admin and client packages contain only the symlink
and require the bash-completion package.
1: https://github.com/scop/bash-completion#faq
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Update the min fedora to 26. Use a macro to record the min versions so that the
later error message is always in sync with the earlier version check. Clarify
the comment that refers to guessing of dist which does not actually happen.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
RHEL-6 doesn't have bash-completion package by default, it has to be
installed from EPEL.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The only purpose of this file is to be sourced. After that one
can use completion even for their bash:
# virsh list --<TAB><TAB>
--all --inactive ...
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If the spec file applies a patch which touches any file in the API XMLs
dependency tree, we need to regenerate the XMLs and consequently
recreate hvsupport.html. The file will contain a time stamp in a comment
which means it will be different every time the package is built. The
commit a54c962286 which added the time stamp also added support for
SOURCE_DATE_EPOCH environment variable. Let's set it to the time stamp
of the spec file itself to make the build reproducible.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pino Toscano <ptoscano@redhat.com>
When building a package in a build system, such as koji or cbs, logs are
the only thing which can be used to diagnose failures. Make them verbose
since human friendly output of V=0 build doesn't really help when a
build fails.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pino Toscano <ptoscano@redhat.com>
When upgrading libvirt packages, there's no strict ordering for the
installation or removal of the individual libvirt sub packages. Thus
libvirt-daemon may be upgraded (and its %postun scriptlet) started
before all sub packages with driver libraries are upgraded. When
libvirt-daemon's %postun scriptlet restarts the daemon old drivers may
still be laying around and the daemon may crash when it tries to use
them.
Let's restart the daemon in %posttrans to make sure libvirtd is
restarted only after all sub packages are at the same version.
https://bugzilla.redhat.com/show_bug.cgi?id=1464300
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Installing dead README symlink only is pretty useless.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Building RPM should only be allowed on a supported platform, but
unpacking the source and applying all patches can be done anywhere.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The HTML pages are currently validated against an XHTML 1.0 DTD.
This makes it impossible to take advantage of features that are
introduced in HTML 5, because they'll fail validation.
There is intentionally no DTD defined for HTML 5, so there's no
alternative to XHTML 1.0 DTD that we could switch to. The only
options are to stick with XHTML 1.0 forever, or drop the DTD
validation, and we pick the latter.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
