libvirt/.gitignore

271 lines
5.3 KiB
Plaintext
Raw Normal View History

*#*#
*.#*#
*.[187]
*.[187].in
2008-10-28 17:47:12 +00:00
*.a
*.cov
*.exe
*.exe.manifest
*.gcda
*.gcno
*.gcov
*.html
*.i
*.la
*.lo
*.loT
2008-10-28 17:47:12 +00:00
*.o
*.orig
*.pem
*.pyc
*.rej
*.s
*.service
*.socket
*.swp
2008-10-28 17:47:12 +00:00
*~
.#*
.color_coded
.deps
build: use automake subdir-objects Automake 2.0 will enable subdir-objects by default; in preparation for that change, automake 1.14 outputs LOADS of warnings: daemon/Makefile.am:38: warning: source file '../src/remote/remote_protocol.c' is in a subdirectory, daemon/Makefile.am:38: but option 'subdir-objects' is disabled automake-1.14: warning: possible forward-incompatibility. automake-1.14: At least a source file is in a subdirectory, but the 'subdir-objects' automake-1.14: automake option hasn't been enabled. For now, the corresponding output automake-1.14: object file(s) will be placed in the top-level directory. However, automake-1.14: this behaviour will change in future Automake versions: they will automake-1.14: unconditionally cause object files to be placed in the same subdirectory automake-1.14: of the corresponding sources. automake-1.14: You are advised to start using 'subdir-objects' option throughout your automake-1.14: project, to avoid future incompatibilities. daemon/Makefile.am:38: warning: source file '../src/remote/lxc_protocol.c' is in a subdirectory, daemon/Makefile.am:38: but option 'subdir-objects' is disabled ... As automake 1.9 also supported this option, and the previous patches fixed up the code base to work with it, it is safe to now turn it on unconditionally. * configure.ac (AM_INIT_AUTOMAKE): Enable subdir-objects. * .gitignore: Ignore .dirstamp directories. * src/Makefile.am (PDWTAGS, *-protocol-struct): Adjust to new subdir-object location of .lo files. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-09-07 22:18:06 +00:00
.dirstamp
2012-09-14 09:09:51 +00:00
.gdb_history
.git
.git-module-status
.libs
.lvimrc
.memdump
.sc-start-sc_*
.ycm_extra_conf.py
/AUTHORS
/GNUmakefile
/INSTALL
/NEWS
/aclocal.m4
/autom4te.cache
/build-aux/*
/build/
tests: add targets for building libvirt inside Docker containers 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: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 16:28:23 +00:00
/ci-tree/
/confdefs.h
/config.cache
/config.guess
/config.h
/config.h.in
/config.log
/config.rpath
/config.status
/config.sub
/configure
/configure.lineno
/conftest.*
/docs/aclperms.htmlinc
/docs/apibuild.py.stamp
/docs/devhelp/libvirt.devhelp
/docs/hvsupport.html.in
/docs/libvirt-admin-*.xml
/docs/libvirt-api.xml
/docs/libvirt-lxc-*.xml
2013-01-15 12:30:30 +00:00
/docs/libvirt-qemu-*.xml
/docs/libvirt-refs.xml
/docs/news.html.in
/docs/todo.html.in
/examples/c/admin/client_close
/examples/c/admin/client_info
/examples/c/admin/client_limits
/examples/c/admin/list_clients
/examples/c/admin/list_servers
/examples/c/admin/logging
/examples/c/admin/threadpool_params
/examples/c/domain/dommigrate
/examples/c/domain/domtop
/examples/c/domain/info1
/examples/c/domain/rename
/examples/c/domain/suspend
/examples/c/misc/event-test
/examples/c/misc/hellolibvirt
/examples/c/misc/openauth
/gnulib/lib/*
/gnulib/m4/*
/gnulib/tests/*
/include/libvirt/libvirt-common.h
/libtool
/libvirt-*.tar.xz
/libvirt-[0-9]*
/libvirt*.pc
/libvirt.spec
/ltconfig
/ltmain.sh
/m4/*
/maint.mk
/mingw-libvirt.spec
/mkinstalldirs
/po/*gmo
po: minimize & canonicalize translations stored in git 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: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-04 18:45:40 +00:00
/po/*po
!/po/*.mini.po
/po/*pot
/proxy/
/python/
/run
/sc_*
Make ESX & Hyper-V code generator safe with parallel builds If from a clean GIT checkout 'make -j 8' is run, the ESX and Hyper-V code will be generated multiple times over. This is because there are multiple files being generated from one invocation of the generator script. make does not realize this and so invokes the generator once per file. This doesn't matter with serialized builds, but with parallel builds multiple instances of the generator get run at once. make[2]: Entering directory `/home/berrange/src/virt/libvirt/src' GEN util/virkeymaps.h GEN remote/remote_protocol.h GEN remote/remote_client_bodies.h GEN remote/qemu_protocol.h GEN remote/qemu_client_bodies.h GEN esx/esx_vi_methods.generated.c GEN esx/esx_vi_methods.generated.h GEN esx/esx_vi_methods.generated.macro GEN esx/esx_vi_types.generated.c GEN esx/esx_vi_types.generated.h GEN esx/esx_vi_types.generated.typedef GEN esx/esx_vi_types.generated.typedef GEN esx/esx_vi_types.generated.typeenum GEN esx/esx_vi_types.generated.typetostring GEN esx/esx_vi_types.generated.typefromstring GEN esx/esx_vi_types.generated.h GEN esx/esx_vi_types.generated.c GEN esx/esx_vi_methods.generated.h GEN esx/esx_vi_methods.generated.c GEN esx/esx_vi_methods.generated.macro GEN esx/esx_vi.generated.h GEN esx/esx_vi.generated.c GEN esx/esx_vi_types.generated.typeenum GEN esx/esx_vi_types.generated.typedef GEN esx/esx_vi_types.generated.typeenum GEN esx/esx_vi_types.generated.typetostring GEN esx/esx_vi_types.generated.typefromstring GEN esx/esx_vi_types.generated.h GEN esx/esx_vi_types.generated.c GEN esx/esx_vi_methods.generated.h ...snip... GEN hyperv/hyperv_wmi.generated.h GEN libvirt_qemu_probes.h GEN locking/qemu-sanlock.conf GEN hyperv/hyperv_wmi.generated.c GEN rpc/virnetprotocol.h GEN hyperv/hyperv_wmi_classes.generated.typedef GEN hyperv/hyperv_wmi_classes.generated.h GEN hyperv/hyperv_wmi_classes.generated.c GEN rpc/virkeepaliveprotocol.h GEN remote/remote_protocol.c GEN remote/qemu_protocol.c GEN rpc/virkeepaliveprotocol.c GEN rpc/virnetprotocol.c GEN libvirt.def Prevent this using a timestamp file to control generation, as was previously done for the python bindings in commit a7868e0131516ef2dece82586edd52dc87fe336c Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-23 14:45:20 +00:00
/src/.*.stamp
/src/*.pc
/src/access/org.libvirt.api.policy
Auto-generate helpers for checking access control rules Extend the 'gendispatch.pl' script to be able to generate three new types of file. - 'aclheader' - defines signatures of helper APIs for doing authorization checks. There is one helper API for each API requiring an auth check. Any @acl annotations result in a method being generated with a suffix of 'EnsureACL'. If the ACL check requires examination of flags, an extra 'flags' param will be present. Some examples extern int virConnectBaselineCPUEnsureACL(void); extern int virConnectDomainEventDeregisterEnsureACL(virDomainDefPtr domain); extern int virDomainAttachDeviceFlagsEnsureACL(virDomainDefPtr domain, unsigned int flags); Any @aclfilter annotations resuilt in a method being generated with a suffix of 'CheckACL'. extern int virConnectListAllDomainsCheckACL(virDomainDefPtr domain); These are used for filtering individual objects from APIs which return a list of objects - 'aclbody' - defines the actual implementation of the methods described above. This calls into the access manager APIs. A complex example: /* Returns: -1 on error (denied==error), 0 on allowed */ int virDomainAttachDeviceFlagsEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags) { virAccessManagerPtr mgr; int rv; if (!(mgr = virAccessManagerGetDefault())) return -1; if ((rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_WRITE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE)) == 0) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG)) == (VIR_DOMAIN_AFFECT_CONFIG)) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } virObjectUnref(mgr); return 0; } - 'aclsyms' - generates a linker script to export the APIs to drivers. Some examples virConnectBaselineCPUEnsureACL; virConnectCompareCPUEnsureACL; Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-18 16:49:41 +00:00
/src/access/viraccessapicheck.c
/src/access/viraccessapicheck.h
/src/access/viraccessapichecklxc.c
/src/access/viraccessapichecklxc.h
/src/access/viraccessapicheckqemu.c
/src/access/viraccessapicheckqemu.h
/src/admin/admin_client.h
/src/admin/admin_protocol.[ch]
/src/admin/admin_server_dispatch_stubs.h
/src/bhyve/test_virtbhyved.aug
/src/bhyve/virtbhyved.aug
/src/bhyve/virtbhyved.conf
/src/esx/*.generated.*
/src/hyperv/*.generated.*
/src/interface/test_virtinterfaced.aug
/src/interface/virtinterfaced.aug
/src/interface/virtinterfaced.conf
/src/libvirt*.def
/src/libvirt.syms
Auto-generate helpers for checking access control rules Extend the 'gendispatch.pl' script to be able to generate three new types of file. - 'aclheader' - defines signatures of helper APIs for doing authorization checks. There is one helper API for each API requiring an auth check. Any @acl annotations result in a method being generated with a suffix of 'EnsureACL'. If the ACL check requires examination of flags, an extra 'flags' param will be present. Some examples extern int virConnectBaselineCPUEnsureACL(void); extern int virConnectDomainEventDeregisterEnsureACL(virDomainDefPtr domain); extern int virDomainAttachDeviceFlagsEnsureACL(virDomainDefPtr domain, unsigned int flags); Any @aclfilter annotations resuilt in a method being generated with a suffix of 'CheckACL'. extern int virConnectListAllDomainsCheckACL(virDomainDefPtr domain); These are used for filtering individual objects from APIs which return a list of objects - 'aclbody' - defines the actual implementation of the methods described above. This calls into the access manager APIs. A complex example: /* Returns: -1 on error (denied==error), 0 on allowed */ int virDomainAttachDeviceFlagsEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags) { virAccessManagerPtr mgr; int rv; if (!(mgr = virAccessManagerGetDefault())) return -1; if ((rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_WRITE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE)) == 0) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG)) == (VIR_DOMAIN_AFFECT_CONFIG)) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } virObjectUnref(mgr); return 0; } - 'aclsyms' - generates a linker script to export the APIs to drivers. Some examples virConnectBaselineCPUEnsureACL; virConnectCompareCPUEnsureACL; Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-18 16:49:41 +00:00
/src/libvirt_access.syms
/src/libvirt_access.xml
Auto-generate helpers for checking access control rules Extend the 'gendispatch.pl' script to be able to generate three new types of file. - 'aclheader' - defines signatures of helper APIs for doing authorization checks. There is one helper API for each API requiring an auth check. Any @acl annotations result in a method being generated with a suffix of 'EnsureACL'. If the ACL check requires examination of flags, an extra 'flags' param will be present. Some examples extern int virConnectBaselineCPUEnsureACL(void); extern int virConnectDomainEventDeregisterEnsureACL(virDomainDefPtr domain); extern int virDomainAttachDeviceFlagsEnsureACL(virDomainDefPtr domain, unsigned int flags); Any @aclfilter annotations resuilt in a method being generated with a suffix of 'CheckACL'. extern int virConnectListAllDomainsCheckACL(virDomainDefPtr domain); These are used for filtering individual objects from APIs which return a list of objects - 'aclbody' - defines the actual implementation of the methods described above. This calls into the access manager APIs. A complex example: /* Returns: -1 on error (denied==error), 0 on allowed */ int virDomainAttachDeviceFlagsEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags) { virAccessManagerPtr mgr; int rv; if (!(mgr = virAccessManagerGetDefault())) return -1; if ((rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_WRITE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE)) == 0) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG)) == (VIR_DOMAIN_AFFECT_CONFIG)) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } virObjectUnref(mgr); return 0; } - 'aclsyms' - generates a linker script to export the APIs to drivers. Some examples virConnectBaselineCPUEnsureACL; virConnectCompareCPUEnsureACL; Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-18 16:49:41 +00:00
/src/libvirt_access_lxc.syms
/src/libvirt_access_lxc.xml
Auto-generate helpers for checking access control rules Extend the 'gendispatch.pl' script to be able to generate three new types of file. - 'aclheader' - defines signatures of helper APIs for doing authorization checks. There is one helper API for each API requiring an auth check. Any @acl annotations result in a method being generated with a suffix of 'EnsureACL'. If the ACL check requires examination of flags, an extra 'flags' param will be present. Some examples extern int virConnectBaselineCPUEnsureACL(void); extern int virConnectDomainEventDeregisterEnsureACL(virDomainDefPtr domain); extern int virDomainAttachDeviceFlagsEnsureACL(virDomainDefPtr domain, unsigned int flags); Any @aclfilter annotations resuilt in a method being generated with a suffix of 'CheckACL'. extern int virConnectListAllDomainsCheckACL(virDomainDefPtr domain); These are used for filtering individual objects from APIs which return a list of objects - 'aclbody' - defines the actual implementation of the methods described above. This calls into the access manager APIs. A complex example: /* Returns: -1 on error (denied==error), 0 on allowed */ int virDomainAttachDeviceFlagsEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags) { virAccessManagerPtr mgr; int rv; if (!(mgr = virAccessManagerGetDefault())) return -1; if ((rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_WRITE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE)) == 0) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } if (((flags & (VIR_DOMAIN_AFFECT_CONFIG)) == (VIR_DOMAIN_AFFECT_CONFIG)) && (rv = virAccessManagerCheckDomain(mgr, conn->driver->name, domain, VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) { virObjectUnref(mgr); if (rv == 0) virReportError(VIR_ERR_ACCESS_DENIED, NULL); return -1; } virObjectUnref(mgr); return 0; } - 'aclsyms' - generates a linker script to export the APIs to drivers. Some examples virConnectBaselineCPUEnsureACL; virConnectCompareCPUEnsureACL; Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-18 16:49:41 +00:00
/src/libvirt_access_qemu.syms
/src/libvirt_access_qemu.xml
/src/libvirt_admin.syms
/src/libvirt_*.stp
/src/libvirt_*helper
/src/libvirt_*probes.h
/src/libvirt_lxc
/src/libvirtd
/src/libvirtd*.logrotate
/src/libxl/test_libvirtd_libxl.aug
/src/libxl/test_virtxend.aug
/src/libxl/virtxend.aug
/src/libxl/virtxend.conf
/src/locking/libxl-lockd.conf
/src/locking/libxl-sanlock.conf
/src/locking/lock_daemon_dispatch_stubs.h
/src/locking/lock_protocol.[ch]
/src/locking/qemu-lockd.conf
/src/locking/qemu-sanlock.conf
/src/locking/test_libvirt_sanlock.aug
/src/locking/test_libvirt_lockd.aug
/src/locking/test_virtlockd.aug
/src/logging/log_daemon_dispatch_stubs.h
/src/logging/log_protocol.[ch]
/src/logging/test_virtlogd.aug
Run an RPC protocol over the LXC controller monitor This defines a new RPC protocol to be used between the LXC controller and the libvirtd LXC driver. There is only a single RPC message defined thus far, an asynchronous "EXIT" event that is emitted just before the LXC controller process exits. This provides the LXC driver with details about how the container shutdown - normally, or abnormally (crashed), thus allowing the driver to emit better libvirt events. Emitting the event in the LXC controller requires a few little tricks with the RPC service. Simply calling the virNetServiceClientSendMessage does not work, since this merely queues the message for asynchronous processing. In addition the main event loop is no longer running at the point the event is emitted, so no I/O is processed. Thus after invoking virNetServiceClientSendMessage it is necessary to mark the client as being in "delayed close" mode. Then the event loop is run again, until the client completes its close - this happens only after the queued message has been fully transmitted. The final complexity is that it is not safe to run virNetServerQuit() from the client close callback, since that is invoked from a context where the server is locked. Thus a zero-second timer is used to trigger shutdown of the event loop, causing the controller to finally exit. * src/Makefile.am: Add rules for generating RPC protocol files and dispatch methods * src/lxc/lxc_controller.c: Emit an RPC event immediately before exiting * src/lxc/lxc_domain.h: Record the shutdown reason given by the controller * src/lxc/lxc_monitor.c, src/lxc/lxc_monitor.h: Register RPC program and event handler. Add callback to let driver receive EXIT event. * src/lxc/lxc_process.c: Use monitor exit event to decide what kind of domain event to emit * src/lxc/lxc_protocol.x: Define wire protocol for LXC controller monitor. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-17 14:54:08 +00:00
/src/lxc/lxc_controller_dispatch.h
/src/lxc/lxc_monitor_dispatch.h
/src/lxc/lxc_monitor_protocol.c
/src/lxc/lxc_monitor_protocol.h
/src/lxc/lxc_protocol.[ch]
/src/lxc/test_libvirtd_lxc.aug
/src/lxc/test_virtlxcd.aug
/src/lxc/virtlxcd.aug
/src/lxc/virtlxcd.conf
/src/network/test_virtnetworkd.aug
/src/network/virtnetworkd.aug
/src/network/virtnetworkd.conf
/src/node_device/test_virtnodedevd.aug
/src/node_device/virtnodedevd.aug
/src/node_device/virtnodedevd.conf
/src/nwfilter/test_virtnwfilterd.aug
/src/nwfilter/virtnwfilterd.aug
/src/nwfilter/virtnwfilterd.conf
/src/qemu/test_libvirtd_qemu.aug
/src/qemu/test_virtqemud.aug
/src/qemu/virtqemud.aug
/src/qemu/virtqemud.conf
/src/remote/*_client_bodies.h
/src/remote/*_protocol.[ch]
/src/remote/*_stubs.h
/src/remote/libvirtd.aug
/src/remote/libvirtd.conf
/src/remote/test_libvirtd.aug
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
/src/remote/test_virtproxyd.aug
/src/remote/virtproxyd.aug
/src/remote/virtproxyd.conf
/src/rpc/virkeepaliveprotocol.[ch]
/src/rpc/virnetprotocol.[ch]
/src/secret/test_virtsecretd.aug
/src/secret/virtsecretd.aug
/src/secret/virtsecretd.conf
/src/storage/test_virtstoraged.aug
/src/storage/virtstoraged.aug
/src/storage/virtstoraged.conf
/src/test*.aug
/src/util/virkeycodetable*.h
/src/util/virkeynametable*.h
/src/vbox/test_virtvboxd.aug
/src/vbox/virtvboxd.aug
/src/vbox/virtvboxd.conf
/src/virt-aa-helper
/src/virtbhyved
/src/virtinterfaced
/src/virtxend
/src/virtlockd
/src/virtlogd
/src/virtlxcd
/src/virtnetworkd
/src/virtnodedevd
/src/virtnwfilterd
remote: introduce virtproxyd daemon to handle IP connectivity The libvirtd daemon provides the traditional libvirt experience where all the drivers are in a single daemon, and is accessible over both local UNIX sockets and remote IP sockets. In the new world we're having a set of per-driver daemons which will primarily be accessed locally via their own UNIX sockets. We still, however, need to allow for case of applications which will connect to libvirt remotely. These remote connections can be done as TCP/TLS sockets, or by SSH tunnelling to the UNIX socket. In the later case, the old libvirt.so clients will only know about the path to the old libvirtd socket /var/run/libvirt/libvirt-sock, and not the new driver sockets /var/run/libvirt/virtqemud-sock. It is also not desirable to expose the main driver specific daemons over IP directly to minimize their attack service. Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets, and back compat for the old libvirtd UNIX socket path(s). It will then forward all RPC calls made to the appropriate driver specific daemon. Essentially it is equivalent to the old libvirtd with absolutely no drivers registered except for the remote driver (and other stateless drivers in libvirt.so). We could have modified libvirtd so none of the drivers are registed to get the same end result. We could even add a libvirtd.conf parameter to control whether the drivers are loaded to enable users to switch back to the old world if we discover bugs in the split-daemon model. Using a new daemon though has some advantages - We can make virtproxyd and the virtXXXd per-driver daemons all have "Conflicts: libvirtd.service" in their systemd unit files. This will guarantee that libvirtd is never started at the same time, as this would result in two daemons running the same driver. Fortunately drivers use locking to protect themselves, but it is better to avoid starting a daemon we know will conflict. - It allows us to break CLI compat to remove the --listen parameter. Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf will default to zero. Either TLS or TCP can be enabled exclusively though virtd.conf without requiring the extra step of adding --listen. - It allows us to set a strict SELinux policy over virtproxyd. For back compat the libvirtd policy must continue to allow all drivers to run. We can't easily give a second policy to libvirtd which locks it down. By introducing a new virtproxyd we can set a strict policy for that daemon only. - It gets rid of the weird naming of having a daemon with "lib" in its name. Now all normal daemons libvirt ships will have "virt" as their prefix not "libvirt". - Distros can more easily choose their upgrade path. They can ship both sets of daemons in their packages, and choose to either enable libvirtd, or enable the per-driver daemons and virtproxyd out of the box. Users can easily override this if desired by just tweaking which systemd units are active. After some time we can deprecate use of libvirtd and after some more time delete it entirely, leaving us in a pretty world filled with prancing unicorns. The main downside with introducing a new daemon, and with the per-driver daemons in general, is figuring out the correct upgrade path. The conservative option is to leave libvirtd running if it was an existing installation. Only use the new daemons & virtproxyd on completely new installs. The aggressive option is to disable libvirtd if already running and activate all the new daemons. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-04 11:33:23 +00:00
/src/virtproxyd
/src/virtqemud
/src/virtsecretd
/src/virtstoraged
/src/virtvboxd
/src/virtvzd
/src/virt-guest-shutdown.target
/src/vz/test_virtvzd.aug
/src/vz/virtvzd.aug
/src/vz/virtvzd.conf
/tests/*.log
/tests/*.pid
/tests/*.trs
/tests/*test
/tests/commandhelper
/tests/qemucapsprobe
!/tests/virsh-self-test
!/tests/virt-aa-helper-test
!/tests/virt-admin-self-test
/tests/objectlocking
/tests/objectlocking-files.txt
/tests/objectlocking.cm[ix]
/tests/reconnect
/tests/ssh
/tests/test_file_access.txt
/tests/test_conf
/tools/libvirt-guests.sh
/tools/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 09:58:31 +00:00
/tools/virt-login-shell-helper
/tools/virsh
/tools/virsh-*-edit.c
/tools/virt-admin
/tools/virt-*-validate
/tools/virt-sanlock-cleanup
/tools/wireshark/src/libvirt
/update.log
GPATH
GRTAGS
GTAGS
Makefile
2008-10-28 17:47:12 +00:00
Makefile.in
TAGS
2008-10-28 17:47:12 +00:00
coverage
cscope.files
cscope.in.out
cscope.out
cscope.po.out
2008-10-28 17:47:12 +00:00
results.log
stamp-h
stamp-h.in
stamp-h1
2012-10-31 15:47:34 +00:00
tags
!/build-aux/*.pl
!/gnulib/lib/Makefile.am
!/gnulib/tests/Makefile.am
!/m4/virt-*.m4