Qubes Salt Beginner's Guide

Thank you for that!!!
Done under Ensure that qubes.user-dirs state actually works by DemiMarie · Pull Request #11 · QubesOS/qubes-mgmt-salt-base-config · GitHub

The fix works!

But not the salt recipe to deploy qubes-builder-v2 as reported with logs there and next reply.
Will try other qubes-builder-v2 salt deployment recipe proposed which is co-dependent on other salt recipes and is not as lean as this salt could be… When personal free time permits it.

Reported PR as fixing user salt dir under Ensure that qubes.user-dirs state actually works by DemiMarie · Pull Request #11 · QubesOS/qubes-mgmt-salt-base-config · GitHub

1 Like

As it so happens, I just tried a clean 4.2 install and did set up user dirs there. Friday and yesterday (since I had to redo the install for other reasons). I saw no problem. (I have no idea what this problem was, in fact.)

Does it work reliably when you run highstate? I found it works a third of the time without error

I’m not sure I follow pas two replies. There is a bug, and a pr to fix that bug at Ensure that qubes.user-dirs state actually works by DemiMarie · Pull Request #11 · QubesOS/qubes-mgmt-salt-base-config · GitHub.

Are you both saying you can’t replicate success nor bug with/without fix? Can you please replicate locally qubes builder v2 salt recipes with without fix and comment on both places? The more votes for fixes and bug replication, the faster it is fixed because raising attention. My salt Fu is not good enough to state where thing break, but from my traces posted one can easily see where things go wrong and what is fixed with pr. It needs replication and confirmation.

I didn’t try the fix yet, but the changes applies through salt the fix I reported to work in my original issue, aka the symbolic link required to make it work fine.

I would be surprised if @SteveC doesn’t see the issue at all, because I’ve been able to reproduce it, even two weeks ago again.

1 Like

That is also my point.

1 Like

I know that yesterday after installing 4.2, I was able to create the user_pillar, user_salt and user_formula directories with that command.

I did have to go into /srv and change ownership of the directories (recursively), then I had to soft link /srv/user_pillar/init.top into /srv/pillar/… (and I needed to do sudo su to be able to do that). If one of those is the bug in question, then there’s your answer.

1 Like

Wow. The qusal project is simply amazing to read and understand salt recipes. Will test tomorrow qusal/salt/qubes-builder/README.md at main · ben-grande/qusal · GitHub

Do not skip dom0 requirements at qusal/docs/BOOTSTRAP.md at main · ben-grande/qusal · GitHub

3 Likes

Trying to help those whostruggle with SaltStack, and have more Salt code and less visual/bash step-by-steps in the forum, I have just created an MIT License repo for the community.

It’s a didactic small and simple config files and step-by-step commands for a VM for video playback with mpv, fzf, smplayer, and vlc inspired by this forum topic.

The repo:

If it fits well, please update in the initial message.

3 Likes

Thanks a lot! I made an appendix and added a link to your repository. By the way, this topic is a wiki so anyone should feel free to edit the first post :slight_smile:

1 Like

I’m trying to use this but keep getting errors because salt/dotfiles is empty. I see that directory is a git submodule and I think it is empty because I dont have access to the git repo. Do you know where I can get default files for this?

Agreed. It is a work of art and the dev is quick to respond. Most comprehensive yet and most states work as intended out of box.

The project needs testing and bug report. Did open a lot and hope others will do the same.

hello everyone,

I’m kinde new there, and can’t proceed very far.

I’m stuck on the commands using ‘qvm-appmenus’ that ‘fail with error code: 1’

The error occurs in every codes of ‘disconnected’ ‘messaging’ and ‘vault’ the vm–create-qube part works but fails for the vm–update-app-menu function .

when I run for example ‘qvm-appmenus --update salty’ directly in terminal I have no errors

If any one know where does the problem come from thanks in advance

best regards ,
edsiot

1 Like

A very good example at The Guardian:

When security matters: working with Qubes OS at the Guardian When security matters: working with Qubes OS at the Guardian | | The Guardian

3 Likes

Hi, could you run the salt state again, with --show-output option and copy the output?

I remember having an error while trying to remove the following line:

{% set gui_user = salt['cmd.shell']('groupmems --list --group qubes') %}
1 Like

Hi, I’ve figured it out;

I’m on Qubes 4.2, don’t know if that make a difference but changed the syntax of the code; I write present directly as said by qubes doc and dont repeat the label tag, don’t know if it’s just for me but now it works, thanks;

{% if grains['id'] == 'dom0' %}

{% set gui_user = salt['cmd.shell']('groupmems --list --group qubes') %}

messaging--create-qube:
  qvm.present:
    - name: messaging
    - template: debian-12
    - label: yellow
    - features:
      - set:
        - menu-items: org.telegram.desktop.desktop org.gnome.Nautilus.desktop

messaging--update-app-menu:
  cmd.run:
    - name: qvm-appmenus --update messaging
    - runas: {{ gui_user }}
    - require:
      - qvm: messaging--create-qube

{% elif grains['id'] == 'debian-12' %}

messaging--install-apps-in-template:
  pkg.installed:
    - pkgs:
      - telegram-desktop

{% endif %}
3 Likes

That’s interesting. As I understand it, the state configuration using the state command qvm.vm,

messaging--create-qube:
  qvm.vm:
    - name: messaging
    - present:
      - template: debian-12
      - label: yellow
    - prefs:
      - label: yellow
    - features:
      - set:
        - menu-items: org.telegram.desktop.desktop org.gnome.Nautilus.desktop

is equivalent to using the qvm.present, qvm.prefs and qvm.features separately:

messaging--create-qube:
  qvm.present:
    - name: messaging
    - template: debian-12
    - label: yellow

messaging--set-prefs:
  qvm.prefs:
    - name: messaging
    - label: yellow

messaging--set-features:
  qvm.features:
    - name: messaging
    - set:
      - menu-items: org.telegram.desktop.desktop org.gnome.Nautilus.desktop

Maybe qvm.prefs or qvm.features is causing the issue.

Edit: It seems that since commit 8ed18dc to qubes-desktop-linux-common, the issue #8494 is fixed and a call to qvm-appmenus is not longer necessary to refresh the list of applications after changing it with qvm.features. In this case, the parts

{% set gui_user = salt['cmd.shell']('groupmems --list --group qubes') %}

and

  cmd.run:
    - name: qvm-appmenus --update name-of-qube
    - runas: {{ gui_user }}

can be removed from all the Salt configuration files.

Has anyone tested whether the list of applications is refreshed when omitting those parts? If so, I’ll update the guide.

I just tried this state file:

create-test-vm:
  qvm.vm:
    - name: test-appmenu
    - present:
      - template: debian-12-xfce
      - label: red
    - features:
      - set:
        - menu-items: org.xfce.mousepad-settings.desktop xarchiver.desktop

And the appmenu is refreshed (even when changing the menu-items list) so I need to update my salt states too :slight_smile:

EDIT: I think this guide is much better with this tip, thanks! Please check if I removed too much code, I hope not.

1 Like

Many thanks!