Do you do this again to all your existing AppVms when you update your preferred configuration, or do you have to manually go in and update each one?
1 Like
Curious about that, too? Let’s say @anon22772651 you do a small change to one of your dotfiles. How do you sync that small change to your existing qubes?
Yeah I understand what you describe. Interesting, but kinda outside of the workflow I am seeking for.
That’s cool. I will try that. Just to see if I understand correctly:
You have a “dotfile” qube where you originate this “bare git repository”. You push this git repo to a machine in the local network (like a raspberry pi, or something like that).
Then, let’s say, you create a “multimedia” qube for watching videos and listening to music. In the multimedia qube, you do git pull [local IP of the raspberry pi] and get the dotfile git repo into the multimedia repo.
Then, let’s say, you make a change to the mpv.conf file in the multimedia qube. In the multimedia qube, you do git add/commit, and then push the git repo back to the local raspberry pi. And all your qubes pull those changes back. Am I getting it right?
Edit: question: can you pull/push git changes from/to the “dotfile” qube, within the same QubesOS, instead of a local raspberry pi?
Honestly I don’t really see the underlying issue in the first place:
For globally required “dot files” (e.g. bashrc, vimrc, …) there are global configuration methods available in /etc/. I tend to use those in the template.
Very specific applications are only used inside a dedicated VM by me as per the Qubes threat model, i.e. I use the local dot file storage at /home/ for these.
I haven’t yet found an application that I need to use in multiple VMs and that doesn’t offer an /etc/ config method. Even if there’s one, you can still symlink to a global config in /etc/.
No need for all these proposed network sync methods IMHO.
1 Like
Thanks. Do you know if what I described is possible with qubes os: instead of syncing to a LAN raspberry pi, we sync (or, push/pull the git commits) to the “dotfiles” qubes, within the same qube, using its internal IP? Am I making any sense?
Many dotfiles can be placed in /etc/, like vimrc. So you’re better off putting as many dotfiles as you can in /etc/ in the template.
This is better than /etc/skel/, because changes will propagate also to old VMs.
2 Likes
This is also a neat setup.
There is some risk though. In this case you need to potentially perform more transfers of (potentially hostile) data into your templates.
I’m considering putting a bootstrap script in my template. On new qubes, running that will pull or clone down dotfiles from some remote source (e.g., GitHub). This could be useful especially for VIM plugins. I wouldn’t want to copy those into my templates.
This thread has definitely sparked some interesting conversation.
1 Like
There are existing solutions for rsync and git over qrexec which allow
for this without using internal Qubes network.
You could find them by searching the forum.
2 Likes
Ooh, I am interested in reading more about this. I will take a look at the forum search.
Since I use both Qubes and a number of other *Nix systems (mostly OpenBSD), I have a “dotfiles” git repo someplace secure enough, where I can access it from all machines. The internet is fast enough these days that I can do a ‘git pull’ in my login scripts so I don’t have to manually update, yet it’s always up to date. There’s a Makefile to symlink the files into place when I clone it onto a new machine. For stuff that shouldn’t be on all the machines, this doesn’t apply, but you could extend it to have a few repos or just handle those few files manually.
2 Likes
I stumbled upon another way to manage the dotfiles across qubes: using GNU stow and git:
Moved to User Support.
Can you explain if using rsync to move git repo locally from qube1 to qube2 would overwrite the qube2’s local git repo version? I mean, let’s say I make a change to my dotfiles git repo on qube1. Then I use rsync to sync that change to qube2. What happens? Is it going to be overwritten?
I am trying to see if it is possible to keep track of a git repo for my dotfiles, with a “remote” server being one of my local qubes os qubes. Can I do git push/pull/fetch/merge operations that way?
Or, let’s say I simply qvm-copy the ~/.dotfiles folder or, ~/.dotfiles/.git folder (?) to other qubes that have the same ~/.dotfiles folder but outdated git repo version.
What do I do with the ~/.dotfiles folder or, ~/.dotfiles/.git in the ~/QubesIncoming directory now? Do I move that to the ~/.dotfiles? If I do that is it going to automatically merge the commits or something?
I might be in the process of devising a solution for my use case. I am making use of git bundle command. See here for an introduction: Git - Bundling
As I keep testing this workflow, I will straighten the kinks and if I am satisfied with it, probably will write a full guide. But for now, here’s some quick notes on it:
Syncing dotfiles across qubes without a remote server on the internet:
on the dotfiles qube:
cd into ~/.dotfiles dir.
You already have a git repo in there. You have your dotfiles organized according to stow program.
~/.dotfiles/zsh/.config/zsh/ → this dir contains your zsh dotfiles.
So, on ~/.dotfiles dir:
$ git bundle create dotfiles.bundle HEAD master
this will create a dotfiles.bundle file containing the version of ~/.dotfiles directory as it is on the dotfiles qube.
You then qvm-move that dotfiles.bundle into another qube that you want to propagate your dotfiles to.
Let’s say you qvm-move 'd that file to “mydebian” qube. On the mydebian qube, create the ~/.dotfile dir. Then, move the dotfiles.bundle file there:
$ mv ~/QubesIncoming/dotfiles/dotfiles.bundle ~/.dotfiles
Then, cd into ~/.dotfiles dir and do
$ git pull dotfiles.bundle
You will have the same dir with the same git history and files as in dotfiles qube now in your mydebian qube.
Let’s say, you change some files in ~/.dotfiles, in this mydebian qube, and you want to propagate those changes back to the dotfiles qube. You commit your changes, and create a git bundle in mydebian:
$ git bundle create dotfiles.bundle HEAD master
Basically qvm-move that dotfiles.bundle file back to dotfiles qube. Move that bundle file again to the ~/.dotfiles dir, and git pull from it in the dotfiles dir.
You can further assign following git usernames for keeping track of which commits came from which qubes:
(on dotfiles ) $ git config user.name ‘dotfiles’
(on dotfiles ) $ git config user.email ‘dotfiles@localhost’
(on mydebian ) $ git config user.name ‘mydebian’
(on mydebian ) $ git config user.email ‘mydebian@localhost’
that way, your commit history will show the qubes’ names as the commit owners.
1 Like
Yes - rsync will copy over the destination. It’s designed to put the
source and destination in sync. (There are configuration options to deal
with various use cases.)
It’s efficient and fast.
For git I would recommend git over qrexec.
New idea that I might implement. Currently I send a script to each new VM and run it, and it’ll configure all my settings by running commands and editing files. This makes updating an issue as someone pointed out, but I rarely update my dotfiles after being set up so it hasn’t bothered me yet. However you could centralize it by placing the scripts in dom0, then running some sort of for loop on each VM you want to update, where it sends the new centralized file from dom0 and then executes the file in each VM. That way you only have to update one file, and then run the update loop.
This is where salt comes in to its own.
You can place the configuration files in dom0, and then target delivery
, writing configuration as needed, and changing in accord with the
target system, either by name or by other features.
You can read about Salt here - I
have a basic tutorial here covering many
uses and examples.