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/codeIf 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/codeGeneral 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/codeWenn 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/codeGenerelles 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
VMware: How to save lost VMs
In this post I will show you how you can save lost VMs.
Especially those that claim they cannot find thier hard drive after a firmwareupgrade.
However if you take a look at what file on the storage that hard drive points to the file is still there.
If you now disconnect the harddrive and add a "existing hard drive" you cannot select it.
What files are relevant
To address the issue we will first have to look at what files we will have to touch
- .vmdk - Pointer to the virtual hard drive
- -flat.vmdk - the actual hard drive file
- .vmx - The file describing the VM
Enable SSH
You will need to enable SSH on the hypervisor to apply the fix
Since it is just that intuitive, here a little graphic.
Setup a new VM
Create a new VM and name it what ever you want (different then the original) and give it a 10GB Harddrive with the same hardware configuration as the defect VM.
You do not want the a server that expects two network cards to boot up finding only one or be unable to start a database as it suddenly has way less RAM available.
Check how much storage is left and that a copy of the VM fits cosily into the remaining space.
(A good value to go by as proven to be 10% of the Storage should remain unused. If your storage is 10TB or more, 5% free should do.)
In this case the size of the VM is 250GB and I have about 2TB left.
Copy the hard drive
Connect to the ESXi host using SSH and navigate to the directory of your new VM.
As the storage in this example is named "Storage" the command looks like this:
cd /vmfs/volumes/Storage
Do not wonder if you prompt is showing a different path.
Storage is just a softlink pointing to the real path of the storage in the /volumes directory.
Now go ahead and delete the current -flat.vmdk of the newly created VM.
rm ./<Name der Neuen VM>-flat.vmdk
Then you copy the -flat.vmdk of the old VM into the directory of the current new one and give it the name of the -flat.vmdk you just deleted.
cp ../<NAME OF THE OLD VM>/<NAME OF THE OLD VM>-flat.vmdk ./<NAME OF THE NEW VM>-flat.vmdk
If the name of the old VM were "broken" and the name of the new VM "working" the command would look like this.
cp ../broken/broken-flat.vmdk ./working-flat.vmdk
The prompt will freeze until the copy process is complete.
This can take a while, depending on the read/write speed of the storage.
In my case it took over 1 hour to copy 250GB...
DO NOT turn on the VM once the copy process has finished.
Enlarge the Harddrive
The .vmx currently describes the connected harddive as 10GB in size.
Go to the settings of the new VM and enlarge the harddrive to the original size +10GB.
You should now be able to start the VM.
If you are starting a windows server it can take quite some time on the first bootup after the restore.
The server will start with DHCP as it detected a new unconfigured network card.
You cannot give the server the same IP it has before as there are still offline-adapters on the server blocking that IP.
To avoid unnecessary pain I suggest removing ALL network adapters from the VM and then go the to device management.
devmgmt.msc
Here you have to enable "show hidden objects".
Go ahead and deinstall all VMware networkadapters.
Next you will have to clean up the registry...
Start the registry editor.
(Windows + R -> regedit)
Delete the RegistryKeys at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\NetworkCards\
Shut down the server, add the needed network adapters and then finally start it to use it.
Cheers,
Ori
VMware: Disk verkleinern
Wenn Ihr unter VMware dynamisch erweiterbare Festplatten benutzt, wird der Speicherplatz von der VM erst genutzt, wenn er wirklich gebraucht wird.
Wenn sich jetzt Daten auf der VM angesammelt haben und sie werden von euch gelöscht, steht der Speicherplatz dem Host nicht wieder zur Verfügung.
Damit der freigeräumte Platz wieder genutzt werden kann, muss die virtuelle Festplatte geschrumpft (shirnk) werden.
Bei Windows Gastbetriebssystemen ist der Task relativ trivial, solange die VMware Tools installiert sind.
Recktsklick auf die VM > Manage > Clean Up Disks...
Wenn der Task durchgelaufen ist, kann die Festplatte in den Einstellungen erweitert werden.
Unter Linux läuft der Task ähnlich und setzt auch voraus, dass die VMware tools installiert sind.
Mit folgendem Befehl könnt Ihr euch listen lassen, welche Disk gemounted sind.
vmware-toolbox-cmd disk list
Und anschließend könnt mir mit folgendem Befehl die Festplatte shrinken.
vmware-toolbox-cmd disk shrink <DISK>
Auf dem Screenshot ist /dev/sda1 der mountpoint vom Rootverzeichnis und aktuell sind nur 11GB von 48GB in Verwendung.
(Merkt euch diesen Wert!)
Jetzt könnt Ihr wie bei der Windows VM auch über Einstellungen > Compact Disk die Disk verkleinern.
Advanced Troubleshooting
Achtung: Diese Maßnahmen können euch die VM zerschießen! Macht Backups...
Falls die Festplatte des Hostssystems schon relativ voll ist, kann das durchaus fehlschlagen.
Installiert auf der VM also gparted und startet es.
apt install gparted
Hier wählt ihr dann die zu verkleinernde Partition aus und wählt resize. Dies kann allerdings an LVM oder anderen Dingen nicht funktionieren.
Falls gparted nicht funktioniert, nutzt fdisk.
Werfen wir nochmal einen Blick auf den Output von df -h weiter oben.
Das Rootfilesystem / lieft auf dem device /dev/sda1.
Sda1 ist die erste Partition auf /dev/sda, ich will also /dev/sda verkleinern.
Startet fdisk mit dem device, das Ihr shrinken wollt.
fdisk /dev/sda
Als erstes listen wir die Partitionstabelle mit
p
Hier sehen wir, dass /dev/sda1 einen Bootflag hat, bei Sektor 2048 beginnt (wichtig! merken!), die Start und Endsektoren der Partition und dass sie 36GiB groß ist.
Wir werden die Parition jetzt löschen und neu anlegen, allerdings kürzer.
Keine Sorge, den Daten passiert nichts, solange Ihr euch merkt, wo die alte Partition begonnen hat.
Löscht die Partition also mit
d
Schauen wir uns mit p nochmal die Partitionstabelle an, ziemlich leer hier order?
Macht die neue partition nicht kleiner, als der genutzte zuvor genutzte Speicher (!)
Wir legen jetzt mit n eine neue Partition an und sagen dann mit p, dass es sich um eine primäre Partition handelt.
Da es sich wieder um die Partition 1 handeln wird und bei Sektor 2048 beginnen soll, kann ich diese beiden Werte auf default lassen.
Wenn die gelöscht Partition bei euch nicht 1 war oder nicht bei Sektor 2048 begann, passt diese Werte bitte unbedingt an!
Als nächstes definieren wir die Größe der neuen Partition.
Ich lege mit +15G fest, dass die neue Partition 15GiB Groß sein soll.
Jetzt setzen wir mit a das Bootflag auf die erste Partition.
Zu guter Letzt schrieben wir die Änderungen in die Partitionstabelle mit w.
Ihr werdet eine Warnung erhalten, dass die VM jetzt neu gestartet werden muss.
Es gibt Methoden die Rootpartition zu unmounten, zu resizen und sie dann wieder zu mounten, falls neu starten aus Gründen für euch keine Option ist.
Das behandle ich vielleicht mal in einem anderen Artikel.
Cheers,
Ori
KVM: Manage virtual networks using libvirt
Just a short refference.
List virtual networks
virsh net-list
Change the configuration of the network
virsh net-edit <network>
Cheers,
Ori
KVM: Virtuelle Netze verwalten mit Libvirt
Nur ganz kurz als Referenz zum Nachlesen.
Virtuellen Netze listen
virsh net-list
Die Configuration des jeweiligen Netzes anpassen
virsh net-edit <network>
Cheers,
Ori
Bad, bad VMware tools
Sometimes you come across things that have the potential of letting fecal matter hit the rotary impeller.
Let me warn you.
Imagine you have successfully completed the ESXi upgrades, systems are back alive, nothing broke and everything is fine and dandy.
After a while you are thinking "shit I forgot to update the VMware Tools on those Servers".
In this purely hypothetical scenario you connect to the Hypervisor select your VMs, right klick and select Guest > update VMware Tools.
A couple minutes later the VMs reboot. (!)
No warning, no check if that is fine with you, the VMs just reboot.
Conclusion: To make sure you do not melt some customers productive systems, plan your VMware Tools updates along with the ESXi upgrade downtimes.
Holy shit,
Ori
Böse böse VMware Tools
Manchmal gibt es unerwartete Effekte die das Potential bergen Exkremente auf rotierende Luftumwälzer treffen zu lassen.
Lasst mich euch warnen.
In einem rein hypothetischen Scenario hat ihr ESXi Firmware Updates bei einem Kunden eingespielt.
Nach einer Weile denkt Ihr euch "oh, wir haben die VMware Tools auf den Servern noch nicht aktualisiert".
Ohne böse Hintergedanken geht ihr die VMs durch, macht jeweils einen Rechtsklick und wählt im Kontextmenü Gastbetriebssystem > VMware Tools aktualisieren.
Ein paar Minuten später startet die jeweilige VM neu. (!)
Keine Warnung, keine Rückfrage ob Ihr damit einverstanden seid, die VM wird einfach neu gestartet.
Lerne: Um nicht die Produktivsysteme eurer Kunden einzuschmelzen, plant die Aktualisierung der VMware Tools zusammen mit den abgesprochenen Downtimes der Systeme.
Holy shit,
Ori
Troubleshooting of windows server hard disk extensions / ESXi
This article desribes how to handle issues you can run into when extending windows server hard disks on ESXi.
In this perticular case the C:\ Partition should be extended from 139GB to 156GB.
After the extending the disk the C:\ Partition to 156GB the Explorer and Monitoring still show that the volume size is 139GB.
Troubleshooting
Always check that there is enaugh disk space remaining on the storage.
If a full storage is not the cause of this issue, keep looking.
A reboot always is a good idea, however in a production envoirement that is not always possible and does not help in this case.
A good trick is to extend the harddrive for one more GB.
After a refresh of the disk management utility using F5 there should be 1GB that is showing as "unallocated".
After extending the volume again, issues like this are normally solved.
Do not wonder that the harddrive is showing as 156GB angezeigt wird...
... this is Windows, and there is a 100MB reserved partition in front of C:\ and the explorer only counts full GB.
Cheers,
Ori
Extend hard disk windows server / ESXi
In this article i will show how to extend the hard disk of a virtual windows server on a ESXi (VMware) hypervisor.
The task is relativley trivial but has to be performed every once in a while so I thought why not write a short article on it.
How to
At first take a look at what you want to extend.
In this case it is the E:\ drive of a windows server 2016.
Before changing anything we need to check that the host has enough resources available.
Start, depending on the ESXi version, the vSphere console or a browser and connect to the ESXi Hypervisor or the vCenter.
Open the VM settings and check on what storage the virtual harddrive (the .vdk or .vmdk file) is located on.
In this case the Storage is called "Datastore-VM".
After that hightlight the hypervisor on the left hand and check how much free space there is left on the storage.
Since there is still over 6TB left, extending the harddrive for 60GB should not be a problem.
Now change the size of the harddrive in the settings of the virtual machine.
When you check the harddrive in the explorer it appears to still have the same size.
The reason for this is that we still need to extend the volume on this harddrive.
Start the Diskmanagement using windows + r -> diskmgmt.msc
Rightklick the E:\ Volume and select "Expand volume..."
After you have gone trough the wizard your job should be done.
Cheers,
Ori