Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Netzwerkbrücke für LXD Container einrichten

Von: zefanja
07. Februar 2019 um 14:05

Die meisten unserer Webanwendungen laufen in LXD Containern. Nicht ohne Grund ist LXD für mich eines der wichtigsten Features von Ubuntu Server. Es gibt viele Wege um von außen auf eine Webanwendung in einem LXD Container zuzugreifen. So kann man z.B. einen Reverse Proxy nehmen und darüber die Zugriff auf die Container regeln (hier hatte ich schon mal davon berichtet). Eine andere Möglichkeit ist die Einrichtung einer Netzwerkbrücke, sodass sich die Container im gleichen Netz wie der Containerhost (Ubuntu Server) befinden. In diesem Artikel möchte ich kurz beschreiben, wie man eine Netzwerkbrücke für LXD Container einrichtet.

Netzwerkbrücke für LXD Container

Um eine Netzwerkbrücke unter Ubuntu einzurichten, muss man die bridge-utils installieren:

$ apt install bridge-utils

Danach kann man die Netzwerkbrücke einrichten.

bis Ubuntu 16.04

Bis Ubuntu 16.04 nutzt Ubuntu ifupdown um Einstellungen für die Netzwerkverbindungen festzulegen. Die Konfiguration nimmt man in den Dateien unter /etc/network/ vor. Eine einfache Netzwerkbrücke, um die Container in das Host-Netzwerk zu bekommen, könnte so aussehen:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The main Bridge
auto br0
iface br0 inet dhcp
    bridge-ifaces enp4s0
    bridge-ports enp4s0
    up ip link set enp4s0 up

# The primary network interface
iface enp4s0 inet manual

Hier bekommt die Brücke ihre Adresse vom DHCP-Server mitgeteilt. Die reale Netzwerkkarte enp4s0 wird in den manuellen Modus gesetzt und der Brücke zugewiesen.

ab Ubuntu 18.04

Ab Ubuntu 18.04 wird Netplan für die Konfiguration der Netzwerkverbindungen verwendet. Die Konfigurationsdateien befinden sich unter /etc/netplan/. Eine Definition für die Brücke könnte folgendermaßen aussehen:

$ cat /etc/netplan/50-cloud-init.yaml 
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp3s0:
            dhcp4: no
    version: 2
    bridges:
        br0:
            dhcp4: no
            addresses:
            - 10.10.10.5/24
            gateway4: 10.10.10.254
            nameservers:
                addresses:
                - 10.10.10.254
            interfaces:
            - enp3s0

Im oberen Teil konfiguriert man die reale Netzwerkkarte (enp3s0) und weißt ihr keine Adresse zu. Danach folgt die Definition der Netzwerkbrücke. Sie wird wie eine statische Netzwerkverbindung eingerichtet und enthält zusätzlich den Punkt interfaces. Dort legt man fest, welche reale Netzwerkkarte „überbrückt“ werden soll. Weitere (komplexere) Beispiele zu Netzwerkbrücken gibt es auf der offiziellen Website.

Nun werden mit dem folgenden Befehl die Änderungen an den Netzwerkeinstellungen angewendet:

$ netplan apply  --debug

Netzwerkbrücke zuweisen

Hat man die Netzwerkbrücke fertig eingerichtet und bekommt sie auch die richtige IP-Adresse, muss man dem LXD Container noch mitteilen, dass er seine IP-Adresse über die Netzwerkbrücke beziehen soll. Das erledigt man mit folgendem Befehl:

$ lxc config device add containername eth0 nic nictype=bridged parent=br0 name=eth0

Mit name=eth0 legt man fest, unter welchen Namen man die Netzwerkkarte im Container findet. Nun kann man im Container eth0 nach Belieben konfigurieren. Ab sofort sollte der Container eine IP-Adresse aus dem Host-Netzwerk bekommen.

Fazit

Eine einfache Netzwerkbrücke lässt sich schnell einrichten und man kann sie ohne Probleme einem Container zuweisen. Andere Benutzer im Netzwerk können so ohne die Einrichtungen eines Reverse-Proxys auf eine Webanwendung zugreifen. Auch komplexere Szenarien sind denkbar (VLANs, mehrere Brücken, um die Container in verschiedene Netz zu bekommen etc.), doch das würde den Rahmen dieses kurzen Artikels sprengen.

3 Kommentare

Der Beitrag Netzwerkbrücke für LXD Container einrichten erschien zuerst auf .:zefanjas:..

Wie wichtig ist Hochverfügbarkeit in einem Schulnetzwerk?

Von: zefanja
05. März 2019 um 13:35

Schulnetzwerke werden mit wachsenden Anforderungen komplexer. Ein Schulserver, schulweites WLAN, Einsatz von Tablets und Laptops im Unterricht, eine Schulcloud, einheitliche Logins für alle Dienste – die Anforderungen an einen Netzwerkbetreuer oder Dienstleister in der Schule sind vielfältig. Wenn alles funktioniert, ist meist auch alles gut. Aber was ist, wenn der Server, die Firewall oder ein Switch ausfällt? Die Konsequenzen können sehr unterschiedlich sein. Wie schnell kann der Normalbetrieb wiederhergestellt werden? Wie wichtig ist Hochverfügbarkeit in einem Schulnetzwerk?

Hochverfügbarkeit

Laut Wikipedia definiert sich Hochverfügbarkeit folgendermaßen

