2019-04-12 12:41:10 +00:00
|
|
|
# vim: filetype=automake
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
REMOTE_DRIVER_GENERATED = \
|
|
|
|
|
remote/remote_protocol.c \
|
|
|
|
|
remote/remote_protocol.h \
|
|
|
|
|
remote/remote_client_bodies.h \
|
|
|
|
|
remote/lxc_protocol.c \
|
|
|
|
|
remote/lxc_protocol.h \
|
|
|
|
|
remote/lxc_client_bodies.h \
|
|
|
|
|
remote/qemu_protocol.c \
|
|
|
|
|
remote/qemu_protocol.h \
|
|
|
|
|
remote/qemu_client_bodies.h \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
REMOTE_DRIVER_SOURCES = \
|
|
|
|
|
remote/remote_driver.c \
|
|
|
|
|
remote/remote_driver.h \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
REMOTE_DAEMON_GENERATED = \
|
2018-02-21 18:05:56 +00:00
|
|
|
remote/remote_daemon_dispatch_stubs.h \
|
2019-10-23 23:22:16 +00:00
|
|
|
remote/lxc_daemon_dispatch_stubs.h \
|
|
|
|
|
remote/qemu_daemon_dispatch_stubs.h \
|
2018-02-21 18:05:56 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
REMOTE_DAEMON_SOURCES = \
|
2018-02-21 18:05:56 +00:00
|
|
|
remote/remote_daemon.c \
|
|
|
|
|
remote/remote_daemon.h \
|
|
|
|
|
remote/remote_daemon_config.c \
|
|
|
|
|
remote/remote_daemon_config.h \
|
|
|
|
|
remote/remote_daemon_dispatch.c \
|
|
|
|
|
remote/remote_daemon_dispatch.h \
|
|
|
|
|
remote/remote_daemon_stream.c \
|
|
|
|
|
remote/remote_daemon_stream.h \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
REMOTE_DAEMON_CFLAGS = \
|
|
|
|
|
$(LIBXML_CFLAGS) \
|
build: link to glib library
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-29 15:12:24 +00:00
|
|
|
$(GLIB_CFLAGS) \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(GNUTLS_CFLAGS) \
|
|
|
|
|
$(SASL_CFLAGS) \
|
|
|
|
|
$(XDR_CFLAGS) \
|
|
|
|
|
$(DBUS_CFLAGS) \
|
|
|
|
|
$(LIBNL_CFLAGS) \
|
|
|
|
|
$(WARN_CFLAGS) \
|
|
|
|
|
$(PIE_CFLAGS) \
|
2019-08-02 11:05:37 +00:00
|
|
|
$(COVERAGE_CFLAGS) \
|
2019-07-03 13:00:33 +00:00
|
|
|
-I$(srcdir)/access \
|
2019-10-23 23:36:43 +00:00
|
|
|
-I$(builddir)/access \
|
2019-07-03 13:00:33 +00:00
|
|
|
-I$(srcdir)/conf \
|
|
|
|
|
-I$(srcdir)/rpc \
|
2019-10-16 12:41:49 +00:00
|
|
|
-I$(builddir)/rpc \
|
|
|
|
|
-I$(builddir)/remote \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
REMOTE_DAEMON_LD_FLAGS = \
|
|
|
|
|
$(RELRO_LDFLAGS) \
|
|
|
|
|
$(PIE_LDFLAGS) \
|
|
|
|
|
$(NO_INDIRECT_LDFLAGS) \
|
|
|
|
|
$(NO_UNDEFINED_LDFLAGS) \
|
2019-08-02 11:05:37 +00:00
|
|
|
$(COVERAGE_LDFLAGS) \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
REMOTE_DAEMON_LD_ADD = \
|
|
|
|
|
libvirt_driver_admin.la \
|
|
|
|
|
libvirt-lxc.la \
|
|
|
|
|
libvirt-qemu.la \
|
|
|
|
|
libvirt.la \
|
|
|
|
|
$(LIBXML_LIBS) \
|
|
|
|
|
$(GNUTLS_LIBS) \
|
|
|
|
|
$(SASL_LIBS) \
|
|
|
|
|
$(DBUS_LIBS) \
|
|
|
|
|
$(LIBNL_LIBS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
if WITH_DTRACE_PROBES
|
|
|
|
|
REMOTE_DAEMON_LD_ADD += ../src/libvirt_probes.lo
|
|
|
|
|
endif WITH_DTRACE_PROBES
|
|
|
|
|
|
|
|
|
|
REMOTE_DAEMON_LD_ADD += \
|
build: link to glib library
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-29 15:12:24 +00:00
|
|
|
$(GLIB_LIBS) \
|
2019-07-03 13:00:33 +00:00
|
|
|
../gnulib/lib/libgnu.la \
|
|
|
|
|
$(NULL)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
LOGROTATE_FILES_IN += \
|
|
|
|
|
remote/libvirtd.qemu.logrotate.in \
|
|
|
|
|
remote/libvirtd.lxc.logrotate.in \
|
|
|
|
|
remote/libvirtd.libxl.logrotate.in \
|
|
|
|
|
remote/libvirtd.logrotate.in \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
SYSCONF_FILES += remote/libvirtd.sysconf
|
|
|
|
|
|
|
|
|
|
PODFILES += remote/libvirtd.pod
|
|
|
|
|
MANINFILES += libvirtd.8.in
|
|
|
|
|
|
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
|
|
|
LIBVIRTD_SOCKET_UNIT_FILES_IN = \
|
2019-04-30 15:41:10 +00:00
|
|
|
remote/libvirtd.socket.in \
|
|
|
|
|
remote/libvirtd-ro.socket.in \
|
|
|
|
|
remote/libvirtd-admin.socket.in \
|
|
|
|
|
remote/libvirtd-tcp.socket.in \
|
|
|
|
|
remote/libvirtd-tls.socket.in \
|
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
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
LIBVIRTD_SOCKET_UNIT_FILES = $(notdir $(LIBVIRTD_SOCKET_UNIT_FILES_IN:%.in=%))
|
|
|
|
|
|
|
|
|
|
LIBVIRTD_UNIT_FILES_IN = \
|
|
|
|
|
remote/libvirtd.service.in \
|
|
|
|
|
$(LIBVIRTD_SOCKET_UNIT_FILES_IN) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
VIRTPROXYD_UNIT_FILES_IN = \
|
|
|
|
|
remote/virtproxyd.service.in \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
GUEST_UNIT_FILES_IN = \
|
2018-02-21 18:05:56 +00:00
|
|
|
remote/virt-guest-shutdown.target.in \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
SYSTEMD_UNIT_FILES += \
|
|
|
|
|
$(notdir $(LIBVIRTD_UNIT_FILES_IN:%.in=%)) \
|
|
|
|
|
$(notdir $(LIBVIRTD_UNIT_FILES_IN:remote/libvirtd%.in=remote/virtproxyd%)) \
|
|
|
|
|
$(notdir $(GUEST_UNIT_FILES_IN:%.in=%)) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
SYSTEMD_UNIT_FILES_IN += \
|
|
|
|
|
$(LIBVIRTD_UNIT_FILES_IN) \
|
|
|
|
|
$(VIRTPROXYD_UNIT_FILES_IN) \
|
|
|
|
|
$(GUEST_UNIT_FILES_IN) \
|
|
|
|
|
$(NULL)
|
2019-07-18 15:38:36 +00:00
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
REMOTE_PROTOCOL = $(srcdir)/remote/remote_protocol.x
|
|
|
|
|
LXC_PROTOCOL = $(srcdir)/remote/lxc_protocol.x
|
|
|
|
|
QEMU_PROTOCOL = $(srcdir)/remote/qemu_protocol.x
|
|
|
|
|
REMOTE_DRIVER_PROTOCOL = \
|
|
|
|
|
$(REMOTE_PROTOCOL) \
|
|
|
|
|
$(QEMU_PROTOCOL) \
|
|
|
|
|
$(LXC_PROTOCOL) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2019-10-23 12:24:37 +00:00
|
|
|
DRIVER_SOURCE_FILES += \
|
|
|
|
|
$(REMOTE_DRIVER_GENERATED) \
|
|
|
|
|
$(REMOTE_DRIVER_SOURCES)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
EXTRA_DIST += \
|
|
|
|
|
$(REMOTE_DRIVER_PROTOCOL) \
|
|
|
|
|
$(REMOTE_DRIVER_SOURCES) \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(REMOTE_DAEMON_SOURCES) \
|
2018-02-21 18:05:56 +00:00
|
|
|
remote/test_libvirtd.aug.in \
|
2019-06-21 16:19:11 +00:00
|
|
|
remote/libvirtd.aug.in \
|
2019-06-21 16:19:11 +00:00
|
|
|
remote/libvirtd.conf.in \
|
2018-03-14 11:08:37 +00:00
|
|
|
remote/libvirtd.policy \
|
2018-02-21 18:05:56 +00:00
|
|
|
remote/libvirtd.rules \
|
|
|
|
|
remote/libvirtd.sasl \
|
|
|
|
|
remote/libvirtd.sysctl \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2018-04-20 10:44:35 +00:00
|
|
|
# Needed to build libvirt.pot, so must be listed outside
|
|
|
|
|
# the WITH_REMOTE/WITH_LIBVIRTD conditionals
|
|
|
|
|
BUILT_SOURCES += \
|
|
|
|
|
$(REMOTE_DRIVER_GENERATED) \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(REMOTE_DAEMON_GENERATED) \
|
2018-04-20 10:44:35 +00:00
|
|
|
$(NULL)
|
2019-10-23 12:24:37 +00:00
|
|
|
CLEANFILES += \
|
2018-04-20 10:44:35 +00:00
|
|
|
$(REMOTE_DRIVER_GENERATED) \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(REMOTE_DAEMON_GENERATED) \
|
2019-06-21 16:19:11 +00:00
|
|
|
remote/libvirtd.conf \
|
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
|
|
|
remote/virtproxyd.conf \
|
2019-06-21 16:19:11 +00:00
|
|
|
$(NULL)
|
2018-04-20 10:44:35 +00:00
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
if WITH_REMOTE
|
|
|
|
|
noinst_LTLIBRARIES += libvirt_driver_remote.la
|
|
|
|
|
libvirt_la_BUILT_LIBADD += libvirt_driver_remote.la
|
|
|
|
|
libvirt_driver_remote_la_CFLAGS = \
|
|
|
|
|
$(XDR_CFLAGS) \
|
|
|
|
|
-I$(srcdir)/conf \
|
|
|
|
|
-I$(srcdir)/rpc \
|
2019-10-16 12:41:49 +00:00
|
|
|
-I$(builddir)/rpc \
|
|
|
|
|
-I$(builddir)/remote \
|
2018-02-21 18:05:56 +00:00
|
|
|
$(AM_CFLAGS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
libvirt_driver_remote_la_LDFLAGS = $(AM_LDFLAGS)
|
2019-10-23 12:24:37 +00:00
|
|
|
libvirt_driver_remote_la_SOURCES = \
|
|
|
|
|
$(REMOTE_DRIVER_SOURCES)
|
|
|
|
|
nodist_libvirt_driver_remote_la_SOURCES = \
|
|
|
|
|
$(REMOTE_DRIVER_GENERATED)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-10-17 12:30:05 +00:00
|
|
|
if WITH_DTRACE_PROBES
|
2019-10-23 12:24:37 +00:00
|
|
|
nodist_libvirt_driver_remote_la_SOURCES += libvirt_probes.h
|
2019-10-17 12:30:05 +00:00
|
|
|
endif WITH_DTRACE_PROBES
|
|
|
|
|
|
2019-04-11 15:58:24 +00:00
|
|
|
if WITH_SASL
|
|
|
|
|
libvirt_driver_remote_la_CFLAGS += \
|
|
|
|
|
$(SASL_CFLAGS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
endif WITH_SASL
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
endif WITH_REMOTE
|
|
|
|
|
|
|
|
|
|
if WITH_REMOTE
|
|
|
|
|
USED_SYM_FILES += $(srcdir)/libvirt_remote.syms
|
|
|
|
|
else ! WITH_REMOTE
|
|
|
|
|
SYM_FILES += $(srcdir)/libvirt_remote.syms
|
|
|
|
|
endif ! WITH_REMOTE
|
|
|
|
|
|
|
|
|
|
if WITH_LIBVIRTD
|
|
|
|
|
|
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
|
|
|
sbin_PROGRAMS += libvirtd virtproxyd
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
augeas_DATA += \
|
|
|
|
|
remote/libvirtd.aug \
|
|
|
|
|
remote/virtproxyd.aug \
|
|
|
|
|
$(NULL)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
augeastest_DATA += \
|
|
|
|
|
remote/test_libvirtd.aug \
|
|
|
|
|
remote/test_virtproxyd.aug \
|
|
|
|
|
$(NULL)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
nodist_conf_DATA += \
|
|
|
|
|
remote/libvirtd.conf \
|
|
|
|
|
remote/virtproxyd.conf \
|
|
|
|
|
$(NULL)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
CLEANFILES += \
|
|
|
|
|
remote/libvirtd.aug \
|
|
|
|
|
remote/virtproxyd.aug \
|
|
|
|
|
$(NULL)
|
2019-06-21 16:19:11 +00:00
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
man8_MANS += libvirtd.8
|
|
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
libvirtd_SOURCES = $(REMOTE_DAEMON_SOURCES)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-10-23 12:24:37 +00:00
|
|
|
nodist_libvirtd_SOURCES = $(REMOTE_DAEMON_GENERATED)
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
libvirtd_CFLAGS = \
|
2019-07-03 13:00:33 +00:00
|
|
|
$(REMOTE_DAEMON_CFLAGS) \
|
2019-07-18 11:30:22 +00:00
|
|
|
-DSOCK_PREFIX="\"libvirt\"" \
|
2019-06-21 16:19:11 +00:00
|
|
|
-DDAEMON_NAME="\"libvirtd\"" \
|
2019-06-21 16:19:11 +00:00
|
|
|
-DWITH_IP \
|
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
|
|
|
-DLIBVIRTD \
|
2018-02-21 18:05:56 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
libvirtd_LDFLAGS = $(REMOTE_DAEMON_LD_FLAGS)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-07-03 13:00:33 +00:00
|
|
|
libvirtd_LDADD = $(REMOTE_DAEMON_LD_ADD)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
virtproxyd_SOURCES = $(REMOTE_DAEMON_SOURCES)
|
2019-10-23 12:24:37 +00:00
|
|
|
nodist_virtproxyd_SOURCES = $(REMOTE_DAEMON_GENERATED)
|
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
|
|
|
virtproxyd_CFLAGS = \
|
|
|
|
|
$(REMOTE_DAEMON_CFLAGS) \
|
|
|
|
|
-DSOCK_PREFIX="\"libvirt\"" \
|
|
|
|
|
-DDAEMON_NAME="\"virtproxyd\"" \
|
2019-09-20 12:11:49 +00:00
|
|
|
-DWITH_IP \
|
remote: handle autoprobing of driver within virtproxyd
The virtproxyd daemon is merely responsible for forwarding RPC calls to
one of the other per-driver daemons. As such, it does not have any
drivers loaded and so regular auto-probing logic will not work. We need
it to be able to handle NULL URIs though, so must implement some kind of
alternative probing logic.
When running as root this is quite crude. If a per-driver daemon is
running, its UNIX socket will exist and we can assume it will accept
connections. If the per-driver daemon is not running, but socket
autostart is enabled, we again just assume it will accept connections.
The is not great, however, because a default install may well have
all sockets available for activation. IOW, the virtxend socket may
exist, despite the fact that the libxl driver will not actually work.
When running as non-root this is slightly easier as we only have two
drivers, QEMU and VirtualBox. These daemons will likely not be running
and socket activation won't be used either, as libvirt spawns the
daemon on demand. So we just check whether the daemon actually is
installed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-23 10:06:27 +00:00
|
|
|
-DVIRTPROXYD \
|
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
|
|
|
$(NULL)
|
|
|
|
|
virtproxyd_LDFLAGS = $(REMOTE_DAEMON_LD_FLAGS)
|
|
|
|
|
virtproxyd_LDADD = $(REMOTE_DAEMON_LD_ADD)
|
|
|
|
|
|
2019-06-21 16:19:11 +00:00
|
|
|
remote/libvirtd.conf: remote/libvirtd.conf.in
|
|
|
|
|
$(AM_V_GEN)$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
2019-07-18 15:17:07 +00:00
|
|
|
-e 's|[@]sysconfdir[@]|@sysconfdir@|' \
|
2019-08-20 10:57:46 +00:00
|
|
|
-e 's|[@]runstatedir[@]|@runstatedir@|' \
|
2019-06-21 16:19:11 +00:00
|
|
|
-e 's|[@]DAEMON_NAME[@]|libvirtd|' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
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
|
|
|
remote/virtproxyd.conf: remote/libvirtd.conf.in
|
|
|
|
|
$(AM_V_GEN)sed \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
2019-08-20 10:57:46 +00:00
|
|
|
-e 's|[@]runstatedir[@]|@runstatedir@|' \
|
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
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtproxyd/' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
INSTALL_DATA_DIRS += remote
|
|
|
|
|
|
|
|
|
|
install-data-remote:
|
|
|
|
|
$(MKDIR_P) "$(DESTDIR)$(localstatedir)/log/libvirt"
|
|
|
|
|
|
|
|
|
|
uninstall-data-remote:
|
|
|
|
|
rmdir "$(DESTDIR)$(localstatedir)/log/libvirt" ||:
|
|
|
|
|
|
2019-06-21 16:19:11 +00:00
|
|
|
remote/libvirtd.aug: remote/libvirtd.aug.in
|
|
|
|
|
$(AM_V_GEN)$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
2019-07-18 15:17:07 +00:00
|
|
|
-e 's|[@]sysconfdir[@]|@sysconfdir@|' \
|
2019-06-21 16:19:11 +00:00
|
|
|
-e 's|[@]DAEMON_NAME[@]|libvirtd|' \
|
|
|
|
|
-e 's|[@]DAEMON_NAME_UC[@]|Libvirtd|' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
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
|
|
|
remote/virtproxyd.aug: remote/libvirtd.aug.in
|
|
|
|
|
$(AM_V_GEN)$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtproxyd/' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME_UC[@]/Virtproxyd/' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
2019-07-19 15:48:10 +00:00
|
|
|
remote/test_libvirtd.aug: remote/test_libvirtd.aug.in \
|
2019-09-27 13:17:54 +00:00
|
|
|
remote/libvirtd.conf $(AUG_GENTEST_SCRIPT)
|
2019-06-21 16:19:11 +00:00
|
|
|
$(AM_V_GEN)$(AUG_GENTEST) remote/libvirtd.conf \
|
|
|
|
|
$(srcdir)/remote/test_libvirtd.aug.in | \
|
|
|
|
|
$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
2019-07-18 15:17:07 +00:00
|
|
|
-e 's|[@]sysconfdir[@]|@sysconfdir@|' \
|
2019-08-20 10:57:46 +00:00
|
|
|
-e 's|[@]runstatedir[@]|@runstatedir@|' \
|
2019-06-21 16:19:11 +00:00
|
|
|
-e 's|[@]DAEMON_NAME[@]|libvirtd|' \
|
|
|
|
|
-e 's|[@]DAEMON_NAME_UC[@]|Libvirtd|' \
|
|
|
|
|
> $@ || rm -f $@
|
2018-02-21 18:05:56 +00:00
|
|
|
|
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
|
|
|
remote/test_virtproxyd.aug: remote/test_libvirtd.aug.in \
|
2019-09-27 13:17:54 +00:00
|
|
|
remote/virtproxyd.conf $(AUG_GENTEST_SCRIPT)
|
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
|
|
|
$(AM_V_GEN)$(AUG_GENTEST) remote/virtproxyd.conf \
|
|
|
|
|
$(srcdir)/remote/test_libvirtd.aug.in | \
|
|
|
|
|
$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/d' \
|
|
|
|
|
-e '/[@]END[@]/d' \
|
2019-08-20 10:57:46 +00:00
|
|
|
-e 's|[@]runstatedir[@]|@runstatedir@|' \
|
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
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtproxyd/' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME_UC[@]/Virtproxyd/' \
|
|
|
|
|
> $@ || rm -f $@
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
if WITH_SYSCTL
|
|
|
|
|
# Use $(prefix)/lib rather than $(libdir), since man sysctl.d insists on
|
|
|
|
|
# /usr/lib/sysctl.d/ even when libdir is /usr/lib64
|
2019-01-09 17:11:33 +00:00
|
|
|
sysctldir = $(prefix)/lib/sysctl.d
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
install-sysctl:
|
2019-01-09 17:11:33 +00:00
|
|
|
$(MKDIR_P) $(DESTDIR)$(sysctldir)
|
2018-02-21 18:05:56 +00:00
|
|
|
$(INSTALL_DATA) $(srcdir)/remote/libvirtd.sysctl \
|
2019-01-09 17:11:33 +00:00
|
|
|
$(DESTDIR)$(sysctldir)/60-libvirtd.conf
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
uninstall-sysctl:
|
2019-01-09 17:11:33 +00:00
|
|
|
rm -f $(DESTDIR)$(sysctldir)/60-libvirtd.conf
|
|
|
|
|
rmdir $(DESTDIR)$(sysctldir) || :
|
2019-01-09 16:11:12 +00:00
|
|
|
|
|
|
|
|
INSTALL_DATA_LOCAL += install-sysctl
|
|
|
|
|
UNINSTALL_LOCAL += uninstall-sysctl
|
|
|
|
|
endif WITH_SYSCTL
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
if WITH_POLKIT
|
2019-01-09 17:14:34 +00:00
|
|
|
polkitdir = $(datadir)/polkit-1
|
|
|
|
|
polkitactionsdir = $(polkitdir)/actions
|
|
|
|
|
polkitrulesdir = $(polkitdir)/rules.d
|
2019-01-09 17:08:57 +00:00
|
|
|
|
2019-01-11 10:03:53 +00:00
|
|
|
install-polkit:
|
2019-01-09 17:14:34 +00:00
|
|
|
$(MKDIR_P) $(DESTDIR)$(polkitactionsdir)
|
2018-03-14 11:08:37 +00:00
|
|
|
$(INSTALL_DATA) $(srcdir)/remote/libvirtd.policy \
|
2019-01-09 17:14:34 +00:00
|
|
|
$(DESTDIR)$(polkitactionsdir)/org.libvirt.unix.policy
|
|
|
|
|
$(MKDIR_P) $(DESTDIR)$(polkitrulesdir)
|
2018-02-21 18:05:56 +00:00
|
|
|
$(INSTALL_DATA) $(srcdir)/remote/libvirtd.rules \
|
2019-01-09 17:14:34 +00:00
|
|
|
$(DESTDIR)$(polkitrulesdir)/50-libvirt.rules
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-01-11 10:03:53 +00:00
|
|
|
uninstall-polkit:
|
2019-01-09 17:14:34 +00:00
|
|
|
rm -f $(DESTDIR)$(polkitactionsdir)/org.libvirt.unix.policy
|
|
|
|
|
rmdir $(DESTDIR)$(polkitactionsdir) || :
|
|
|
|
|
rm -f $(DESTDIR)$(polkitrulesdir)/50-libvirt.rules
|
|
|
|
|
rmdir $(DESTDIR)$(polkitrulesdir) || :
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-01-09 16:11:12 +00:00
|
|
|
INSTALL_DATA_LOCAL += install-polkit
|
|
|
|
|
UNINSTALL_LOCAL += uninstall-polkit
|
|
|
|
|
endif WITH_POLKIT
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-01-09 16:11:12 +00:00
|
|
|
endif WITH_LIBVIRTD
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
.PHONY: \
|
|
|
|
|
install-data-remote \
|
|
|
|
|
uninstall-data-remote \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
# This is needed for clients too, so can't wrap in
|
|
|
|
|
# the WITH_LIBVIRTD conditional
|
|
|
|
|
if WITH_SASL
|
2019-01-09 17:22:39 +00:00
|
|
|
sasldir = $(sysconfdir)/sasl2
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
install-sasl:
|
2019-01-09 17:22:39 +00:00
|
|
|
$(MKDIR_P) $(DESTDIR)$(sasldir)
|
2018-02-21 18:05:56 +00:00
|
|
|
$(INSTALL_DATA) $(srcdir)/remote/libvirtd.sasl \
|
2019-01-09 17:22:39 +00:00
|
|
|
$(DESTDIR)$(sasldir)/libvirt.conf
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
uninstall-sasl:
|
2019-01-09 17:22:39 +00:00
|
|
|
rm -f $(DESTDIR)$(sasldir)/libvirt.conf
|
|
|
|
|
rmdir $(DESTDIR)$(sasldir) || :
|
2019-01-09 16:11:12 +00:00
|
|
|
|
|
|
|
|
INSTALL_DATA_LOCAL += install-sasl
|
|
|
|
|
UNINSTALL_LOCAL += uninstall-sasl
|
|
|
|
|
endif WITH_SASL
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-07-18 15:31:45 +00:00
|
|
|
LIBVIRTD_UNIT_VARS = \
|
|
|
|
|
$(COMMON_UNIT_VARS) \
|
2019-07-18 15:34:41 +00:00
|
|
|
-e 's|[@]name[@]|Libvirt|g' \
|
|
|
|
|
-e 's|[@]service[@]|libvirtd|g' \
|
|
|
|
|
-e 's|[@]sockprefix[@]|libvirt|g' \
|
|
|
|
|
-e 's|[@]deps[@]||g' \
|
2019-07-18 15:31:45 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
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
|
|
|
VIRTD_UNIT_VARS = \
|
|
|
|
|
$(COMMON_UNIT_VARS) \
|
|
|
|
|
-e 's|[@]deps[@]|Conflicts=$(LIBVIRTD_SOCKET_UNIT_FILES)|g' \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
VIRTPROXYD_UNIT_VARS = \
|
|
|
|
|
$(VIRTD_UNIT_VARS) \
|
|
|
|
|
-e 's|[@]name[@]|Libvirt proxy|g' \
|
|
|
|
|
-e 's|[@]service[@]|virtproxyd|g' \
|
|
|
|
|
-e 's|[@]sockprefix[@]|libvirt|g' \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
libvirtd.service: remote/libvirtd.service.in $(top_builddir)/config.status
|
2019-07-18 15:31:45 +00:00
|
|
|
$(AM_V_GEN)$(SED) $(LIBVIRTD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
|
|
|
|
|
|
|
|
|
libvirt%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status
|
|
|
|
|
$(AM_V_GEN)$(SED) $(LIBVIRTD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
2019-04-30 15:41:10 +00:00
|
|
|
|
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
|
|
|
virtproxyd.service: remote/virtproxyd.service.in $(top_builddir)/config.status
|
|
|
|
|
$(AM_V_GEN)$(SED) $(VIRTPROXYD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
|
|
|
|
|
|
|
|
|
virtproxy%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status
|
|
|
|
|
$(AM_V_GEN)$(SED) $(VIRTPROXYD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
virt-guest-shutdown.target: remote/virt-guest-shutdown.target.in \
|
|
|
|
|
$(top_builddir)/config.status
|
|
|
|
|
$(AM_V_GEN)cp $< $@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
remote/remote_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \
|
|
|
|
|
$(REMOTE_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
|
|
|
|
|
remote REMOTE $(REMOTE_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/remote_client_bodies.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
remote/lxc_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \
|
|
|
|
|
$(LXC_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
|
|
|
|
|
lxc LXC $(LXC_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/lxc_client_bodies.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
remote/qemu_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \
|
|
|
|
|
$(QEMU_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
|
|
|
|
|
qemu QEMU $(QEMU_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/qemu_client_bodies.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
remote/remote_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
|
|
|
|
|
$(REMOTE_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
|
|
|
|
|
--mode=server remote REMOTE $(REMOTE_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/remote_daemon_dispatch_stubs.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-10-23 23:22:16 +00:00
|
|
|
remote/lxc_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
|
2018-02-21 18:05:56 +00:00
|
|
|
$(LXC_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
|
|
|
|
|
--mode=server lxc LXC $(LXC_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/lxc_daemon_dispatch_stubs.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2019-10-23 23:22:16 +00:00
|
|
|
remote/qemu_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
|
2018-02-21 18:05:56 +00:00
|
|
|
$(QEMU_PROTOCOL) Makefile.am
|
|
|
|
|
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
|
|
|
|
|
--mode=server qemu QEMU $(QEMU_PROTOCOL) \
|
2019-10-16 12:52:23 +00:00
|
|
|
> remote/qemu_daemon_dispatch_stubs.h
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
libvirtd.8.in: remote/libvirtd.pod
|
|
|
|
|
$(AM_V_GEN)$(POD2MAN) --section=8 $< $@-t1 && \
|
|
|
|
|
if grep 'POD ERROR' $@-t1; then rm $@-t1; exit 1; fi && \
|
|
|
|
|
sed \
|
|
|
|
|
-e 's|SYSCONFDIR|\@sysconfdir\@|g' \
|
2019-10-18 14:31:30 +00:00
|
|
|
-e 's|RUNSTATEDIR|\@runstatedir\@|g' \
|
2018-02-21 18:05:56 +00:00
|
|
|
< $@-t1 > $@-t2 && \
|
|
|
|
|
rm -f $@-t1 && \
|
|
|
|
|
mv $@-t2 $@
|
