Hello and great work on this guide. I am not new to Qubes however I am new to Salt and thought I would run this guide to confirm on a clean Qubes 4.3.0rc4 instalation. I ran this command and it seemed to missed setting permissions where I could list files or browse via Thunar. Is there a recommended permissions to apply?
To move past I applied 777 and everything works until the backup section where I have a couple of questions.
I presume that the need to create the BTRFS subvolume is not needed since it is my understanding that the pool is already on BTRFS?
The initial state init.sls makes sure that Wyng and the python libraries that are required for encryption and compression are installed in dom0, and creates the “sys-backup” service qube. We must run this state at least once before using the other states. We can run this state with:
sudo qubesctl state.sls backup saltenv=user
Running this returns:
“No matching sls found for ‘backup’ in env ‘user’”
Unless I am mistaken I don’t see a backup.sls described anywhere. I am not sure how to proceed, seems it would be some form of running init.sls?
I don’t remember if I was able to list files on Thunar when I wrote the guide. I am planning to try to run everything again and update the guide if necessary in a couple of weeks, when I install the stable version of Qubes 4.3.
If you are planning to use Wyng, I believe you still need to create a new BTRFS subvolume for /var/lib/qubes as this is not a BTRFS subvolume by default. See the instructions in 3.2 Creating a BTRFS subvolume, or on the wyng-util-qubes’s project page) for how to do this.
As described in 1.3 Targeting qubes, Salt looks at two locations when you run this command: /srv/user_salt/backup.sls and /srv/user_salt/backup/init.sls. Therefore, the error message implies that there is no file /srv/user_salt/backup/init.sls on your system.
If that is the case, the error is expected because this part of the guide presumes that the following files are already present on your system before running init.sls:
/srv/user_salt/backup/map.jinja
/srv/user_salt/backup/init.sls
/srv/user_salt/backup/configure.sls
/srv/user_salt/backup/clear-cache.sls
/srv/user_salt/backup/send.sls
/srv/user_salt/backup/receive.sls
/srv/user_salt/backup/files/wyng
/srv/user_salt/backup/files/wyng.ini
In any case, this guide is only meant as a “walk-through” example based on what I was using on my system at the time. Feel free to create your own Salt configuration for your own needs, and please check out the Appendix: Salt resources made by Qubes users for more inspiration.
Thank you for the quick reply, and I appreciate all who contribute. I intentionally tried to stay to the step-by-step before doing my own searching on the topic. I hope this points out possible points to confirm to help add to the guide pertaining to 4.3 by highlighting possible areas to confirm.
I double check the permissions and at least on my system it is needed. Of course staying secure since this is in dom0.
I looked again and while searches give different answers, I think as of 4.3rc4 the pool is still LVM, I suggest confirming since I am not familiar enough to confirm and would only need some discalimer as to not being needed only since in my opinion data seecurity is king and noobies (like my self don’t need to possible bork an install.)
I reread the areas you called out and you actually stated " If we were to uncomment those lines and run highstate, Salt would run in all targeted qubes (this is what is meant by the * character) the state locale, for which the state configuration file can either be /srv/user_salt/locale.sls or /srv/user_salt/locale/init.sls." my top.sls is:
If we were to uncomment those lines and run highstate, Salt would run in all targeted qubes (this is what is meant by the * character) the state locale, for which the state configuration file can either be /srv/user_salt/locale.sls or /srv/user_salt/locale/init.sls.
So I have both a blank /locale/init.sls and I made the /backup/init.sls as docs say.
Again great guide and I am trying to contribute if only as a guinea pig .
Having done my reading of the Appendix I am still not understanding a couple of things:
IT seems qubes.user-dirs needs to be enabled to have many commands available. With it disabled if I try yo enable I get the following:
sudo qubesctl top.enable qubes.user-dirs
[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.enable' is not available.
DOM0 configuration failed, not continuing
I have tried running
sudo qubesctl saltutil.sync_all
Doesn’t help
Not sure how to get it re-enabled.
When it is enabled, running state.apply resets the permissions to the directories where I can’t ls or cd to the directories, I can create and edit files but it is a shot in the dark what files are there. Unless I sudo su then I can view. Anyone know if this is by Qubes design?
I can avoi this reset if I run sudo qubesctl state.sls salty saltenv=user without the reset as I would expect however I thought the point of a top file was being able to run a multitude of states. I am loath to poke around the base install at my understanding level.
I run sudo qubesctr top.enable to where my top.sls file is located in /srv/user_salt but nothing enables it.
Any help in understanding this would be greatly appreciated.
I think there is a basic misunderstanding here:
possibly on my part.
You have not said what commands you have run prior to trying to enable
this.
You should be able to run this command on a clean install without issue.
Once you have run the user-dirs state the relevant directories are
created and the configuration to use them is already in /etc/salt by
default.
You do not need to use user-dirs, nor do you need to further enable the
state prior to use.
What do you mean here?
It is be design.
You do not say what paths you have tried to use.
Look at /etc/salt/minion.d/f_defaults.conf and you will see that /srv/user_salt is defined as the file root for the user environment.
This means that if you have a state at /srv/user_salt/test/test.sls
you can reference it simple as test.test when using the user
environment.
(This is the same way that you can reference files under /srv/salt when
using the base environment.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
So to give some more context. I have tried to be very careful not to mess with the base salt install. After running the state to setup the user directories I began the Salt for beginners guide step by step. Because the visibility to the directory structure was limited I ran chmod 777 -R on /srv.
Previously the Backup chapter of the guide was working as I thought it should. But I was still not really understanding how the top files inter related. So I was trying to characterize what I saw with top.enabled.
It seemed strange to me that qubes.user-dirs was enabled with my limited understanding so I was trying to characterize the behavior because if I ran a state.highstate it would change permissions so I thought there was another top file in the “system salt” that was bringing the permissions to the expected state.
Only commands were the listed states under user.salt, top.enable, top.disable, saltutil.sync_all.
Trying to understand the syntax for the path to the top file I tried like sudo qubesctl top.enable user_salt and user_salt.top. Also /srv/user_salt/top.sls as sudo qubesctl top.enable top.
All give the same error:
sudo qubesctl top.enable qubes.user-dirs
[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.enable' is not available.
DOM0 configuration failed, not continuing
Should I try removing salt, then re-installing it and the qubes-mgmt-salt-config?
Is everything working as intended until you change the permissions? If so, perhaps you need keep the permissions and navigate/and edit the files directly from the command line
I would never change permissions on system files like this.
You have not said what you did not understand. top.enabled would not
help you to understand this.
I still do not understand why it seemed strange, but I tried to
clarify that. The configuration is already written to support the user
environment.
Which top.file? It’s generally not a good idea to try at random.
If a file is at /srv/user_salt/top.sls then you would address this simply
as topin the user environment If you create new states at /srv/user_salt/example/state.sls then you address this as example.statein the user environment
You could do this with a reinstall, but you could also simply revert
the misguided chmod, manually delete the user_* directories.
It would help if you clearly set out what problem you are trying to
solve, or what things you do not understand - perhaps in a new thread.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I did not think making the files more permissive would break something, certainly a security concern. It seemed to me that being forced to blindly opening files (I mean this as since ls was not permitted randomly trying to edit user_salt files was odd. Maybe I just dont understand how one would view the state files a user has made. Any suggestion would be helpful.)
I was trying to go step by step through the Beginners guide. For instance I was not understanding in section 3 how running sudo qubesctl state.sls backup saltenv=user would actually run the init.sls. My understanding was for a top.sls file to run it had to be enabled. Seemed to me top.enabled lists all enabled top files. What I experienced was with qubes.user-dir enabled running sudo qubesctl state.highstate would run the top file I had in my user_salt directory. I didnt see how that would happen.
It seemed strange to me at least because my understanding was nothing in the user_salt directory was configured to change permissions on the /srv directories that there must be a state file somewhere that would do this. My understanding was that a state file can be ran directly on certain targets:
sudo qubesctl --targets=fedora-38 state.sls my-custom-state will run my-custom-state targeting dom0 and fedora-38.
sudo qubesctl --skip-dom0 --targets=debian-12,untrusted state.highstate will run highstate targeting the qubes debian-12 and untrusted but not dom0.
or by having a top file but the top file would have to be enabled.
I didn’t think I was being random. I was trying to understand how salt uses the . in place of the / when targeting a top file. Without the top file enabled, my understanding was that I could run a state targeting specific states. But I was seeing my user_salt/top as created in the guide running, so was trying to figure out.
The problem I am having is to correct these errors:
sudo qubesctl top.enable qubes.user-dirs
[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.enable' is not available.
DOM0 configuration failed, not continuing
Since they seem to be system wide not just user, since now I if I run a top.enabled or other commands I get the same error.
7. A restart reset the permission, so I will try deleting the user_salt dir and re-install salt and the user-dirs.
Thank you for the thoughts and insights
The notion of “enabling top files” is specific to Qubes: it is a mechanism that can be used to merge different files into one top file automatically. I intentionally left it out of this beginner’s guide as it is not part of Salt and is not necessary to use it.
The way it is defaulted, you essentially have to do “sudo su -” to be able to do anything–even just look around–in the /srv/salt area. [Unless, of course, I am making some sort of rookie mistake out of ignorance.] It’s one thing having to do “sudo” to edit a file, it’s another thing being unable to do an ls or cd without being root.
Of course once you’ve done that. now you can stomp on file contents without meaning to.
Once I created the user area, I gave myself permissions to at least navigate the /user_* directory trees and do ls in those directories. (The files in those directories are still protected.)
Interestingly when example commands are given, “sudo” is never part of the example although you will get a not-completely-explanatory error message when you don’t.
.
