Versuche mit Icinga Web 2

Neben LibreNMS für die Langzeitüberwachung ist die Tage eine weitere Instanz für das Monitoring hinzugekommen. Neben dem Wunsch auch gezielt Ports oder Dienste zu überwachen war Neugierde ein weiterer Beweggrund. Gerät einschalten und es geht oder geht nicht ist halt mittlerweile nicht mehr so einfach. Dazwischen gibt es immer mehr mögliche Fehlerquellen oder Ursachen welche den regulären Betrieb in Teilen einschränken oder gar unbenutzbar werden lassen. Nun betreibe ich kein Rechenzentrum oder stelle Hochverfügbarkeitsdienste zur Verfügung. Es ist aber trotzdem ein beruhigendes Gefühl zu wissen, daß alles reibungslos funktioniert. Nach etwas Überlegungen meinerseits und intensiven Austausch mit einem Bekannten haben wir uns für Icinga Web 2 entschieden. Schon während der Installation mekt man, daß sowas nicht “mal eben” gemacht wird. Ich als relativ GUI-verwöhnter Mensch musste mich auch erst damit anfreunden, daß nicht alles über eine hübsche Oberfläche machbar ist. Auch bei dem ersten Anlegen eines Hosts bleibt es textlastig. Geräte, Dienste oder Anwendungen welche man gezielt überwachen möchte werden unter /etc/icinga2/conf.d/hosts/ als *.conf – Dateien angelegt. Exemplarisch die Konfigurationsdatei meiner Synology DS415+

object Host "Synology DS415+"{
	import "generic-host"
	address = "10.1.1.14"
	}
	
	object Service "SSH"{
		host_name = "Synology DS415+"
			check_command = "ssh"
			}
			
	object Service "DSM SSL"{
		host_name = "Synology DS415+"
		check_command = "http"
		vars.http_ssl = "1"
		vars.http_port = "5001"
		}
		
	object Service "DSM PLAIN"{
		host_name = "Synology DS415+"
		check_command = "http"
		vars.http_port = "5000"
		}
		
	object Service "RSYNC"{
		host_name = "Synology DS415+"
		check_command = "tcp"
		vars.tcp_port = "873"
		}
		
	object Service "HyperBackup"{
		host_name = "Synology DS415+"
		check_command = "tcp"
		vars.tcp_port = "6281"
		}
		
	object Service "Freigabe NetBackup"{
		host_name = "Synology DS415+"
		check_command = "disk_smb"
			vars.disk_smb_port = "445"
			vars.disk_smb_hostname = "DS415"
			vars.disk_smb_share = "NetBackup"
			vars.disk_smb_username = "user"
			vars.disk_smb_password = "password"
			vars.disk_smb_wused = "85"
			vars.disk_smb_cused = "95"	
		}

Hier werden die “üblichen” Dienste in das Monitoring aufgenommen. Der erste Block inkludiert auch die Abfrage über Ping. Für den zweiten Block SSH sind keine weiteren Parameter nötig. Interessant ist der dritte Block. Eine Abfrage per HTTP (wir wollen wissen ob DSM erreichbar ist), das es sich um eine SSL-Verschlüsselte Verbindung (vars.http_ssl = “1”) und einen abweichenden Port -nämlich 5001- handelt. Analog das ganze für DSM ohne Verschlüsselung. Die Objekte RSYNC und HyperBackup überwachen die Ports welche von den Diensten genutzt werden. Im letzten Block wird definiert ob eine Freigabe erreichbar ist. Unter vars.disk_smb_username und vars.disk_smb_password müsst ihr natürlich einen User/PW eingeben welcher das Recht hat um auf die Freigabe zugreifen zu dürfen.

Zumindest die Anzeige der Parameter und Zustände kann man sich grafisch auf einer einfachen übersichtlichen Weboberfläche angucken.

Icinga2 ist unheimlich mächtig, aber deswegen auch erstmal schwer zu verstehen. Ich bin froh wenn ich die mir wichtigsten Dienste und Anwendungen überprüfen kann, ohne gleich 2 Semester Icinga studieren zu müssen. Der Vorteil liegt aber deutlich auf der Hand. Man sieht mehr zwischen “Geht” und “Geht nicht”. Als Unterbau dient mir ein minimales Debian 10.4 welches sehr Ressourcenschonend ist. Die VM läuft auf einer Synology DS1019+ mit 256MB RAM sehr vernünftig. Nachteil: fällt die DS1019+ aus, ist auch Essig mit Monitoring. 🙂

