Template levels

[Vincent Penquerc'h]

Can a template VM be based on another template VM ?

By this, I mean that one could start from a Fedora VM, then branch
another template VM from it, designed to have browsing capability, so
one would install things like Noscript, RequestPolicy, etc. Actual
AppVMs would be created from that template. The point being to avoid
having to do all that setup for each new VM, and not have to do it on
the template itself, since installing Firefox plugins may run random
stuff on the (original) template. Branching that second template from a
first one avoids having two different templates (helps both time spend
on maintenance and disk usage). I guess it might come down to CoW fs
being able to stack, which I don't know if they do.

[Marek Marczykowski-Górecki]

No, chained template VMs are not supported and will not be. Our template
mechanism is based on block layer, not filesystem layer, so it isn't possible
to (safely) merge changed made on different levels. This means that if you've
updated "lower" template, you'll need to redo all the changes in "upper"
template anyway.

But you can create some "browser-template" normal AppVM, in which you'll
prepare your browser settings and simply copy browser profile to whatever VM
you want.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Axon]

Marek Marczykowski-Górecki:

> On 12.01.2014 15:40, Vincent Penquerc'h wrote:
>> Can a template VM be based on another template VM ?
>>
>> By this, I mean that one could start from a Fedora VM, then branch
>> another template VM from it, designed to have browsing capability, so
>> one would install things like Noscript, RequestPolicy, etc. Actual
>> AppVMs would be created from that template. The point being to avoid
>> having to do all that setup for each new VM, and not have to do it on
>> the template itself, since installing Firefox plugins may run random
>> stuff on the (original) template. Branching that second template from a
>> first one avoids having two different templates (helps both time spend
>> on maintenance and disk usage). I guess it might come down to CoW fs
>> being able to stack, which I don't know if they do.
>
> No, chained template VMs are not supported and will not be. Our template
> mechanism is based on block layer, not filesystem layer, so it isn't possible
> to (safely) merge changed made on different levels. This means that if you've
> updated "lower" template, you'll need to redo all the changes in "upper"
> template anyway.
>
> But you can create some "browser-template" normal AppVM, in which you'll
> prepare your browser settings and simply copy browser profile to whatever VM
> you want.
>

I think this is a good solution. As I mentioned in another thread, it
can be useful in general to have dedicated AppVMs which are used as
"sub-templates." Treat the sub-template AppVM as if it were a
TemplateVM, but in which you make some changes which you wouldn't want
to make in an actual TemplateVM. Then, when you want to create a new
AppVM containing these changes, just create a clone of the sub-template
AppVM instead of creating a new AppVM based on the original template.
(Or, as Marek said, just qvm-copy over the desired files.) The example
from the other thread was a Tor Browser sub-template: For various
reasons, you may not want to download and verify TBB in a TemplateVM
(changing firewall settings, importing keys, not all AppVMs based on
that Template will be AnonVMs, etc.). The only thing is that this
solution requires a little bit of discipline, because you have to make
sure to treat your sub-template AppVM as if it were a kind of TemplateVM
(i.e., don't use it for the actual activity it's designed for; instead,
use copies of it for that activity). In a true TemplateVM, the default
firewall rules help you with this, since you can't accidentally browse
to www.randomsite.com without first changing those rules. By contrast,
in your sub-template AppVM, the firewall rules will probably be more
open (so that you could download TBB or your Firefox plugins or
whatever), so it will actually be possible for you to accidentally
browse to www.randomsite.com in the sub-template. But it shouldn't be
very difficult for a (somewhat) experienced Qubes user to keep this all
straight, IMO.

[David Schissler]

Slightly related to this, I'm wondering what the best way to develop for the LAMP stack would be.  For example, the webspace would be in the template file system and changes wouldn't stick in an AppVM.  So would I copy a template and then just run everything directly from the template?  Basically I have no idea how to work with persistent data in an AppVM that needs to store files off of the root.

Also is there a way to hide a Linux HVM window if I only want to use it for its services?

[Axon]

David Schissler:

Perhaps a StandaloneVM would be more appropriate for that case?

[Alex Dubois]

You have 2 options:

- Stateless set-up (i.e. you don't mind server going back to initial state after reboot, for example a reverse proxy, an app server which store all in DB). You will have a TemplateCopy customised for your service, you run the service in an appVM based on the template. On a daily basis you can delete/recreate appVM reverting your service to clean set-up.

- Stateful set-up (i.e. your app server or DB is making changes as it process user requests). For this, have a look at the blog post I did on setting up Jira/Confluence in Qubes. It is based on templates, the appVM is customized on boot to configure and launch service. http://bowabos.blogspot.co.uk/2013/12/how-to-set-up-jira-and-confluence-on.html

[David Schissler]

Thank you for this.  This is fully within my abilities to do, and that is something, because around these parts more than half of the time that is not the case.

So once again though not having a variety of templates is causing me some difficulties.  I have some library issues migrating from PHP 5.3 to 5.5 and my Ubuntu 12.04 setup uses the Suhosin security patch which makes the replacement module not work with it.  I'm on PHP 5.3 using module X and it is not supported on 5.5 so I want to use module Y.  I think that it would be a hell of a lot easier to use a template based approach to test this between the two versions. I don't need any special systemd stuff (for my particular application) but just the symlinking and the template user and group creation.

Well I think that Qubes is really billing itself short at the moment by not having more templates.  Regardless of it being secure, it would simply be a badass development environment.  I could see myself creating some make-shift script to determine which template OS the AppVM is running on in order to link to slightly different configurations and symlink setups from rc.local.  Other than that it would be all of the same.  Maybe if the DB versions were so different then I could standardize the two templates on a particular DB version so that the data files were guaranteed to be the same.

Perhaps Merek might be willing to get a CentOS 7 template working when it comes out.  The advantage there is that this template would still be valuable for many years, unlike the Fedora templates which have a short life span.  So then that would be pretty wild to be able to be able to switch a AppVM between bleeding edge Fedora and a stable server OS, that might actually be used in a long term deployment.  This would allow one to easily see dependency obstacles ahead and just to test out new technology.

I can see a need for a skeleton config setup that would use symlinks to create a structure that worked well for debian and redhat based systems.  Then when debian moves to systemd in 1.5 years it will be possible to relatively easily switch an AppVM between these two templates and then to first symlink to either debian or redhat.  Of course there would be caveats but simply having this would save everyone the need to keep solving the same problem.


Well on one hand I'm really excited about what Qubes could offer me and I also realize that there really isn't anyone to do that work and I'm not capable of doing it myself.