Zur Adress- und Projektverwaltung und für die Rechnungserstellung nutze ich die Community-Version des ERP-Systems odoo. Bisher lief odoo in einer virtuellen Maschine auf meinen Arbeitsplatzrechner. Aus Sicherheits- und Performancegründen möchte ich odoo auf einem eigenen Rechner laufen lassen.
Am Lager habe ich noch einen 10 Jahre alten Mini-PC mit einer Intel-CPU Pentium G3250T (2 CPU-Kerne, 2 Threads), 4 GB RAM, und einer Festplatte mit 500 GB. Darauf soll odoo in einer virtuellen Maschine ausgeführt werden. Odoo läuft im Browser und benötigt keinen Client. Auf dem Server ist odoo sehr genügsam: für 10 bis 50 Benutzer sind die Systemvoraussetzungen: 2 CPU-Kerne, 4 GB RAM, 40 GB Festplatte. Auf dem PC habe ich ein Ubuntu 24.04 LTS Server installiert und verwende KVM zur Virtualisierung. Für die virtuelle Maschine mit odoo habe ich 2 CPU-Kerne und 2 GB RAM reserviert. Als Betriebssystem für die virtuelle Maschine verwende ich ebenfalls Ubuntu 24.04 LTS Server. Tatsächlich kann ich mit dieser Konfiguration mit odoo vernünftig arbeiten.
KVM installieren:
sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst libosinfo-bin virt-top libguestfs-tools
Zeitzone anpassen:
sudo timedatectl Europe/Berlin
Automatische Updates:
In Ubuntu ist voreingestellt, dass Sicherheitsupdates automatisch installiert werden. Dazu muss die Datei/etc/apt/apt.conf.d/20auto-ugprades diese Zeilen enthalten:
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::Unattended-Upgrade "1"; Unattended-Upgrade::Automatic-Reboot-Time "05:00";
Manche Updates benötigen einen Neustart des Systems. In der genannten Konfiguration erfolgt der Neustart um 5:00 Uhr. Der Neustart muß aber in der Datei etc/apt/apt.conf.d/50unattended-upgrades erlaubt werden:
Unattended-Upgrade::Automatic-Reboot "true";
Die Änderungen müssen noch aktiviert werden. Starten Sie dazu den Dienst neu:
sudo systemctl restart unattended-upgrades
Die Anwendung virt-manager stellt eine grafische Oberfläche zur Verfügung, mit der man virtuelle Maschinen remote erstellen und verwalten kann. Dazu muß auf einem Linux-System mit grafischer Oberfläche dieses Paket installiert werden:
sudo apt install virt-manager
Der Standort des PC wird der Keller sein, da stört er am wenigsten. Dumm nur, dass an dem gewünschten Platz kein Netzwerk vorhanden ist. WLAN ist vorhanden, aber nur in schlechter Qualität. Daher verwende ich PowerLAN-Adapter, die ich ebenfalls noch im Lager gefunden habe. Da die Steckdose ungeschickt angebracht ist, muss ich eine Mehrfachsteckdose verwenden. Daran wird der PC und der PowerLAN-Adapter angeschlossen. Das sollte man eigentlich nicht tun, da die PowerLAN-Adapter anfällig für Störquellen sind und das Netzteil des PC an der Mehrfachsteckdose ist eine Störquelle. Ich hatte Glück, bei mir funktioniert die Verbindung ohne Probleme.
Von der virtuellen Maschine wird jede Nacht ein Backup erstellt. Die Backups werden 7 Tage aufgehoben und danach überschrieben. Zusätzlich wird das aktuelle Backup auf einen USB-Stick kopiert, der am PC angeschlossen ist. So habe ich noch eine externe Datensicherung. Falls der PC und der USB-Stick durch Diebstahl, Brand, oder sonstigen Unbilden nicht mehr verfügbar wären, kopiere ich das Backup auf eine DSGVO-konforme Cloud. Vor dem Hochladen wird das Backup mit AES 256 verschlüsselt und mit einem starken Passwort versehen, falls es aus der Cloud gestohlen werden sollte.
Hier das Skriptbackup.sh für die Datensicherung:
#!/bin/bash # Virtuelle Maschine herunterfahren virsh shutdown odoo-vmfree # Kurz warten, bis die virtuelle Maschine heruntergefahren ist sleep 20 # Virtuelle Maschine klonen virsh undefine odoo-vmfree-clone sleep 10 rm /work/backup/odoo-vmfree-clone.qcow2 virt-clone --original odoo-vmfree --name odoo-vmfree-clone --auto-clone # An jedem Wochentag eine Datensicherung # DAY = Wochentag (So, Mo, Di...) DAY=$(date +%a) # Virtuelle Maschine mit tar komprimieren tar cvfjp /work/backup/odoo-vmfree_$DAY.qcow2.tar.gz /etc/libvirt/qemu/odoo-vmfree.xml /work/kvm/odoo-vmfree.qcow2 cp /work/backup/odoo-vmfree_$DAY.qcow2.tar.gz /work/backup/odoo-vmfree.qcow2.tar.gz # Virtuelle Maschine wieder starten virsh start odoo-vmfree # Sicherung auf USB-Stick kopieren mount /dev/sdb1 /work/usb cp /work/backup/odoo-vmfree.qcow2_$DAY.tar.gz /work/usb umount /work/usb # Datensicherung mit AES256 verschlüssel und mit Passsphrase schützen gpg -c --batch --passphrase 'PASSWORT' --symmetric --cipher-algo aes256 /work/backup/odoo-vmfree.qcow2.tar.gz # Verschlüsselte Datei in die Cloud hochladen sshpass -p 'PASSWORTCLOUD' sftp BENUTERZNAME@HOTSTNAMECLOUD < /work/system/upload.cmd 2> /tmp/sftp.err # Fehlermeldungen von sftp werden in die Datei /tmp/sftp.err geschrieben. Danach wird mit grep der String "Connected to" entfernt. # sftp schreibt nach stderr die Verbindungsmeldung und das ist kein Fehler. grep -v "Connected to" /tmp/sftp.err date exit 0Im Skript muss PASSWORT durch das Passwort zum verschlüsseln der Datei und PASSWORTCLOUD, BENUTERZNAME und HOTSTNAMECLOUD durch die Zugangsdaten von Ihrer Cloud ersetzt werden.
Nachdem das Backup erstellt wurde, prüft dieses Skript, ob es eine Backupdatei auf dem PC und auf dem USB-Stick gibt. Falls eine Datei nicht vorhanden ist, wird eine E-Mail versendet.
Versenden einer E-MailDazu muss das Paket ssmtp installiert werden:
sudo apt install ssmtpssmtp muss noch konfiguriert werden. Dazu die Datei
/etc/ssmtp/ssmtp.conf ändern:
root=root@kvm.de mailhub=SMTPSERVER:587 rewriteDomain=DOMAIN hostname=kvm.de FromLineOverride=YES AuthUser=BENUTERZNAME AuthPass=PASSWORT UseSTARTTLS=YES UseTLS=YES AuthMethod=LOGIN
Im Skript müssen SMTPSERVER, DOMAIN, BENUTZERNAME und PASSWORT durch die Zugangsdaten von Ihrem E-Mail-Provider ersetzt werden.
Das Skript sendmail.sh versendet eine E-Mail:
#!/bin/bash # $1 = Betreff # $2 = Datei mit E-Mail-Inhalt FILE=/tmp/sendmail.txt echo "To: volker.matheis@mail.de" > $FILE echo "From: kvm@vmfree.de" >> $FILE echo "Subject:" $1 >> $FILE echo "" >> $FILE echo "" >> $FILE cat $2 >> $FILE ssmtp EMAILEMPFAENGER < $FILE
Ersetzen Sie EMAILEMPFAENGER durch die E-Mailadresse, die die Meldungen erhalten soll.
Prüfen der Sicherung mit dem Skript checkbackup.sh:
#!/bin/bash # Datei /tmp/backup.err enthält Fehlermeldungen vom Skript backup.sh if (test -s /tmp/backup.err) then /work/system/sendmail.sh "Fehler in Datensicherung" /tmp/backup.err fi # Sicherung vorhanden? if ! (test -s /work/backup/odoo-vmfree.qcow2.tar.gz) then echo "Pruefe /work/backup/odoo-vmfree.qcow2.tar.gz auf USB" > /tmp/checkbackup.txt /work/system/sendmail.sh "Backup nicht vorhanden" /tmp/checkbackup.txt fi # Sicherung in Cloud vorhanden? sshpass -p 'Insftp!Urml1Murml2' sftp a228466@access-5018040323.webspace-host.com < /work/system/checkupload.cmd > /tmp/checkupload.erg if ! (grep "odoo-vmfree.qcow2.tar.gz.gpg" /tmp/checkupload.erg) then echo "Pruefe /work/backup/odoo-vmfree.qcow2.tar.gz.gpg in cloud" > /tmp/checkbackup.txt /work/system/sendmail.sh "Backup nicht vorhanden" /tmp/checkbackup.txt fi exit 0
Datei checkupload.cmd enthält die Kommandos für den FTP-Server:
cd backup ls quitPeriodische Ausführung der Skripte
Datei crontab zur periodischen Ausführung des Backups und dessen Prüfung erstellen:
00 23 * * * /work/system/backup.sh > /tmp/backup.mld 2> /tmp/backup.err 00 04 * * * /work/system/checkbackup.sh
Das Skript backup.sh erstellt zwei Ausgabedateien: /tmp/backup.mld enthält die Ausgaben, die die Kommandos schreiben. /tmp/backup.err enthält Fehlermeldungen.
sudo crontab crontab
Ich hätte odoo auch direkt auf den PC installieren können, also ohne eine virtuelle Maschine zu verwenden. Das hätte sicher zu einer besseren Performance beigetragen. Allerdings hätte ich bei einem Ausfall des PC mehr Aufwand, um wieder ein lauffähiges System zu bekommen: Ich müsste die Datenbank und ausgelagerte Dateien (externe Dokumente, z. B. Lieferantenrechnungen als PDF, werden in odoo als Datei gespeichert) sichern. Auf einem Ersatz-PC müsste ich Ubuntu und odoo installieren und die Datenbank und die Dateien wieder importieren. Mit der virtuellen Maschine ist eine Wiederherstellung wesentlich einfacher.
Ich hätte odoo auch in einem Container installieren können. Die Installation auf einem Ersatzsystem würde sich auf die Installation von Docker, des Containers und dem Kopieren der Datenbank und der ausgelagerten Dateien von odoo beschränken.
Es ist klar, dass ein PC nicht den Anforderungen an einen Server genügen kann. Die Komponenten eines PC sind nicht für einen dauerhaften Einsatz ausgelegt. Dies betrifft nahezu alle Komponenten, von der Festplatte bis hin zur CPU (Server-CPUs z. B. verfügen über eine Funktion zur Korretur von Datenfehlern im RAM (ECC)). Bei Servern sind viele Komponenten doppelt oder mehrfach vorhanden (Netzteile, Festplatten, Netzwerkanschlüsse) damit bei Ausfall einer Komponente der Server weiter funktionsfähig bleibt. Daher sind Server auch teuer und haben trotzdem einen „Single Point of failure“, durch Komponenten, die nur einmal vorhanden sind.
Eine weitere Möglichkeit wäre der Einsatz eines NAS. Bei einem NAS sind zumindest die Festplatten mehrfach vorhanden. Bei Ausfall einer Festplatte läuft das NAS weiter. Moderne NAS-Systeme haben auch die Möglichkeit, virtuelle Maschinen zu verwalten. Aber auch hier sind Komponenten nur einfach vorhanden. Bei Ausfall des Netzteils z. B., funktioniert das NAS nicht mehr. Und NAS-Systeme mit mehrfach vorhandenen Komponenten, sind wiederum teuer.
Die dritte Möglichkeit ist, einen weiteren PC einzusetzen. Dieser ist ebenfalls dauerhaft im Einsatz. Auf dem PC ist KVM installiert und jede Nacht wir die virtuelle Maschine mit odoo auf diesen PC kopiert. Die beiden PC sind dann zur Sicherheit in verschiedenen Räumen aufgestellt.
Wenn ich zwei PC im Einsatz habe, werde ich odoo hochverfügbar machen. Dies mittels Load balancer, einer Master-Client-Datenbank oder einer HA-Lösung wie pacemaker.
So komme ich aber mit der eingesetzten Lösung gut zurecht. Sollte das System ausfallen, habe ich den Verlust von Daten eines Tages. Diese kann ich wiederherstellen. Und in weniger als 2 Stunden ist ein lauffähiges System mit Ubuntu und KVM wieder einrichten.