Hey @marmarek @SkypLabs,

I am looking into deploying a NetworkManager configuration file under sys-net for it to randomize macs, since QubesOS didn't choose to deploy it by default. That is based on this

I'm reading how to deploy this but didn't figured out how to do it for already configured AppVMs.

Content of the files would be /etc/NetworkManager/conf.d/randomized_macs.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=random
ethernet.cloned-mac-address=random
connection.stable-id=${CONNECTION}/${BOOT}

User can then change the mac configuration for known networks, keeping the randomized mac stable if desired.

Any idea how a salt formula would look like?

I have a hard time finding this info and your git is the most complete i've found. I have found no info on applying salt recipes to dom0, but for templates installation.

What I would love to do, for example:

• Install powertop in dom0
• activate systemd powertop service wich starts powertop --auto-tune at boot automatically?

Working on it. Will post my findings and propose a pull request with working recipes.

@SkypLabs @marmarek
QubesOS decided to not apply these trimming configuration changes by default.

The tool bc is required by the my tmux configuration file: https://github.com/SkypLabs/dotfiles/blob/df1ce9d6c10825bd44f7da3ba06b5e027c4c3583/tmux.conf#L42.

See SkypLabs/dotfiles#1 for further details.

Clone, build and deploy qubes-updates-cache so packages are downloaded only once from the network, while being installed on all cloned templates.

Hey @SkypLabs

I'm wondering if you are interested in joining forces to create additional recipes? Your project's persona mostly represents the "developer" one, but it would be interesting to develop others. And be able to deploy them remotely, if needed (organization scenario, remote support needs, etc).

This issue proposes a solution to easily deploy salt recipes in a sepearated AdminVM, in managed mode, permitting to deploy persona's needed customizations, being manageable only by that AdminVM.

The idea here would be:

• Create an additional AdminVM with SSH server in it, having networking from sys-whonix and create required policies under dom0 for this new AdminVM to be able to create and manage qubes created by it.
• Create a unique hidden onion service under sys-whonix pointing to AminVM IP:22, restart tor and export hidden onion name and it's public token to dom0 console. (or better: sys-whonix widget, showing user created hidden services in a GUI, see below)

QubesOS servers or laptop daily drivers could be remotely managed for support by a whonix-ws qube from anywhere in the world, under condition that the AdminVM is started prior to the user support request, and that the support team's sys-whonix knows the remote hidden onion domain name and it's public token, exported previously!

This way, managing AdminVM could permit remote management without jeopardizing security, run needed custom salt recipes for additional personas from a remote support team, etc.

Dom0 would need to run this base salt recipe once after a clean QubesOS install (by the support team), and the other AdminVM would be used to create all other qubes that it can manage after if the user needs it, remotely.

That would fit organization needs and user support needs, and permit different persona deployments, after default installation.

Problem and mitigation:
One problem still persists for organizational deployments though.

• One way is for the admin to visit user's owned computer (LUKS formatted computer, unlocked by user password. It cannot just be changed), and install the AdminVM recipe under the user eye's supervision.
• Another would be to deploy cryptsetup-reencrypt in dom0 in first stage install of QubesOS. Stage 1 could also set default LUKS encryption passphrase in anaconda.cfg installation file and set a default QubesOS username and password, install this AdminVM, and in stage 2, require the user to change default username and password and reencrypt LUKS with user's passphrase. (PoC needed. @marmarek, thoughts?). Librem QubesOS's OEM install disk implemented a workaround to ask for user's LUKS password to encrypt disk on stage1 and install QubesOS from there, but that solution is limited in the current proposition scope, permitting complete user's ownership of the laptop, but not permitting remote support and persona's deployments. EDIT: PoC here.

Further steps needed from QubesOS/Whonix:
@adrelanos @marmarek @vic @mfc: For organizations, it would be amazing if this hidden service, pointing to the AdminVM, could be displayed to the user in a sys-whonix widget, showing their existence and even permit the renewal of those hidden onion names (delete the hidden services directory content and restarting tor and showing hostname content would do) show their associated public token would permitting the user to see/activate/deactivate them on demand. That would greatly facilitate QubesOS deployments in organizations and facilitate user's support needs and general UX. Even give an additional opportunity to generate revenue for QubesOS or subcontractors or support freelancers, or even AccessNow helplines, who knows.