On Mon, Mar 27, 2023 at 06:33:26PM +0200, r.wiesb...@web.de wrote: > 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".
I think that a generic systemd service is already compatible by design:if you install such a service and enable it in the template it will be enabled in the qubes using that template. Is that not so? The current system provides a simple condition that gives granular control over services on a per qube basis. The same control can be achieved by *disabling* the service in the template, and having a switch that enables the service and starts it in the qube. I do this myself in some cases. (From dom0 with qvm-run, or with entries in rc.local, e.g.) Both approaches require some action in the template as well as action in the qube. So both are "two-switch". The current mechanism provides a dead mans handle but allows services to start at an early stage. You are not obliged to use it for other services. -- 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/ZCL4GLiMKwI%2B2btY%40thirdeyesecurity.org.
