Awesome Things: scp ProxyJump

Dies ist ein Artikel aus der "Awesome Things" Serie, in der ich kleine tolle Dinge festhalte.

Heute: scp -o 'ProxyJump'

Damit kann man Daten über einen Server verschieben, der lediglich als Proxy dient.

Beispiel: scp -o 'ProxyJump user@some.serverB' root@some.ServerA:/some/remote/directory/some.file /some/local/direcroty/.

Das Charmante daran ist, dass:

  • a) der Client und der Zielserver sich netzwerktechnisch nicht in der Lage sein müssen sich zu sehen
  • b) die Daten nicht auf dem Proxy zwischengespeichert werden und somit dessen Dateisystem nicht zumüllen


Integration of collabora online on a Nextcloud behind NAT on a KVM hypervisor

This one had me struggle quite a bit.
I felt like this is something that cannot possibly be super hard to setup.
Before running Nextcloud in a VM I remember the setup to be quite trivial.

And once again it has proven to be true that there are only three networking issues. DNS DNS and DNS. But lets take a step back.

I am running a Nextcloud for my family and wanted to integrate collabora.

This is the How-To I used: https://www.linuxbabe.com/cloud-storage/integrate-collabora-online-server-nextcloud-ubuntu-16-04

Collabora, much like Google Docs or Office365, enables you to edit documents online in your browser. Collabora is a child of Libreoffice Online. The Idea is to still perform well even if 20 people or more are working on a document simultaneously.

The average collabora installation guide is using the collabora\code docker container. It expect you to run it in a "classical" nextcloud setup in wich the Apache or Nginx Server is run on the Aplication Layer of the Host Operating System of the Server.

In such a setup the docker container is running in the kernelspace of the host machine that is hooked up to the internet.

If we now add a layer of virtualisation things become a little more tricky.

The docker container is still running in the same kernelspace as the nextcloud instance. However the NAT is having some effects on the DNS resolution.

The docker container gets run using the hostname for the subdomain that will be used by the webserver for the rewrite rules interacting with the docker container.

sudo docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloud\\.your-domain\\.com' --restart always --cap-add MKNOD collabora/code

If we run this setup without nat, the docker container can resolve nextcloud.your-domain.com to 127.0.0.1.

Then the container can speak to the nextcloud using the loopback interface.
Behind a nat, this is not working.

A simple change does the trick.
We will have to edit the hosts file inside the docker conainer.

EDIT: Docker has a parameter to perform this task (since version 17) called --add-host. Using this option your changes wont be lost if the container restarts (e.g. if the host reboots). Lets say the IP of your Nextcloud behind the NAT is 192.168.122.10. Then you will have to start the container like this:

sudo docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloud\\.your-domain\\.com' --restart always --cap-add MKNOD --add-host=nextcloud.your-domain.com:192.168.122.10 --add-host=office.your-domain.com:192.168.122.10 collabora/code

General container debugging

EDIT: I will leave this bit in for general purpose docker container debugging.

Check docker ps -a to find the name the collabora docker container has been assigned. Then start a shell inside the container using docker exec -i -t <ContainerName> /bin/bash.

There we edit the /etc/hosts file and add two lines.
One for office.your-domain.com and one for nextcloud.your-domain.com. It worked best for me using the IP address of the virtual machine.

Beeing lazy I did run apt update and apt install vi to have an editor inside of the container. You could also just echo it into the hosts file.

Afterwards you also need to edit the /etc/hosts file of the VM.
To be able to properly communicate with the container I had to have office.your-domain.com resolve to 127.0.0.1 rather then my public IP.

Cheers,
Ori


Integration von Collabora Online auf einer Nextcloud hinter NAT auf KVM

Ich habe mir an diesem Thema etwas die Zähne ausgebissen.
Das kann doch nicht so schwer sein dachte ich mir.
Bevor ich Nextcloud virtualisiert habe erinnere ich daran, dass das Setup relativ trivial war.

Ich bin nach folgender Anleitung vorgegangen: https://www.linuxbabe.com/cloud-storage/integrate-collabora-online-server-nextcloud-ubuntu-16-04

Und wieder stellte sich heraus, es gibt nur drei Probleme im Netzwerk.
DNS, DNS und DNS. Aber treten wir einen Schritt zurück.

