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?
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.
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.
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.
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.)
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.
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?
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?
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.