Plain text configuration Window Managers and Desktop Environments available out there:
Now lumina is a special case, it has tools to configure the desktop environment. But it saves all of that configuration in a flat text file, or in several text files available. So there is no need to use the internal tools, but it is easier using that tools. Still the configuration can be saved to a revision control system like f.e. git or RCS is.
Why to care about text file configuration WM's and DE's, and why is this good anyway?
- Text files are human readable, it is not as XML.
- It can be stored in RCS system
- It is easy to edit with the simplest editor f.e. nano or mcedit
- No hidden complexity
- Easy to restore
It does not fancy stuff without you notice it. It is simple and easy at same time. There is no black box. By the way, do you remember the last time after an update that your DE and your icons and all the profile setting got lost?
Initially I have been searching for a point-to-point IP linux TUN device connection from '''host'' to ''guest'' system. I have not been able to find a easy to use solution with QEMU. Everything was pretty complicated dealed with creating additional interfaces and was no easy to use even for the average and professional user. But there is a QEMU guest to host connection possiblity via loopback interface solution dealing with redirecting TCP/UDP ports from guest to host operating system. This is useful if one needs to access the guest OS HTTP server to configure an web application like f.e. cacti, nginx, mediawiki or similar application used in guest virtual machines.
The main goal of this blog entry is, redirect TCP/UDP socket from guest to host:
- using native tools
- no additional drivers or configuration on guest and host
- do not create additional interfaces on the host operating system
- do not create additional interfaces on the guest operating system
- ideally a one-liner on the host operating system
The guest operating system is running locally on the machine. However it is no problem to redirect to all host network interfaces. Using the QEMU's official documentation. First example on howto redirect a guest service to host IPv4 loopback interface (127.0.0.1) . here the HTTP service is redirected. Additional command line parameters have been skipped for brevity:
Is the TCP socket created on the host system? Verification using the ss tool. Since my blog is located in west germany and the filters used out there are weak, I need to explain the usage of ss tool more. SS - another utility to investigate sockets this tool is the successor for the deprecated netstat tool and is installed along with iproute2 utility, it is a part of it.
root@host:~# ss -tulpen | grep 1080
tcp LISTEN 0 0 127.0.0.1:1080 0.0.0.0:* users:(("qemu-system-x86",pid=16694,fd=15)) uid:1000 ino:349880 sk:eec6ca38i
Now this looks good. The TCP socket has been created on the host system. Now is the redirection working from the host system via loopback interface via the TCP socket 1080 to to the guest HTTP TCP port? Since we like to play text adventure (using CLI tools) verification occurs using the cURL tool. Does it really work?
It works!
It is working as seen from outside. What does the guest operating system see in the logging files of the webserver, grep curl:
root@guest:~# grep curl /var/log/apache2/access.log
10.0.2.2 - - [12/Oct/2020:14:22:12 +0200] "GET / HTTP/1.1" 200 45 "-" "curl/7.72.0""
So everything is working as it should. Finally how to redirect TCP or UDP sockets to all host available interfaces:
Verification successful. The service is bound to 0.0.0.0 interface, which is a wildcard on nodes stating that all local interfaces are used:
root@host:~# ss -tulpen | grep 1080
tcp LISTEN 0 0 0.0.0.0:1080 0.0.0.0:* users:(("qemu-system-x86",pid=18230,fd=16)) uid:1000 ino:361424 sk:67e1eeea
Check also the QEMU serial console port redirection blog entry written some time ago.