Ich betreibe eine Nextcloud für meine Familie und wollte dort Collabora Einrichten.

Collabora ermöglicht es, ähnlich wie Google Docs oder Office365, Dokumente online im Browser zu editieren. Vater des Kindes ist Libreoffice Online. Collabora hat zum Ziel auch dann noch gut zu performen, wenn es mehr als 20 Personen Zeitgleich nutzen.

Die standart Collabora Installationsanleitung ist darauf ausgelegt, dass Collabora als Docker Container läuft. Es wird von einem "Klassischen" Nextcloud setup ausgegangen, bei dem der Apache oder Nginx Webserver "Bare Metal" also direkt in der Anwendungsschicht des Hostbetriebssytems läuft.

Bei so einem Setup würde der Docker Container dann im Kernelspace des Hosts laufen.

Wenn wir jetzt allerdings eine Virtualisierungsschicht hinzufügen wird das ganze etwas komplexer.

Es läuft zwar noch immer der Docker Container im gleichen Kernelspace wie die Nextcloud Instanz, allerdings hat das NAT besondere Auswirkungen auf die DNS Auflösung.

Der Container wird mit dem Hostname der Subdomain für die Collabora Instanz gestartet.

sudo docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloud\\.your-domain\\.com' --restart always --cap-add MKNOD collabora/code

Wenn wir dies im Setup ohne NAT ausführen, kann der Docker Container nextcloud.your-domain.com zu 127.0.0.1 auflösen.

Dann kann der Container über die Loopbackaddresse mit der Nextcloud Instanz sprechen. Hinter dem NAT kann er dies allerdings nicht umsetzen.

Eine mögliche Lösung ist es, die Hosts Datei des Docker Containers um eine statische IP Addresse zu erweitern.

EDIT: Docker bietet (seit Version 17) eine Funktion an um dies zu erledigen. Sie nennt sich --add-host. So gehen die Einstellungen auch bei Neustart des Containers (z.b. durch Neustart des Hosts) nicht verloren. Sagen wir die IP eurer Nextcloud hinter dem NAT ist 192.168.122.10. Somit müsst ihr den Container folgendermaßen starten:

sudo docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloud\\.your-domain\\.com' --restart always --cap-add MKNOD --add-host=nextcloud.your-domain.com:192.168.122.10 --add-host=office.your-domain.com:192.168.122.10 collabora/code

Generelles Container-debugging

EDIT: Ich lasse diesen Teil mal als generellen Container Debugging Teil in dem Artikel.

Geht auf die Maschine mit dem Docker Container und startet eine bash innerhalb des Containers.

Mit docker ps -a schauen wir uns an, welchen Namen der Container hat.
Anschließend starten wir mit docker exec -i -t <ContainerName> /bin/bash innerhalb des Containers eine shell. Dort editieren wir dann die /etc/hosts datei. Tragt office.your-domain.com und nextcloud.your-domain.com jeweils die IP Adresse der Virtuellen Maschine ein.

Ich habe mir der faulheit halber einfach mit apt update und apt install vi einen Texteditor hierzu im Container nachinstalliert. Ihr könnt es natürlich auch rein echoen.

Anschließend solltet Ihr noch die /etc/hosts datei der VM editieren.
Damit Ihr direkt mit dem Container sprecht, solltet Ihr office.your-domain.com direkt gegen 127.0.0.1 auflösen lassen.

Dann klappts auch mit den Nachbarn.

Cheers,
Ori


Setup Grafana on Ubuntu 18.04 with LetsEncrypt

In this article I will show you how to get the data visualisation solution Grafana to work with clean HTTPS on Ubuntu 18.04.
As alwaysI recommend not running the service natively on your server but rather to run it in a VM.

See: virtualization with KVM

Installation

Simply follow along the instructions of the  official guide on the Grafana website.

LetsEncrypt

To secure our webserver with valid SSL certificates we generate an certificate using LetsEncrypt
Ubuntu comes with certbot installed nativley.

sudo certbot certonly -d your.website

Write down the fullchain.pem and privkey.pem path.
You will later put that into the grafana.ini configuration file.

Before we do that, we have to make sure grafana can access these certificates.
To do that we create a new group.

sudo groupadd sslcerts

/etc/letsencrypt is owned by the user root and the group root.
We will change the group ownership recursivley to sslcerts.