Das ganze könnte man jetzt noch wunderbar beispielsweise mit InfluxDB verknüpfen und mit Prometheus oder Grafana grafisch visualisiert aufbereiten. Erste Versuche sind aber gescheitert, weil ich der DB keine vernünftigen und vor allen Dingen vergleichbaren Metriken entlocken konnte. Jeder angelegte Host hatte unterschiedliche Werte auf der Zeit,- als auch Datenachse. Sieht zwar schön aus, aber ein direkter Vergleich zwischen den Systemen kommt so nicht zustande.

Aber das ganze macht man auch nicht “mal eben”….

Umzug via Synologys Migrations Assistant

Seit meinem letzten Eintrag 4 Monate vergangen. Wie doch die Zeit vergeht.
Kurzum: Seit 3 Wochen wohnt eine DS1019+ bei mir. Diese ersetzt die DS415+ welches zukünftig mit bereits verbauten 2 x 14TB als Backup-Storage dient. Ich habe lange mit mir gehadert, wie ich die Migration machen sollte. Festplatten umstecken, manuell von A nach B kopieren, oder den neuen Migrations Assistant von Synology ausprobieren. Die HDDs wollte ich nicht umstecken weil diese ja weitehin für das Backup gebraucht werden. Der manuelle Umzug von rund 13 TB und der Aufwand diverse Apps wieder erneut zu konfigurieren war mir diesmal zu viel Arbeit. Klar hätte man die Konfig wieder einspielen können, aber das ersetzt trotzdem nicht die langwierigen Nacharbeiten. Zu der Zeit hatte ich privat viel um die Ohren und wenig Ressourcen übrig. Also habe ich mich entschlossen den Migrationassistant zu probieren. Ein valides und tragfähiges Backup der Daten vom Quellsystem (DS415+) war vorhanden. Der Assistant wird am Zielsystem (DS1019+) installiert, für das Quellsystem die IP-Adresse sowie das Passwort für einen User welcher Mitglied der Administratorengruppe ist eingetragen. Nach einer kurzen Überprüfung beginnt auch schon das kopieren. Der gesamte Vorgang wird über SSH durchgeführt.

Die Übertragunsrate schwanke stark zwischen 30 und 100MB/s. In meinem Fall hat das Kopieren rund 4 Tage gedauert. Es war während der gesamten Zeit keinerlei Interaktion notwendig. Auf das Quell,- sowie Zielsystem konnte weiterhin zugegriffen werden. Nach der Migration manuell den VMM installiert, das System hat die VMs der “alten” Maschine nahtlos importiert. Einzig die Netzwerkverbindung für die VMs musste händisch nachgezogen werden. Das steht aber auch so in der oben verlinkten Anleitung. Auf Wunsch werden die Dienste und Anwendungen auf dem Quellsystem gestoppt. Ich habe der DS1019+ die ursprüngliche IP der DS415+ gegeben. Nach einem obligatorischen Neustart waren sämtliche Freigaben, Benutzer, Dienste, Anwendungen, Daten, Mails, Kalender, Datenbanken und die Homepage vollständig migriert. Sogar die eingerichteten Jobs von HyperBackup waren vorhanden und funktionierten auf Anhieb. Einzig den Job zu Google Drive musste ich erneut verknüpfen. Mein innig geliebtes OSCM greift problemlos auf die Datenbank welche nun auf der DS1019+ liegt zu.

Um die Integrität und Konsistenz der Daten zu wahren, habe ich vor der Migration sämtliche Zugriffe auf das Quellsystem unterbunden. Nach Abschluß der Migration die Zugänge in der Sophos UTM auf das neue Ziel gelegt und aktiviert. So macht eine Migration echt Spaß. Ich wurde positiv überrascht, werde das Konzept weiterverfolgen und bei Bedarf vermutlich wieder so durchführen.

Nextcloud 17.0.2

