Trying to minimize the CPU+RAM usage of minimal templates, I’m wondering why Xorg is needed.
Is it only to be able to conveniently run xterms and to use the colored windows decorations ?
I’m thinking about a SSH-like mechanism using qubes-rpc / qrexec commands.
I’ve tried qrexec-client -d sys-net user:bash and I get a terminal, but for example top won’t work (I get TERM environment is not set).
Note: for now I’m only trying to minimize the minimal templates for sys-net and sys-fw, so I don’t need fancy X output, just remote shells.
1 Like
You can try setting TERM=vt100 in your .bashrc file if TERM is not currently set, or try something like “TERM=vt100;top” as a command line to start top.
Hopefully the terminal you are currently using in dom0 will evaluate the vt100 ansi control sequences needed for displaying top. But it’s better that dom0 not be interpreting anything coming from a lesser trusted domain, just in principle.
What is wrong with starting a terminal in that AppVM and running top there? You can launch that remote terminal just as easy from dom0 as you can run your command from dom0, and that limits the risk in doing so.
It doesn’t work, but you led the path so I went env TERM=vt100 top but it also fails, with top: failed tty get … ^^
A normal terminal gets me a pts/0, but this kind gives me a ? (like all other processes btw).
I’m always up to understand/learn more, and why, but read below.
Ah good reminder, I already got the same warning about using xl console. Didn’t connect the dots !
Well, I ps aux --forest’ed this terminal and here is the result :
qrexec-fork-server (ppid 1)
\_ python3 qubes.StartApp qubes-run-terminal
\_ xterm
\_ bash
So the terminal is a bash shell running under xterm, is not a subprocess of X/Xorg, but isn’t it needing/using it nonethless ?
For example with ssh, there’s no xterm, only bash.
The context is that I’m trying to get the smallest system to run sys-net (and sys-fw afterwards).
I started using the official debian11-minimal, but Xorg is still there (the docs mention that so no surprise).
I could start from a debian netinst, but I’m not confortable enough with qubes tools to start this way ! And I still need remote control ^^
Currently in R4.1 it seems you can open the console of any VM directly - the console emulator is from a default-mgmt-dvm dispVM by default. This should be a good reminder if you are worrying about dom0 interpreting terminal contents.
If you want terminal, why not try something like python -c 'import pty;pty.spawn("bash")'? (Do you know the difference between pipe, socket, tty, and normal files?) By the way I find that most problems we are asking in Qubes forum is about something that is generic in linux, and this is unavoidable 
Considering the security boundary, if you have a sys-gui, actually you can be more efficient by opening the shell in sys-gui - you won’t need the dispVM.
sys-net need NetworkManager to show icon for you to select the network; in R4.1 when you are qubes-dom0-updateing, sys-firewall xterm is popped to show you the progress. When you are removing the Xorg dependency, make sure to take them into consideration.
Yep, I’m on R4.1 and qvm-console-dispvm works (this was the suggestion on my linked post aout xl console).
Didn’t know that possibility ^^ That worked both ways (minor change, used python3 as it’s not aliased to python OOTB) :
qrexec-client -d sys-net user:bashthenpython3 -c 'import pty;pty.spawn("bash")'- but this is easier
qrexec-client -d sys-net user:"python3 -c 'import pty;pty.spawn(\"bash\")'"
Kinda, as they cover different use cases, but TBH not completely “under the hood”. If you have good documentation to point me to, I’ll happily read it !
I’ve not read enough about sys-gui yet, but you mean that’s always better to NOT run things from dom0 ? And noob question, even from sys-gui, isn’t it safer to nonetheless use a dispVM ?
But I don’t need it ^^ /etc/network/interfaces is enough, no ? I’ll be using separate template+dispvm for each sys-net and sys-fw.
I’ve seen that, nice warning as I again didn’t connect the dots, more to test then ! ^^
This is a bit offtopic, but as you launched me ^^. Hidden so no one is scared by the length !
I agree, but there is a difference between doing things, doing them securely, and doing them in Qubes ! IT (life ? ^^) is way easier without security in mind.
I also think Qubes www/forum is a great ressource to learn how to do secure computing, and can be a good publicity for the project.
The biggest problem for Qubes noobs like me, is to grasp Qubes paradigms ! I’m coming from vanilla Xen, no libvirt, so there are many commands and procedures to learn.
I think there should be a document showing “how you did it before” and “how you should do it now”. I’m also thinking about a doc explaining the differences in doing things between usual hypervisors and Qubes. It could help ppl coming from vanilla Xen or KVM, XCP-ng, proxmox, virtualbox, vmware, etc.
Maybe I should start them, leaving the gaps open for Qubes specialists to fill ?
Anyways, thanks guys for the help and information !