‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On August 27, 2018 10:48 AM, unman <un...@thirdeyesecurity.org> wrote:
> On Mon, Aug 27, 2018 at 05:13:29AM -0000, 'awokd' via qubes-users wrote: > > > On Mon, August 27, 2018 2:02 am, averyfuentes9rs via qubes-users wrote: > > > > > Hola Qubers, > > > For stream-lined management and ease of updating I wanted to implement > > > the following Qubes hierachy: > > > > > > 1. Official FC28-minimal TemplateVM from qubes-itl-templates repo > > > 2. 'FC28-base' TemplateVM, a clone of 1) > > > With same small adaptations > > > > > > 3. 'FC28-$ROLE': TemplateVM which uses 2) as a Template > > > With the goal of creating a role specific template that automatically > > > benefits from all changes made to 2) 4) 'AppVM-$ROLE': AppVM based on > > > 3) + > > > some user settings > > > > > > > > > Trying to create a TemplateVM from a TemplateVM I get: > > > $ qvm-create --class=TemplateVM --template=FC28-base --label=red > > > FC28-Test > > > app: Error creating VM: Got empty response from qubesd. See journalctl in > > > dom0 for details. > > > > > Is a TemplateVM of a TemplateVM an unsupported feature or should I create > > > an issue on github for this? > > > > Unsupported/not implemented, but it's an interesting idea- multiply > > layered templates. Anyways, I think the expectation under Qubes would be > > to clone your 'FC28-base' as many times as needed, then you can apply Salt > > scripts to those to customize further. You can do some limited > > customization (selecting services to start or not) from the AppVM, but > > sounds like you'd like more. > > awokd is right: it's not implemented. > In fact the idea has been raised on these lists a few times before. E.g: > https://groups.google.com/d/topic/qubes-users/a_VX6xSWj-Q/discussion > https://groups.google.com/d/topic/qubes-users/iLJjTTQqgrw/discussion > > You'll see that the current implementation precludes templateception, > and changing to allow it would alter the security profile. > > As awokd says, multiple templates are the way to go. There's some extra > admin pain but you can mitigate this using salt (or a simple bash > script) and a caching proxy. > > unman Thanks for the links. marmareks description of the template mechanism working on block level logically explains why this is not possible. It raises a few other (more or less) random thoughts: 1) The python trace I posted above should not happen. IMO qvm-clone should display an error for this setup being unsupported instead. 2) qubesctl should have something like a '--recursive' flag: Expected behabvior: Lets say I execute 'state.apply' on an AppVM 'FC28-Random', adding the recursive flag would first execute 'state.apply' on the TemplateVM 'FC28-Random' is based on and afterwards apply 'state.apply' to the AppVM itself. I find 2) especially helpful, since software and OS upgrades need to done in the TemplateVM. As a new user to Qubes + Salt (alternatively as I'm prone to forgetting things :-P) I frequently forget to run qubesctl twice to incorporate all changes that I expect to manifest in the AppVM. IMO the '--recursive' flag would make the situation more "working as expected". --- Salud, Avery -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/UsT2YfOGoPx2CvemXI_x6u_aO-y9m2L-KJsu1K1TfnNhLOelUdi3coYfkUU4_Iwy1z7IbKmm5QNnTdCNGZS18xFmRpHFy6Mg-n7K6ZAqxsk%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