user chown -R root:sslcerts /etc/letsencrypt/

Now we will add the user grafana (added when installing grafana) to this grop.

sudo usermod -G sslcerts -a grafana

Now we will have to adjust the permissions of /etc/letsencrypt/live and /etc/letsencrypt/archive

sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

Editing the configfile /etc/grafana/grafana.ini

You will have to change the following lines:

30 [server]
31 # Protocol (http, https, socket)
32 protocol = https

37 # The http port to use
38 http_port = 443

40 # The public facing domain name used to access grafana from a browser
41 domain = your.grafana.url

47 # The full public facing url you use in browser, used for redirects and emails
48 # If you use reverse proxy and sub path specify full url (with sub path)
49 root_url = https://your.grafana.url

60 # https certs & key file
61 cert_file = /etc/letsencrypt/live/your.grafana.url/fullchain.pem
62 cert_key = /etc/letsencrypt/live/your.grafana.url/privkey.pem

Empowering Grafana to bind 443

The grafana service is not running as root.
This is why in the default configuration a ein highport is beeing used for the webserver.

But we want to use 443...

To do this without granting grafana super user, we explicitly allow it to bind ports below 1024 using setcap.
sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/grafana-server

Further read:
https://wiki.apache.org/httpd/NonRootPortBinding
https://wiki.archlinux.org/index.php/Capabilities

Now, finally, restart the grafana service.

sudo systemctl restart grafana-server.service

If you have done everything right, a clean HTTPS should be greeting you.
If it does not work, a look into the logfile can be quite helpful.

sudo tail -f /var/log/grafana/grafana.log

At this webinterface you can now login using admin admin.
You will be asked to change that password on the first login.

Now you can carry on using this guid: https://grafana.com/docs/guides/getting_started/

Cheers,
Ori


Grafana auf Ubuntu 18.04 mit LetsEncrypt einrichten

In diesem Artikel möchte ich kurz darauf eingehen, wie man die Datenvisualisierungslösung Grafana mit sauberem HTTPS auf Ubuntu 18.04 aufsetzen kann.
Ich würde euch wie immer empfehlen Dienste nicht Nativ auf einem Server laufen zu lassen sondern zu Virtualisieren.

Siehe: Virtualisieren mit KVM

Installation

Wir gehen einfach nach der Offiziellen Anleitung auf der Grafana Website vor.

LetsEncrypt

Um unsere Seite mit einem Validen SSL Zertifikat laufen zu lassen, generieren wir ein Zertifikat mit LetsEncrypt.
Certbot ist bei ubuntu 18.04 bereits vorinstalliert.

sudo certbot certonly -d your.website

Die Pfade der fullchain.pem und privkey.pem solltet Ihr euch merken.
Diese tragen wir gleich in die grafana.ini ein.

Zunächst müssen wir aber noch dafür sorgen, dass Grafana auf die Zertifikate zugreifen kann.
Dazu erstellen wir zunächst eine neue Gruppe.

sudo groupadd sslcerts

/etc/letsencrypt gehört dem user root und der gruppe root.
Wir ändern jetzt die Gruppe von /etc/letsencrypt rekursiv auf sslcerts.

user chown -R root:sslcerts /etc/letsencrypt/

Anschließend fürgen wir den Benutzer grafana (wird bei der Grafana Installation angelegt) dieser Gruppe hinzu.

sudo usermod -G sslcerts -a grafana

Jetzt müssen wir noch die Permissions auf /etc/letsencrypt/live und /etc/letsencrypt/archive anpassen.

sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

Anpassung der /etc/grafana/grafana.ini

In der Grafa Konfigurationsdatei müsst ihr nun folgende Zeilen anpassen:

30 [server]
31 # Protocol (http, https, socket)
32 protocol = https

37 # The http port to use
38 http_port = 443

40 # The public facing domain name used to access grafana from a browser
41 domain = your.grafana.url

47 # The full public facing url you use in browser, used for redirects and emails
48 # If you use reverse proxy and sub path specify full url (with sub path)
49 root_url = https://your.grafana.url

60 # https certs & key file
61 cert_file = /etc/letsencrypt/live/your.grafana.url/fullchain.pem
62 cert_key = /etc/letsencrypt/live/your.grafana.url/privkey.pem

