How to replicate dotfiles across qubes?

User Support
1

Is there a smart way to replicate (or, propagate) the various dotfiles that are under ~/.config (or the /home/user ) dir? What are your workflows for that?

Currently, I simply use qvm-copy to pass changes in my dotfiles to other qubes. But this is a haphazard way of doing dotfile synchronization across qubes. I have to keep in mind which qubes have the “latest” changes in my dotfiles and which don’t—that’s obviously a pain in the neck.

Another option might be having a dotfiles qube, and collecting all the dotfiles in it. Creating a git repo for the ~/.config dir, and do push/pull to a github repo, and then pull that github repo to other qubes. But that is also missing the qubes with no-internet connection (think “vault” and such).

How do “smart” users of QubesOS achieve this goal?

2

When you create an AppVM it can inherit from its template. This won’t keep your dotfiles synchronized after AppVM creation but it does provide a starting point.

Beyond that, for networked VMs, you could sync your dotfiles from a version control system (you should be able to find some examples online of how others have achieved this) or from some other remote source.

For network-isolated VMs, I’d probably handle those on a case-by-case basis. For example, I really only open my vault app in Vault so I probably wouldn’t need to worry about dotfiles. In a less sensitive, yet isolated app, I might just do the occasional copy between VMs.

Others have configured things such as Firefox profiles and configurations from a template, too, in case that gives you additional ideas.

3

The new qube (ie, “AppVM”) seems to inherit only the /etc/skel changes from the template, though. Do you utilize the /etc/skel for dotfile inheritence?

4

Not yet. I probably will start using it now, after finding out about it during my earlier response.

As you mentioned, these would only be be copied once at AppVM creation.

For networked AppVMs, I would use something like git and a VCS for maintaining versions and updates.

I am actually curious to read how others handle dotfiles. My setup is probably on the basic end of the scale, not advanced.

1 Like
5

Being able to use /etc/skel for such things as dot files (and config files for certain applications) has done a lot to let me make app qubes into disposables.

[From here forward I’ll just talk about “dot files” but that should be taken to mean any file that stores configurations that lives in /home/user somewhere. In one or two cases a useful config file lives somewhere out in the area that templates preserve; in that case just modify what I say below.]

Start with a clean template. Install the app. Install the dot files into /etc/skel. (And other config files where they go.) Now I can base a disposable off of that and every time I start the disposable up comes my app, already preconfigured the way I like it.

There’s no reason you can’t put multiple apps on the template (I do that with LibreOffice) but in general, I have one app per template.

Now your dot files’ original copies live on dom0, and they’re easy to back up. It costs you almost nothing to regenerate the template AND the disposable template; because now there’s nothing on them that needs to be backed up that isn’t already (particularly the disposable template).

Of course to make all of this work you must store your actual data on a mounted drive external to the VM. That could either be NAS storage or just some separate hard drive/ssd in your computer (or a different partition), or anything in between. (This is what I developed my split-veracrypt for.)

But by this means almost everything on my computer that I touch as a “plain old user” is disposables.

2 Likes
6

That is actually quite an interesting perspective. And now I get what you mean by “using app qubes as disposables” better.

Yeah that point makes me wonder: where do you store your personal pdf’s, music/video files and such? I would be interested in hearing more about how you mount a partition to your disposables for this purpose.

7

Another variation, of course, is to set up the template as above, but then base an AppVM off of it. [This is probably closer to what you are looking to do.] Of course now you have an AppVM that might need to be backed up (unless you commit to using external-to-the-VM storage).

Why bother with an AppVM if you’re not going to store “stuff” on it? I have one such scenario, but describing it turned my prior draft of this comment into something six times longer. I suppose I should probably just do a topic on Qube Tricks someday. (Some are trivial, like getting a named disposable to behave more like an un named disposable.)

1 Like
8

I select a qube as my dotfile “master” and create a git bare repo there (see How to Store Dotfiles - A Bare Git Repository | Atlassian Git Tutorial for more info). I then have push/pull scripts to do the sync stuff with other qubes. I have a local git server, so am not sync’ing to the internet.

3 Likes
9

I hope I understand what you’re asking. Otherwise, I’m about to explain a bunch of stuff you already know.

A partition will show up in qui-devices. As will a thumb drive.

You can then assign that partition to your qube.

You can then see it in the qube with lsblk; it will likely be /dev/xvdi (if there are multiples, they will be -j, -k, etc).

You can then do the standard linux “mount” command to mount this to a folder in /home/user. (Needless to say I have one of those pre-configured by creating it in /etc/skel.) When finished, use the umount command, go into qui-devices and detach the device from your qube, and shut the qube down. (Strictly speaking you needn’t bother with the detach, but it’s tidy.)

If that’s not what you were asking, please let me know.

10

I created a simple script that does it automatically for me. When I create a new AppVM I send the script to it and run it with ./configure.sh and then it’s done.

1 Like
11

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
12

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?

13

Yeah I understand what you describe. Interesting, but kinda outside of the workflow I am seeking for.

14

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?

15

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
16

@tanky0u Yep that’s pretty much it in a nutshell.

1 Like
17

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?

18

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
19

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
20

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