syncing config across qubes

[Daniel Allcock]

Dear all,

I am wondering how you all deal with (for example) having an elaborate vim
or emacs environment built up over several decades, and being able
to use it in all of your regular everyday qubes (personal, work, untrusted, etc,
probably leave vault out). Of course, you expect it to keep evolving as you
figure out how some package solves a problem for you, or you write some
vimscript or elisp to stop an annoyance.

What is the qubes way to do this? I've considered several solutions from
the simple to the baroque:

(simple) do the common config in the template vm (but not in /home
or /rw or /usr/local) and replace the relevant config files/dirs in the actual-work
vm's with symlinks to them.

(also simple) have a "config" qube where you keep the configs you want to sync,
but do no actual work there and have no net access. Set up a script to copy the relevant files/dirs to your working qubes. When you find an annoyance, fix it there, and then run the script.

(rather complicated) set up a git server (say in its own dvm)
and have your qubes push commits to it when
you make changes to one of the files-to-sync. That way you can make your
tweaks wherever you happen to be working at the time, and later accept
those changes on the server. Then you can download the updated version
on your working qubes (perhaps by a script).

All of these have different convenience levels and data-flow implications.
But I feel like maybe they are all wrong and I am overlooking something obvious. Any thoughts appreciated!
Daniel

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 9/14/18 4:31 PM, Daniel Allcock wrote:
> But I feel like maybe they are all wrong and I am overlooking
> something obvious.

You could have one "work qube" with your vim/emacs environment and use
qvm-open-in-vm in all other qubes to open documents with the work qube.

/Sven
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlucK5IACgkQ2m4We49U
H7ZwWg//dOKD++4cYTmjOFbNATxTYiSgkrr+x/UVaGZvs4qbCaiCO7WBS0IT7XF3
7I2ZWRSCK1vrgZy1vFrL2y+4qVjVmRE7JFTIlkXsn2oUdH7HhjCCueuKBAg+089E
/ER4b1+s7T5yGxdHV37tlehYcim2Z0CAAFhDbyslGTeHAmRVcomf1N8k9gEX/v5C
NQXV88QlJNMhGf4J/pN8h0ugamKqR9Z11zaF2quqWUNh/ebHxnSunwH7WGplyczG
JtX8KIap/ICqbJHRhxTn772qUcCBvTwoi4GF0aaObsl/+uTJFJYE5iz0bNrwK+9o
UixJK3ZyUXC/IIdiyXHTfuxTuyj11N985QrUIJp+3FiOruXwpDq/Vfw0a5MxWSM/
lQt+9bgwYdQ9JF8Z2xOghgQp19su2tqvVxXoBujj4ZhlB7MEAFQGQ3XBVqLuOyH0
tsTWogIN6f/tCSdpOm6TjjFqReopGTZ10/CZOco3NOBlvtfcGCnmwfUeQVRLvUBV
7QFl/waoebiI/ps5YaWZ2X+PNHlnhHtSqEYinWXzgp0H0xR3ulYGTP+DRb6YfBwn
sZLT94S2z+NsN6gQ5IiVzusnLrezOIEPy1VeJnMGk3/+V5wvvG/nbhp+ZLQeINOr
LlNUIPJzOZ4plAiBNCxQ1c4u1lRLNsrzowmIXkLOwQxYxsen9Og=
=Oz3W
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Fri, Sep 14, 2018 at 04:31:19PM -0500, Daniel Allcock wrote:
> Dear all,
>
> I am wondering how you all deal with (for example) having an elaborate vim
> or emacs environment built up over several decades, and being able
> to use it in all of your regular everyday qubes (personal, work, untrusted, etc,
> probably leave vault out). Of course, you expect it to keep evolving as you
> figure out how some package solves a problem for you, or you write some
> vimscript or elisp to stop an annoyance.
>
> What is the qubes way to do this? I've considered several solutions from
> the simple to the baroque:
>
> (simple) do the common config in the template vm (but not in /home
> or /rw or /usr/local) and replace the relevant config files/dirs in the actual-work
> vm's with symlinks to them.

Most tools that allow a customized local config in /home also have an area
for global configuration (for instance /etc/vim/vimrc). So since Qubes acts
more like a single-user system you could just store your settings,
plugins, etc. in their global location in the appropriate template. This
has the added advantage that you could still override your global
preferences in a particular qube if you needed to by setting things in
/home.

I follow the pattern where you clone the "default" provided templates to
create ones that you customize with custom packages anyway. The default
Qubes-provided templates just get package updates. That way backup/restore
is a bit cleaner as you don't have a conflict when the fresh install has a
brand new debian-9 template, for instance. So following this pattern you'd
change that customized template and leave the default Qubes-provided ones
for system qubes and vault, etc.

-Kyle

>
> (also simple) have a "config" qube where you keep the configs you want to sync,
> but do no actual work there and have no net access. Set up a script to copy the relevant files/dirs to your working qubes. When you find an annoyance, fix it there, and then run the script.
>
> (rather complicated) set up a git server (say in its own dvm)
> and have your qubes push commits to it when
> you make changes to one of the files-to-sync. That way you can make your
> tweaks wherever you happen to be working at the time, and later accept
> those changes on the server. Then you can download the updated version
> on your working qubes (perhaps by a script).
>
> All of these have different convenience levels and data-flow implications.
> But I feel like maybe they are all wrong and I am overlooking something obvious. Any thoughts appreciated!
> Daniel
>

> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/DF890AFA-A2CC-4033-9532-56F905DF8714%40allcock.org.
> For more options, visit https://groups.google.com/d/optout.
>

[Chris Laprise]

It gets more complicated if you want to keep settings in /home/user
updated. Otherwise, updating configs only in templates isn't hard.

The server idea would be OK if it were coordinated by a dom0 program and
used qvm-copy or sending via qvm-run+tar. An actual networked server
seems both more complicated and a security risk.

Another way you could keep /home/user settings updated is to stash the
settings somewhere in '/' and have a VM startup script copy the files
into home. You can already do this with the service in
Qubes-VM-hardening since it can deploy files from template to anywhere
in /rw at the moment the appVM mounts it...
https://github.com/tasket/Qubes-VM-hardening

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[unman]

On Fri, Sep 14, 2018 at 04:43:45PM -0500, Sven Semmler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 9/14/18 4:31 PM, Daniel Allcock wrote:
> > But I feel like maybe they are all wrong and I am overlooking
> > something obvious.
>
> You could have one "work qube" with your vim/emacs environment and use
> qvm-open-in-vm in all other qubes to open documents with the work qube.
>
> /Sven

Better still, make the "work qube" a Template for DisposableVMs, and use
those disposableVMs from the other qubes.

[bbrr...@gmail.com]

You can make use of git without a server:

qvm-run -p VMa "git -C /home/user/config bundle create - <revspec>" | qvm-run -p VMb "cat > /tmp/VMa.bundle"

and setup a pull on VM from /tmp/VMa bundle and vv. Easy to automate to reasonable comfort level with a simple script in dom0