Persistent, autostart docker in AppVM script

Community Guides
1

I have a script. It does stuff.

  1. Copies my default AppVM to a create a new AppVM, sets sys-whonix as a temporary netVM
  2. Launches a terminal where i can drop a docker-compose.yml and start the container once to fetch it
  3. Makes the container persistent
  4. Creates stuff to autostart the container when the AppVM starts.
  5. Sets the production netvm to none

Here is the code, maybe it is of some use to others:

#!/bin/bash
# This script creates a new docker AppVM
#
# Usage <name>
#
# Parameter
#       <name> the name of the new Docker AppVM

DOCKER_BASE_SOURCE="debian-11-app"
DOCKER_COLOR="gray"
DOCKER_INSTALL_NETVM="sys-whonix"
DOCKER_PRODUCTION_NETVM="none"
TERMINAL_COMMAND="\"gnome-terminal --wait\""

# Clone the source
qvm-clone $DOCKER_BASE_SOURCE $1

# Set netvm for installation
qvm-prefs --set $1 netvm $DOCKER_INSTALL_NETVM

# Remove the dispvm-template flag if it is enabled
qvm-prefs --set $1 template_for_dispvms False

# Make /var/lib/docker persistant
qvm-run -p -u root $1 'mkdir -p /rw/config/qubes-bind-dirs.d'
qvm-run -p -u root $1 'echo "binds+=( /var/lib/docker ) " >> /rw/config/qubes-bind-dirs.d/>

# Enable docker service on startup
qvm-run -p $1 'echo "sudo systemctl start docker" >> ~/.profile'

# Restart
qvm-shutdown --wait $1

# Open Terminal, so user can install stuff
qvm-run -p $1 "gnome-terminal --wait"


# User is done with installing, we can change the netvm to whatever she wants
qvm-prefs --set $1 netvm $DOCKER_PRODUCTION_NETVM

This needs to be run in dom0.
This does not install docker! It only automates the steps described above, so you need to have docker (and docker-compose if you want that) installed in your template.

4 Likes
2

Thanks, can I install like Tor browser to this docker image, then go out through whonix ?

3

I have never tried this. Theoretically this should be possible, but Tor-over-Tor is absolutely not recommended. It will create Tor circuits through Tor and nobody really knows what happens then.

Or do you mean like whonix-ws actually working as intended with sys-whonix? If so: Im sure somebody can and knows how to, but that is not me. I just use the whonix-ws tor browser and sometimes test stuff in the native TBB linux package with sys-firewall as the netvm for those qubes.

I use this script to create my docker qubes that for example hold paperless-ng, drawio and stuff like that. It only automates the Steps outlined in the first post.

4

Yeah I know about (TOR over TOR), many augments about this topic.
I am having bigger issue right now I am trying to address with all my HVM’s not connecting before I look into this “docker” image but thanks bro…

5

I wonder if this could be useful in a lightweight localhost Continuous Integration environment too — doing all this: Creating a new App VM, cloning a Git repo from GitHub, starting a build & run-all-tests script.

A bit later, the human (who uses that computer) could have a look to see if the build went well. Or the dom0 script could even copy an API secret into the AppVM so, after the build had completed, the AppVM could ping some external service and tell it “Build failed / OK”. Or the AppVM could pop up a notification icon in QubesOS for the human to see.

6

Definitively!

For a corporate environment, with multiple users on qubes it is possible to use AdminVMs so not all devs need to have access to the holy grail of dom0.

Also writing a small qrexec server on an AppVM or even disposable could work very well for this use case.

Maybe i will write a script/qrexec service, as this is very closely related to my backup restore process (getting configurations and other goodies to my AppVMs from a dedicated “seed” qube over git).

7

@Suspicious_Actions Wow, this is lovely :- )   I mean, the AdminVMs. Looks like more than what I could have dreamed of. Will take long before I have time to dive into that, but looks like the best way I can think of, to setup a CI env & such things. (Assuming one wants to be able to run the CI things on localhost.)

so not all devs need to have access

I’d use this in single user mode, still, nice to mostly be able to avoid doing things in dom0. Hmm, I wonder if one day there’ll be a QubesOS server distro, with shared VMs, thin clients, maybe shared CI VMs like you indicated. — Or you had in mind desktops-located-in-the-office-building, shared by many devs?

Maybe i will write a script/qrexec service, as this is very closely related to my backup restore process

That sounds interesting. Hmm, aha, you mean that setting up a CI env, is sort of “restoring” a saved clean slate CI env into a new VM?

8

Pretty much what i thought! It is quite powerful, but does not offer enough granularity for the thing i am working on, without some workarounds.

If you want to play with AdminVMs and the API, best start here. I wasted so much time…

Yup, QubesAir. The last big step towards that came with the gui-vm in 4.1.

If you don’t need gui stuff you can do that now, but some parts are still missing like the operator API for some more advanced and granular policing.

I meant my ~/.config and any other user space modification i use, so i can sync my many VMs to be the same.

9

Something wrong with the script: line 26 is

qvm-run -p -u root $1 'echo "binds+=( /var/lib/docker ) " >> /rw/config/qubes-bind-dirs.d/>

but it is obvious that is should not end like this. The last character in the row should be ', but what should be instead of the “>” in the end? I tools like script was coppied incorrectly…

10

Ok, according to manual https://www.qubes-os.org/doc/bind-dirs/ the string should look like this:

qvm-run -p -u root $1 'echo "binds+=( /var/lib/docker ) " >> /rw/config/qubes-bind-dirs.d/50_user.conf'

Also I have noticed that in the script the variable TERMINAL_COMMAND is defined, but never used. You have written command “gnome-terminal --wait” directly into code (in line
36).

also, I get error:

qvm-prefs: error: no such property: 'template_for_dispvms'
1 Like