On Wed, Nov 18, 2020 at 08:54:23AM -0500, Matt McCutchen wrote: > I have the honor of a response from Andrew! :) > > On Tue, 2020-11-17 at 20:57 -0800, Andrew David Wong wrote: > > For me, the advantage of TemplateVMs over StandaloneVMs (even if there's > > only one TemplateBasedVM based on the TemplateVM) is that it's easier to > > update the TemplateVM and back up the TemplateBasedVM. > > I assumed the update process was the same for a TemplateVM or a > StandaloneVM (though I've never tried the latter), and for backups, I > can select any set of VMs in the Qube Manager. Perhaps you're pointing > out that if the system volume of the desired AppVM is easy enough to > recreate that it's not worth backing up, then using a TemplateVM + > TemplateBasedVM rather than a StandaloneVM makes it possible to skip > the backup? Interesting point. Though I suppose the more general > observation underlying my original proposal was that if the process to > generate the system volume from that of the main TemplateVM is > automated and reasonably fast, then there's the option to run it on > every boot of the TemplateBasedVM rather than persisting a separate > system volume at all. > > > > my bigger > > > concern is the custom tools and configuration changes in my main > > > template that aren't currently packaged for dnf. I could probably > > > package them and/or do without some of them in some proprietary-app > > > VMs, but I think that would end up being a bigger hassle than > > > developing and using my proposed tool. > > > > No need. Just make your changes in one template, then clone that > > template as needed. That way, you only have to make the changes once. > > The problem is when I change the main TemplateVM and want to apply the > change to all existing system volumes. For example, recently I've > migrated some really useful configuration settings (e.g., enabling > undo-tree by default in Emacs and setting "merge.conflictstyle = diff3" > in Git) from the user volume of my "main" AppVM to my TemplateVM so I > would enjoy their benefits in all AppVMs. If I had multiple > TemplateVMs, I would have to somehow copy those changes to all of them. > If I changed a single file, maybe I could write a script that does a > bunch of qvm-copy commands. But if I want to make sure things do not > get out of sync over time due to mistakes, it would help to have a > management tool of some kind.
Just one word - salt. Salt your templates, and you can straightforwardly clone, and configure, those templates with one command. Using salt also has the benefit that you can sit down at a new machine, pull down the salt config and recreate your system. No more wondering if you kept track of what was installed, or whether your scripts contain all the nice config changes you laboured over. > > However, on second thought, I realize that the only VM with a > proprietary app in which most of these customizations are valuable is > the one with Visual Studio Code, in which I do some of my software > development. In the others, I pretty much run the proprietary app and > nothing else because I want to minimize the data exposed to the > proprietary app. So as long as there are only two TemplateVMs in which > the customizations are needed, it may be manageable to copy them > manually. > > > > Also, I'm low on disk space and > > > making many templates would make it worse, though maybe it's time that > > > I just bought a bigger disk. > > > > > > > If you use minimal templates, even having a lot of them doesn't take up > > much space. > > Good point. This would likely be appropriate for my VMs that run a > proprietary app and nothing else, although the video conferencing ones > will need at least pavucontrol, for example. For the Visual Studio > Code VM, I'd need a lot more, but probably still a lot less than the > ~13G of software in my main TemplateVM that is the union of everything > needed for all the projects in its TemplateBasedVMs. > > Matt > > -- > 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/d14988baabf450f6b979f4c68ad4d3589f1c54f6.camel%40mattmccutchen.net. -- 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/20201118143426.GA18950%40thirdeyesecurity.org.
