Hi uman,
that was the reference in qubes-doc that I found before and that I could
not find today when I was writing this email. However, it does not
explain what the advantage of this two-switch-model is compared to just
run the services defined in the per-qube services tab/setting without
the dependence on being enabled in the template.
That approach would render adding support for [any generic] systemd
service not only "pretty simple" but would make every systemd service
compatible "by design".
Am 27.03.23 um 17:03 schrieb unman:
On Mon, Mar 27, 2023 at 03:48:15PM +0200, r.wiesb...@web.de wrote:
Hi there,
every VM/qube has a "services" tab in its settings window. It seems like
Qubes is designed in a manner that requires two switches for a service:
it needs to be enabled in the template *and* requires an entry in
"services" tab.
My expectation was that when selected in the "services" tab, qubesrc (or
any other instance) will just start the corresponding service in the VM.
During troubleshooting I found out that it is designed as above, but I
could not find the reason for this design decision.
At least the "services tab" should have a red text warning that it is
required to enable the service in the template as well in order to not
confuse users the way it confused myself.
best,
Ron
This is a long standing design.
The process is explained at https://www.qubes-os.org/doc/qubes-service/
The text on the service tab is unclear - it *does* say that the service
will be turned on. I've raised an issue to have this clarified.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/1220e333-5413-e3fd-d3de-78e1c67bd9c6%40web.de.
