Re: [qubes-users] How Qubes handles the start of services
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.
Re: [qubes-users] How Qubes handles the start of services
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.
Re: [qubes-users] How Qubes handles the start of services
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/ZCGwR5nTbOD/kLIl%40thirdeyesecurity.org.
[qubes-users] How Qubes handles the start of services
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 -- 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/818b8e19-a1b7-7365-a059-2ac8b134c9a9%40web.de.