Ich habe die freien Tage zwischen Weihnachten und Silvester genutzt um meinen Nextcloud-Container auf 17.0.2 zu bringen. Mit dem integrierten Updater eine runde Sache ohne Komplikationen. Bin hier vermutlich immer noch von diversen Update-Orgien von ownCloud vorbelastet.

Nach dem Login wurde ich aber von einer Einrichtungswarnung begrüßt.

Das ganze kann man aber schnell bereinigen. Unbedingt vorher die Instanz in den Wartungmodus versetzen.
Nun können wir weitermachen und die Konvertiertung auf big int ausführen:

php occ db:convert-filecache-bigint

Je nach Umgebung und Datenmenge kann dies lange dauern.
Wenn die Konvertierung abgeschlossen ist, den Wartungmodus abschalten und erneut anmelden.

Das Changelog liefert wie übliche weitergehende Informationen über das Update.

Nextcloud als Container

In meinem letzten Beitrag habe ich ja die Hardware welche zur Virtualisierung eingesetzt wird kurz vorgestellt. Das darauf laufende Proxmox kann ja auch Container virtualisieren. Ein gänzlich neues Themengebiet für mich. Erste kurze und schnelle Ergebnise wollten sich leider nicht einstellen. Der Versuch den heruntergeladenen Container (Turnkey-Nextcloud) scheiterte bereits beim Einschalten mit:

 extracting archive  '/mnt/ssd2/template/cache/debian-9-turnkey-nextcloud_15.2-1_amd64.tar.gz'  tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not  permitted tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation  not permitted Total bytes read: 1378150400 (1.3GiB, 158MiB/s) tar:  Exiting with failure status due to previous errors TASK ERROR: unable to  create CT 1200 - command 'lxc-usernsexec -m u:0:100000:65536 -m  g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse  --numeric-owner --acls --xattrs '--xattrs-include=user.*'  '--xattrs-include=security.capability' '--warning=no-file-ignored'  '--warning=no-xattr-write' -C /var/lib/lxc/1200/rootfs --skip-old-files  --anchored --exclude './dev/*'' failed: exit code 2</ 

Das Häckchen bei der Checkbox beim erstellen des Containers “Unprivilegierter Container” muß rausgenommen werden. Damit ließ sich der Container auch starten. Der Container bringt Webmin als auch Adminer bereits mit. Auf dem Container muß man sich anschließend als “root” anmelden. Hier wird die weitere Einrichtung durchgeführt, wie z. B. setzen der Passwörter für Webmin und Adminer und die Domäne unter welcher der Container erreichbar ist. Im Prinzip ist man danach auch schon fertig. Nicht so bei mir….

Der Container soll ja unter einer sub.domain.de mit einem Zertifikat von Let’s Encrypt erreichbar sein. Ein wenig tricky, da hier mittlerweile sämtlicher Traffic über eine Sophos UTM läuft.
Der logische Aufbau ist
WAN -> Domain -> DynDNS -> Router -> Sophos -> DMZ

Einige Zeit und Wutausbrüche später hab ich das doch noch erreicht.
In der Sophos ist ein “Virtueller Webserver”, sowie ein “Echter Webserver” angelegt worden. In dem “Virtuellen Webserver” wird die Subdomain angegeben, in dem “Echten” der Host mit IP. Sophos hat auch für die Subdomain ein Zertifikat von Let’s Encrypt bezogen. Im Gegensatz zu einer VM mit Debian wo Nextloud installiert wurde, gibt es bei dem Aufruf der Subdomain des Containers nur eine Einrichtungswarnung – sehr positiv.

Da ich meiner Sophos welche auch Proxy spielt traue, nehme ich die als “Vertrauenswürdig” in die config.php von Nextcloud auf.

'trusted_proxies' => array (0 => '10.1.1.1',),
 'forwarded_for_headers' => array (0 => 'HTTP_X_FORWARDED_FOR',),

Zum Schluß den Webserver neu starten, und sich an einem Container erfreuen.

Zum Vergleich: Eine DebianVM mit Nextloud verbraucht von 1GB RAM im Mittel rund 75%. Der Container beansprucht von zugewiesenen 512MB rund 50%.

VM
Container