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 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

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

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

Ü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 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

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.

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.

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

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.

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)

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.

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:..

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 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:..

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:..

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:..