Grafana die Möglichkeit geben 443 zu binden

Der Grafana Dienst wird nicht als root ausgeführt, darum wird in der defaultconfig auch ein highport verwendet.
Wir wollen aber 443 nutzen...

Daher erlauben wir grafana explizit, dass es das darf mit setcap.
sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/grafana-server

Siehe:
https://wiki.apache.org/httpd/NonRootPortBinding
https://wiki.archlinux.org/index.php/Capabilities

Startet anschließend den Grafana dienst neu.

sudo systemctl restart grafana-server.service

Wenn Ihr alles richtig gemacht habt, sollte euch ein sauberes HTTPS begrüßen.
Falls nein, hilft es sich das log anzusehen.

sudo tail -f /var/log/grafana/grafana.log

An dieser Weboberfläche solltet Ihr euch jetzt mit admin admin einloggen können.
Ihr werdet daraufhin aufgefordert das Passwort zu ändern.

Jetzt könnt Ihr mit diesem Guide weitermachen: https://grafana.com/docs/guides/getting_started/

Cheers,
Ori


MaSSHandra Installation on Ubuntu 18.04 with LetsEncrypt

In this article I will describe how to get MaSSHandra running on an Ubuntu 18.04.
As alwaysI recommend not running the service natively on your server but rather to run it in a VM.

See: virtualization with KVM

Preperation

First things first.
Update your sources and install pending updates.

sudo apt update -y && sudo apt upgrade -y

Now we install the following packages:

  • Sendmail - will be used to send emails to the MaSSHandra users
  • NodeJS - will run the services
  • npm - Node packet manager, will be used to update NodeJS
  • mysql - an SQL Server, that is going to hold MaSSHandras data

sudo apt install -y sendmail nodejs npm apache2 mysql

Now we empty the npm cache and install the current version of node.

sudo npm cache clean -f
sudo npm install -g n

The command node -v should now be showing a Version above 10.0.

Clone the git repo to your home diretory.
git clone https://github.com/pablomarle/networkmaps

Now we create a few directories MaSSHandra is going to use.

sudo mkdir /etc/networkmaps/
sudo mkdir /sendmail/
sudo mkdir /sendmail/queue/
sudo mkdir /sendmail/sent/
sudo mkdir /diagrams/

SQL Database

First we are going to harden the SQL Database a bit.
Mysql comes with a script that is going to interactivley ask you a few settings to make it a bit more secure.

sudo mysql_secure_installation

Now login to mysql.

sql -u root -p

Create a database that MaSSHandra will later use to handle users.
create database users;

You can ofcourse use another database name then users if you want.
Just make sure that you use this altered name on the database import and later when configurung the config.json.

Logoff by typing

exit;

Import the sql database included in the git repo.
There are no users in there, however a bunch of tables that will handle users, passwords (binary64 with salt), diagrams and permissions.

mysql -u root -p users < ~/networkmaps/database_schema/users.sql

Now log back into mysql.
sql -u root -p

We will now create a SQL user that MaSSHandra can use to access the database.
Please change "YourMasshandraSqlPassword".
Here you can use a username of your choice that later will be put in the config.json.

CREATE USER 'masshandra'@'localhost' IDENTIFIED BY 'YourMasshandraSqlPassword';
GRANT ALL ON Users.* TO 'masshandra'@'localhost' IDENTIFIED BY 'YourMasshandraSqlPassword' WITH GRANT OPTION;

Then reload the sql permissions and exit mysql.
FLUSH PRIVILEGES;
EXIT;

LetsEncrypt

To secure our webserver with valid SSL certificates we generate an certificate using LetsEncrypt
Ubuntu comes with certbot installed nativley.

sudo certbot certonly -d your.website

MaSSHandra configuration

So far so prepearing.
Lets now head over to tweaking masshandras settings.

MaSSHandra is expecting a configuration file at /etc/networkmaps/config.json
So we copy the example config included in the git repo to that location.

sudo cp ~/networkmaps/docs/sample_config.json /etc/networkmaps/config.json

In it, change the settings marked in red:

