Re: [qubes-users] Re: TemplateVM Best-Practices?
On 12/02/2016 12:29 AM, Chris Laprise wrote: Exceptions to this routine may emerge out of necessity. For example, it generally isn't a good idea to add new software to Whonix templates. Some also feel that service VMs like sys-net and sys-firewall should be run with a minimal template without regular apps present... this makes them more like router installations and theoretically more secure. Is there other advantages of using minimal template for sys-net etc. ? Maybe fast boot? Less memory usage? What size of minimal template? -- Regards -- 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/41101f8f-f9fb-c20a-1a8a-9d4947c8f4e4%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: TemplateVM Best-Practices?
On 11/30/2016 07:02 PM, Loren Rogers wrote: On 11/30/2016 09:14 AM, Daniel Moerner wrote: On Wednesday, November 30, 2016 at 8:59:58 AM UTC-5, Loren Rogers wrote: Hi all, Are there any recommended strategies for creating and managing TemplateVMs for regular users? Speaking personally, I use four templates: (based on Debian 9) base: For sys-*, vault, gpg, shopping, banking, etc. office: Libreoffice, thunderbird extensions, latex. For work and personal VMs. dev: Developer tools, compilers, etc. For dev VMs. untrusted: Media software (vlc, etc.) as well as Chrome. This lets me keep the individual templates to a more manageable size and prevents me from accidentally mixing up my workflow across VMs. I would be open to using a more stripped-down base template but I'm not convinced it's worth it. Thanks - it's really helpful to hear how others manage things. I'll give a similar setup a try. There have been discussions about this over the years. I don't think its wrong to add lots of software to a 'general appVM use' template as long as the new programs are not network-facing *services* (as opposed to network clients). This touches on the Qubes idea that users should compartmentalize. 'How' we should do it is left to us to decide, however the default Qubes config including VMs for work, personal, etc. suggests we can comfortably segregate by role; We don't have to do it app-by-app they way some people suggest and that would drive a lot of people crazy. Implied in role-based compartmentalization is that each role will need a lot of common apps working in concert. Exceptions to this routine may emerge out of necessity. For example, it generally isn't a good idea to add new software to Whonix templates. Some also feel that service VMs like sys-net and sys-firewall should be run with a minimal template without regular apps present... this makes them more like router installations and theoretically more secure. Chris -- 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/02c637e8-63b1-2d86-8300-52ebf0d6b580%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: TemplateVM Best-Practices?
On 11/30/2016 09:14 AM, Daniel Moerner wrote: On Wednesday, November 30, 2016 at 8:59:58 AM UTC-5, Loren Rogers wrote: Hi all, Are there any recommended strategies for creating and managing TemplateVMs for regular users? Speaking personally, I use four templates: (based on Debian 9) base: For sys-*, vault, gpg, shopping, banking, etc. office: Libreoffice, thunderbird extensions, latex. For work and personal VMs. dev: Developer tools, compilers, etc. For dev VMs. untrusted: Media software (vlc, etc.) as well as Chrome. This lets me keep the individual templates to a more manageable size and prevents me from accidentally mixing up my workflow across VMs. I would be open to using a more stripped-down base template but I'm not convinced it's worth it. Thanks - it's really helpful to hear how others manage things. I'll give a similar setup a try. -- 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/22a3e0ee-ce10-85eb-627b-1bf82157a46a%40lorentrogers.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: TemplateVM Best-Practices?
On Wednesday, November 30, 2016 at 8:59:58 AM UTC-5, Loren Rogers wrote: > Hi all, > > Are there any recommended strategies for creating and managing > TemplateVMs for regular users? Speaking personally, I use four templates: (based on Debian 9) base: For sys-*, vault, gpg, shopping, banking, etc. office: Libreoffice, thunderbird extensions, latex. For work and personal VMs. dev: Developer tools, compilers, etc. For dev VMs. untrusted: Media software (vlc, etc.) as well as Chrome. This lets me keep the individual templates to a more manageable size and prevents me from accidentally mixing up my workflow across VMs. I would be open to using a more stripped-down base template but I'm not convinced it's worth it. -- 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/0e38e8cb-2595-4eee-9222-2990c8b8aecd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
