On Thu, Nov 19, 2020 at 07:33:27AM -0500, Matt McCutchen wrote:
> On Wed, 2020-11-18 at 14:34 +0000, unman wrote:
> > On Wed, Nov 18, 2020 at 08:54:23AM -0500, Matt McCutchen wrote:
> > > 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.
>
> I thought someone might mention Salt. :) If you feel like it, to
> satisfy my curiosity, can you point me to documentation on how I'd use
> Salt to copy a file to all templates? I'm still more likely to use my
> original proposed solution though.
The state file, copyit.sls, could look like this:
```
/home/user/target:
file.managed:
- source:
- salt://source
- user: user
- group: group
```
And the command would be:
qubesctl --skip-dom0 --templates state.apply copyit
The best source is, of course, the docs, which explain all the
different things you can do with files/directories:
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html
I have some introductory notes at
https://github.com/unman/notes/tree/master/salt
>
> In the long term, I'd indeed like to have a concise script of some kind
> to reproduce all my templates. It will be a significant amount of
> work to find all my customizations and get them into such a script, so
> I'm seeking a nearer-term solution for these proprietary apps. But
> while we're on the topic: while mutating templates may be a decent
> solution for rapid iteration, how fast could I make the clean
> regeneration run? Is there a reasonable way to generate one template
> and then generate the others from it? Might OSTree be helpful?
>
> Thanks for any insights!
>
> Matt
>
As the Irishman said, "I wouldn't start from here".
It's undoubtedly *much* easier to start by installing and customising
using salt, than to try to remember what one has done and fit that in to
salt states.
As to "how long", that depends on exactly what you're doing. Creating and
cloning templates is, I'd say, pretty much as fast as
qvm-create/qvm-clone.
Installing and configuring slower than opening console and doing it
manually, I think, although I haven't done that for some time, except for
minimal templates that cant be salted out of the box. (This is a
constant source of frustration for me and a huge error imo)
The first thing I do is salt a caching proxy in place of tinyproxy.
Then I clone the vanilla template, build the largest template (which
caches almost all the packages), and start on the rest.
Most of my templates don't share new packages, so I cant install, clone and
install in to the clone. If your model is different, then you'd be able to do
this quite simply, using cascading template installs.
--
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/20201119163807.GA26002%40thirdeyesecurity.org.