{
"comment": "This file is expected to be in /etc/networkmaps",
"timers": {
"usertimeout": 3600,
"savediagram": 300
},
"use_ssl_socket": true,
"use_ssl": true,
"socket": {
"address": "IP OF YOUR SERVER",
"port": "3000",
"cert": "/etc/letsencrypt/live/your.website/fullchain.pem",
"key": "/etc/letsencrypt/live/your.website/privkey.pem"

},
"server":
{
"hostname": "your.website",
"port": 3000
},
"staticserver":
{
"hostname": "your.website",
"port": 443
},
"db":
{
"users":
{
"database": "users",
"host": "localhost",
"user": "masshandra",
"password": "YourMasshandraSqlPassword"
}
},
"diagrams":
{
"path": "/diagrams/"
},
"sendmail":
{
"queue": "/sendmail/queue/",
"sent": "/sendmail/sent/",
"server": "your.mailserver",
"port": 465,
"is_secured": true,
"user": "mailuser@your.mailserver",
"password": "YourMailPassword",
"from": "your.website.url <noreply@your.website.url>"
}
}

Starting the server

Now we start the services that will open a websocket on :3000 and handle the emails.

sudo node ~/networkmaps/server.js
sudo node ~/networkmaps/smtp_daemon.js

Remember that you can send the processes to the background by appending & to the command.
Leave them as they are if you want to debug.

When you now head over to your MaSSHandra instance and register a user, you sould see some logs.

Once you confirmed the Email you should be able to login and use MaSSHandra.

Cheers,
Ori


MaSSHandra Installation auf Ubuntu 18.04 mit LetsEncrypt

Stand: 05.07.2019

In diesem Artikel soll es darum gehen, wie man MaSSHandra auf einem Ubuntu 18.04 einrichtet.
Ich würde euch wie immer empfehlen Dienste nicht Nativ auf einem Server laufen zu lassen sondern zu Virtualisieren.

Siehe: Virtualisieren mit KVM

Vorbereitung

Als Erstes aktualisieren wir die Paketquellen und spielen ausstehende Updates ein.

sudo apt update -y && sudo apt upgrade -y

Anschließend installieren wir folgende Pakete:

  • Sendmail - wird zum versenden von Mails an die MaSSHandra User verwendet
  • NodeJS - Auf NodeJS laufen die Dienste
  • npm - Der Node Packet manager, werden wir benutzen um node auf die aktuelle Version zu bringen

sudo apt install -y sendmail nodejs npm apache2 mysql

Jetzt leeren wir den cache von npm und aktualisieren node.
sudo npm cache clean -f
sudo npm install -g n
sudo n stable

Der Befehl node -v sollte jetzt eine Version über 10.0 anzeigen.

Klont euch jetzt das Git Repo in euer home Verzeichnis.
git clone https://github.com/pablomarle/networkmaps

Anschließend legen wir noch ein paar Verzeichnisse an, die MaSSHandra erwartet.

sudo mkdir /etc/networkmaps/
sudo mkdir /sendmail/
sudo mkdir /sendmail/queue/
sudo mkdir /sendmail/sent/
sudo mkdir /diagrams/

LetsEncrypt

Um unsere Seite mit einem Validen SSL Zertifikat laufen zu lassen, generieren wir ein Zertifikat mit LetsEncrypt.
Certbot ist bei ubuntu 18.04 bereits vorinstalliert.

sudo certbot certonly -d your.website

MaSSHandra konfiguration

So weit so vorbereitend.
Kommen wir nun zur eigentlichen Konfiguration von MaSSHandra.

MaSSHandra erwartet eine Konfigurationsdatei unter /etc/networkmaps/config.json
Wir kopieren also die im Repo enthaltene Beispielconfig dort hin.

sudo cp ~/networkmaps/docs/sample_config.json /etc/networkmaps/config.json

Passt die in Rot markierten Parameter in der Config an:

{
"comment": "This file is expected to be in /etc/networkmaps",
"timers": {
"usertimeout": 3600,
"savediagram": 300
},
"use_ssl_socket": true,
"use_ssl": true,
"socket": {
"address": "IP OF YOUR SERVER",
"port": "3000",
"cert": "/etc/letsencrypt/live/your.website/fullchain.pem",
"key": "/etc/letsencrypt/live/your.website/privkey.pem"

},
"server":
{
"hostname": "your.website",
"port": 3000
},
"staticserver":
{
"hostname": "your.website",
"port": 443
},
"db":
{
"users":
{
"database": "users",
"host": "localhost",
"user": "masshandra",
"password": "YourMasshandraSqlPassword"
}
},
"diagrams":
{
"path": "/diagrams/"
},
"sendmail":
{
"queue": "/sendmail/queue/",
"sent": "/sendmail/sent/",
"server": "your.mailserver",
"port": 465,
"is_secured": true,
"user": "mailuser@your.mailserver",
"password": "YourMailPassword",
"from": "your.website.url <noreply@your.website.url>"
}
}

