Allow users to configure Qusal with Pillars

[ben-grande]

Current problem (if any)

Qusal installation chooses some defaults, such as Chromium for web browsing and KDE for Dom0 DE.

Proposed solution

This can be customized with Jinja to give users the choice of choosing the default installation instructions while choosing their configuration, such as Firefox for browser and I3 for Dom0 DE.

It can also be use to install extra tools for various formulas such as emoji (fonts-noto-color-emoji) for Element and Chromium (Firefox has built-in fonts) while others may need certain accessibility tools (libatk) on multiple qubes.

Can also customize configuration, such as default font size for notifications, which can be very hard to read depending on the user monitor size. Pillars would help a lot in cases like this.

This is the bare mininum, later it can be used to specify netvm, maxmem and other qube preferences besides package installation.

The value to a user, and who that user might be

Allow the user to customize their Qusal installation with Jinja, in a declarative format, instead of specifying by running certain Salt states.

[seven-beep]

Hello @ben-grande,

Thank's you for Qusal, I started to to use it since a few months in my own repository of states and rapidly made use of some of your workflows.

I use pillars data (defaults and secrets) in my repository :
The bootstrap of the pillars.
Default pillars

There is an ignored secrets directory that handle sensitive pillar data.

You can see in the states for disposables sys-openvpn, (Line number may move ...), how I use mandatory pillar data to create the VMs, configure them, and eventually enforce firewall rules.

What do you think of this way to handle configuration / secrets via pillars ? Would you like I try to implement this in your repository, starting with openvpn ?

[ben-grande]

Hello @ben-grande,

Hello there.

Thank's you for Qusal, I started to to use it since a few months in my own repository of states and rapidly made use of some of your workflows.

That is great to hear!

I use pillars data (defaults and secrets) in my repository : The bootstrap of the pillars. Default pillars

I think it is great to see widespread Pillar usage (which Qusal lacks).

I learned now that Orgmode is an Emacs syntax. I don't know if the domains.org 8k lines are just documentation or the source files it contains are also managed by Salt.

There is an ignored secrets directory that handle sensitive pillar data.

You can see in the states for disposables sys-openvpn, (Line number may move ...), how I use mandatory pillar data to create the VMs, configure them, and eventually enforce firewall rules.

What do you think of this way to handle configuration / secrets via pillars ? Would you like I try to implement this in your repository, starting with openvpn ?

To handle configuration via pillar, I desire that, starting with small things first than standardizing across formulas, so not starting with openvpn but something smaller such as choosing the DE for Dom0.

To handle secrets, there was a discussion about Qubes Salt connector holding secrets:

• Salt Managment Inter VM Communication QubesOS/qubes-issues#1541 (comment)

On the last comment of that thread, it says it was completed, but I don't know (and didn't test) if pillar data is shared across qubes that should not have access to it.

So delaying holding secrets for later on, the implementation will start off with configuration changes.

[seven-beep]

I learned now that Orgmode is an Emacs syntax. I don't know if the domains.org 8k lines are just documentation or the source files it contains are also managed by Salt.

Yes, this is 'literate programming'. What you see are code blocks that are exported on demand into salt files, which are also version controlled. So maybe looking at the exported files would be more familiar for you ?

To handle configuration via pillar, I desire that, starting with small things first than standardizing across formulas, so not starting with openvpn but something smaller such as choosing the DE for Dom0.

What about making your dotfiles optional on pillar ? There was previous concerns about it (#17), and found my self often seeking to which file exclude from your dotfiles. You can also see a poc for that in my repo in dotfiles.org and related files.

This would have the merit to dress the files necessary to use pillars and would so eventually facilitate next operations (DE and Cie).

To handle secrets, there was a discussion about Qubes Salt connector holding secrets:
QubesOS/qubes-issues#1541 (comment)

I don't think this issue is up to date. The comment you refer date from 2016, AFAIK in 2022, @marmarek said :

for pillars, filtering is done in dom0, and the DispVM gets only pillars targeting specific VM.

[ben-grande]

I learned now that Orgmode is an Emacs syntax. I don't know if the domains.org 8k lines are just documentation or the source files it contains are also managed by Salt.

Yes, this is 'literate programming'. What you see are code blocks that are exported on demand into salt files, which are also version controlled. So maybe looking at the exported files would be more familiar for you ?

Thanks, will take a look.

To handle configuration via pillar, I desire that, starting with small things first than standardizing across formulas, so not starting with openvpn but something smaller such as choosing the DE for Dom0.

What about making your dotfiles optional on pillar ? There was previous concerns about it (#17), and found my self often seeking to which file exclude from your dotfiles. You can also see a poc for that in my repo in dotfiles.org and related files.

I understand the concerns... but some Qusal formulas depend on some dotfiles so that needs to be fixed first. I don't know them by heart. You can start with the dotfiles them.

What do you think of adding the pillar checks inside dotfiles/copy-*.sls?

This would have the merit to dress the files necessary to use pillars and would so eventually facilitate next operations (DE and Cie).

What Cie stands for in this case?

To handle secrets, there was a discussion about Qubes Salt connector holding secrets:
QubesOS/qubes-issues#1541 (comment)

I don't think this issue is up to date. The comment you refer date from 2016, AFAIK in 2022, @marmarek said :

for pillars, filtering is done in dom0, and the DispVM gets only pillars targeting specific VM.

Ok, that is good to know, that info was really really old yeah.

[seven-beep]

Thanks, will take a look.

Well don't look too deep, it is not as nice and open for others than you repo ;)

What do you think of adding the pillar checks inside dotfiles/copy-*.sls?

That seems a good entry point. See you in PR.

What Cie stands for in this case?

Sorry, it is my mother tongue. Cie means company, think about it as '... etc'.

[ben-grande]

To consider when to use pillar and jinja with lookup tables:

• Saltstack Formula Conventions
• TOFS pattern

This is not strictly pillar related but can have a great influence on how the formulas are organized and the data is queried. Many formulas use different methods, I haven't had time to see what is the best one, but TOFS seems good.

[seven-beep]

For reference, we can see the TOFS implementation of the file_switch macro in the systemd-formula.

I see value in the TOFS pattern.