Hochverfügbarkeit (englisch high availability, HA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten.

Es geht also darum, dass ein System („das Schulnetzwerk“) einsatzfähig bleibt, auch wenn eine oder mehrere Komponenten einmal ausfallen sollten. Dabei kann es durchaus zu Unterbrechungen kommen. Je nachdem wie lang so eine Unterbrechung ist, teilt man die Hochverfügbarkeit in verschiedene Klassen ein. Ein Schulnetzwerk muss vor allem an Schultagen einsatzfähig sein (ca. 180-200 Tage pro Jahr). Auch wenn eine 99,999% Verfügbarkeit in den wenigsten Schulen absolut notwendig ist, ist der reibungslose Betrieb für den Unterrichtsalltag sehr wichtig.

Single Point of Failures

Um Hochverfügbarkeit herzustellen, müssen sogenannte „Single Point of Failures“ reduziert werden. Es handelt sich dabei um Komponenten bei deren Ausfall das ganze Schulnetzwerk still stehen würde. Was können solche „Single Point of Failures“ sein?

  • Firewall → fällt sie aus, gibt es kein Zugang mehr zum Internet, je nach Konfiguration funktioniert auch das interne Netz nicht mehr
  • Switche (v.a. Hauptswitch) → siehe Firewall, Komplettausfall
  • Server → fällt er aus, sind viele Anwendungen nicht mehr zu erreichen, d.h. keine Anmeldung mehr im internen Logins, Webanwendungen, Schulcloud, …
  • Internetanschlüsse → fällt der einzige Zugang aus, ist man offline.

Kurze Geschichte am Rande:

Letzte Woche ist unsere Firewall ausgefallen (aufgrund des Atom C2000 Bugs). Das Netzwerk lag still, wir waren offline. Ein erster Versuch die Firewall zu virtualisieren scheiterte, sodass wir auf einen kleinen Minicomputer mit 2 Netzwerkkarten ausgewichen sind. Es waren ein paar zusätzliche Konfigurationen an unserem Hauptswitch nötig um alle WANs und VLANs auf zwei Netzwerkkarten aufzuteilen. Nach einigen Stunden lief das Netzwerk dann wieder (wir konnten das Backup der Konfiguration mit wenig Änderungen problemlos wiederherstellen).

Wie kann man die Ausfallsicherheit erhöhen?

Es gibt mehrere Möglichkeiten, wie man die Ausfallsicherheit erhöhen und das System „Schulnetzwerk“ besser gegen Ausfälle schützen kann. Allgemein geht es darum, dass man möglichst wenige (am besten keine) „Single Point of Failures“ hat und kritische Komponenten bei einem Ausfall fehlertolerant sind. Wie bereits oben erwähnt, hängen die Anforderungen an ein hochverfügbares Schulnetzwerk sehr von den Gegebenheiten und Wünschen des Schulträgers ab. Zum einen ist es eine Frage des Geldbeutels, zum anderen muss auch nicht jedes Netzwerk innerhalb weniger Minuten wieder verfügbar sein.

Hier einige Ideen, wie man die Ausfallsicherheit erhöhen kann:

  • qualitative Hardware → gute Hardware kostet zwar mehr, aber sie läuft oft stabiler
  • Backups, Backups → Konfigurationen, Daten, Virtuelle Maschinen, Container – an Backups führt kein Weg dran vorbei (Backups unbedingt auch testen!)
  • Monitoring → ein gutes Monitoring kann in manchen Fälle Fehler früh erkennen bzw. gibt einen Überblick, wo es im Netzwerk gerade Probleme gibt. So kann man schneller reagieren und ist nicht auf die Hinweise der Benutzer im Netzwerk angewiesen („Das Internet geht nicht mehr“, „Der Drucker ist kaputt“, …)
  • Fehlertoleranz erhöhen → auch „Failover“ genannt, d.h. zwei Netzteile im Server, mehrere Internetanschlüsse („Multi-WAN), zwei Firewalls, RAID, zwei Server, …
  • Ersatzteile vorhalten → Festplatten, Ersatzswitch, …
  • UPS/USW → Hardware bei Stromschwankungen schützen und Weiterbetrieb auch bei einem Stromausfall gewährleisten (für begrenzte Zeit)
  • „personelle Redundanz“ → besser zwei oder mehrere Administratoren bzw. Dienstleister (bei Abwesenheit durch Krankheit, Urlaub, …)
  • vorbeugende Wartungen

Fazit

Ein Schulnetzwerk ist sicher kein hochkritisches System, aber mit der fortschreitenden Digitalisierung der Schulen wird es immer wichtiger, dass die IT-Infrastruktur möglichst ohne Ausfälle erreichbar bleibt. An manchen Schulen wiegt ein Ausfall des Internets so schwer, dass kaum weiter gearbeitet werden kann (Onlinesysteme zur Verwaltung, Schulclouds, Online-Lernsysteme, Student Information Systems). Um die Ausfallsicherheit zu erhöhen, muss man nicht immer viel Geld in die Hand nehmen. Viel wichtiger ist, dass man auf einen Ausfall vorbereitet ist (v.a. bei den Single Point of Failures).

3 Kommentare

Der Beitrag Wie wichtig ist Hochverfügbarkeit in einem Schulnetzwerk? erschien zuerst auf .:zefanjas:..

Bootzeit mit Systemd analysieren

Von: Niko
07. April 2019 um 12:08
Systemd Analyze Beitrag

Systemd wird häufig kritisiert, weil es größer und komplexer als bisherige Init-Systeme ist. Dafür bringt Systemd aber auch eine ganze Reihe an Tools zur Fehlerbehebung und Systemanalyse mit.

Eines davon ist systemd-analyze, mit dem sich der Bootvorgang des Systems darstellen und analysieren lässt. Die Ausgabe kann dabei textbasiert auf der Kommandozeile erfolgen, oder auch als svg-Grafik exportiert werden.

Bootvorgang mit systemd-analyze untersuchen

Ein simpler Aufruf von

systemd-analyze

zeigt eine Übersicht, welche Systembestandteile wie lange zum booten benötigen. Damit erhält man folgende Ausgabe.

Sofern das Betriebssystem auf einem Computer mit UEFI installiert ist, bekommt man auch die Startzeit des UEFI (firmware) präsentiert. Anschließend wird die Startzeit des Bootloaders ausgegeben (loader). Dass diese bei mir mit knapp 32 Sekunden angegeben ist, liegt (denke ich) an der Wartezeit im Grub Auswahlbildschirm. Anschließend werden die Startzeiten der systemnahen Komponenten (kernel) und der Benutzerumgebung (userland) angegeben.

Eine genauere Ausgabe erhält man mit dem Befehl

systemd-analyze blame

Damit erhält man eine Auflistung aller beim booten gestarteten Dienste, sortiert nach ihrer Startzeit. Damit lassen sich Dienste, die das starten verzögern schnell identifizieren.

Ausgabe von systemd-analyze blame

Außerdem lässt sich die Ausgabe auch als SVG-Grafik exportieren. Damit erhält man noch detailliertere Ergebnisse. der Export erfolgt mit

systemd-analyze plot > boot.svg

Allerdings ist die exportierte Grafik ziemlich groß, so dass man viel scrollen muss um diese zu analysieren. Horizontal wird dabei die Startzeit in Sekunden angegeben. Vertikal werden die einzelnen Dienste aufgelistet.

Ausgabe von systemd-analyze als SVG-Grafik

Die Ausgaben von systemd-analyze sind nicht nur interessant, sondern ermöglichen auch, auf den ersten Blick zu erkennen, warum der Bootvorgang so lange dauert. Dienste, die den Bootvorgang verlangsamen lassen sich damit direkt identifizieren, wo ansonsten möglicherweise eine langwierige Fehlersuche oder Analyse notwendig wäre.

Bootzeit mit Systemd analysieren ist ein Beitrag von techgrube.de.

PHP-Seiten wie WordPress mit OPCache beschleunigen

Von: Niko
05. Mai 2019 um 10:58
PHP Speed Beitrag

Normalerweise werden PHP-Skripte zur Laufzeit kompiliert. Das heißt, wenn jemand eine PHP-Seite wie WordPress aufruft, wird der PHP-Quelltext (die PHP-Datei) gelesen und vom PHP-Interpreter in sogenannten Bytecode (vorkompilierter Code) umgewandelt. Dieser Bytecode wird an eine virtuelle Maschine (die Zend Engine) übergeben, die daraus maschinenlesbaren Code erzeugt. Die Zend Engine stellt dabei eine einheitliche Laufzeitumgebung für verschiedene CPU-Architekturen und Betriebssysteme bereit.

Der Bytecode wird daraufhin verworfen und muss bei jedem Aufruf der Webseite neu generiert werden. Dies kostet Rechenzeit und verzögert den Aufruf der Webseite.

Durch die Nutzung von OPCache wird der Bytecode für die spätere Verwendung zwischengespeichert, so dass er nicht bei jedem Aufruf der Webseite neu erzeugt werden muss. Dies kann die Ladezeit von WordPress (oder anderen PHP-Projekten) spürbar beschleunigen.

Der Preis dafür ist, dass zum Zwischenspeichern des vorkompilierten Bytecodes RAM und/oder Festplattenspeicher benötigt wird. Außerdem werden (abhängig von der OPcache Knfiguration) Änderungen am PHP-Code unter Umständen nicht sofort sichtbar, da sich noch eine alte Version im Cache befindet.

OPcache aktivieren und konfigurieren

Um OPCache auf einem Ubuntu-Server zu nutzen, muss das Paket php7.2-opcache installiert werden. Anschließend kann der Cache über die php.ini aktiviert werden. Die php.ini befindet sich bei Ubuntu und der Verwendung von PHP als Apache-Modul unter /etc/php/7.2/apache2/php.ini. Bei Verwendung von PHP-FPM, beispielsweise mit NGINX, findet man die Konfigurationsdatei unter /etc/php/7.2/fpm/php.ini

In der php.ini scrollt man bis zum Abschnitt [opcache].

Um OPcache zu aktivieren muss die Zeile

;opcache.enable=0

abgeändert werden in

opcache.enable=1

Außerdem können und sollten weitere Einstellungen vorgenommen werden. In untenstehender Tabelle sind einige Option beschrieben, die ich für die wichtigsten halte.

Option Bedeutung
opcache.memory_consumption=256 Die Menge an Speicherplatz die OPcache zur Verfügung steht, in Megabytes.
opcache.interned_strings_buffer=16 Speicherplatz der für string interning zur Verfügung steht, ebenfalls in Megabytes.
opcache.max_accelerated_files=16229 Die maximale Anzahl an Schlüsseln (und damit PHP-Skripte) die gespeichert werden können. Der Wert sollte größer als die Anzahl vorhandener Skripte sein. Der tatsächlich verwendete Wert wird aus einem festen Set aus Primzahlen gewählt (223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987). Es wird die Primzahl verwendet, die größer oder gleich dem gesetzten Wert ist. Gibt man beispielsweise als Wert 10000 an, werden tatsächlich 16229 Schlüssel gecached. Man kann also auch direkt eine der angegebenen Primzahlen als Wert setzen.
opcache.max_wasted_percentage=10 Prozentsatz an verschwendetem Speicherplatz, der akzeptiert wird, becor der Cache komplett geleert wird. “Waste” entsteht, wenn sich der Code ändert, während OPcache läuft. Der alte Cache-Eintrag wird dabei als “waste” markiert.
opcache.validate_timestamps=1 Legt fest, ob OPcache in regelmäßigen Abständen prüfen soll, ob sich der PHP-Code in einer Datei geändert hat. Wenn dies deaktiviert ist, muss nach jeder Änderung am Code (z.B. ein WordPress Update) ein Reset von OPcache durchgeführt werden, oder OPcache neu gestartet werden. Wer WordPress-Updates automatisch einspielen lässt, sollte die Option aktivieren. Wer die manuell macht, kann die Option deaktivieren und zusätzlich Rechenzeit sparen.
opcache.revalidate_freq=300 Zeit in Sekunden, nach der überprüft wird ob sich der PHP-Code in einen Skript keändert hat. “0” bedeutet, dass die Prüfung bei jedem Aufruf vorgenommen wird.
opcache.file_cache=/path/to/cache OPcache kann Daten im Ram und/oder auf einem Datenträger speichern. Damit kann OPcache z.B. auch in Shared-Hosting Umgebungen genutzt werden. Auf dem eigenen Server hat die Nutzung dieser Option den Vorteil, dass bereits erzeugte Daten nach einem Neustart des Servers nicht verloren gehen. Das Verzeichnis muss vom PHP-Prozess beschrieben werden können.
opcache.file_cache_only=0 Legt fest ob OPcache seine Daten nur auf dem Datenträger speichert (1) oder ob Daten im RAM und zusätzlich auf dem Datenträger gespeichert werden (0)

Wenn der Server von mehreren Benutzern verwendet wird, sind evtl. die Optionen opcache.validate_permission und opcache.validate_root von Bedeutung, die standardmäßig deaktiviert sind. Erstere prüft, ob der User überhaupt Leseberechtigung für das entsprechende Skript hat. Dies verhindert, dass zwischengespeicherte Daten an andere Benutzer geleaked werden. Zweitere verhindert Namenskollisionen bei verschiedenen chroot Umgebungen.

Damit Änderungen wirksam werden, muss Apache, bzw. PHP-FPM neu gestartet werden. Dabei wird außerdem der Cache geleert.

Überprüfen ob OPcache genutzt wird

Eine schöne Möglichkeit zum Steuern von OPcache und zum prüfen, ob OPcache überhaupt genutzt wird ist das Tool opcache-gui das auf Github zu finden ist. Es handelt sich dabei um ein PHP-Skript, das den verwendeten Speicherplatz, die Anzahl der zwischengespeicherten Skripte uvm. anzeigt. Da sich außerdem verschiedene Funktionen von OPcache steuern lassen, sollte man den Zugriff auf das Skript mit einem Passwort sichern.

Um opcache-gui zu nutzen, muss lediglich das PHP-File in den eigenen Webverzeichnis kopiert werden und über den Webbrowser aufgerufen werden.

Wer opcache-gui dauerhaft einsetzen will, der sollte den Zugang unbedingt mit einem Passwortschutz versehen.

OPcache Gui

PHP-Seiten wie WordPress mit OPCache beschleunigen ist ein Beitrag von techgrube.de.

Xen Orchestra installieren und aktualisieren (Vollversion)

Von: zefanja
10. Mai 2019 um 12:24

An unserer Schule verwenden wir  Citrix Hypervisor (ehemals XenServer) (bald xcp-ng) für die Virtualisierung unseres Schulservers und anderer Anwendungen. Citrix liefert mit XenCenter ein Verwaltungstool für Windows. Damit kann man bequem alle virtuellen Maschienen verwalten und Einstellungen am Citrix Hypervisor vornehmen. Eine andere Möglichkeit ist Xen Orchestra. Es ist ein webbasiertes Tool, was noch einiges mehr als XenCenter kann. Auf der Website kann man sich eine fertig eingerichtete Appliance herunterladen. Diese ist allerdings von den Features stark eingeschränkt (man hat ca. 2 Wochen Zeit alle Features zu testen). Deshalb möchte ich einen kleinen Tipp weitergeben, wie man Xen Orchestra installieren kann – mit allen Features der Enterprice und Premium Edition.

Xen Orchestra installieren

Xen Orchestra ist eine Open Source Projekt, deshalb kann es sich jeder selbst den Quellcode nehmen und installieren. Die Anleitung dazu findet man in der offiziellen Dokumentation. Auf Github findet man auch ein Installationsskript, welches die Installation automatisch durchführt. Damit kann man Xen Orchestra in wenigen Schritten installieren. Auf einem frischen Ubuntu LTS Server muss man nur die folgenden Befehle ausführen:

$ sudo bash
$ curl https://raw.githubusercontent.com/Jarli01/xenorchestra_installer/master/xo_install.sh | bash

Das war es auch schon 🙂 Xen Orchestra kann man nun unter IP des Servers erreichen. Der Standard-Benutzername ist admin@admin.net, das Password admin.

Xen Orchestra installieren

Xen Orchestra aktualisieren

Wenn man Xen Orchestra fertig eingerichtet hat und sollte man es natürlich aktuell halten, um alle Sicherheitsupdates und neue Features zu bekommen. Eigentlich bringt jede Version einige neue Features mit, welche die Arbeit mit dem XenServer (bzw. xcp-ng) erweitern oder erleichtern. Der Autor des Installationsskript stellt ein weiteres Skript für die Aktualisierungen bereit. Zu finden ist es ebenfalls auf Github.

Das Aktualisierungsskript bietet verschiedene Optionen an. Zum einfachen Aktualisieren reicht der folgende Aufruf:

$ sudo bash
$ sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash

Nach wenigen Minuten ist Xen Orchestra wieder auf den aktuellen Stand!

Wer sich unwohl dabei fühlt ein Skript aus dem Netz als root laufen zu lassen, kann sich das Skript natürlich vorher noch genau anschauen, was es macht bzw. nicht macht 🙂

Fazit

Xen Orchestra ist ein tolles Projekt. Unser XenServer lässt sich damit leicht verwalten. Backups sind schnell angelegt (seit neustem auch Backups der Konfiguration von Xen Orchestra) inklusiver Benachrichtigungen (eMail oder nach Slack / Mattermost). Diese beiden Skripts haben uns das Leben sehr erleichtert. Ein großes Dankeschön an Jarli01!

1 Kommentar

Der Beitrag Xen Orchestra installieren und aktualisieren (Vollversion) erschien zuerst auf .:zefanjas:..

Zammad sichern und wiederherstellen

Von: zefanja
06. Juli 2019 um 07:05

Seit einigen Jahren verwenden wir Zammad als Support- bzw. Helpdesk-Software in unserer Schule. Wir sind damit sehr zufrieden, denn Zammad bietet viele Features und ein angenehm zu bedienende Benutzeroberfläche. Vor einiger Zeit mussten wir unseren Server umziehen und somit auch unsere Zammad-Installation. In diesem Artikel möchte ich kurz zeigen, wie man Zammad sichern und wiederherstellen kann.

Zammad sichern

Zammad bietet von Haus aus ein Backup-Skript, welches aber standardmäßig deaktiviert ist. Man kann das Skript dazu benutzen, um regelmäßige Backups anzulegen. Es befindet sich unter /opt/zammad/contrib/backup/. Das Backup-Skript greift auf eine Konfigurationsdatei zu, in der alle wichtigen Einstellungen vorgenommen werden. Diese Datei muss man zuerst umbenennen:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Anschließend öffnet man die Datei und kann einige wenige Dinge einstellen:

$ nano /opt/zammad/contrib/backup/config 

...
BACKUP_DIR='/var/tmp/zammad_backup'
HOLD_DAYS='10'
DEBUG='no'

BACKUP_DIR legt fest, wohin die Backups gespeichert werden sollen. Das Verzeichnis muss existieren! HOLD_DAYS gibt an, wie lange ein bzw. wie viele Backup(s) aufbewahrt werden sollen.

Nun kann man das Backup-Skript ausführen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_backup.sh

Das Skript legt zwei Archive an (Datenbanksicherung und Zammad-Ordner), die sich nun im konfigurieren Backup-Ordner befinden.

Hinweis: Wenn man eine Installation migrieren möchte, ist es sinnvoll, Zammad vorher anzuhalten und erst dann das Backup zu erstellen. Das spielt aber nur bei größeren Installationen eine Rolle.

Zammad wiederherstellen

Wenn man ein Backup auf dem gleichen Host wiederherstellen möchte, kann man das mit dem Wiederherstellungsskript erledigen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Fertig 🙂

Wenn man allerdings eine Zammad-Installation umziehen möchte (Migration, Neuinstallation), gibt es einige Dinge zu beachten:

  • Zammad muss installiert sein (inklusive Elasticsearch)
  • die Zammad-Version sollte gleich oder höher sein (als die vom Backup)
  • es sollte die gleiche Datenbank verwendet werden (ein Wechsel ist wohl möglich, aber sehr aufwändig, da die Daten abgepasst werden müssen).
  • Es sollte genügend freier Speicherplatz vorhanden sein (ca. 2x so viel wie die Größe des Backups)

Wenn alle Bedingungen erfüllt sind, muss man zuerst die Konfiguration auf dem Zielsystem aktivieren:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Danach die Backupdateien in den konfigurierten Backup-Ordner kopieren (mit cp oder wenn man LXD-Container verwendet mit lxc file push/pull) und letztendlich das Wiederherstellungsskript laufen lassen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Weitere Informationen finden sich in der offiziellen Dokumentation.

Fazit

Zammad bringt einen einfachen Sicherungs- und Wiederherstellungsmechanismus mit, der zuverlässig funktioniert. Wer seine Zammad-Installation nicht anderweitig sichert, kann für das Backup-Skript auch einen Cron-Job einrichten, um regelmäßig ein Backup zu erstellen.

 

1 Kommentar

Der Beitrag Zammad sichern und wiederherstellen erschien zuerst auf .:zefanjas:..

keys.openpgp.org als Standard setzen

29. Dezember 2019 um 05:00

keys.openpgp.org ist aktuell die einzige Alternative zu den alten SKS-Keyservern. In diesem Beitrag zeige ich euch wie ihr den keys.openpgp.org als Standard-Schlüsselserver hinterlegt nano ~/.gnupg/gpg.conf Dort eintragen: keyserver hkps://keys.openpgp.org/ Alle anderen „keyserver“ Einträge mit...

Schulserverlösung linuxmuster.net Version 7 veröffentlicht

Von: zefanja
17. April 2020 um 01:58

Knapp vier Jahre nach dem letzten Release wurde heute die neue Version 7 von linuxmuster.net veröffentlicht. Damit ist ein weiterer wichtiger Meilenstein in der Geschichte der freien Open Source Schulserverlösung erreicht.

Zum Release wird es heute (17.04.) um 15:00 Uhr (MESZ) eine kleine Präsentation der LMN 7 geben (virtuell über BigBlueButton): https://bz-pfinztal7.dynalias.org/b/gad-tnt-hdg. Das Passwort für den Raum wird ca. 15min vorher hier veröffnetlicht. Jeder ist herzlich eingeladen.

Was ist neu?

Mit Version 7 haben sich einige Dinge im Vergleich zu den Vorversionen geändert. Hier die wichtigsten Änderungen im Überblick:

  • Wechsel von Samba 3 auf Samba 4 (mehr als nötig, um ein aktuelles Serverbetriebssystem einsetzen zu können, Samba 4 macht weiterhin die Anbindung von Windows und anderer Software leichter)
  • OPNSense ersetzt die bisherige Firewall (IPFire)
  • neue Schulkonsole (webbasierte Administration) ist moderner (Responsive Design, etc.)
  • Version 7 ist mehrschulfähig, d.h. es lassen sich mit einer Installation mehrere Schulen verwalten
  • Netzwerksegmente / IP-Bereiche sind frei wählbar (das war vorher nur sehr eingeschränkt der Fall)

Schulkonsole

weitere (bekannte) Features

Neben den oben genannten Veränderungen bringt linuxmuster.net noch weitere Features mit, die bereits in den vorhergehenden Versionen enthalten waren.

  • Linbo – für mich das Killerfeature bei linuxmuster.net, weil es einem sehr sehr viel Arbeit bei der Verwaltung der Schulcomputer und -laptops abnimmt. Mit Linbo lassen sich viele Rechner und Konfigurationen sehr einfach (und sogar aus der Ferne) verwalten (siehe auch „Warum Linbo eines der besten Features von linuxmuster.net ist„).
  • Schulkonsole – in der Schulekonsole lassen sich alle administrativen und pädagogischen Funktionen steuern, wie z.B. Zugang zum Internet / WLAN ein/ausschalten, Aufgaben verteilen und einsammeln, Klassenarbeitsmodus, etc.

Umsteigen?

Wir verwenden aktuell noch Version 6.2 bei uns an der Schule. In den nächsten Wochen werden wir aber den Umstieg vorbereiten und Version 7 installieren, testen und einen neuen Linuxclient einrichten. Bisher haben wir noch Ubuntu 16.04 auf den Rechnern, welches aber durch ein aktuelles OS (Ubuntu? Kubuntu? Xubuntu?) ersetzt werden soll.

Alle, die bisher eine andere Schulserverlösung einsetzen, sollten meiner Meinung nach mal den Blick über den Tellerrand wagen und sich mit linuxmuster.net auseinandersetzen. Es ist ein System, welches von vielen engagierten Lehrkräften weiterentwickelt wird und somit nah an Schule ist. Die Community (https://ask.linuxmuster.net) ist sehr hilfbereich und man bekommt Hilfe zu allen Themen rund um Schul-IT.

Der Beitrag Schulserverlösung linuxmuster.net Version 7 veröffentlicht erschien zuerst auf zefanjas.

Koha LDAP / AD Verbindung einrichten

Von: zefanja
23. Juli 2020 um 09:40

Koha ist eine freie Bibliothekssoftware, die wir an unserer Schule verwenden. Wir verwalten damit unsere Lehrmittel- als auch unsere Schulbibliothek. Vorher haben wir LITTERA dafür verwendet, doch seit letztem Sommer sind wir komplett auf Koha umgestiegen. Der Kern unserer Schulinfrastruktur ist ein linuxmuster.net Schulserver. Jeder Schüler und Kollege hat einen schulinternen Benutzernamen, den man für die Anmeldung an unseren Schulcomputern braucht. linuxmuster.net bringt dafür einen LDAP Server mit. In diesem Artikel möchte ich zeigen, wie man in Koha die LDAP Verbindung einrichtet, sodass sich alle Benutzer in der Bibliothek mit ihrem schulinternen Login anmelden können.

Koha an Active Directory / AD anbinden (ab linuxmuster.net v7)

Linuxmuster.net v7 bringt einen Samba 4 Active Directory mit sich. Dadurch hat sich auch die Anbindung an Koha im Vergleich zur Vorgängerversion geändert. Die Einstellungen befinden sich immer noch in der /etc/koha/sites/library/koha-conf.xml (falls die Koha-Instanz library heißt). Diese Datei müssen wir nun wie folgt bearbeiten:

<ldapserver id="ldapserver"  listenref="ldapserver">
  <hostname>ldaps://10.16.1.1</hostname>
  <base>ou=schools,dc=linuxmuster,dc=net</base>
  <user>cn=global-binduser,ou=Management,ou=GLOBAL,dc=linuxmuster,dc=net</user><!-- DN, if not anonymous -->
  <pass>Bind-User-Passwort</pass><!-- password, if not anonymous -->
  <replicate>1</replicate>       <!-- add new users from LDAP to Koha database -->
  <update>1</update>             <!-- update existing users in Koha database -->
  <anonymous_bind>0</anonymous_bind>
  <auth_by_bind>1</auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison -->
  <principal_name>%s@linuxmuster.net</principal_name>
  <update_password>0</update_password>
  <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid -->
  <mapping>             <!-- match koha SQL field names to your LDAP record field names -->
   <userid       is="samAccountName"></userid>
   <email        is="mail"></email>
  </mapping>
</ldapserver>

Dazu ein paar kurze Hinweise:

  • <hostname>: Hier müssen wir die Addresse des LDAP-Servers (der linuxmuster.net Server) angeben. Weiterhin müssen wir sichergehen, dass unser Koha Server den LDAP-Server auch über die Ports (TCP/UDP 636) für LDAPS erreichen kann.
  • <base>: Der LDAP Pfad für unsere Benutzeraccounts. Die Domain am Ende muss wahrscheinlich angepasst werden.
  • <user>: der Bind-User, damit Koha an die Benutzerdaten herankommt.
  • <pass>: Das Passwort des Bind-Users. Es befindet sich auf dem linuxmuster.net Server unter /etc/linuxmuster/.secret/global-binduser
  • <replicate>: Wenn sich ein Benutzer per LDAP anmeldet, möchten wir, dass er auch ein Koha-Konto bekommt.
  • <update>: Diese Option brauchen wir, damit Benutzer mit Informationen aus dem LDAP aktualisiert werden, falls bereits ein Koha-Konto existiert.
  • <auth_by_bind>: Für die Überprüfung der Anmeldedaten wollen wir den Bind-User verwenden. Für Active Directory muss diese Option 1 sein.
  • <principal_name>: Das ist wahrscheinlich der schwierigste Teil. Am besten eignet sich der userPrincipalName aus dem AD. Bei linuxmuster.net v7 steht dort user@linuxmuster.net (Domain wieder anpassen!). User wird hier durch %s ersetzt (das wiederrum durch das mapping weiter unten bestimmt wird).
  • <mapping>: Hier können wir festlegen, welche Daten aus dem LDAP welches Attribut in Koha überschreiben soll. Wichtig ist vor allem userid, denn diese wird verwendet, um das %s in <principal_name> zu ersetzen. Bei Samba 4 / AD sieht das Mapping so aus: <userid is=“samAccountName„></userid>

Konfiguration für Koha LDAP Verbindung anpassen (bis linuxmuster.net v6.2)

Koha speichert seine Einstellungen in der Datei koha-conf.xml. Diese Datei befindet sich unter /etc/koha/sites/library/koha-conf.xml, falls die Koha-Instanz library heißt. Diese Datei öffnen wir mit einem Editor unserer Wahl und suchen den Eintrag <useldapserver>0</useldapserver>.

$ sudo nano /etc/koha/sites/library/koha-conf.xml

Die Dokumentation für die Koha LDAP Verbindung ist leider nicht sehr ausführlich. Die wesentlichen Informationen findet man in der Perl-Dokumentation zum Koha LDAP-Modul. Auf dieser Seite finden wir eine Beispielkonfiguration, die wir größtenteils übernehmen können. Ein paar kleine Änderungen sind allerdings notwendig, damit die Integration zwischen Linuxmuster und Koha auch gut funktioniert. Zuerst ändern wir <useldapserver>0</useldapserver> in <useldapserver>1</useldapserver>, um Koha mitzuteilen, dass wir gern einen LDAP-Server für die Anmeldung verwenden wollen. Direkt danach fügen wir folgende Zeilen ein:

 <ldapserver id="ldapserver"  listenref="ldapserver">
  <hostname>ldaps://10.16.1.1</hostname>
  <base>ou=Accounts,dc=linuxmuster,dc=net</base>
  <user>cn=admin,dc=linuxmuster,dc=net</user><!-- DN, if not anonymous -->
  <pass>Bind-User-Passwort</pass><!-- password, if not anonymous -->
  <replicate>1</replicate>       <!-- add new users from LDAP to Koha database -->
  <update>1</update>             <!-- update existing users in Koha database -->
  <auth_by_bind>1</auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use A$
  <principal_name>uid=%s,ou=Accounts,dc=internal,dc=cdsc,dc=ac,dc=th</principal_name>
  <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid -->
  <mapping>             <!-- match koha SQL field names to your LDAP record field names -->
   <userid       is="uid"></userid>
   <password     is="userpassword"></password>
   <email        is="mail"></email>
  </mapping>
</ldapserver>

Dazu ein paar kurze Hinweise:

  • <hostname>: Hier müssen wir die Addresse des LDAP-Servers (der linuxmuster.net Server) angeben. Weiterhin müssen wir sichergehen, dass unser Koha Server den LDAP-Server auch über die Ports (TCP/UDP 636) für LDAPS erreichen kann.
  • <base>: Der LDAP Pfad für unsere Benutzeraccounts. Die Domain am Ende muss wahrscheinlich angepasst werden.
  • <user>: der Bind-User, damit Koha an die Benutzerdaten herankommt.
  • <pass>: Das Passwort des Bind-Users. Es befindet sich auf dem linuxmuster.net Server unter /etc/ldap/ldap.secret
  • <replicate>: Wenn sich ein Benutzer per LDAP anmeldet, möchten wir, dass er auch ein Koha-Konto bekommt.
  • <update>: Diese Option brauchen wir, damit Benutzer mit Informationen aus dem LDAP aktualisiert werden, falls bereits ein Koha-Konto existiert.
  • <auth_by_bind>: Für die Überprüfung der Anmeldedaten wollen wir den Bind-User verwenden.
  • <mapping>: Hier können wir festlegen, welche Daten aus dem LDAP welches Attribut in Koha überschreiben soll. Wichtig ist vor allem userid und password.

Koha LDAP / AD Verbindung testen

Um die LDAP Verbindung zu testen, rufen wir die Koha OPAC Seite auf und melden uns mit einem linuxmuster.net Benutzeraccount an. Sollte es Probleme beim Laden der Website geben oder die Anmeldung nicht klappen, kann man auf dem Koha-Server unter /var/log/koha/library/opac-error.log nachschauen, woran es liegt.

koha login

Falls die Anmeldung erfolgreich war, sieht man eine Liste mit den aktuellen Ausleihen des Benutzers:

koha user

Koha LDAP / AD Verbindung per Kommandzeile testen

Gerade beim Einrichten der Verbindung zum LDAP / AD Server geht es schneller, wenn man direkt auf der Kommandozeile testen kann, ob die Konfiguration richtig ist. Dazu gibt man die folgenden Befehle ein:

$ service koha-common restart && service memcached restart
$ export PERL5LIB=/usr/share/koha/lib/ && export KOHA_CONF=/etc/koha/sites/library/koha-conf.xml && perl /usr/share/koha/opac/cgi-bin/opac/opac-user.pl userid=user1 password=foo

Der Pfad zur koha-conf.xml, sowie user und password müssen wir natürlich noch anpassen.

Fazit

Die Einrichtung der LDAP Verbindung in Koha bringt für unsere Schule einen großen Mehrwert. Vorher war es mit LITERRA nicht möglich, dass einzelne Benutzer ihre aktuellen Ausleihen sehen konnten. Weiterhin müssen jetzt die Benutzerdaten nur noch an einem Ort gepflegt werden und nicht in verschiedenen Programmen. Die Bedienung über ein Webinterface ist für alle Bibliotheksmitarbeiter ein großer Gewinn und eine Arbeitserleichterung. Der Einstieg in Koha ist vielleicht etwas steiler als in andere Bibliotheksprogramme, aber die Möglichkeiten und Flexibilität dieser Open Source Software sind beeindruckend.

Der Beitrag Koha LDAP / AD Verbindung einrichten erschien zuerst auf zefanjas.

Die 5 besten Open Source Anwendungen für eine Schule

Von: zefanja
09. Oktober 2020 um 00:39

Seit vielen Jahren setzen wir stark auf Open Source Anwendungen in unserer Schule – auf dem Server, aber auch auf den Computern und Laptops. Vor allem im Serverbereich ist Open Source Software weit verbreitet und es gibt viele tolle Softwareprojekte, die sich wunderbar in einer Schule einsetzen lassen. Heute möchte ich deshalb meine 5 Favoriten vorstellen.

Koha

koha

Koha ist ein integriertes Bibliothekssystem. Es wird weltweit in öffentlichen, Schul- und anderen Bibliotheken eingesetzt. Auch wir haben vor ca. 5 Jahren unsere Bibliothek auf diese Software umgestellt. Koha bringt sehr viele Features mit und ist flexibel in der Konfiguration. Der Einstieg ist, wenn man nicht gerade vom Fach ist, etwas steil, aber man wird dafür mit einem tollen System belohnt. Wer mehr über Koha und den Einsatz in Schulen erfahren möchte, sollte sich diese kleine Blog-Post Serie anschauen.

xcp-ng / LXD

xcp-ng

Mein nächster Favorit betrifft die Serverinfrastruktur. Wer eigene Server in der Schule betreibt, muss sich mit der Frage beschäftigen, welchen Hypervisor er einsetzen will. Die Auswahl ist groß und man kann zwischen einigen Open Source Optionen wählen. Wir haben uns vor Jahren für xcp-ng entschieden (aus XenServer hervorgegangen). Dazu setzen wir XenOrchestra ein, um die Server zu verwalten. Mit xcp-ng verwalten wir unsere virtuellen Maschinen.

Die meisten unserer (Web)Anwendungen laufen aber in Linuxcontainern. Dafür verwenden wir LXD – ein Container-Hypervisor. LXD bringt mit lxc einen sehr einfach zu bedienende Anwendung mit, um Container zu erstellen, Backups zu erstellen, usw. Der große Vorteil von Linuxcontainern ist für mich, dass ich sie genauso wie eine virtuelle Maschine verwalten, konfigurieren und administrieren kann. Dafür sind sie wesentlich ressourcensparender als eine VM. Seit dem 4.0 Release kann man sogar „richtige“ VMs mit LXD erstellen und verwalten!

pfSense

pfsense

Für mich ist pfSense eines der besten Open Source Firewall Systeme. PfSense kann man einfach installieren und benutzen und läuft seit Jahren sehr stabil in unserem Netzwerk. Mit pfBlockerNG hat man zusätzlich ein sehr mächtiges Werkzeug, um Werbung, Malwareseiten u.v.a. aus dem Netzwerk fernzuhalten (Webfilter auf DNS Basis).

linuxmuster.net

linuxmuster.net

Über linuxmuster.net habe ich schon oft in diesem Blog geschrieben. Linuxmuster.net ist eine Open Source Schulserverlösung, mit der man Benutzer (Lehrkräfte, Schüler/innen) und Schulcomputer einfach verwalten kann. LINBO, ein Werkzeug von linuxmuster.net, ist für mich eines der wichtigsten Features, denn damit kann ich alle Schulcomputer mit nur einem Image verwalten, auch wenn sie unterschiedliche Konfigurationen haben.

Nextcloud

nextcloud

Nextcloud darf in dieser Liste nicht fehlen. Gerade in den letzten Monaten sind eine Menge neuer Features dazugekommen, die auch im Schulumfeld sehr nützlich sind. Nextcloud ist dabei weit mehr, als nur eine gemeinsame Dateiablage. Durch die vielen Erweiterungen kann man Nextcloud sehr an die individuellen Bedürfnisse anpassen. Egal ob Online Office Suite, Videokonferenz oder einfach nur ein gemeinsamer Kalender – vieles ist mit Nextcloud möglich.

Bonus: Zammad

zammad

Noch eine kleine Bonusempfehlung am Ende: Zammad. In den letzten Jahren haben wir verschiedene Service Desk / Helpdesk Anwendungen ausprobiert. Letztendlich sind wir bei Zammad gelandet und es gefällt uns sehr gut. Wie auch alle anderen Empfehlungen hier, bringt es viele nette Features mit. Es lässt sich gut in die bestehende Infrastruktur integrieren und man kann über viele verschiedene Kanäle Tickets erstellen (Soziale Netzwerke, eMail, Chat, …).

Fazit

Die Liste hier könnte man noch beliebig erweitern. Gerade für den Infrastrukturbereich gibt es eine große Menge an Open Source Anwendungen. Allein diese Liste spricht für sich: https://github.com/awesome-selfhosted/awesome-selfhosted. Moodle oder Mahara sollten eigentlich auch noch mit aufgenommen werden, aber damit haben wir bisher kaum Erfahrung sammeln können.

Welche Open Source Anwendungen gehören zu deinen Favoriten, die in keiner Schule fehlen sollten?

Der Beitrag Die 5 besten Open Source Anwendungen für eine Schule erschien zuerst auf zefanjas.

Fehlermeldung nach Nextcloud-Upgrade auf Version 21.0.3

12. August 2021 um 05:05

Beim Upgrade auf die Version 21.0.3 meiner Nextcloud erhielt ich folgende Fehlermeldung:

Letzte Cron-Job-Ausführung: Vor 5 Stunden. Check the background job settings.

Die Hintergrund-Aufgaben via CronDen System-Cron-Dienst verwenden, um die Datei cron.php alle 5 Minuten aufzurufen. Die cron.php muss durch den Systemnutzer „www-data“ ausgeführt werden.„, konnten nicht mehr ausgeführt werden.

Normalerweise kommt es i.d.R. zu solchen Meldungen eher beim Upgrade auf die nächste Major-Version. Da ich diesen Fehler nun auf zwei betreuten Nextcloud-Instanzen feststellen musste, konnte es nur etwas mit der Konfiguration der Server zu tun haben.

Nach ein wenig Recherche im Netz fand ich die Lösung. Das Command Line Interface des PHP Cache musste explizit nachträglich aktiviert werden. Wenn ich das richtig deute, ist dies aber nur in meiner älteren PHP 7.3 nötig.

Hierzu öffnet man im Editor nun die Config /etc/php/7.3/mods-available/apcu.ini mit

sudo nano /etc/php/7.3/mods-available/apcu.ini

trägt folgende Zeile am Ende ein

apc.enable_cli=1

und speichert diese ab. Bei Verwendung von FPM startet man das Ganze neu.

sudo /etc/init.d/php7.3-fpm restart

Wer kein FPM aktiviert hat, führt einen Restart des Webservers durch.

SWAP des Raspberry Pi vergrößern

03. November 2021 um 17:39

Neulich hatte ich Bedarf den SWAP eines Raspberry Pi, auf dem ein Raspberry Pi OS läuft, zu erweitern, da dieser ständig überlief. Hier sind per Standard 100MB eingerichtet. Diesen Wert galt es nun auf 1000MB anzuheben.

Diese Änderung kann ganz einfach wie folgt umgesetzt werden. Dazu ruft man mit dem Editor Nano die Datei  /etc/dphys-swapfile auf

sudo nano /etc/dphys-swapfile

sucht den entsprechenden Eintrag und ändert den Wert, wie im Beispiel auf 1000.

CONF_SWAPSIZE=1000

Nach dem Abspeichern via Ctrl + o, dem Verlassen des Editors mit Ctrl + x und einem anschließenden Reboot, steht die neue Größe des SWAP-Speichers zur Verfügung.

sudo reboot

NextcloudPi angesehen

04. Januar 2022 um 17:18

Wie schön wäre es doch, seine Daten sicher zu Hause aufzubewahren, sie immer und überall verfügbar zu haben und diese nicht an zweifelhafte Cloud-Dienstleister auszulagern. Geht das? Na klar, mit der Nextcloud!

Hierzu benötigt man nicht viel. Ein Raspberry Pi mit Internetanschluss und etwas Interesse sich mit dieser interessanten Materie zu beschäftigen reicht völlig aus. Ich bevorzuge generell die klassische Installation der Cloud-Software auf einem LAMP-Server.

Einen etwas einfacheren Weg zur eigenen Cloud geht OWN YOUR BITS. Die Entwickler stellen komplette Images zur Verfügung, um die Cloud ohne Linux-Erfahrung in den eigenen vier Wänden zu realisieren.

Installation

Ich habe mir nun einmal NextcloudPi für den Raspberry Pi etwas genauer angesehen. Das Image hierzu ist 4,3GB groß und kann direkt von der Webseite kostenlos heruntergeladen und eingesetzt werden. Dabei muss man natürlich aufpassen, dass das richtige Download-Paket ausgewählt wird. Ist dies geschehen, wird das Image entpackt und z.B. mit dem Raspberry Pi Imager auf eine mindestens 16GB-große MicroSD geschrieben.

Der erste Kontakt

Nachdem die MicroSD in den Raspberry Pi eingelegt und dieser gestartet wurde (ohne Bildschirm, Tastatur und Maus), erreicht man NextcloudPi über die lokale Adresse https://nextcloudpi.local im heimischen Netzwerk. Voraussetzung ist jedoch der vorherige Anschluss des Einplatinencomputers über LAN-Kabel an den Router.

Wenn alles funktioniert, wird man nach dem Booten von folgendem Bildschirm begrüßt. 

NextcloudPi – Erstkontakt

Hier bekommt man Benutzernamen und Passwörter für das NextcloudPi Webinterface sowie die Nextcloud. Nach der Aktivierung gelangt man nun in den NextcloudPi-Maschinenraum. Dazu wird das erste Passwort benötigt, welches später auch geändert werden kann. Weiter geht es mit einem Installations-Wizard, welcher dabei hilft die Cloud mit einer Festplatte oder SSD über USB zu erweitern. Außerdem hat man nun die Möglichkeit das System über einen DynDNS-Anbieter von außen über das Internet erreichbar zu machen.

NextcloudPi – Installations-Wizard

Im Webinterface lassen sich serverseitig einige Einstellungen erledigen, ohne jedoch wirklich selbst Serverkenntnisse besitzen zu müssen. Das birgt allerdings die Gefahr, dass das System ungewollt beschädigt werden kann, was mir tatsächlich einige Male gelungen ist. Um nun in solch einer Situation zur Reparatur selbst Hand anzulegen, muss an den Raspberry Pi ein Monitor und eine Tastatur angeschlossen werden, damit auf den eigentlichen Server zugegriffen werden kann. Dies geht nun direkt auf dem Raspberry Pi oder nach SSH-Aktivierung von einem anderen Computer. Im letzteren Fall kann der RasPi wieder von den zuvor angeschlossenen Peripheriegeräten getrennt werden. Ohne ein wenig Linux-Erfahrung ist man aber hier aufgeschmissen.

Die Nextcloud

Die Nextcloud erreicht man nach erfolgreicher Beendung der Installationsroutine über https://nextcloudpi oder die vom Router für den Raspberry Pi vergebene IP-Adresse. In meinem Fall: https://192.168.178.32. Falls die DynDNS-Adresse zu diesem Zeitpunk schon eingerichtet und in die config.php über das Webinterface aufgenommen wurde, wäre die Nextcloud-Instanz auch über die vergebene Web-Adresse erreichbar, vorausgesetzt die Ports 80 und 443 sind am Router auf Port Forwarding gesetzt.  Das Login erfolgt nun über das am Anfang vergebene zweite Passwort. Begrüßt wird der neue Nutzer nun erstmalig von der eigenen Cloud-Instanz. Ratsam wäre es hier, einen neuen Benutzer als Administrator anzulegen und den User ncp später zu löschen.

Nextcloud - Login

Auch in der Nextcloud sind Änderungen am System mit äußerster Vorsicht vorzunehmen! Die Erstellung eines Backups ist aus meiner Sicht vorher ebenfalls unverzichtbar. So wurde ich z.B. nach einem App-Upgrade komplett ausgesperrt, da die Cloud dauerhaft im Wartungsmodus verharrte.

Auch anzumerken ist, dass die verwendete Nextcloud-Version nicht up to date ist, wie auch das auf Debian basierende Raspberry Pi OS. Das ist aber nicht weiter schlimm, da diese Versionen eine Langzeitunterstützung seitens der Entwickler erfahren. Die aktuelle Nextcloud-Version ist die 23. Auf NextcloudPi läuft Version 21 und Raspberry Pi OS 10, aktuell v11.

Nextcloud – Fehlermeldungen

Wie man oben im Bild sehen kann, kommt es noch zu diversen Fehlermeldungen, die ebenfalls ohne Serverkenntnisse nicht beseitigt werden können. Es müssen Pakete nachinstalliert werden, bzw. sind Eingriffe in die Konfigurationsdatei der Nextcloud-Instanz notwendig.

Fazit

NextcloudPi ist mit Sicherheit ein interessantes Projekt, welches es dem User erlaubt, schnell eine eigene Nextcloud-Instanz auf dem Einplatinencomputer Raspberry Pi einzurichten und in Betrieb zu nehmen. Die Erreichbarkeit aus dem Internet wird bei Bedarf über eine DynDNS-Adresse realisiert. Wer nicht die neueste Version der Nextcloud einsetzen muss und bereit zu Abstrichen ist, für den ist das System durchaus empfehlenswert.

Meinen Zugang zur Cloud konnte ich problemlos via 2FA mit einem YubiKey absichern.

Leider fehlt ein Turn-Server im System, welcher es quasi unmöglich macht Videokonferenzen via nachinstallierter App Talk zu führen. Ein Turn-Server kann aber im Nachhinein auf dem Raspberry Pi noch nachinstalliert werden. Auch hierzu sind Linux-Kenntnisse von Vorteil.

Standort in Flightradar festlegen

28. Januar 2022 um 16:58

Vor einiger Zeit hatte ich schon einmal einen Artikel zum Thema Luftraumüberwachung mit Flightradar24  geschrieben. An der eigentlichen Vorgehensweise der Installation und der einzusetzenden Hardware hat sich nichts gravierend geändert.

Der Befehl zur Installation des entsprechenden Pakets setzt jetzt allerdings SSL voraus.

sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

Ich habe mich allerdings inzwischen für einen stärkeren Empfänger der Firma Nooelec mit RTL2832U/R820T2-Chip entschieden, was ein wenig mehr Reichweite bringt.

Standort sichtbar machen

Heute möchte ich zeigen, wie man auf der lokalen Karte den Standort der Station als Punkt markiert und Radien im Abstand von 50 NM um die Station einzeichnet (siehe Screenshot).

lokale Darstellung der empfangenen Flugzeuge

Hierfür ist es nötig die Konfigurationsdatei /etc/dump1090-mutability/config.js entsprechend anzupassen. Dazu werden die Einträge wie folgt geändert:

alte Konfiguration

// -- Map settings ----------------------------------------
...
// Default center of the map.
DefaultCenterLat = 45.0;
DefaultCenterLon = 9.0;
...
SiteShow = false; // true to show a center marker
SiteLat = 45.0; // position of the marker
SiteLon = 9.0;
SiteName = "My Radar Site"; // tooltip of the marker
...
// -- Marker settings -------------------------------------
...
SiteCircles = true; // true to show circles (only shown if the center marker is shown)
// In nautical miles or km (depending settings value 'Metric')
SiteCirclesDistances = new Array(100,150,200);
...

Unter DefaultCenterLat und DefaultCenterLon trägt man nun die Koordinaten der Empfangsstation ein, um die Karte bei Aufruf auf den entsprechenden Standort zu zentrieren. Die gleiche Vorgehensweise erfolgt unter SiteShow. Hierbei muss die Vorgabe jedoch noch von false auf true geändert werden. Die Radien legt man unter SiteCircles fest. In meinem Fall 50, 100 und 150 NM.

neue Konfiguration

// -- Map settings ----------------------------------------
...
// Default center of the map.
DefaultCenterLat = 51.44871;
DefaultCenterLon = 11.98762;
...
SiteShow = true; // true to show a center marker
SiteLat = 51.44871; // position of the marker
SiteLon = 11.98762;
SiteName = "My Radar Site"; // tooltip of the marker
...
// -- Marker settings -------------------------------------
...
SiteCircles = true; // true to show circles (only shown if the center marker is shown)
// In nautical miles or km (depending settings value 'Metric')
SiteCirclesDistances = new Array(50,100,150);
...

Viel Spaß!

Red Hat Enterprise Linux 8.6 veröffentlicht

11. Mai 2022 um 19:04
Red Hat gab die allgemeine Verfügbarkeit seiner Linux Business Server Lösung Red Hat Enterprise Linux (RHEL) 8.6 als neuestes Update seiner Red Hat Enterprise Linux 8 Betriebssystemserie bekannt. Red Hat Enterprise Linux 8.6 kommt mehr als sechs Monate nach Red Hat Enterprise Linux 8.5 und ist das fünfte Wartungsupdate für Red Hat Enterprise Linux 8...

Red Hat Enterprise Linux 9 (RHEL 9) wurde veröffentlicht

18. Mai 2022 um 18:25

Red Hat hat heute die allgemeine Verfügbarkeit von RHEL 9 bekanntgegeben. Nach rund sechs Monaten Entwicklung erschien nun mit RHEL 9 das unternehmenstaugliche Linux Betriebssystem mit erstklassiger Leistung. RHEL 9 kommt u.a. mit Linux Kernel 5.14 und führt verbesserte Webkonsolen-Leistungsmetriken ein um verschiedene Bedrohungen, die die Leistung der Systeme beeinträchtigen können, besser zu identifizieren und...

Der Beitrag Red Hat Enterprise Linux 9 (RHEL 9) wurde veröffentlicht erschien zuerst auf MichlFranken.

OpenSuse Leap Micro 5.2: Leichtgewicht für Container

19. Mai 2022 um 10:14

Mit Opensuse Leap Micro bringt die Community ein Pendant zu Suse Linux Enterprise Micro heraus. Die Leap Micro-Ausgabe ist für Workloads in containerisierten und virtualisierten Umgebungen gebaut.

Angeboten wird Opensuse Leap Micro auch als Offline-Image mit Installer. Die Raw- und Selbstinstallation ermögliche eine Anpassung durch Combustion oder manuell im Image, nachdem es auf die Festplatte geschrieben wurde. Combustion ist ein minimales Modul für dracut, das ein vom Benutzer bereitgestelltes Skript beim ersten Start eines Systems ausführt. Es gibt Leap Micro auch eine Option für einen Echtzeit-Kernel.

Aus Sicherheitsgründen sei kein Root-Passwort gesetzt, Nutzer müssten, sofern sie nicht die Offline-Installation verwenden, Ignition oder Combustion verwenden, um es einzurichten, heißt es in der Ankündigung.

Die neue Distribution lässt sich in VMs testen, die entweder auf Xen oder KVM laufen, teilt Opensuse mit. In Verbindung mit Raspberry Pi oder anderer System-on-Chip-Hardware lasse sich das vorkonfigurierte Image zusammen mit der Combustion-Funktionalität für den Boot-Prozess verwenden. Sowohl die vorkonfigurierten als auch die selbst installierten Images seien für die Verwendung mit Combustion vorbereitet, das sich auf einen USB-Stick schreiben lässt, um die gewünschte Konfiguration bei jedem ersten Start zu ermöglichen. Das Projekt stellt auf Youtube eine Installations-Demo mit Combustion bereit. Die Release Notes verlinken die Dokumentation..

Der Beitrag OpenSuse Leap Micro 5.2: Leichtgewicht für Container erschien zuerst auf Linux-Magazin.

Proxmox Backup Server unterstützt Namespaces

20. Mai 2022 um 08:13

Version 2.2 des Proxmox Backup Servers basiert auf Debian 11.3 “Bullseye” und nutzt den neueren Linux-Kernel 5.15 und ZFS 2.1.4. Der Open-Source-Server dient der Sicherung und Wiederherstellung von Systemen, virtuellen Maschinen und Containern.

Eine neue Namespace-Funktion ermöglicht die Verwaltung von Sicherungen aus mehreren Quellen vor Ort, aus der Ferne und in der Cloud zu vereinfachen, indem die Nutzer die Sicherungen in “Namespaces” innerhalb eines einzigen Datenspeichers organisieren, heißt es im Blogbeitrag zur neuen Ausgabe. Dank der Namespaces sei die Wiederverwendung einer einzigen Chunk-Store-Deduplizierungsdomäne für mehrere Quellen möglich, ohne Namenskonflikte auszulösen.

Neu sind auch zwei Wartungsmodi “schreibgeschützt” und “offline”. Die erlauben sicherere Wartungsarbeiten an einem Datastore. Verbesserung im Zusammenspiel mit dem Glibc-System-Allokator sorgen dafür, dass die Spitzen- und Gesamtnutzung des RSS-Speichers drastisch reduziert wird, teilen die Anbieter mit.

Die Release Notes nennen die Details.

Der Beitrag Proxmox Backup Server unterstützt Namespaces erschien zuerst auf Linux-Magazin.

AlmaLinux 9 veröffentlicht

28. Mai 2022 um 18:38

AlmaLinux 9 kommt mit der LTS Serie des Linux Kernels 5.14 und besitzt eine vollständige Kompatibilität mit dem erste kürzlich veröffentlichten Red Hat Enterprise Linux 9 (RHEL 9). AlmaLinux 9 führt neue Funktionen ein, die die Automatisierung und Bereitstellung erleichtern. Weiter sind mit dabei: Netzwerkverbesserungen für Cloud und Edge Zugriff auf Informationen Identifizierung von Engpässen...

Der Beitrag AlmaLinux 9 veröffentlicht erschien zuerst auf MichlFranken.

Red Hat Enterprise Linux 9.0 (Plow) im Test

17. Juni 2022 um 14:00

Der Enterprise Markt im Linux Umfeld wird von drei Firmen mit ihren Distributionen beherrscht. Canonical mit Ubuntu, SUSE Linux mit Suse Linux Enterprise und Red Hat mit Red Hat Enterprise Linux – kurz RHEL. Wir sind hier also in der Königsklasse. Mit RHEL 9.0 (Plow) erschien kürzlich eine neue Hauptversion von Red Hat Enterprise Linux...

Der Beitrag Red Hat Enterprise Linux 9.0 (Plow) im Test erschien zuerst auf MichlFranken.

Nextcloud 24.0.2, 23.0.6 und 22.2.9 verfügbar – Wartungsversionen

Von: jdo
21. Juni 2022 um 09:23

Hier eine kurze und schmerzlose News – es gibt Wartungsversionen für Nextcloud. Genauer gesagt stehen ab sofort Nextcloud 24.0.2, 23.0.6 und 22.2.9 zur Verfügung. Bei kleinen Versionssprüngen sind die Updates normalerweise problemlos. Ich habe auf jeden Fall gerade das Update eingespielt und es ist ohne Probleme durchgelaufen. Die Zweige 22, 23 und 24 werden derzeit offiziell unterstützt. Die Changelogs für die entsprechenden Varianten findest Du auf der Projektseite.

Der Beitrag Nextcloud 24.0.2, 23.0.6 und 22.2.9 verfügbar – Wartungsversionen ist von bitblokes.de.

❌
❌