So are these Linux commands here also applicable in Qubes then?
Source:
Many problems that people have in Qubes are actually not Qubes specific.
This is one of those.
The only Qubes specific part here is that you have to do this in dom0.
I dont underestimate how intimidating it can be for someone coming fresh
to Linux and Qubes. That is why I tend to emphasise the importance of
not going to far from the Qubes defaults for most new users.
1 Like
My Threat Model right now requires me to go beyond the defaults
No offense but I wouldnât even be using Qubes if I wasnât placed in a situation forcing me to âŚ
⌠and my mom isnât too thrilled either but at least I can try to do the difficult stuff where all she has to do is learn how to use the GUI to prompt USB and network auth and keep her qubes activities segregated along with the external hard drive that will save/store data backups
Donât get me wrong I am thankful this option to use QubesOS exists, but it isnât how I prefer to live unless forced to do so and now I am forced. I spent a whole decade being spoiled on MacOS, I am already crying inside that my new laptop doesnât turn on when I lift the lid lol oh well new way of life I guess
By the way, i think uman gave some good tips on changing disk passwords on this thread for changing disk passwords:
1 Like
Also FYI
Source: [from a chat platform that cannot be linked to sorry just screenshots there is no public links for that chat app platform]
/usr/local is similar to your home directory in that each VM gets their own copy of it. So if you add a file like /usr/local/bin/really-cool-script to a template VM, none of the AppVMs based on in will get it. On the other hand, adding /usr/local/bin/really-cool-script within an AppVM will keep that script there even after a reboot.
2 Likes
If you want stuff in your template to show up in /usr/local/bin then put it in /usr/local.orig/bin on the template.
The difficulty is that /usr/local.orig/bin on the template gets copied once to /usr/local/bin on the AppVM when the AppVM is created, so you canât just alter the template and expect the AppVM to have it the next time you run it. (And this applies to AppVMs that are Disposable templates, too.) Thatâs fairly easy to fix, though; go into /usr/local/bin on your AppVM and copy the new/changed file(s) out of /usr/local.orig/bin. (That directory always matches whatâs currently on the template, as of the time the AppVM started up.)
I deal with this a LOT because Iâve written a LOT of scripts and a few executables, and I donât want to put them in /usr/bin where they get lost amongst the thousands of ârealâ system scripts and executables. In my case I can usually just regenerate the AppVM (most of mine are disposable templates, so I donât lose data), but there are a few ârealâ AppVMs with data on them so I have to do that copy. (In fact, I think I might just work on a way to automate that.)
2 Likes
I will try to remember this, thank you for the tip!
So this syntax literally has a dot in itâs path directory? Just trying to make sure I get this correct if I try it
Thanks btw (and a script would be really cool)
btw I never did find any conclusive answers on the web for LUKS2 risk of wiping everything out or not, my best guess is it will (based on the very vaguely worded warning on Red Hat)
Do yall know?
yes, it has a dot in the path!
The script I was thinking of was one that would be run on the AppVM once the template is created, to simply copy everything in local.orig to local. Iâd only run it on âregularâ AppVMs, not Dvm templates (which I will simply regenerate anyway, and that causes the copy to happen). This would end up happening in salt (in fact, thereâs a salt state to do exactly this sort of thing, no need to write a script).
But itâs a pretty simple script. Really, all you need to do is open a terminal on the AppVM and issue sudo mkdir -p /usr/local/bin (the directory might not exist yet) and then sudo cp /usr/local.orig/bin/* /usr/local/bin
1 Like
Thanks for the information!
Thank you so much! 