1. 20 5月, 2019 1 次提交
    • D
      rpm: remove dependancy from qemu to network/storage drivers · 06a61a20
      Daniel P. Berrangé 提交于
      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 064fec69
        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 5b13570a
        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 1438aea4
        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: NDaniel P. Berrangé <berrange@redhat.com>
      06a61a20
  2. 13 5月, 2019 2 次提交
    • A
      examples: Install under $(docdir) · 4faaaa8b
      Andrea Bolognani 提交于
      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: NAndrea Bolognani <abologna@redhat.com>
      Acked-by: NMichal Privoznik <mprivozn@redhat.com>
      4faaaa8b
    • A
      docs: Install documentation under $(docdir) · 6716c997
      Andrea Bolognani 提交于
      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: NAndrea Bolognani <abologna@redhat.com>
      Acked-by: NMichal Privoznik <mprivozn@redhat.com>
      6716c997
  3. 09 5月, 2019 1 次提交
  4. 01 5月, 2019 1 次提交
  5. 12 4月, 2019 1 次提交
  6. 27 3月, 2019 1 次提交
  7. 22 3月, 2019 2 次提交
  8. 21 3月, 2019 1 次提交
  9. 07 3月, 2019 2 次提交
  10. 12 2月, 2019 2 次提交
  11. 02 2月, 2019 1 次提交
    • L
      configure: selectively install a firewalld 'libvirt' zone · 3b71f2e4
      Laine Stump 提交于
      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: NLaine Stump <laine@laine.org>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      3b71f2e4
  12. 22 1月, 2019 1 次提交
  13. 21 1月, 2019 2 次提交
  14. 18 12月, 2018 1 次提交
  15. 08 11月, 2018 1 次提交
  16. 05 10月, 2018 1 次提交
  17. 27 9月, 2018 2 次提交
  18. 11 9月, 2018 1 次提交
  19. 28 8月, 2018 1 次提交
  20. 16 8月, 2018 2 次提交
  21. 14 8月, 2018 2 次提交
  22. 13 8月, 2018 3 次提交
  23. 08 8月, 2018 2 次提交
  24. 01 8月, 2018 1 次提交
    • D
      util: avoid symbol clash between json libraries · ce3c6ef6
      Daniel P. Berrangé 提交于
      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: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      ce3c6ef6
  25. 23 7月, 2018 2 次提交
  26. 18 7月, 2018 2 次提交
  27. 11 7月, 2018 1 次提交