qvm-start-daemon now uses `qubes-guid -C` - ensure correct version
installed.
But to not require qubes-gui-daemon installed always, use reverse
conflict dependency.
* origin/pr/143:
qvm-start-daemon: common_guid_args is now a staticmethod
tests: kde_args are passed with property of launcher
Fix missing semi-colon and new line
Handle KDE with specific arg/desktop file
core-admin-client side had less strict rules for hostname than core-admin,
leading to unexpected empty qubesd response. Fixed by copying the logic from core-admin.
Qubes().domains.refresh_cache() tries to preserve cached VM objects if
the class matches - this way if an application keeps reference to any,
it will still be the same as freshly obtained from the collection, and
also it will receive cache updates/invalidates based on events.
The check for class change was invalid - on core-admin-client side we
have just one QubesVM class with 'klass' attribute. This leads to VM
objects being disconnected from VMCollection and stale properties cache
there (because they no longer receive events).
Fix the check.
And also add a test if indeed the same object is returned.
Allow configuring options per VM or globally per GuiVM. The
qvm-start-daemon program reads the options from VM features, and
generates a configuration file for qubes-guid.
Requires QubesOS/qubes-gui-daemon#47 (customizing the configuration
file).
Do not require permission to list sys-gui itself just to get keyboard
layout. Listing itself is not sensitive (sys-gui knows it exists), but
it will make other tools request its properties, which may not be
desirable.
qubesd socket protocol is changed in qubes-core-dom0 4.1.12 and also in
this release. Ensure matching versions are installed.
Note the python3-qubesadmin package can be installed in VM too and the
socket protocol applies only to dom0 case - use Conflicts instead of
Requires for this reason (to not break installation in the VM).
Application that runs EventsDispatcher can safely use also cache , which
greatly improve performance. This is because cache then is properly
updated/invalidated when needed.
Instead of modifying each application to explicitly enable cache based
on this simple rule, make it implicit when EventsDispatcher is created.
Do not enable caching when EventsDispatcher is created only temporarily
in wait_for_domain_shutdown.
QubesOS/qubes-issues#3293
Both tools issue a large number of Admin API calls and greatly benefit
from a cache filled with a single per-vm Admin API call
(admin.vm.property.GetAll). In case of qvm-ls, this also saves multiple
admin.vm.CurrentState calls (power state is given in the admin.vm.List
response too).
QubesOS/qubes-issues#3293
Power state changes are signaled with events too, so it is possible to
cache it and update/invalidate cache with events.
Additionally, admin.vm.List returns a power state, so the cache can be
populated early. This in particular greatly improves qvm-ls performance -
eliminate admin.vm.CurrentState call at all.
QubesOS/qubes-issues#3293
Qrexec itself does not support loopback calls. Since a call into dom0
is a common case for GUIVM (which may be dom0) to do, add a convenient
handling inside vm.run_service() function.
FixesQubesOS/qubes-issues#5140
When caching is enabled, reduce number of calls by getting all the
properties at once. If the call is not available (for example because of
the policy), fallback to getting individual values.
QubesOS/qubes-issues#5415
Reduce Admin API calls by caching returned values. The cache is not
enabled by default, because it could result in stale values being
returned. It can be enabled by setting 'cache_enabled' to True on
Qubes() object. This is safe in two cases:
- the application don't care about changed values - like a short-lived
process that retrieve values once (for example qvm-ls)
- the application listen for events and invalidate cache when property
is changed
For the second case, invalidating the cache on appropriate event
(property-set:*, property-reset:*) is done before calling other event
handlers. This is because the event may try to access the property value
(not necessary from the event arguments), so we need to be sure it will
see the new value.
FixesQubesOS/qubes-issues#5415
When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.
This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.
QubesOS/qubes-issues#5099