Server Starten

Jetzt starten wir den Server, der einen Websocket auf :3000 aufmacht und den smtp dienst.
sudo node ~/networkmaps/server.js
sudo node ~/networkmaps/smtp_daemon.js

Ihr könnt den Dienst in den Hintergrund schicken, wenn Ihr ein & an den Befehl hängt.
Für das Debugging solltet ihr den Dienst aber erstmal im Vordergrund laufen lassen.

Wenn Ihr jetzt auf eurer MaSSHandra Instanz einen User registriert, solltet Ihr einiges an Logging sehen.

Once you confirmed the Email you should be able to login and use MaSSHandra.

Cheers,
Ori


MaSSHandra

In this article I want to tell you about the 3D network diagram editor MaSSHandra.
Its origins are a software project that was cancelled in 2016 by the same name.

Version 2.3 of MaSSHandra was a standalone application for Windows, Linux and Mac.
A commercial license was at 20€, the software was free for private users.

Amongst other features it came with SNMP autodiscovery, access to devices via SSH, RDP and was packed with 3D models.

The new project is also called MaSSHandra and it is web based.
It relies on NodeJS und ThreeJS, which means it will natively run in modern browsers.
ThreeJS is using WebGL, a way to let your browser access parts of your GPU directly.
Very impressive tech.

The MaSSHandra source code is on github under MIT license.

The project itself is still in its early days but is showing a lot of potential if you ask me.
If you think so as well, please donate a coffee to Pablo, the developer of MaSSHandra here.
Or help further developing the software.

In upcomming articles I will show you how to get your own MaSSHandra instnace up and running.

Cheers,
Ori


MaSSHandra

In diesem Artikel möchte ich euch den 3D Editor für Netzwerkdiagramme MaSSHandra vorstellen.
Hervorgegangen ist er aus dem 2016 eingestellten Projekt mit dem selben Namen.

In der Version 2.3 war MaSSHandra eine standalone Anwendung für Windows, Linux und Mac.
Eine kommerzielle Lizenz kostete 20€, für privatanwender war es kostenlos.

Die Software ermöglichte es SNMP autodiscovery, Zugang zu Geräten via SSH, RDP und kam mit einer Fülle an 3D modellen und vielem mehr daher.

Das aktuelle Projekt nennt sich auch MaSSHandra und ist webbasiert.
Es setzt auf NodeJS und ThreeJS, was bedeutet, dass es nativ von allen aktuellen Browsern unterstützt wird.
ThreeJS verwendet WebGL, welches es dem Browser erlaubt direkt auf Teile der GPU zuzugreifen.
Sehr beeindruckende Tech.

Der MaSSHandra source code steht unter MIT license auf github.

Das Projekt ist noch in seinen Anfängen, hat aber aus meiner Sicht viel potential.
Wenn Ihr das auch so seht, spendiert doch dem Entwickler Pablo ein Kaffee oder macht bei der Entwicklung der Software mit.

MaSSHandra Website

In kommenden Artikeln werde ich darauf eingehen, wie man selbst eine MaSSHandra Instanz aufsetzen kann.

Cheers,
Ori


KVM - resize qcow2

To resize the qcow2 image of a KVM Virtual Machine there is an easy command line tool.
First shut down the VM and check where the qcow image is located.

Using the virt-manager go to view > details > highlight the hard drive > source path

On the comand line you can check virsh edit <VM NAME> to open the XML descriptor file where the qcow is located.

Now you can resize it using the following command.

qemu-img resize path_to_.qcow +??G

In my case this would be:

sudo qemu-img resize /var/lib/uvtool/libvirt/images/vm_haproxy.qcow +20G

If you now start the vm, you can take a look at df -h to find that it worked.
Also it should be quite clear in the Monitoring, in case you monitor the vm.

Cheers,
Ori