What I am trying to do is a sanity check between vanilla Salt and the QubesOS implementation. I have tried to go through the Qubes management section of the docs, as well as the Beginners Guide, @unman notes, several great projects and all links I can find and still have not directly found my answer. I think I have answered my consternation, so here goes.
From what I have found vanilla Salt seams to allow for running state.highstate confined to individual environments by issuing salt ‘*’ state.highstate saltenv= however using qubesctl in place of salt returns different results bellow a begining snipopet:
sudo qubesctl ‘*’ state.highstate saltenv=user
local:
:
'’ is not available.
acl.delfacl:
Remove specific FACL from the specified file(s)
CLI Examples:
salt '*' acl.delfacl user myuser /tmp/house/kitchen
salt '*' acl.delfacl default:group mygroup /tmp/house/kitchen
salt '*' acl.delfacl d:u myuser /tmp/house/kitchen
salt '*' acl.delfacl g myuser /tmp/house/kitchen /tmp/house/livingroom
salt '*' acl.delfacl user myuser /tmp/house/kitchen recursive=True
acl.getfacl:
With more digging AI says the ‘*’ is not implemented for qubesctl, thereby requiring explicit –targets= instead. Bigger issue seems to be just issuing any sudo qubesctl state.highstate saltenv=user command without explicit states seems toleave the environment broken with subsequent sudo qubes top.enabled returning:
sudo qubesctl top.enabled
[CRITICAL] Specified ext_pillar interface qvm_features is unavailable
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
[CRITICAL] Specified ext_pillar interface qvm_tags is unavailable
‘top.enabled’ is not available.
DOM0 configuration failed, not continuing
No offense taken, i did review the man pages as well as all the Qubes specific info I could find as well as the Salt docs but couldnt find a direct answer. Because I was getting what I consider strange resuls I wanted to ask before trying to submit a bug since I dont feel I am versed enough to know if what I am seeing is a bug. From what I little experience I have, vanilla Salt allows for one command state for a environment (state.highstate) however, understanding that Qbes is its own beast and that Qubes has specific differences both in architecture (instead of master/minion, minion/minion) and Qubesctl which is stated as being used directly as replacing the salt command I wanted to reach out. The sudo qubesctl –all state.apply works as I would expect as do other modifiers.
Salt is powerful and there are good resources I know they are working on. Mostly just trying to see if I am just missing something obvious.
Thanks for the confirmation of my feelings, all the “config” tools seem similar in this regard. I personally like Salt the most and since it is the “native “ QubesOS tool see no reason to use other. I try to keep my own limited knowledge in mind and wish to provide any input even if from a different perspective of a non developer/technology generalist more network centric user that has broad knowledge and usage experience however not very deep. I think there is a place for this perspective to contribute.
Most of my issues with Salt, were caused by me, trying to be clever. Apart from the fact that I am not, avoiding complex jinja templating, avoiding doing things not like they are supposed to be done, splitting things across files helped me to fix those issues.
Here, the fact that you want to separate the environments doesn’t help.
What I seem to have found is this is more of a issue with me not really following the recommendations. I have to run a longer command or split up minions but it runs. My effort is more to just confirm the behavior is expected. Salt explicitly allows for choosing the enviroment and highstate. IIt seems to be more with the qubsctl wrapper and how it parses the top file merge or it is not including a feature of salt-call or salt command even though it is documented as being used everywhere salt is used.
Again this is not a complaint, only my limited knowlege of salt and qubes showing.
I appreciate this and think I found the root problem which is my understanding of Salt (which I was guessing was the case) and I think may help you as well as most others. By using Claude I was able to focus my thoughts and here is the basic issue. I was looking at the enviroment aspect of Salt as determining minions like many other config tools like ansible, where it is only file placement. Meaning it determins which top files are used not minions unless the top file is doing it. Further, I was misunderstanding that the command state.highstate was applying to all minions vs applying to all top files that have been enabled and merged. The state.highstate modifiers like –all. –templates, –vm constrict or expand the targeted minions that state.high state applies to, the top file is what directly determine the minions. So in snswering my own title of this post, sudo qubesctl state.apply uses what ever top.sls file or files are in user_salt merged using top.enable into a single list of states that are then applied. Where as I processed a result of showing nothing from minions not referenced in the top merger as simply nor affecting all the other minions it was actually not touching them. I was thinking I needed a modifier like ‘*’ or -all vs these expand the targets to run the user_salt states files against. So the saltenv=user is referensing dom0 and user like spaces for templates or vm’s, it is referencing file storage spaces.
I think this may be where you find difficulty and where I think the documents could clarify, further if I am not mistaken qubesctl is actually a wrapper for salt-call not salt, this is a master vs minion difference. (It turned out I was mistaken and I think it was a conflict I read somewhere, big reason why having one accurate and consise place to reference helps)