1. 09 8月, 2019 4 次提交
    • D
      remote: introduce virtproxyd daemon to handle IP connectivity · b7ed8ce9
      Daniel P. Berrangé 提交于
      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: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      b7ed8ce9
    • D
      remote: conditionalize IP socket config in augeas definitions · 5f449aea
      Daniel P. Berrangé 提交于
      Prepare for reusing libvirtd augeas defintions with other daemons by
      making the config parameters for IP sockets conditionally defined by
      the make rules.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5f449aea
    • D
      remote: conditionalize IP socket config in libvirtd.conf · 6d9e520d
      Daniel P. Berrangé 提交于
      Prepare for reusing libvirtd config to create other daemons by making
      the config parameters for IP sockets conditionally defined by the make
      rules.
      
      The main libvirtd daemon will retain IP listen ability, but all the
      driver specific daemons will be local UNIX sockets only. Apps needing
      IP connectivity will connect via the libvirtd daemon which will proxy
      to the driver specfic daemon.
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      6d9e520d
    • D
      build: create all augeas test files in same dir as their source · 2cdabb17
      Daniel P. Berrangé 提交于
      The current make rules are inconsistent about which directory the
      augeas test files are created in. Put them all in the same dir as
      their source.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2cdabb17
  2. 07 8月, 2019 1 次提交
    • D
      tools: split virt-login-shell into two binaries · 4feeb2d9
      Daniel P. Berrangé 提交于
      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: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      4feeb2d9
  3. 03 6月, 2019 2 次提交
  4. 12 4月, 2019 1 次提交
    • D
      tests: add targets for building libvirt inside Docker containers · 89f8902a
      Daniel P. Berrangé 提交于
      The Travis CI system uses Docker containers for its build environment.
      These are pre-built and hosted under quay.io/libvirt so that developers
      can use them for reproducing problems locally.
      
      Getting the right Docker command syntax to use them, however, is not
      entirely easy. This patch addresses that usability issue by introducing
      some make targets. To run a simple build (aka 'make all') using the
      Fedora 28 container:
      
         make ci-build@fedora-28
      
      To also run unit tests
      
         make ci-check@fedora-28
      
      This is just syntax sugar for calling the previous command with a
      custom make target
      
         make ci-build@fedora-28 CI_MAKE_ARGS="check"
      
      To do a purely interactive build it is possible to request a shell
      
         make ci-shell@fedora-28
      
      To do a MinGW build, it is currently possible to use the fedora-rawhide
      image and request a different configure script
      
         make ci-build@fedora-rawhide CI_CONFIGURE=mingw32-configure
      
      It is also possible to do cross compiled builds via the Debian containers
      
         make ci-build@debian-9-cross-s390x
      
      In all cases the GIT source tree is cloned locally into a 'ci-tree/src'
      sub-directory which is then exposed to the container at '/src'. It is
      setup to use a separate build directory so the build takes place in a
      subdir '/src/build'. A source tree build can be requested instead
      by passing an empty string CI_VPATH= arg to make.
      
      The make rules are kept in a standalone file that is included into the
      main Makefile.am, so that it is possible to run them without having to
      invoke autotools first.
      
      It is neccessary to disable the gnulib submodule commit check because
      this fails due to the way we have manually cloned submodule repos as
      primary git repos with their own .git directory, instead of letting
      git treat them as submodules in the top level .git directory.
      
        make[1]: Entering directory '/src/build'
        fatal: Not a valid object name origin
        fatal: run_command returned non-zero status for .gnulib
        .
        maint.mk: found non-public submodule commit
        make: *** [/src/maint.mk:1448: public-submodule-commit] Error 1
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      89f8902a
  5. 05 4月, 2019 1 次提交
    • C
      docs: Remove search.php and all references · fb0d6049
      Cole Robinson 提交于
      libvirt.org/search.php drops into some kind of screen which I guess
      is supposed to show a search bar with options, but presently for me
      renders as nothing but the following text:
      
      Search the documentation on Libvirt.org
      
      The search service indexes the libvirt APIs and documentation as well as the libvir-list@redhat.com mailing-list archives. To use it simply provide a set of keywords:
      
      The main page search bar now redirects to google, this page is broken,
      I say we just remove it and move on.
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Signed-off-by: NCole Robinson <crobinso@redhat.com>
      fb0d6049
  6. 03 4月, 2019 1 次提交
    • A
      maint: Stop generating ChangeLog from git · ce97c33a
      Andrea Bolognani 提交于
      Our ChangeLog is generated by basically redirecting the output
      of 'git log' into it so, as can be expected, it has only gotten
      bigger as development has progressed. As of today, its size has
      reached pretty much comical levels:
      
        $ du -sk ChangeLog
        11328 ChangeLog
      
      All of that for information *literally nobody* cares about: end
      users and distro maintainers have proper release notes lovingly
      compiled for them, while developers peruse the history either by
      calling 'git log' directly or through their favorite $EDITOR's
      git integration.
      
      Replacing the generated ChangeLog with a short message pointing
      interested parties to the git repository does not only reduce
      the size of the unpacked sources from 259904 KiB to 248576 KiB
      (~4% saving): from a quick test on my laptop, doing so reduces
      the size of the *compressed* release archive from 15140 KiB to
      12364 KiB (~18% saving) and also takes the time needed to run
      'make distcheck' down from 4:44 to 4:21 (~8% saving).
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      ce97c33a
  7. 16 3月, 2019 1 次提交
  8. 12 2月, 2019 1 次提交
    • M
      tools: Keep wireshark plugin registration code in git · a87a75e5
      Michal Privoznik 提交于
      In order to be able to dissect libvirt protocol the wireshark
      plugin needs to be registered. So far this plugin registration
      code was generated on every build using a script that was copied
      over from wireshark's tools/ directory.
      
      This is suboptimal, because the way that plugins register changes
      across wireshark releases. Therefore, let's keep the generated
      file in the git, put the command line used to generate the file
      into a comment and remove the script.
      
      This solution allows us to put different registration mechanism
      into one file (under #ifdef-s) and thus compile with wider range
      of wireshark releases.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      a87a75e5
  9. 19 4月, 2018 2 次提交
    • D
      po: minimize & canonicalize translations stored in git · a3857dbe
      Daniel P. Berrangé 提交于
      Similar to the libvirt.pot, .po files contain line numbers and file
      names identifying where in the source a translatable string comes from.
      The source locations in the .po files are thrown away and replaced with
      content from the libvirt.pot whenever msgmerge is run, so this is not
      precious information that needs to be stored in git.
      
      When msgmerge processes a .po file, it will add in any msgids from the
      libvirt.pot that were not already present. Thus, if a particular msgid
      currently has no translation, it can be considered redundant and again
      does not need storing in git.
      
      When msgmerge processes a .po file and can't find an exact existing
      translation match, it will try todo fuzzy matching instead, marking such
      entries with a "# fuzzy" comment to alert the translator to take a
      look and either discard, edit or accept the match. Looking at the
      existing fuzzy matches in .po files shows that the quality is awful,
      with many having a completely different set of printf format specifiers
      between the msgid and fuzzy msgstr entry. Fortunately when msgfmt
      generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy
      entries could be useful to translators if they were working on the .po
      files directly from git, but Libvirt outsourced translation to the
      Fedora Zanata system, so keeping fuzzy matches in git is not much help.
      
      Finally, by default msgids are sorted based on source location. Thus, if
      a bit of code with translatable text is moved from one file to another,
      it may shift around in the .po file, despite the msgid not itself changing.
      If the msgids were sorted alphabetically, the .po files would have
      stable ordering when code is refactored.
      
      This patch takes advantage of the above observations to canonicalize
      and minimize the content stored for .po files in git. Instead of storing
      the real .po files, we now store .mini.po files.
      
      The .mini.po files are the same file format as .po files, but have no
      source location comments, are sorted alphabetically, and all fuzzy
      msgstrs and msgids with no translation are discarded. This cuts the size
      of content in the po directory from 109MB to 19MB.
      
      Users working from a libvirt git checkout who need the full .po files
      can run "make update-po", which merges the libvirt.pot and .mini.po
      file to create a .po file containing all the content previously stored
      in git.
      
      Conversely if a full .po file has been modified, for example, by
      downloading new content from Zanata, the .mini.po files can be updated
      by running "make update-mini-po". The resulting diffs of the .mini.po
      file will clearly show the changed translations without any of the noise
      that previously obscured content. Being able to see content changes
      clearly actually identified a bug in the zanata python client where it
      was adding bogus "fuzzy" annotations to many messages:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1564497
      
      Users working from libvirt releases should not see any difference in
      behaviour, since the tarballs only contain the full .po files, not the
      .mini.po files.
      
      As an added benefit, generating tarballs with "make dist", will no
      longer cause creation of dirty files in git, since it won't touch the
      .mini.po files, only the .po files which are no longer kept in git.
      
      To avoid creating a single commit 100+MB in size, each language is
      minimized separately in a following commit.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a3857dbe
    • D
      po: provide custom make rules for po file management · c0a8ea45
      Daniel P. Berrangé 提交于
      Historically we have relied on autopoint/gettextize to install a
      standard po/Makefile.in.in. There is very limited scope for customizing
      this and it also causes a bunch of extra stuff to be pulled into
      configure.ac which potentially clashes with gnulib. Writing make rules
      for po file management is no more difficult than any other rules libvirt
      has, so stop using autopoint/gettextize.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      c0a8ea45
  10. 14 3月, 2018 1 次提交
  11. 22 2月, 2018 5 次提交
  12. 31 1月, 2018 1 次提交
  13. 09 5月, 2017 2 次提交
    • A
      Add YouCompleteMe support · 64b474a8
      Andrea Bolognani 提交于
      YouCompleteMe[1] is a vim plugin that implements semantic
      code completion using libclang.
      
      For non-trivial projects such as libvirt, the plugin needs
      some help figuring out where to find the various header
      files: generate its configuration file at configure time
      so that the plugin works out of the box.
      
      [1] http://valloric.github.io/YouCompleteMe/
      64b474a8
    • A
      Add color_coded support · a50dee9f
      Andrea Bolognani 提交于
      color_coded[1] is a vim plugin that implements semantic
      syntax highlighting using libclang.
      
      For non-trivial projects such as libvirt, the plugin needs
      some help figuring out where to find the various header
      files: generate its configuration file at configure time
      so that the plugin works out of the box.
      
      [1] https://github.com/jeaye/color_coded
      a50dee9f
  14. 26 4月, 2017 2 次提交
  15. 07 4月, 2017 1 次提交
  16. 11 1月, 2017 1 次提交
    • A
      NEWS: Improve building pipeline · be36ea4b
      Andrea Bolognani 提交于
      Currently, building the NEWS file involves using a XSLT stylesheet
      to extract information from the same HTML file that's used on the
      libvirt website.
      
      The process works, but it's quite fiddly in that it requires the
      source HTML to be formatted in a very precise way, and a single
      missing newline can mess up the resulting plain text considerably.
      
      Moreover, the XSLT stylesheet itself encodes a lot of the details
      of converting to plain text in a way that's not necessarily easy
      to understand, tweak or fix.
      
      To improve the process, move all existing entries to a new XML
      file that contains exactly the information we care about in a
      simple structured format, and start generating both the HTML and
      plain text versions of the release notes using XSLT stylesheets
      that can now afford to be almost trivial.
      be36ea4b
  17. 15 12月, 2016 1 次提交
  18. 14 9月, 2016 1 次提交
  19. 26 6月, 2016 1 次提交
    • E
      examples: admin: Add some examples for the new admin APIs · fbb8205d
      Erik Skultety 提交于
      Some of the examples make use of asprintf and strtol functions (to keep
      things simple) which are prohibited to use within our code (enforced by
      syntax-check). Therefore besides adding some examples, this patch also updates
      cfg.mk to exclude examples directory from asprintf and strtol rules, as well as
      updates .gitignore to exclude all the new admin binaries created in the
      'examples' dir.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      fbb8205d
  20. 23 6月, 2016 1 次提交
  21. 21 6月, 2016 1 次提交
    • J
      Introduce virsh self-test · 920ab8bd
      Ján Tomko 提交于
      A new hidden command for virsh that will iterate over
      all command groups and commands and print help for every single one.
      
      This involves running vshCmddefOptParse so we can get an error if
      one of the command's option structure is invalid.
      920ab8bd
  22. 16 6月, 2016 1 次提交
  23. 08 6月, 2016 1 次提交
    • J
      Introduce virschematest · cf0974fb
      Ján Tomko 提交于
      Instead of calling xmllint via a shell script, use our virXMLValidator
      API to do it directly via libxml.
      cf0974fb
  24. 14 5月, 2016 1 次提交
    • M
      virtestmock: Print invalid file accesses into a file · 6326865e
      Michal Privoznik 提交于
      All the accesses to files outside our build or source directories
      are now identified and appended into a file for later processing.
      The location of the file that contains all the records can be
      controlled via VIR_TEST_FILE_ACCESS env variable and defaults to
      abs_builddir "/test_file_access.txt".
      
      The script that will process the access file is to be added in
      next commit.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      6326865e
  25. 05 5月, 2016 1 次提交
  26. 03 5月, 2016 3 次提交
  27. 26 4月, 2016 1 次提交