staging.inyokaproject.org

In den letzten Jahren habe ich verschiedene Backuplösungen ausprobiert. Ob es rsync, DejaDup, Borg immer war es das Selbe, dass ich nie wirklich zufrieden bzw. begeistert von der Lösung war. Sicherlich lag es auch daran, dass ich nicht wirklich mich groß umstellen wollte, bzw. ich auch manchmal zu Faul war überhaupt Backups zu machen, was natürlich sehr oft zu einem schlimmer Ergebnis geführt hat :-).

Doch jetzt habe ich für mich die Lösung gefunden. Durch einen kleinen Hinweis auf der Fedora Project Page, konnte ich das Tool meiner Träume finden:

restic

restic ist eine OpenSource Backup Lösung die im Terminal läuft. Einige Vorteile von restic:

• AES-256Bit Verschlüsselung
  • Unterstützung mehrerer Schlüssel
• Unterstützung großer Cloud-Anbieter (Google, AWS…)
• Unterstützung verschiedener Protokolle
• Snapshots
• Inkrementelle Backups

Installation

Die Installation von restic ist sehr gut in der Doku beschrieben. Es gibt für alle großen Distros fertige Pakete.

Repository

restic ähnelt im Konzept und dem Aufbau der Befehlen sehr git. Deswegen ist es auch nicht verwunderlich, dass die Speicherorte für die Backups Repositorys heißen. Im folgenden, werden wir ein lokales Repositiory einrichten. Für externe Repositorys schaut bitte in der Doku für den entsprechenden Aufbau des Befehls nach.

restic init --repo /run/media/malte/Backup/Sicherungen

Mit diesem einfachem Befehl wird uns Repository auf einer externen Festplatte eingerichtet. Nach der Eingabe des Befehls, werdet ihr nach eurem Wunschpasswort für die Repository und dessen Bestätigung gefragt. Wenn alles richtig verlaufen ist sieht es dann so aus:

[malte@FedLin ~] $ restic init --repo /run/media/malte/Backup/Sicherungen/
enter password for new repository: 
enter password again: 
created restic repository 2ba283f830 at /run/media/malte/Backup/Sicherungen/

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Wir haben erfolgreich eine Repository angelegt und können nun mit dem Backupprozess beginnen.

Backup

Um ein Backup durchzuführen, müssen wir nur folgenden Befehl eingeben

restic -r /run/media/malte/Backup/Sicherungen/ backup /home/malte

Mit -r geben wir unsere Repository an, mit backup welcher Befehl durchgeführt werden soll und schlußendlich was man sichern soll. Nach erfolgreicher Sicherung, sieht es dann so aus:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ backup /home/malte
enter password for repository: 
password is correct
using parent snapshot 5b523b51
scan [/home/malte]
scanned 3464 directories, 19166 files in 0:04
[0:10] 100.00%  16.300 GiB / 16.300 GiB  22630 / 22630 items  0 errors  ETA 0:00 
duration: 0:10
snapshot c8c62281 saved

Allerdings bin ich davon ein Freund bestimmte Dateien nicht mit zu sichern, das wären zum Beispiel mein Papierkorb, Cache Files und einiges mehr. Da ich aber nicht alle aufführen will im Befehl mache ich das in einer Exclude Datei. Zum Glück hat auch das schon jemand gemacht: github/rubo77/rsync-homedir-excludes. Um diese Datei nutzen zu können, machen wir folgendes:

wget https://raw.githubusercontent.com/rubo77/rsync-homedir-excludes/master/rsync-homedir-excludes.txt -O /var/tmp/ignorelist

Und jetzt noch schnell den Sicherungsbefehl anpassen:

restic -r /run/media/malte/Backup/Sicherungen/ backup /home/malte --exclude-file="/var/tmp/ignorelist" --exclude="/home/malte/Downloads"

Und fertig.

Snapshots

Mit dem snapshots Befehl ist es möglich die Snapshots zu verwalten:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ snapshots
enter password for repository: 
password is correct
ID        Date                 Host        Tags        Directory
----------------------------------------------------------------------
91c5cf74  2018-04-14 14:57:46  FedLin                  /home/malte
f9f83b20  2018-04-14 15:10:55  FedLin                  /home/malte
9d3ff71e  2018-04-14 15:36:18  FedLin                  /home/malte
5f093a5f  2018-04-14 16:12:05  FedLin                  /home/malte
92f19ae4  2018-04-14 17:24:24  FedLin                  /home/malte
5b523b51  2018-04-14 17:25:47  FedLin                  /home/malte
c8c62281  2018-04-14 18:09:01  FedLin                  /home/malte
----------------------------------------------------------------------
7 snapshots

Um ein Snapshot zu entfernen, ist folgender Befehl nötig:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ forget c8c62281

Jedoch sind die entsprechenden Verlinkungen noch vorhanden, um diese zu löschen, wird noch der folgende Befehl benötigt:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ prune

Wiederherstellen

Es gibt zwei Wege die Backups wiederherzustellen, zurück spielen oder mounten. Der einfachste Weg ist der folgende:

restic -r /run/media/malte/Backup/Sicherungen/ restore latest --target /home/malte

Um einen speziellen Snapshot zurück zuspielen, muss der Befehl ein wenig angepasst werden:

restic -r /run/media/malte/Backup/Sicherungen/ restore 5b523b51 --target /home/malte

Um nur bestimmte Dateien zurück zuspielen, kann man auch einfach ein Snapshot mounten:

restic -r /run/media/malte/Backup/Sicherungen/ mount /mnt

Schlüssel

Es ist sehr einfach die Schlüssel für die Repo zu verwalten:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ key list
enter password for repository: 
password is correct
 ID          User        Host        Created
----------------------------------------------------------------------
*af7f857b    malte       FedLin      2018-04-14 14:57:32
----------------------------------------------------------------------

Um einen neuen Schlüssel hinzuzufügen, muss man einfach nur folgenden Befehl ausführen:

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ key add

Und natürlich kann man den Schlüssel auch löschen

[malte@FedLin Blog] $ restic -r /run/media/malte/Backup/Sicherungen/ key remove af7f857b

Kleiner Tipp für alle, die Algorithmen in Python debuggen möchten: der Pythontutor visualisiert wunderschön, wie eingegebene Algorithmen durchlaufen werden - Schritt für Schritt.

Einfach hier den Sourcecode eingeben, "Visualize Execution" anwählen und schrittweise anschauen, wie dieser bis zum Ergebnis durchlaufen wird.

Besonders gut eignet sich aus meiner Sicht das Tool, wenn man komplexe Algorithmen mit z.B. Rekursion analysieren will. Zum Beispiel eine mögliche Implementierung für die Fibonacci-Zahlen.

Der Sourcecode ist auf GitHub verfügbar.

Bild von pixelcreatures via pixabay / Lizenz: CC0 Public Domain

Die zentralen Paketquellen der meisten Linux-Distributionen erlauben einen kontrollierten Bezug von Software. Kein Herumstöbern im Internet, keine Downloads von ungeprüften Quellen und ein zentrales Sicherheits- und Qualitätsmanagement durch den Distributor galten immer als zentrale Argumente für dieses System. Doch gilt das wirklich so uneingeschränkt?

Das bekannteste Beispiel ist sicherlich Ubuntus universe. Dort liegen die nicht unterstützen Pakete der Distribution, mehr oder minder gewartet von der Community. Je nach Standpunkt ist das mit zunehmendem zeitlichen Abstand zur Veröffentlichung ein Müllkippe oder gar eine tickende Zeitbombe. Das universe ist berühmt-berüchtigt, aber in der Linux-Welt nicht so singulär, wie man das gerne hätte. Die meisten Distributionen haben tausende oder gar zehntausende Pakete in ihren Quellen, auf die sich theoretisch das Supportversprechen erstreckt.

Dabei entwickeln, die Distributoren kaum Software selbst. Die meiste Entwicklungsarbeit erfolgt in den Entwicklungsteams der einzelnen Softwareprojekte, im Jargon "upstream" genannt. So lange die jeweilige Softwareversion hier noch gepflegt wird, muss der Distributor Patches nur anpassen und für die Distribution ausrollen. Doch was passiert, wenn das Upstream-Projekt den Support einstellt? Das ist nicht so theoretisch, wie man es gerne hätte. Die meisten LTS-Distributionen haben deutlich längere Laufzeiten, als die Upstream-Projekte.

Ein Beispiel verdeutlicht das ziemlich gut. Das viel genutzte Toolkit Qt liegt derzeit in Version 5 vor. Die vorangegangene Version 4 ist seit 2015 nicht mehr unterstützt. Trotzdem liefern sie nach zahlreiche Distributionen aus, weil sie immer noch die Basis für viele Anwendungen darstellt, die immer noch nicht auf Version 5 portiert wurden. Den Finger in die Wunde hat nun das Debian-Projekt gelegt, indem es Qt4 für die kommenden Versionen aus den Paketquellen entfernt hat. Die Ankündigung zeigt auch, wie kompliziert es ist eine offiziell abgekündigte Version weiter zu pflegen - selbst für ein professionelles Security-Team wie das von Debian. Ubuntu wird Qt4 trotzdem noch für die kommende LTS 18.04 ausliefern, wenn auch nur in universe. OpenSUSE will für die kommende Leap-Version 15 ebenfalls an Qt4 festhalten, weil davon noch so viel abhängt.

Natürlich muss man relativierend sagen, dass nicht jeder ungelöste Fehler und jede semi-kritische Sicherheitslücke gleich eine Katastrophe darstellt. Nicht jedes Problem destabilisiert gleich das gesamte System. Wobei es auch Pakete gibt, die deutlich kritischer sind und ebenso wenig gewartet werden. Man denke nur an die zahllosen Browser auf WebKit-Basis, welche je nach Versionsstand katastrophale Sicherheitslücken hat.

Der normale Benutzer bekommt von solchen Schwierigkeiten nichts mit. Er installiert Software aus den offizielle Paketquellen und fühlt sich sicher. Die oben thematisierten Distributionen gehören zudem zweifelsohne zu den Vorreitern in Sachen Verbreitung und Qualität in der Linux-Welt. Wie das bei den unzähligen Nischenprojekten und Forks aussieht möchte man gar nicht erst prüfen.

Das bisherige System ist also alles andere als perfekt, das sollte man im Hinterkopf behalten, wenn man möglicherweise veraltete Bibliotheken als großes Risiko in den kommenden Formaten Snap und Flatpak anprangert.

Zudem sollte man sich nicht zu sicher fühlen. Die Linux-Distributionen sitzen auf riesigen ungelösten Baustellen. Bei einer höheren Verbreitung haben viele davon das Potenzial einem um die Ohren zu fliegen. Daran sollte man denken, wenn man mal wieder die vermeintlich überlegene Sicherheitsarchitektur von Linux anpreist.

Beim Start einer Ubuntu-Installationen wird ein Splash Screen angezeigt. Möchte man stattdessen dauerhaft die Statusmeldungen beim Hochfahren sehen, so kann dies über die GRUB-Konfiguration geändert werden. Dazu muss die Default-Konfigurationsdatei von GRUB im Editor geöffnet werden:

sudo nano /etc/default/grub

Dort muss die Zeile:

GRUB_CMDLINE_LINUX_DEFAULT="splash quiet"

zu:

GRUB_CMDLINE_LINUX_DEFAULT="text"

geändert werden. Nachdem die Änderung der Konfiguration gespeichert wurde, muss GRUB bzw. die Konfiguration desselben aktualisiert werden. Dies geschieht mittels:

sudo update-grub

Anschließend kann der Rechner neugestartet werden. Statt des Splash Screen werden nun die Statusmeldungen beim Start angezeigt.

Wie schon im vergangenen Jahr hat Mozilla auch dieses Jahr seinen „Statusbericht zur Internetgesundheit“ veröffentlicht. In diesem setzt sich Mozilla auf Grundlage von Forschungsergebnissen mit den Dingen auseinander, welche dem Internet helfen respektive ihm schaden.

Vor einem Jahr hat Mozilla seinen ersten sogenannten „Statusbericht zur Internetgesundheit“ veröffentlicht. Nun hat Mozilla seinen Bericht für das Jahr 2018 fertiggestellt. Kernthemen dabei sind Dezentralisierung, Digitale Teilhabe, Offenheit, Datenschutz und Sicherheit sowie Digitale Bildung.

Statusbericht zur Internetgesundheit 2018

Der Bericht ist in verschiedenen Sprachen verfügbar, darunter auch Deutsch. Außerdem bietet Mozilla eine 54-seitige Kurzfassung als PDF-Download an, welche ebenfalls in deutscher Sprache zur Verfügung steht.

Mehr Informationen gibt es in der offiziellen Presseankündigung zum Thema.

Der Beitrag Mozilla veröffentlicht Statusbericht zur Internetgesundheit 2018 erschien zuerst auf soeren-hentzschel.at.

Nachdem wir Koha im ersten Teil installiert und im zweiten Teil das Bibliografische Framework eingerichtet haben, geht es heute darum einige Grundeinstellungen in Koha vorzunehmen. Wir wollen neue Kategorien für unsere Benutzer und Medien einrichten, sowie einige Systemparameter ändern.

Dieser Artikel ist ein Teil einer Serie:

1. Installation und Einrichtung einer ersten Bibliothek
2. Das bibliografische Framework
3. Grundeinstellungen
4. Buchaufnahme
5. Drucken von Etiketten
6. Ausleihkonditionen
7. Verbinden mit einem Z.39.50 / SRU Server
8. Benachrichtigungen und Erinnerungen
9. Mahnungen und Gebühren

Grundeinstellungen

Bibliothek

Wir loggen uns wieder mit unseren Administrator-Account aus Teil 1 ein und wählen Administration → Basisparameter → Bibliotheken und Gruppen. In der Tabelle klicken wir auf Bearbeiten und können nun weitere Angaben zu unserer Bibliothek machen.

Neben der Post-Adresse können wir eine eMail-Adresse angeben oder eine zusätzliche Informationen, die im OPAC erscheinen sollen. Der OPAC ist der Teil von Koha, den die Benutzer sehen und in dem sie den Bestand durchsuchen können, sozusagen der öffentliche Teil der Bibliothekswebseite.

Medientypen

Bei der Installation haben wir bereits den Medientyp „Buch“ angelegt. Diesen wollen zuerst bearbeiten unter Administration → Basisparameter → Medientypen. In der Tabelle klicken wir wieder auf Bearbeiten und können noch einiges einstellen. So können wir ein Bild festlegen oder bestimmen, ob Medien generell ausleihbar sind oder nicht. Wenn man möchte, kann man noch einen Leihgebühr, Bearbeitungskosten bei Verlust oder eine einen allgemeinen Rückgabehinweis eintragen.

Nach dem gleichen Muster legen wir jetzt noch weitere Medientypen an. Hier muss jeder selbst entscheiden, welche Medientypen er braucht. Man kann z.B. nur einen Typ für Bücher haben, oder mehrere anlegen z.B. zusätzlich für Präsenzexemplare. Für eine Schulbibliothek empfehle ich folgende Typen:

• Buch (BU)
• DVD (DV)
• CD-Audio (CD)

Wenn man noch Karten, CD-ROMs, … hat, kann man dafür natürlich noch weitere Medientypen anlegen.

Benutzerkategorien

Nachdem wir nun die Medientypen angelegt haben, brauchen wir noch verschiedene Kategorien für unsere Benutzer. Für jede Benutzerkategorie können wir separat Ausleihkonditionen oder Gebühren bei überfälligen Medien festlegen. Bei der Installation haben wir bereits eine Kategorie für Bibliotheksmitarbeiter angelegt. Unter Administration → Benutzer und Ausleihe → Benutzertypen richten wir nun noch folgende Gruppen ein:

• Bibliotheksmitarbeiter – (MA) → haben wir bereits
• Schüler (S)
• Eltern (P)

Über „+ Neue Kategorie“ können wir einen neuen Benutzertyp hinzufügen. Man kann entweder ein festes Ablaufdatum für diese Kategorie festlegen oder eine in Monaten angeben. Ich habe mich hier für 10 Jahre entschieden, also 120 Monate. Wenn man möchte kann man auch noch ein Mindest- oder Höchstalter festlegen. Unter Kategorie muss man eine der vorgebenden Kategorien wählen, in diesem Fall „Kind“.

Das gleiche machen wir jetzt auch für unsere Elternkategorie. Die Felder können individuell angepasst werden, nur beim Punkt Kategorie wählen wir „Erwachsener“. Wenn man zwischen Grundschülern und Mittel- bzw. Oberstufenschülern unterscheiden möchte (z.B. Ausleihkonditionen), braucht man dafür noch extra Benutzertypen.

Normierte Werte anpassen

Normierte Werte sind immer dann sinnvoll, wenn man möchte, dass festgelegte Werte verwendet werden sollen. In der Regel braucht man das z.B. für den Status von Medien (verloren, beschädigt, …) oder für Standorte. Die Einstellungen zu den Normierten Werten befinden sich unter Administration → Basisparameter → Normierte Werte. Im Drop-Down Menü können wir die Kategorie auswählen und dann die Werte anpassen oder neue ergänzen.

Folgende Normierte Werte sollten wir uns anschauen und gegebenenfalls ändern bzw. ergänzen:

• LOC → Standorte
• CCODE → Sammlungen
• LOST → Status für verlorene Medien

Systemparameter

Über die vielen verschiedenen Systemparameter können wir global Einstellungen in Koha vornehmen und verändern. Darüber kann man Koha sehr individuell anpassen. Wir werden jetzt einige wichtige Parameter kontrollieren und anpassen, sodass es für unseren Einsatzzweck passt. Hier die wichtigsten Paremeter:

Sprache und Formate

• dateformat → Datumsformat
• CalendarFirstDayOfWeek → ersten Tag der Woche definieren
• opaclanguagesdisplay → nur interessant, wenn man mehrere Sprachen installiert hat
• opaclanguages → nur interessant, wenn man mehrere Sprachen installiert hat
• language → nur interessant, wenn man mehrere Sprachen installiert hat

Ausleihe

Unter diesem Punkt gibt es sehr viele Parameter. Die meisten von ihnen können wir in der Standardeinstellung so lassen bzw. werden wir später noch anpassen. Wenn wir eine Altersbeschränkung einrichten wollen, z.B. für DVDs oder Bücher, müssen folgenden Paramter ändern:

• AgeRestrictionMarker → in FSK|PEGI|Age| ändern

Danach speichern.

Benutzer

Bei Bedarf können wir folgende Parameter ändern:

• CardnumberLength → Länge der Benutzernummer
• minPasswordLength → Mindestlänge für das Passwort eines Benutzers

Katalogisierung

Hier ändern wir nur einen Parameter:

•  autoBarcode  → inkrementelle EAN-13-Barcodes

Kataloganreicherung

Die folgenden Parameter bewirken, dass Cover-Bilder von Amazon im OPAC bzw. in der Dienstoberfläche (Backend / Intranet) angezeigt werden:

•  AmazonCoverImages → auf Zeige ändern
• OPACAmazonCoverImages → auf Zeige ändern

OPAC

Zum Schluss können wir noch den OPAC an unsere Schulbibliothek anpassen. Auch hier gibt es wieder recht viele Parameter, von denen die meisten so gelassen werden können. Einige sollten wir aber bei Bedarf ändern:

•  LibraryName → Name der Bibliothek
• OpacMainUserBlock→ Willkommensnachricht für die Hauptseite

Fazit

Die wichtigsten Grundeinstellungen in Koha haben wir nur abgearbeitet. Koha ist nun soweit eingerichtet, dass wir unsere ersten Bücher aufnehmen und ausleihen können. Das wird das Thema im nächsten Teil sein. Danach werden wir uns noch mit weiteren Themen wie Mahnungen und Gebühren, Benutzerverwaltung und -Import beschäftigen.

Viel Spaß beim Einrichten der Schulbibliothek!

2 Kommentare

Der Beitrag Teil 3: Grundeinstellungen – Wie man Koha installiert und für Schulen einrichtet erschien zuerst auf .:zefanjas:..

Bild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

Die ständige Tendenz zu Forks ist Fluch und Segen der Open Source Welt. Segen, weil Projekte nicht sterben müssen, wenn sich der Hauptentwickler zurück zieht oder aber jegliche konstruktive Entwicklung verweigert. Fluch, weil es zu einem regelrechten Wildwuchs kommen kann. Letzteres kann man gerade sehr schön bei Firefox beobachten und hier ist dringend Vorsicht geboten.

Der Browser-Markt ist schwer umkämpft und Mozilla versucht hier gegenüber den Schwergewichten Google, Apple und Microsoft nicht noch mehr an Boden zu verlieren. Dazu werden bei Firefox alte Zöpfe abgeschnitten und wenn man sich die Presseschau für Firefox Quantum anschaut, kommt dies durchaus positiv an. Aber es gibt natürlich diejenigen Anwender, die jegliche Entwicklung seit - sagen wir mal Windows XP - ablehnen und an ihrem heimischen 19" Monitor mit 1280er Auflösung an den Designänderungen verzweifeln.

Diese konservativen Anwender werden von zahllosen Forks bedient. Neben dem Urgestein SeaMonkey kommen da PaleMoon, WaterFox und viele weiter hinzu. Sie alle teilen eine Gemeinsamkeit: Sie basieren auf der veralteten Technik XUL und dem hat Mozilla mit Quantum den Stecker gezogen. Sobald Thunderbird auf eine neue Basis gestellt ist dürften hier die Lichter ausgehen. Mal abgesehen davon, dass der riesige Addon-Park von Firefox durch die jeweiligen Entwickler kaum noch Pflege erhalten wird, sobald kein offizieller Firefox sie mehr unterstützt.

Der Browser ist das Tor ins Internet. Hier geht man keine Kompromisse in der Sicherheit ein. Keiner der Forks hat genug Entwickler um etwaige Sicherheitslücken schnell und gut zu schließen. Entweder sie stellen ebenfalls auf die neue Quantum-Basis um oder sie werden tickende Zeitbomben.

Das ist der große Nachteil an Open Source. Niemand schützt Anwender und Entwickler vor sich selbst und der Versuchung alte Versionen zu konservieren und sich heillos zu übernehmen.

Bild von IO-Images via pixabay / Lizenz: CC0 Creative Commons

OwnCloud oder Nextcloud ist eine Glaubensfrage und sicher auch davon abhängig, wie wichtig einem ein communitybasiertes Entwicklungsmodell ist. Die Macher von Nextcloud können sich bei ownCloud aber auf jeden Fall eine Scheibe in Sachen Öffentlichkeitsarbeit abschneiden. Während die Nextcloud-Entwicklung kaum über die Community hinaus ausstrahlt macht ownCloud professionell Ankündigungs- und Pressearbeit.

Diese Woche neu: DeltaSync.

Nachdem man kürzlich bereits ein neues Interface angekündigt hat, gab man heute bekannt, dass ownCloud ab der nächsten Hauptversion (erscheint wohl noch dieses Jahr) s. g. DeltaSync unterstützen wird. Dadurch sollen bei Änderungen an Dateien nur die Änderungen erneut hochgeladen werden und nicht die gesamte Datei. Konkurrierende Dienste wie Dropbox unterstützen das schon lange.

Die notwendigen Änderungen kamen aus der Community, wurden jedoch über Bountysource durch ownCloud angestoßen.

Unterstützt werden erstmal folgende Formate:

• Krypto-Container (z.B. VeraCrypt)
• Disc-Images (.iso /.img
• Audio (Roh-Audioformate /.wav /.aiff)
• Bilder (.svg /.tiff /.bmp /.dng)
• Video (Rohvideoformate, z.B. unkomprimierte .avi)
• Virtual Machine Images (.vdi /.ova /.img /RAW)
• Microsoft PST Dateien (E-Mails, Kalendereinträge, etc.)
• Textdateien
• Tar-Archive

Naturgemäß ist für dieses Blog natürlich DeltaSync von Krypto-Containern am interessantesten. Das bietet die Möglichkeit sich von unsicheren Lösungen wie EncFS oder unzureichenden wie Cryptomator zu emanzipieren.

Die AGPL/GPL-Lizensierung dürfte gewährleisten, dass diese Funktion auch schnell bei Nextcloud landet.

Am Wochenende habe ich die Zeit genutzt, um die Ubuntu 18.04 auf meinem Rechner zu installieren. Bisher habe ich Ubuntu 16.04 mit Unity verwendet. Vom Typ her bin ich jemand, der möglichst den Standard verwendet, weil ich meine Zeit nicht jedes Mal mit vielen Anpassungen verschwenden möchte. Der Wechsel vor vielen Jahren von Gnome2 auf Unity verlief damals recht schmerzlos und ich konnte mich schnell damit anfreunden. Das war ehrlich gesagt auch meine Hoffnung beim Installieren von Ubuntu 18.04 und dem neuen Gnome3 Desktop. Ubuntu hat ja einige Änderungen vorgenommen, um den Umstieg von Unity auf Gnome3 zu erleichtern. Ist es ihnen gelungen? Persönlich sage ich nein. Nach zwei Tagen bin ich wieder zurück bei Unity in Ubuntu 18.04. Warum?

Was ich in Gnome3 als Unity-Umsteiger vermisse

Ich habe mich ja bereits als Unity-Liebhaber geoutet. Damit konnte ich mich schnell anfreunden und finde es in vielen Punkten sehr benutzerfreundlich und gelungen. Auf den neuen Gnome3 Desktop war ich neugierig und war ehrlich bereit mich darauf einzulassen, aber das wird einem nicht gerade leicht gemacht. Es fehlen mir viele kleine Dinge, die ich an Unity schätzen gelernt habe und die mir meine Arbeit mit dem Computer erleichtern. Hier einige Beispiele.

Einbindung externer Medien

Ich habe mir gleich Dash-to-Dock installiert, um mehr Möglichkeiten bei der Anpassung des Docks zu haben, z.B. um den Programmstarter (heißt das so?) oben statt unten im Dock zu haben. In Unity werden externe Medien wie USB-Sticks als weiteres Symbol im Dock angezeigt – in Gnome3 als Icon auf dem Desktop. Das finde ich unpraktisch, gerade, wenn man mit maximierten Fenstern arbeitet, da man erst diese minimieren muss, um das Symbol zusehen und öffnen zu können. Vielleicht gibt es auch hier irgendeine Erweiterung dafür, aber das ist genau der Punkt. Ich möchte den Desktop nicht erst durch 50 Erweiterungen anpassen müssen, bis er sich so verhält, wie ich es gern hätte, zumindest nicht für grundlegende Sachen, wie das folgende Beispiel.

Computer in Bereitschaft setzen

Im Gnome3-Menü gibt es standardmäßig nur Buttons für Systemeinstellungen, Bildschirm sperren und Herunterfahren. Ich versetze meinen Laptop am Ende des Tages in Bereitschaft. Das kann ich aber in Gnome3 nur, wenn ich gleichzeitig die ALT-Taste drücke oder mir eine Erweiterung installiere. In Unity reichen 2 Klicks aus, in Gnome3 brauche ich dafür 2 Hände  oder eine Erweiterung.

Ausnutzung des Bildschirmplatzes

Einen großen Vorteil von Unity sehe ich in der oberen Bildschirmleiste. Dort sind die Fenstermenüs und auch die Buttons für Schließen, minimieren und maximieren versteckt. Mir erleichtert es das Arbeiten enorm, wenn ich mit der Maus nur in die oberste linke Ecke fahren und klicken muss und weiß, das Fenster wird geschlossen. Ich muss nicht „zielen“ oder die Maus pixelgenau navigieren. Einfach links hoch schieben, klick und fertig. Weiterhin spart die Integration der Menüs in die obere Leiste eine Menge Bildschirmplatz. Gerade bei kleineren Bildschirmen. Standardmäßig ist das bei Gnome3 nicht so, kann natürlich wieder über Erweiterungen erreicht werden.

Icons in der Topbar

Es scheint mir, dass einige Anwendungen eher auf Unity, statt auf Gnome3 optimiert sind, v.a. die Icons in der oberen Bildschirmleiste angeht. Ich hatte einige Anwendungen (z.B. Mattermost Desktop), die unter Unity gut integriert sind, die ich aber in Gnome3 – mal wieder – nur mit einer Erweiterung integrieren konnte.

GDM vs. LightDM

Auch wieder so eine Sache. Es sind die kleinen Dinge, die das Leben einfacher machen. Abgesehen davon, dass ich den Lightdm Anmeldeschirm im Vergleich zu dem vom GDM wesentlich schöner und hübscher finde, bietet er noch andere Vorteile. Standardmäßig wird sowohl bei GDM als auch Lightdm die Anmeldemaske nur auf einem Bildschirm angezeigt (wenn man mehr als einen Bildschirm angeschlossen hat). Bei Lightdm muss ich nur die Maus von einem Schirm auf den nächsten verschieben, um die Anmeldemaske auf den anderen Bildschirm zu holen. Das geht bei GDM nicht. Ein großer Nachteil, vor allem in Schulen, wo in den Klassenräumen oft ein Beamer angeschlossen ist. Wenn die Anmeldemaske am Beamer erscheint, kann ich sie nicht „einfach so“ auf den angeschlossenen Rechner holen.

Fazit

Vielleicht sind das alles nur kleine Dinge und sicher lassen die sich auch größtenteils mit entsprechenden Erweiterungen anpassen, aber genau das ist der springende Punkt. Ich wünsche mir einen Desktop, den man produktiv einsetzen kann, ohne ihn erst durch Erweiterungen anpassen zu müssen. Sicher bin ich auch einige Jahre durch Unity geprägt und schaue jetzt stark durch diese gefärbte Brille, aber es sind u.a. die oben genannten Dinge, die mir die Arbeit am Rechner erleichtern.

Für meinen Teil bin ich wieder zurück bei Unity, was mit

$ sudo apt install ubuntu-unity-desktop

auch in Ubuntu 18.04 schnell erledigt ist – inklusive lightdm.

An alle Unity-Liebhaber – werdet ihr auf Gnome3 in Ubuntu 18.04 wechseln?

36 Kommentare

Der Beitrag Warum ich Unity in Ubuntu 18.04 verwenden werde erschien zuerst auf .:zefanjas:..

Heute möchte ich kurz GeoGebra als weitere App des Monats vorstellen. Es ist ein sehr bekanntes Projekt und wir wahrscheinlich in fast allen Schulen im Mathematikunterricht eingesetzt. Doch was genau ist GeoGebra?

GeoGebra (Kofferwort aus Geometrie und Algebra) ist eine Dynamische-Geometrie-Software (DGS), die zu ihren geometrischen Objekten nicht nur die übliche geometrische, sondern auch eine algebraische Schnittstelle zur Verfügung stellt. Geometrische Objekte können damit nicht nur gezeichnet, sondern auch durch die Angabe beziehungsweise Manipulation von Gleichungen verändert werden. Neben elementargeometrischen Objekten erlauben neuere Versionen von GeoGebra auch die Erzeugung von Funktionsgraphen, ebenen Kurven und Vektoren und verfügen über ein integriertes Computeralgebrasystem (CAS) und eine Tabellenkalkulation. (Wikipedia)

Funktionen von GeoGebra

Der Wikipedia-Artikel über GeoGebra listet einige Funktionen auf. Kurz kann man sagen, dass GeoGebra viele leistungsstarke Funktionen hinter einer einfach zu bedienenden Benutzeroberfläche zugänglich macht. Dazu zählen:

• Funktionsgraphen (inkl. Krümmung, Extrema, Wendepunkt, Tangenten, Asymptoten, Spiegelungen etc.)
• Bestimmte Integrale sowie Stammfunktionen
• Geraden und ihre Steigung, Halbgerade
• Mittelpunkt, Mittelsenkrechte, Lote, Parallele, Winkelhalbierende
• Fläche von beliebigen Polygonen und regelmäßigen Vielecken
• Länge von Strecken, Größe von Winkeln
• Kegelschnitte: Ellipse, Kreis, Pol und Polare
• Kreissektoren, Kreisbögen, Umkreis
• Vektoren, Normalenvektor
• Rechnen mit komplexen Zahlen, Matrizen, Polynomen

Installation

GeoGebra ist ein weiteres Beispiel dafür, dass es heutzutage immer weniger auf das Betriebssystem ankommt, sondern man eigentlich nur noch einen Browser braucht. Es ist für eine Vielzahl an Plattformen verfügbar, aber man kann es auch online nutzen.

Auf der Webseite des Projekts gibt es Pakete im DEB oder RPM Format zum Download. Dort findet man auch eine portable Version, die man vom direkt von einem USB-Stick starten kann. Um die DEB für Debian oder Ubuntu zu installieren, lädt man sich das entsprechende Paket herunter und installiert es mit der Paketverwaltung.

$ sudo dpkg -i geogebra-classic*

Danach kann man das Programm über den Programmstarter starten.

GeoGebra gibt es noch in verschiedenen anderen Versionen für fast alle Plattformen zum Download. Unter anderem auch eine Augmented Reality App. Damit kann man Funktionen, Körper etc. virtuell im Raum darstellen. Hier ein Beispiel:

An unserer Schule verwenden wir GeoGebra hauptsächlich im Mathematikunterricht. Ich persönlich verwende es als Grundschullehrer aber eher weniger in meinem Unterricht 🙂

Fazit

GeoGebra ist eine preisgekrönte Software, die man sehr gut im Unterricht einsetzen kann. Es gibt auch einen „Klassenarbeitsmodus“, sodass man die App in Klausuren verwenden kann. Manche allerdings kritisieren die Lizenz, die für diese Software verwendet wird. Teile der Software stehen unter der GPL, andere Teile (wie z.B. der Installer oder auch die Sprachdateien) sind unter einer eigenen Lizenz lizenziert. Die Nutzung für den Unterricht ist kostenfrei möglich – für Schüler und Lehrkräfte.

Insgesamt kann man diese Software nur empfehlen, da es eine Unmenge an Features bietet und dabei noch einfach zu bedienen bleibt.

Kommentar hinzufügen

Der Beitrag GeoGebra – App des Monats erschien zuerst auf .:zefanjas:..

Mozilla hat mit Firefox Reality einen neuen Browser speziell für Virtual, Augemented und Mixed Reality angekündigt. Mozilla spricht vom ersten plattformübergreifenden sowie einzigen quelloffenen Browser für Mixed Reality.

Themen wie Virtual Reality, Augemented Reality und Mixed Reality werden uns in den nächsten Jahren noch viel beschäftigen. Längst handelt es sich dabei nicht mehr nur um einen technologischen Trend. Mozilla war bei diesem Thema von Anfang an vorderster Front dabei: Firefox 55 war der erste Desktop-Browser mit Unterstützung für Virtuelle Realität, mit A-Frame bietet Mozilla ein beliebtes Framework für Virtuelle Realität an, welches über zehn Millionen Mal pro Monat genutzt wird, und mit dem WebXR Viewer gibt es von Mozilla eine App für Apple iOS zum Betrachten von Mixed Reality-Inhalten.

Nun hat Mozilla Firefox Reality angekündigt. Dabei handelt es sich um einen eigenen Browser speziell für Virtual, Augmented und Mixed Reality, der von Technologien aus Firefox Quantum und Mozillas Next-Generation-Engine Servo profitiert. Erst vergangenen Monat hatte Mozilla angekündigt, dass Mozillas Servo-Team Teil von Mozillas Team für Mixed Reality wird.

Mozilla gibt die folgenden Argumente an, wieso es wichtig ist, dass Mozilla Firefox Reality entwickelt:

• „Firefox Reality ist der erste plattformübergreifende Browser für die Mixed Reality.“
• „Firefox Reality ist der einzige quelloffene Browser für die Mixed Reality.“
• „Firefox Reality wird von einem Unternehmen entwickelt, das die Privatsphäre der Nutzer respektiert.“
• „Firefox Reality wird superschnell.“
• „Firefox Reality ist ein Browser mit Zukunft.“
• „Browser sind die Zukunft der Mixed Reality.“

In der offiziellen Ankündigung geht Mozilla genauer auf jeden dieser Punkte ein. Die Entwicklung findet transparent auf GitHub statt. Dort finden Interessierte auch eine erste Vorab-Version zum Download.

Das folgende Video zeig eine frühe Version von Firefox Reality auf einem HTC VIVE Focus:

Original-Video ansehen

Der Beitrag Mozilla kündigt neuen Browser Firefox Reality an erschien zuerst auf soeren-hentzschel.at.

Linux-Admins werden es kennen: arbeitet man viel mit Konfigurationsdateien des Systems oder verschiedener Daemons, kann es passieren, dass man vergisst, sie als root-Benutzer zu öffnen.

Das ist ärgerlich, man muss die Änderungen kopieren, den Editor verlassen (vim:

:q!

sudo !!

vim-Nutzer sind hier im Vorteil: der Editor ist so flexibel, dass man eine read-only-geöffnete Datei als root speichern kann.

Voraussetzung hierfür ist, dass sudo auf dem System installiert ist und der Nutzer die Berechtigungen hat, hiermit Kommandos auszuführen.

Nun zum Trick:

:w !sudo tee %

Die Zauberei hinter diesem Trick ist, dass vim “pipen” kann, denn anders als oft angenommen, ist

:w

Linux-Admins werden es kennen: arbeitet man viel mit Konfigurationsdateien des Systems oder verschiedener Daemons, kann es passieren, dass man vergisst, sie als root-Benutzer zu öffnen.

Das ist ärgerlich, man muss die Änderungen kopieren, den Editor verlassen (vim: :q! ), ihn wieder mit u.U. sudo (shortcut hierfür: sudo !! zum aufrufen des letzten Kommandos mit root-Rechten) öffnen, Änderungen einfügen und neu abspeichern. Noch ärgerlicher ist es, wenn die Datei nicht bearbeitet, sondern erstellt werden soll und relativ umfangreich ist.

vim-Nutzer sind hier im Vorteil: der Editor ist so flexibel, dass man eine read-only-geöffnete Datei als root speichern kann.

Voraussetzung hierfür ist, dass sudo auf dem System installiert ist und der Nutzer die Berechtigungen hat, hiermit Kommandos auszuführen.

Nun zum Trick:

:w !sudo tee %

Die Zauberei hinter diesem Trick ist, dass vim "pipen" kann, denn anders als oft angenommen, ist :w nicht ausschließlich für das Speichern der Datei zuständig, sondern sendet eher den current buffer in die aktuelle Datei, eine andere Datei oder gar in ein anderes Kommando. Und dieses Kommando lässt sich eben auch per sudo ausführen. tee übrigens lässt sich wie ein T-Stück verstehen. Alle Hintergründe hierzu sind bei Stackoverflow erklärt.

Firefox wird im Standard-Auslieferungszustand neben seinem Standard-Design auch noch mit einem alternativen hellen sowie dunklen Theme ausgeliefert. Während das dunkle Theme bislang nur die Tab- und Symbolleisten dunkel färbte, ändert sich dies mit Firefox 61: ab dann wird das dunkle Theme auch darüber hinaus dunkel sein.

Wer dunkle Designs mag und dem das dunkle Theme von Firefox bisher nicht weit genug ging, darf sich freuen: ab Firefox 61 wird das dunkle Theme vollständig dunkel. Das heißt, dass nicht länger nur die Tab- und Symbolleisten einschließlich der Symbole dunkel sind, sondern auch die Adressleisten-Vorschläge, die Seite, welche beim Öffnen eines neuen Tabs erscheint, das Hauptmenü, sämtliche Panels von Firefox und die Seite zum Anpassen der Firefox-Oberfläche.

Der Beitrag Firefox 61: Dunkles Theme wird vollständig dunkel erschien zuerst auf soeren-hentzschel.at.

Mit dem Windows-Subsystem für Linux (WSL) können Linux-Distributionen wie bspw. Debian GNU/Linux direkt unter Windows ausgeführt werden – einschließlich aller Anwendungen.

Um grafische Anwendungen (GUI) unter WSL ausführen zu können, muss unter Windows ein X Window System/X-Server installiert sein.

Es bietet sich hier an, den X-Server von Gygwin/X XWin.exe zu installieren, da Gygwin auch viele andere Pakete wie Perl, SSH, usw. bereitstellt und es ggf. schon installiert ist. Auf die Installation von Gygwin selbst geht dieser Artikel aber nicht weiter ein. Wie man Gygwin unter Windows installiert, aktualisiert usw. ist auf der Webseite des Projekts beschrieben. Siehe: https://cygwin.com und https://x.cygwin.com/. Kurz: Es wird das Programm setup-x86_64.exe ausgeführt und im Dialog ein Mirror ausgewählt, die Paketliste geladen/aktualisiert und die Pakete zur Installation/Aktualisierung ausgewählt.

Ist kein X-Server installiert, wird dies i.d.R. durch folgende Fehlermeldung ausgedrückt:

$ DISPLAY=":0" thunderbird # Start einer grafischen Anwendung (hier thunderbird)
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0

X-Server installieren

Der X-Server XWin.exe wird über das Cygwin-Paket xorg-server installiert:

Damit XWin.exe beim Windows Systemstart startet, muss es in den Autostart z.B. unter %APPDATA%\Microsoft\Windows\Start Menu\Programs\startup:

Wichtig für eine Verknüpfung im Autostart ist als Ziel: C:\cygwin64\bin\XWin.exe :0 -multiwindow -listen tcp -auth und Ausführen in: C:\cygwin64\home\%USERNAME% anzugeben.

Außerdem muss in der Windows Firewall XWin.exe konfiguriert/eingetragen sein, da es ein Netzwerkprotokoll ist! Der Zugriff muss aber nicht erlaubt werden und der Dialog kann mit abbrechen beendet werden.

Nun können auch grafische Anwendungen aus WSL (und auch aus Gygwin) heraus gestartet werden.

Die Anwendungsdaten befinden sich in folgenden Ordnern:

• WSL:
  /mnt/c/Users/,
  /mnt/c/Cygwin/home/, /mnt/c/Cygwin64/home/,
  %LOCALAPPDATA%\Packages\*\LocalState\rootfs\home\
• Cygwin:
  /cygdrive/c/Users/,
  C:\Cygwin\home\, C:\Cygwin64\home\,
  /cygdrive/c/Users/*/AppData/Local/Packages/*/LocalState/rootfs/home/

Cygwin aktualisieren

Um Cygwin bzw. die installierten Pakete zu aktualisieren, habe ich ein kleines PowerShell-Skript geschrieben:

# Download Cygwin
Invoke-WebRequest -uri "https://cygwin.com/setup-x86_64.exe" -OutFile "setup-x86_64.exe"

# Run Cygwin in unattended setup mode
# setup-x86_64.exe --help
Start-Process -FilePath "setup-x86_64.exe" -ArgumentList "--verbose","-q","--upgrade-also"

GRUB 2 hat viele Funkionen in Module ausgelagert. Dadurch ist es möglich, dass man nur die benötigten Funktionen lädt und damit kleinere Core-Images möglich sind. Man kann diese Module aber auch nutzen, um GRUB zu erweitern, z.B. um eine Zeitsteuerung in GRUB einzubauen. Damit ist es möglich ein bestimmtes Betriebssystem zu einer festgelegten Zeit zu starten.

Eine Liste aller vorhandenen Module erhält man mit

$ ls /boot/grub/i386-pc/

Zeitsteuerung in GRUB konfigurieren

Für die Zeitsteuerung in GRUB braucht man das Module datehook. Damit können in GRUB auf folgende Variablen zugreifen:

• DAY
• HOUR
• MINUTE
• SECOND
• MONTH
• WEEKDAY
• YEAR

Alle diese Werte basieren auf der Uhrzeit und dem Datum, das im BIOS eingestellt wurde (i.d.R. die Hardwareuhr des Mainboards). Das muss man im Hinterkopf behalten, wenn man die Zeitsteuerung in GRUB einrichtet.

Mit dem folgenden Befehl erhält man eine Liste mit allen Menü-Punkten des GRUB-Menüs:

$ grep -E '^menuentry|^submenu' /boot/grub/grub.cfg | cut -d '"' -f2 | cut -d "'" -f2

Der erste Eintrag hat die Nummer 0, der zweite die Nummer 1 usw.

Als nächstes öffnet man die Datei /boot/grub/grub.cfg und fügt folgende Zeilen relativ am Anfang der Datei ein:

insmod datehook
# Eine extra Null beo Minute 0-9 hinzufügen, sodass MINUTE immer zweistellig ist
if [ $MINUTE -lt 10 ]; then PADDING="0"; else PADDING=""; fi  
TIME=$HOUR$PADDING$MINUTE

# Standardmäßig Ubuntu starten
set default=0

# Starte "Windows 10" von 17 bis 23 Uhr
if [ $TIME -ge 1700 -a $TIME -lt 2300 ]; then
  set default=3
fi

Am Anfang fügt man eine extra Null bei Minuten kleiner als 10 ein, sodass die Minutenzahl immer zweistellig ist. Dann konstruiert man eine neue Variable TIME, die die aktuelle Uhrzeit mit dem Format HHMM hat. Diese kann man nun nutzen, um die Zeitsteuerung in GRUB zu implementieren.

Ubuntu soll standardmäßig gestartet werden, aber am Abend bekommt Windows 10 den Vorrang. Eventuell muss man die Uhrzeiten noch anpassen, da im BIOS oft die Zeitzone UTC eingerichtet ist.

Fazit

Die Änderungen oben gelten nur solange bis zum nächsten Mal update-grub ausgeführt wird. Damit die Änderungen dauerhaft in GRUB erhalten bleiben, sollte man ein Template mit diesem Code unter /etc/grub.d/ anlegen.

Wir nutzen diese Option, um unsere Rechner in der Schule besser verwalten zu können. Am Tag wird standardmäßig Ubuntu gestartet, aber während der Nacht lassen wir Linbo booten, damit die Rechner dann z.B. aktualisiert oder mit einem neuen Image versorgt werden können.

1 Kommentar

Der Beitrag Zeitsteuerung in GRUB einrichten erschien zuerst auf .:zefanjas:..

Mozilla hat eine neue Einstellung in Firefox 61 implementiert, welche das Schließen von Tabs per Doppelklick erlaubt.

Tabs in Firefox können entweder per Tastatur (Strg + W; macOS: Cmd + W) geschlossen werden oder über die Schließen-Schaltfläche im Tab. Ab Firefox 61 kommt für aktive Tabs eine weitere Option dazu: wird zunächst über about:config der Schalter browser.tabs.closeTabByDblclick durch einen Doppelklick auf true geschaltet, lassen sich aktive Tabs auch durch einen Doppelklick in eben jenen schließen.

Für nicht aktive Tabs funktioniert dies allerdings nicht. Statistiken von Mozilla Peking zeigen, dass eine Implementierung für den aktiven Tab bereits 80 Prozent der Doppelklicks in der chinesischen Firefox-Version abdeckt, wo man dieses Verhalten in der Vergangenheit per Erweiterung implementiert hatte. Außerdem sei das versehentliche Schließen von falschen Tabs mit nicht korrekt funktionierenden Mäusen eine häufige Beschwerde, die man erhalten habe, was durch die Limitierung auf aktive Tabs verhindert wird.

Der Beitrag Firefox 61: Neue Einstellung zum Schließen von Tabs per Doppelklick erschien zuerst auf soeren-hentzschel.at.

Bild von pixelcreatures via pixabay / Lizenz: CC0 Public Domain

EncFS ist im übertragenen Sinne die Mutter der Cloudverschlüsselung. Obwohl nicht unbedingt dafür gemacht, bot sich die dateibasierte Verschlüsselung für die Cloud geradezu an. Die erste Version des überaus populären Boxcryptor (siehe: Boxcryptor - Proprietäre Cloudspeicher-Verschlüsselung) setzte somit auch auf eine modifizierte EncFS Implementierung. Ein Audit 2014 setzte dem aber ein jähes Ende. Ob die gravierenden Schwachstellen heute behoben sind ist trotzdem unklar.

Der Audit-Bericht kam 2014 zu dem Ergebnis, dass die Verschlüsselung nicht sicher ist, wenn mehr als eine Version der Datei vorliegt. Dies ist beim Cloudeinsatz die Regel, weshalb EncFS für selbigen ungeeignet ist. Die Homepage zeigt keinen Verweis auf den Audit, ebenso die Github-Seite.

Die überprüfte Versionsnummer war damals 1.7.4, inzwischen ist man bei 1.9.4 angelangt. Das Changelog schweigt sich aber darüber aus, ob die Schwachstellen von damals behoben wurden. Zumindest eine Schwachstelle scheint offen zu sein und ist erst für Version 2 zur Behebung vorgesehen. Auch weitere minder schwere Schwachstellen scheinen nicht behoben zu sein.

Man ist hier immerhin so transparent, dass die Bugreports und ihr Status einsehbar sind. Wenn man als unbedarfter Anwender aber nicht in den tiefen des Projekts wühlt, könnte man auf die Idee kommen EncFS wäre sicher. Im Internet wird es schließlich auch allenthalben empfohlen und die regelmäßigen Veröffentlichungen verweisen auf ein aktives Entwicklungsgeschehen.

Transparenz und Verantwortung gegenüber dem Anwender sieht anders aus!

Bild von andries48 via pixabay / Lizenz: CC0 Creative Commons

Linux hat im Desktopbereich einen verschwindend geringen Marktanteil, egal welche Statistik man zu Grunde legt. Wenn man sich durch die Blogs und Foren der "Datenschutz-Szene" sieht das aber ganz anders aus. Konkrete Zahlen liegen nicht vor, aber vermutlich nutzen mehr als 50% der Personen Linux als primäres Betriebssystem.

Die Gründe werden deutlich seltener thematisiert.

Meistens kommt zuerst ein lapidarer Verweis auf Open Source und die Freiheit des Entwicklungsmodells. Das ist ein Punkt, der viel zu wenig hinterfragt wird (siehe: Proprietär vs. Open Source – Die ewige Debatte um die Sicherheit &  Kommentar: Open Source ist gut für die Sicherheit - Oder doch nicht?). Natürlich ist es prinzipiell für die Sicherheit förderlich, dass der Quellcode frei zugänglich ist. Es ermöglicht unabhängige Audits, die nicht von der Gnade einer Firma abhängig sind und im Zweifelsfall kann der versierte Anwender selbst nachschauen. Faktisch sind die meisten, insbesondere die sicherheitskritischen, Open Source Projekte riesig. Kaum ein Anwender hat die Kenntnisse und die Zeit "mal eben" ein Projekt wie Firefox zu überprüfen. Gleichzeitig ist die Entwicklerzahl in vielen Projekten sehr gering, so dass ein Mehr-Augen-Prinzip kaum gewährleistet wird. Natürlich ist ein proprietäres Entwicklungsmodell mit nicht einsehbarem Quellcode nicht sicherer, der Verweis auf den offenen Quellcode ist ohne Berücksichtigung der realen Umstände jedoch ein Scheinargument.

Anders gelagert ist bei einer weniger ideologischen Argumentation. Linux-Distributionen sind im Prinzip Baukästen, bei denen man sehr viele Bestandteile ersetzen oder komplett weglassen kann. Im Gegensatz zu macOS oder Windows ist z. B. bei keiner Linux-Distribution ein Clouddienst fest in das Betriebssystem eingebunden. Weiterhin stehen in diesem modularen Baukasten leistungsstarke Verschlüsselungslösungen für Kommunikation, Daten und Betriebssystem zur Verfügung. Bei vergleichbaren Betriebssystemen trifft das nur für teurere Editionen zu oder gilt nur für Teile wie das eigentliche Betriebssystem. Linux senkt hier die Hürden zu weitergehenden Schutzmaßnahmen enorm.

Im Zusammenhang mit Windows 10 liegt der Fokus mal wieder auf Telemetrie-Daten und Datenabfluss. Wie sensibel das Thema inzwischen ist musste auch Canonical kürzlich feststellen. Es ist leider auch keineswegs so, dass unter Linux keine Telemetrie-Daten erhoben werden. Firefox ist sicherlich das prominenteste Beispiel für eine Open Source-Software, die per Opt-out-Verfahren Daten sammelt - es ist aber bei weitem nicht die einzige. Richtig ist hingegen, dass dahinter - auch bedingt durch die Fragmentierung in unterschiedliche Projekte - kein groß angelegter Plan zur Datensammlung steht.

Als vor über 15 Jahren Windows XP auf den Markt erlebte das Internet seinen vielleicht ersten großen Shitstorm, auch wenn man das damals noch nicht so bezeichnete. Windows XP nahm nämlich vielfältige Verbindungen ins Internet auf. xp-AntiSpy gehörte bald zur Basisausstattung vieler Systeme. Viele der Aufregerthemen von damals muten heute befremdlich an. Windows XP überprüfte erstmals die Lizenz online, nahm Kontakt zum Update-Server auf und hatte noch andere Funktionen wie einen automatischen Coverdownload integriert. Vieles davon ist heute selbstverständlich, so nehmen natürlich auch die meisten Linux-Distributionen Kontakt zu Servern auf. Updates der Paketdatenbank, Zeitsynchronisierung, automatischer Coverdownload bei vielen Musikplayern usw. usf. Bei allen diesen Verbindungen fallen potenziell Daten an, zur Zeit jedoch höchstwahrscheinlich nicht systematisch erfasst und vermutlich auch nicht statistisch verarbeitet. Wobei manche Distributionen immerhin ab und an einen Blick auf die Daten nehmen.

Ein beliebter Kritikpunkt ist, dass viele der großen IT-Giganten ihren Sitz in den USA haben (und inzwischen zunehmend auch in China) und damit den dortigen Gesetzen unterliegen - mit all den problematischen Implikationen. Das ist soweit nicht falsch, verkennt aber, dass Linux hier kaum besser dasteht. Red Hat - einer der wichtigsten Akteure im Linux-Bereich - sitzt in Nord Carolina, die SUSE GmbH gehört Micro Focus mit Sitz in Großbritannien. Einem Land mit einer Affinität zu weitreichenden Überwachungsgesetzen, der GCHQ stand nicht umsonst auch im Fokus der globalen Überwachungs- und Spionageaffäre. Man sollte sich da keine Illusionen machen, Linux wird schon lange nicht mehr von kleinen Hobbyentwicklern im Keller voran getrieben. Insbesondere in den zentralen Bestandteilen erfolgt die Entwicklung durch bezahlte Entwickler, die in Firmen angestellt sind, die ihre Sitze oft in den gleichen Staaten haben, wie die proprietären - vermeintlich nicht vertrauenswürdigen - IT-Giganten. Hier schließt sich dann der Kreis zum Anfang. Der offene Quellcode sollte gewährleisten, dass diese Firmen nichts schädliches einbauen. Doch geschieht das faktisch wirklich? Selbst so zentrale Bestanteile wie OpenSSL wurden schließlich jahrelang kaum angeguckt.

Große Probleme liegen zudem noch unterhalb des Betriebssystems. Es gibt kaum Hardware mit wirklich freier Firmware und Bestandteile wie Intel ME haben inzwischen komplette eigene Betriebssysteme. Selbst Hardware von in Linux-Kreisen traditionell populärer Anbieter ist da nicht besser. Umso wichtiger sind Projekte wie Purism oder Coreboot. Wer solch spezielle Hardware nicht besitzt, sollte sich also trotz Linux nicht zu sicher fühlen.

Linux ist trotzdem eine gute Grundlage. Vor allem durch die hohe Verfügbarkeit erweiterter Werkzeuge und den modularen Aufbau, der es ermöglicht unerwünschtes wirklich zu entfernen. Zudem können viele der hier geäußerten Kritikpunkte in manueller Kleinarbeit behoben werden. Linux ist aber kein abgeschottetes System, das keinen Kontakt nach außen aufnimmt und einmal generierte Daten, können prinzipiell auch irgendwann mal ausgewertet werden. Hier sollte man sich nicht zu sicher wähnen. Das Open Source-Argument sollte man mit zunehmender Komplexität der Software und Einfluss großer Unternehmen auf die Entwicklung auch nicht zu offensiv vor sich her tragen. Denn eigentlich sagt es kaum was aus.

Bild von harshahars via Pixabay / Lizenz: CC0 Creative Commons

Snaps, Flatpaks und andere vergleichbare Systeme sind momentan eine der wenigen spannenden Entwicklungen am Linux-Desktop. Die Entwickler aus dem Umfeld von Canonical und RedHat wollen damit viele Probleme angehen: Der hohe Aufwand für Firmen Pakete für alle möglichen Distributionen und Versionen zur Verfügung zu stellen, der sinkende Anteil an Maintainern für die bisherigen Paketsammlungen der Distributionen und vieles weiteres. Damit stellt man den Heiligen Gral der Linuxwelt in Frage: Die Paketverwaltung.

Grundsätzlich sind tiefgreifende Änderungen im Linux-Desktop immer schwerer durchzusetzen. Meiner Meinung nach liegt das auch strukturell an der Zusammensetzung der Linux-Community (siehe: Nabelschau und Phantomschmerzen - die Linux Community auf dem Weg in die Bedeutungslosigkeit?). Richtig schön sieht man das an der neuen Auseinandersetzung um die neuen Paketformate vs. die alten Lösungen. In den Foren ist die Empörung allgegenwärtig, Aussagen wie "Braucht kein Mensch", "zu aufgeblasen", "Wer soll, die integrierten Bibliotheken warten?" und "Das bisherige System funktioniert doch, wozu braucht es was neues?" decken wohl die meisten Reaktionen ab. Der Linux-Desktop ist bekanntermaßen perfekt, Änderungen unerwünscht.

Doch funktioniert das alte System wirklich so gut oder wird nicht nur der Status quo verherrlicht? Paketverwaltungen waren prinzipiell einer der großen Vorteile von Linux gegenüber alternativen Betriebssystemen. Anstatt Betriebssystem und Programme unabhängig davon über dutzende Updateroutinen zu aktualisieren, hebt man das gesamte System mit einem Befehl auf einen aktuellen Stand. Andere Betriebssysteme haben aber nachgezogen und mit den heutigen App Stores erreicht man einen ähnlichen Effekt bei macOS und Windows. Sofern man natürlich nicht alles manuell an diesen Programmsammlungen vorbei installiert, aber das gilt auch für die Paketverwaltung.

Der zweite Vorteil ist natürlich, dass eine Bibliothek exakt ein mal installiert haben muss und dann jedem Programm zur Verfügung steht. Das spart Speicherplatz, aber der ist inzwischen selbst in SSD-Form preiswert und reichlich vorhanden. Zudem kann das auch problematisch sein, wenn Programme unterschiedliche Versionen einer Bibliothek benötigen.

Das System Paketverwaltung hat in den letzten Jahren aber auch einige Exzesse hinter sich. Insbesondere Debian-basierte Distributionen haben die Pakete förmlich atomisiert. Jedes Programm wird in dutzende, von einander abhängige, Pakete zerlegt - ein Trend der mit jeder Version extremer wurde. Ein KDE-Desktop in Debian Lenny hatte noch deutlich weniger als 700 Pakete, heute hat man leicht weit über tausend installierte Pakete. Das liegt nicht nur daran, dass Desktopumgebungen an Umfang gewonnen haben. Manuelle Aktualisierungen sind dadurch kaum noch möglich, weil man ziemlich schnell in einer Abhängigkeitshölle landet.

Dies führt unweigerlich zu einem hohen Einsatz von Fremdquellen, da nur diese eine partielle Aktualisierung von Programmen ermöglichten. Fremdquellen sind jedoch ein riesiges Sicherheitsproblem. Ohne ein durchdachtes Priorisierungssystem (das gegenwärtig, abgesehen von YaST in openSUSE, keine grafische Oberfläche unterstützt) sind Fremdquellen nämlich dazu in der Lage Systempakete zu überschreiben. Dies kann auch nachträglich geschehen, wenn der Maintainer der Fremdquelle diese Pakete der Quelle hinzufügt. Dieses Sicherheitsrisiko ist viel realer als die abstrakte Gefahr von irgendwelchen nicht ganz aktuellen Bibliotheken in Snaps und Flatpaks.

Viele Vorteile von klassischen Paketverwaltungen existieren zudem real gar nicht mehr. Ein klassisches Argument lautet, dass eine Sicherheitslücke ja potenziell nur in einem Paket gepatcht werden muss und nur dieses aktualisiert wird. Real ziehen moderne Build-Prozesse immer die Versionsnummern von ganzen Paketgruppen hoch. Ob Qt dann z.B. in zig Unterpakete gesplittet ist, kann dem Anwender eigentlich egal sein, aktualisieren muss er meistens eh alle Pakete der Programmgruppe. Deltapakete haben das Problem der großen Downloads auch schon lange behoben, werden jedoch nur von RPM-basierten Distributionen verwendet.

Weiterhin sind die Synergieeffekte doch eher überschaubar. Nimmt man zum Beispiel LibreOffice: Das Paket ist bei den meisten Distributionen vorbildhaft zerlegt in seine Einzelteile. Die Bestandteile Calc, Writer & Co, die man abwählen kann, sind jedoch vergleichsweise klein. Der dicke Brocken ist LibreOffice-Core und den braucht man immer. Andere Bibliotheken wie uno braucht man nur für LibreOffice. Ihre Ausgliederung ist also ohne Mehrwert für den Benutzer.

Die Beschränkungen der klassischen Paketverwaltung, die fast zwangsläufig zum Antagonismus Rolling Release vs. Stabile Distribution führt, ist zudem ein großes Problem für den Linux-Desktop. Viele langjährige Nutzer merken das nicht mehr, weil sie es nichts anders kennen, aber es ist eben nicht normal, dass man entweder das komplette Betriebssystem permanent aktualisieren muss oder sonst komplett auf alten Versionen sitzen bleibt

Die neuen Paketformate haben natürlich auch ihre Probleme. Es wird sich zeigen müssen, ob sie langfristig gepflegt werden oder letztlich zu viele veraltete Bibliotheken mit Sicherheitslücken aufweisen. Für einen wirklichen Mehrwert muss sich zudem noch klären, ob sich Snaps oder Flatpaks durchsetzen. Erfahrungsgemäß muss Canonical irgendwann seine eigene Lösung einstampfen.

Der Mehrwert ist aber offensichtlich. Die Pakete von z. B. Flathub laufen auf allen Distributionen, die Flatspaks unterstützen (eigentlich alle außer Ubuntu) und müssen nicht permanent für jede Version neu gebaut werden.

Flatpaks & Co werden natürlich die Paketverwaltung nicht komplett ersetzen. Solche Bestrebungen wurden vom Fedora-Team nicht umsonst aufgegeben. Für das eigentliche Basissystem und den Desktop ist die Paketverwaltung nach wie vor bestens geeignet. Es gibt aber keinen Grund klassische Endanwenderprogramme genau so wie den Kernel zu verwalten. Außer natürlich man ist der Meinung, der Linux-Desktop wäre perfekt und ausentwickelt.

In freiesMagazin 07/2015 und in der DTK 4/2015 habe ich verschiedene E-Book-Konverter gezeigt, die aus einem LaTeX-Dokument eine HTML-Seite bzw. gleich ein EPUB erzeugen.

Auf Basis dessen erreichte mich vor zwei Wochen eine Anfrage, ob ich bei der Konvertierung eines Buches, welches mit TeX gesetzt wurde, helfen könne. Das Buch umfasst ca. 500 Seiten, enthält ca. 70 Abbildungen und 4000 mathematische Formeln. Es werden 32 LaTeX-Pakete eingebunden, wovon ich maximal drei Viertel kenne – was aber auch kein Wunder ist bei der Masse an Paketen, die es gibt.

Unterstützen sollte ich bei der Konvertierung des Buches mittels tex4ebook, was Herbert Voss kurz in der DTK 4/2015 anriss, da ich es in meinem Test damals nicht mit einbezogen hatte. Nach ein bisschen Handarbeit lief tex4ebook in der neuesten Version dann bei mir auch. Schade ist, dass man schon Einiges an Linux- und TeX-Wissen braucht, um das Programm überhaupt zum Kompilieren und Installieren zu bekommen.

Leider übersetzte aber die TeX4ht-Engine – welche zum Konvertieren nach HTML benutzt wird – das Dokument nicht sofort. Folgende Änderungen musste ich manuell vornehmen:

• PDF-Bilder, die mit \includegraphics ohne Dateiendung eingebunden wurden, wurden nicht gefunden. Hier musste ich das .pdf ergänzen, was dazu führt, dass pdflatex das Dokument nicht mehr übersetzt. \includepdf wäre wohl die richtige Wahl.
• Bei einer description, itemize oder enumerate muss der erste Eintrag ein \item sein. Im Buch stand dort des öfteren ein Hyperref-Linkziel mit \hypertarget.
• Das Paket subfig erzeugt ein fehlendes \fi und musste daher entfernt werden. Die entsprechenden Benutzungen von \subfloat habe ich durch simple Tabellen ersetzt. Wie ich gelesen habe, könnte das Paket subfigure auch helfen.
• Das Paket arydshln erzeugt ebenfalls ein Problem mit einem „Undefined control sequence“. Das Paket musste ich entfernen, ebenso wie die genutzten \hdashline durch \hline ersetzen.
• Ganz tödlich waren Fußnoten \footnote bzw. \footnotemark oder Indexverweise mit \index in Überschriften. Das erzeugte regelmäßig ein „Tex capacity exceeded, sorry [input stack size = 5000]“. Grund war weniger die Fußnote oder der Index, sondern der Fehler trat bei einem darauf folgenden \label auf, weil vermutlich das Label dann ebenso die Fußnote/Index enthielt, was zu viel des Guten war.

Nach diesen Anpassungen lief zumindest tex4ebook durch und erzeugte ein PDF. Zu einem großen Teil sah das auch ganz okay aus. Es fehlten aber auch einige Abbildungen, Formeln und vieles mehr. Ich denke, dass man hier einige Stunden bzw. realistischer Tage und Wochen Arbeit vor sich hat, um ein ansehnliches E-Book zu erzeugen.

Mir hat das reale Beispiel (meine Beispieldatei entspricht nicht ganz der Realität und freiesMagazin wurde fast von Anfang an darauf getrimmt) aber wieder einmal mehr gezeigt, dass für die Konvertierung einer TeX-Datei in PDF, HTML und EPUB einige Punkte wichtig sind:

• Trennen von Paketinkludierung, von Befehlsdefinitionen und vom eigentlichen Inhalt. So kann man nämlich wesentlich leichter eine spezielle EPUB-Version mit eigenen Befehlsdefinitionen oder anderen Paketen einbinden.
• Möglichst eigene Befehlsdefinitionen verwenden und keine reinen LaTeX-Befehle. Klingt erst einmal komisch, hilft aber enorm, wenn man für die EPUB-Version eigene Befehlsdefinitionen schreiben muss.
• Fußnoten möglichst spärlich einsetzen, das Konzept passt einfach nicht in ein E-Book.

Ich bin jedenfalls gespannt, wie es mit dem Buch weitergeht und ob es der Ersteller schafft, daraus ein E-Book zu generieren. Ich drücke ihm natürlich die Daumen, es bleibt ein spannendes Unterfangen.

An dieser Stelle möchte ich ein Konzept erarbeiten, um meinen Blog mit Hilfe von Ansible[1. Ansible – IT-Automation für Jedermann – My-IT-Brain] [2. Ansible – Wikipedia] auf einem Ubuntu-Server ausbringen zu können.

Dabei hoffe ich auch ein wenig auf eure Unterstützung. Habt ihr Anregungen, konkrete Verbesserungsvorschläge oder auch Fragen, freue ich mich über eure Kommentare. Denn ich selbst bin kein Ansible-Experte und führe dieses Projekt zum Selbststudium und zu Übungszwecken durch.

Die Testumgebung

Die Testumgebung besteht aus der Ansible Control Machine, basierend auf RHEL 7[3. Red Hat Enterprise Linux – Wikipedia] und dem Zielsystem, basierend auf Ubuntu Bionic Beaver[4. Bionic Beaver – wiki.ubuntuusers.de]. Zum Zeitpunkt der Erstellung dieses Artikels nutze ich Ansible in Version 2.4.2.

Zwar wurde bereits die Ansible-Version 2.5 veröffentlicht, in den RHEL-7-Paketquellen ist jedoch noch die Version 2.4.2 enthalten. Ich verwende diese Version auch auf der Arbeit und erhoffe mir so, Erkenntnisse aus diesem Projekt in meine dienstliche Tätigkeit einfließen lassen zu können.

Auf dem Zielsystem existiert ein Benutzer, welcher über volle sudo-Berechtigung verfügt. Dieser Benutzer muss sich mit seinem Passwort authentisieren, wenn er sudo verwendet.

Auf der Ansible Control Machine wird ein SSH-Schlüsselpaar[5. Authentifizierung über Public-Keys – wiki.ubuntuusers.de] generiert, dessen privater Schlüssel nicht mit einer Passphrase geschützt ist. Der öffentliche Schlüssel wird auf dem Zielsystem abgelegt. Damit wird sichergestellt, dass die Ansible Control Machine SSH-Zugriff auf das Zielsystem hat.

Die Konfiguration von Ansible (/etc/ansible/ansible.cfg) wird so angepasst, dass standardmäßig das oben erzeugte SSH-Private-Key-File beim Verbindungsaufbau genutzt wird.

Die Installation der benötigten Betriebssysteme und Ansible sind nicht Gegenstand dieses Artikels.

Geplante Vorgehensweise

Um eine Vorgehensweise zu erarbeiten, orientiere ich mich an dem Artikel Testinstanz für einen WordPress-Blog erstellen. In diesem habe ich bereits beschrieben, wie ein Blog auf einem weiteren System als Testsystem aufgesetzt werden kann. Die Vorgehensweise ist ähnlich, mit dem Unterschied, dass sämtliche Schritte nun durch Ansible orchestriert werden sollen.

Danach ergibt sich folgende (vorläufige) Reihenfolge:

1. Vom Produktivsystem benötigte Dateien holen
2. Sicherstellen, das alle benötigten Pakete auf dem Zielsystem installiert sind
3. VirtualHost erstellen
4. DocumentRoot aus Backup-Datei erstellen
5. Datei-Attribute und Zugriffsrechte korrekt setzen
6. Eine .httpasswd-Datei erzeugen/ausbringen
7. Datenbank aus Backup wiederherstellen
8. Datenbankbenutzer erstellen
9. Troubleshooting

Mit hoher Wahrscheinlichkeit ist die obige Liste noch nicht vollständig. Daher werde ich diese im Laufe des Projekts anpassen, sobald weitere Erkenntnisse vorliegen.

Als Quelldaten für den Blog liegen das DocumentRoot meines Blogs als Tarball[6. tar – Wikipedia] vor. Von der Datenbank wurde ein logisches Backup[7. Logisches Backup – wiki.ubuntuusers.de] erstellt. Auf diese Datensicherung wird zurückgegriffen, um den Blog auf einem neuen Ubuntu-Server auszubringen bzw. wiederherzustellen.

Der erste Versuch

Im ersten Anlauf habe ich eine Ansible-Rolle[8. Directory Layout — Ansible Best Practices] mit folgendem Aufbau erstellt:

/etc/ansible/roles/
└── deploy-my-blog
    ├── files
    │   ├── backup-documentroot.tar.bz2
    │   ├── dh_params.pem
    │   ├── db_dump.sql.bz2
    │   ├── my-it-brain.vhost
    │   └── php-fpm-pool.conf
    ├── handlers
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

5 directories, 8 files

Unterhalb von files wurden Dateien abgelegt, welche vom aktuellen Produktivsystem stammen und für das Deployment auf einem neuen Server benötigt werden.

Im folgenden werde ich zuerst auf die eingesetzten Module eingehen und anschließend das Playbook zum Deployment des Blogs vorstellen.

Verwendete Module

Die in der Spalte Status angegebenen Werte stableinterface und preview lassen Rückschlüsse auf die Stabilität der Schnittstellen eines Moduls zu.

So garantieren die Entwickler bei einem stableinterface, dass es in Zukunft keine Änderungen geben wird, die nicht abwärtskompatibel sind. Auch wenn sich keine explizite Angabe findet, wie lange diese Garantie gilt, kann man davon ausgehen, dass man seine Playbooks bei Verwendung dieser Module nicht so schnell aufgrund von Updates anpassen muss. Für Module mit dem Status preview wird genau dies hingegen nicht garantiert. Hier kann es von Version zu Version Änderungen geben, welche Anpassungen an Playbooks erforderlich machen, welche diese Module verwenden. Dadurch entsteht ggf. ein erhöhter Testaufwand, bevor man seine Ansible-Installation aktualisieren kann.

Das Playbook

Den Inhalt der Datei /etc/ansible/roles/deploy-my-blog/tasks/main.yml habe ich unter dem Namen deploy-blog-playbook.yml als Gist veröffentlicht. Um es in diesem Artikel anzeigen zu können, müsst ihr JavaScript in eurem Webbrowser aktiveren.

Die Zeilen 2-11 sorgen dafür, dass die benötigten Pakete auf dem Zielsystem installiert werden. Da es sich dabei um einen Ubuntu-Server handelt, verwende ich das Modul apt.

Die Zeilen 13-16 stellen das DocumentRoot und die SSL-Zertifikate aus dem Dateibackup auf dem Zielsystem wieder her.

In meiner aktuellen Konfiguration verwende ich PHP-FPM mit einem eigenen Pool, welcher in meinem VirtualHost referenziert wird. Um diese Konstellation auch auf dem neuen System nutzen zu können, stelle ich entsprechende Konfiguration mit den Zeilen 18-47 her. Vermutlich können die Zeilen 39-47 entfallen, da PHP-FPM das Logfile automatisch erstellt. Weitere Tests müssen dies noch zeigen. Ich habe diese Zeilen während des Troubleshootings eingefügt. Ursache für den Fehler wird vermutlich das fehlende Log-Verzeichnis gewesen sein, welches ich in den Zeilen 29-37 erzeuge.

Der NGINX auf meinem Produktivsystem verwendet die Datei dh_params.pem, welche ich in den Zeilen 49-57 auch auf den neuen Host kopiere. Anschließend wird in den Zeilen 59-66 die vHost-Datei auf das Zielsystem kopiert und durch die Zeilen 68-77 verlinkt und damit aktiviert.

Die letzten Zeilen kümmern sich um die Einrichtung der Datenbank. Zuerst wird die Dump-Datei auf das Zielsystem kopiert und dort anschließend in die neue Datenbank db_my_it_brain eingespielt. Zum Schluss wird noch der benötigte Datenbank-Benutzer erstellt.

In Zeile 94 und 95 habe ich Variablen eingesetzt, welche in vars/main.yml definiert wurden. Dort habe ich auch eine Variable für den Namen der Datenbank definiert, welche ich gern in Zeile 96 genutzt hätte. Leider ist es mir nicht gelungen, da sowohl priv: '"{{ DBNAME }}".*:ALL' als auch priv: "{{ DBNAME }}".*:ALL zu Fehlern führten. Falls hier jemand eine Idee hat, freue ich mich, wenn ihr mir die korrekte Syntax mitteilt.

Erstes Fazit

Das ging leichter als gedacht. Die benötigten Module waren schnell gefunden und ihre Anwendung aufgrund der hinreichend guten Dokumentation nicht schwierig.

Da die aktuell genutzten Variablen sensible Informationen beinhalten, möchte ich diese zukünftig mit Ansible Vault schützen.

Stand heute bin ich jedoch erstmal in der Lage meinen Blog aus der Datensicherung heraus erneut deployen zu können.

Im ersten Teil dieser Serie haben wir bereits Koha installiert. Bevor wir ein Buch aufnehmen oder verleihen können, müssen noch einige Einstellungen vorgenommen werden. Ein großes Thema ist das bibliografische Framework. Bei der Installation haben wir bereits MARC21 gewählt. Was das ist, warum es wichtig ist und wie wir das Framework für eine Schule anpassen können, darum geht es in diesem 2. Teil.

Dieser Artikel ist ein Teil einer Serie:

1. Installation und Einrichtung einer ersten Bibliothek
2. Das bibliografische Framework
3. Grundeinstellungen
4. Buchaufnahme
5. Drucken von Etiketten
6. Verbinden mit einem Z.39.50 / SRU Server
7. Benutzerverwaltung und Ausleihkonditionen
8. Benachrichtigungen und Erinnerungen
9. Mahnungen und Gebühren

Was ist das bibliografische Framework?

Am besten stellen wir uns das bibliografische Framework wie eine Vorlage vor, nach der Bücher oder andere Medien in Koha aufgenommen werden. In dieser Vorlage legen wir fest, welche Daten wir in unserem System haben wollen. Das könnten z.B. folgende sein:

• Titel und Author/in
• Verlag, Erscheinigsort und -jahr
• ISBN / ISSN
• Altersbeschränkung
• evtl. Sprache

Diese Liste lässt sich beliebig erweitern, aber für eine Schulbibliothek wollen wir es so einfach wie möglich machen. Diese Daten nennt man auch Felder.

Damit sich nicht jede Bibliothek ihre eigenen Felder ausdenken muss, wurde vor vielen Jahren ein Standard geschaffen, der in Koha verwendet wird: MARC21.

MARC21

Wikipedia definiert MARC folgendermaßen:

MARC (MAchine-Readable Cataloging) ist ein bibliographisches Datenformat. Entwickelt wurde es 1966 in den USA. Im Lauf der Jahre folgten zahlreiche verschiedene Versionen, von denen bis heute vor allem die Version MARC 21 weltweit von Bibliotheken verwendet wird. MARC 21 ist ein allgemeines Format, das von verschiedensten Anwendungen gelesen und verarbeitet werden kann. Hauptzweck ist die Übertragung von bibliographischen Daten zwischen Bibliotheken.

Es geht also einen bibliografischen Datensatz, der von einem Computer gelesen werden kann.

Koha verwendet ebenfalls MARC21, deswegen müssen wir uns ein wenig damit auseinander setzen. Es gibt eine gute Einführung in MARC21, die aber nur in Englisch verfügbar ist. Ich kann sie sehr empfehlen, da sie mir geholfen hat MARC21 besser zu verstehen: Understanding MARC.

Ein MARC21 Feld besteht aus einem Tag (einer dreistelligen Zahl), zwei Indikatoren und einem Unterfeld-Code. Hier ein Beispiel für das Feld ISBN:

020 ##  $a 0877547637

Die ersten drei Zahlen 020 stehen für das MARC21 Feld bzw. Tag. Die zwei „##“ stehen für die beiden Indikatoren, die für dieses Feld nicht definiert sind. Mit $a folgt das Unterfeld a für die ISBN. Zum Schluss steht die ISBN. Laut Definition kann man im Unterfeld $z auch eine nicht mehr gültige ISBN angeben.

Eine Übersicht über alle MARC21-Felder gibt es hier: https://www.loc.gov/marc/bibliographic/

MARC21 für Schulbibliotheken anpassen

Ich empfehle wirklich jedem, der Koha einsetzen möchte, sich die oben verlinkte Einführung in MARC durchzulesen, denn es hilft ungemein beim Verständnis, wie Koha funktioniert und wie man es verwenden kann und muss.

Framework exportieren

Da wir jetzt grob wissen, was MARC21-Felder sind, wollen wir in Koha das bibliografische Framework anpassen. Dazu loggen wir uns mit unserem im Teil 1 erstellen Benutzer ein und öffnen den Menüpunkt Administration.

Dort wählen wir den Punkt bibliografisches Framework.

Hier sehen wir nun eine Liste mit allen bibliografischen Frameworks. Wir können theoretisch für jeden Medientyp ein eigenes Framework erstellen, doch wir möchten es so einfach wie möglich haben.

Das Framework können wir gut im Browser anpassen, aber es ist mit viel Klicken und Warten verbunden. Deshalb werden wir das Framework exportieren und anschließend wieder importieren.

In der Liste klicken wir neben Framework mit dem Code „FA“ und dem Namen „Schnellaufnahme“ auf Aktionen → Export. (Falls das Schnellaufnahme Framework fehlt, wurde bei der Installation vergessen, den Haken an der entsprechenden Stelle zu setzen…)

Framework anpassen

Nun müssen wir die heruntergeladene Datei (man kann zwischen CSV, Exel oder Open Document Format wählen) mit einer Tabellenkalkulation unserer Wahl öffnen und wie folgt anpassen.

Im ersten Reiter marc_tag_structure  und zweitem Reiter marc_subfield_structure alle Zeilen löschen mit den Tags:

• 010, 050, 082, 090, 099

Im zweiten Reiter werden wir noch einige Felder verstecken, damit die Maske zur Aufnahme der Bücher übersichtlicher wird. In der Spalte hidden geben wir an folgenden Stellen „5“ für folgende Tags und Unterfelder ein:

• 020 → alle bis auf Unterfeld a
• 022  → alle bis auf Unterfeld a
• 100  → alle bis auf Unterfeld a (und l optional)
• 245  → alle bis auf Unterfelder a und b
• 250  → alle bis auf Unterfeld a
• 260  → alle bis auf Unterfelder a, b und c
• 300  → alle
• 500  → alle bis auf Unterfeld a
• 942  → alle bis auf Unterfeld c
• 952 → nur Unterfelder 2, b, e, f, i, j, l, m, n, q, r, s, u, v, w, y

Wenn wir das geschafft haben, haben wir eine große Hürde bei der Verwendung von Koha genommen. Das was jetzt noch kommt, wird wieder leichter 🙂

Framework importieren

Nun müssen wir unser bearbeitetes Framework wieder importieren. Dazu klicken wir auf Aktionen → Import und wählen unserer bearbeitet Tabellenkalkulationsdatei, die wir gerade eben bearbeitet haben, aus. Mit Import wird unser „FA“ Framework aktualisiert.

Fazit

Wir haben nun ein sehr wichtiges Element in der Konfiguration von Koha eingerichtet – unser bibliografisches Framework! Es ist fast alles für die Aufnahme oder den Import unserer Medien eingerichtet. Im nächsten Teil dieser Serie geht es um weitere grundlegende Einstellungen für Schulen sowie die Einrichtung weitere Medien- und Benutzergruppen.

2 Kommentare

Der Beitrag Teil 2: Das bibliografische Framework – Wie man Koha installiert und für Schulen einrichtet erschien zuerst auf .:zefanjas:..

Unter dem Namen Test Pilot betreibt Mozilla eine Möglichkeit für Firefox-Nutzer, potentielle neue Funktionen vorab zu testen und Feedback zu geben. Mit Min Vid, Snooze Tabs und Voice Fill beendet Mozilla drei Experimente. Dieser Artikel klärt auf, wie es mit besagten drei Projekten sowie mit den weiteren Experimenten Send und Notes weitergeht.

Über testpilot.firefox.com können Firefox-Nutzer mögliche Neuerungen vorab testen, indem entsprechende Erweiterungen installiert werden. Min Vid, Snooze Tabs und Voice Fill haben nun das Test Pilot-Programm verlassen. Für jede dieser Experimente hat Mozilla einen Abschlussbericht mit Dingen veröffentlicht, die Mozilla aus dem Experiment gelernt hat.

Min Vid

Min Vid ermöglicht es, Videos anzusehen und gleichzeitig andere Dinge zu machen. Dafür werden Videos per Knopfdruck in einem Mini-Player angezeigt, der von der Webseite losgelöst ist und andere Fenster überlagern kann. Dies funktioniert mit YouTube, Vimeo sowie Soundcloud.

Das Experiment im Rahmen von Test Pilot hat Mozilla beendet. Für bestehende Nutzer bleibt Min Vid vorerst weiter installiert. Mozilla möchte weiter mit dem Konzept experimentieren und Min Vid daher als sogenannte SHIELD-Studie in Firefox bringen. Das heißt, dass Min Vid bald für einen kleinen Teil der Nutzer zurückkehren könnte.

Allerdings hat Mozilla erkannt, dass eine komplette Neuentwicklung der Code-Basis erforderlich ist, um Min Vid in Sachen Wartbarkeit und Performance tauglich für eine Release-Version von Firefox zu machen. Eine weitere Erkenntnis ist, dass weniger oft mehr ist. Das Playlisten-Feature wird entfernt werden, ebenso die Unterstützung für Vimeo und Soundcloud – Daten zeigen, dass 99 Prozent aller Benutzungen von Min Vid auf YouTube fielen. Mit einem abgespeckten Min Vid und einer kleinen Test-Population möchte Mozilla herausfinden, ob das Konzept im Release-Firefox funktioniert.

Vollständiger Bericht von Mozilla zu Min Vid

Snooze Tabs

Snooze Tabs ging im Februar 2017 an den Start. Wie es der Name bereits andeutet, überträgt Snooze Tabs die Snooze-Funktion eines Weckers auf Tabs.

In diesem Fall geht es aber nicht darum, dass man nicht aufstehen möchte, sondern darum, dass man einen Tab nicht sofort, sondern erst später wieder benutzen will. Der Nutzer kann entweder eine der vordefinierten Optionen auswählen, wie „Später“, „Morgen“, „nächste Woche“ oder „beim nächsten Start“ oder aber man wählt selbst ein Datum und eine Uhrzeit aus. Nach der Auswahl verschwindet der gerade aktive Tab und taucht zum gewünschten Zeitpunkt wieder auf.

Die Funktion wird nicht direkt in Firefox integriert werden. Stattdessen steht Snooze Tabs ab sofort auf addons.mozilla.org als Erweiterung zur Verfügung. Nutzer des Test Pilot-Experiments werden automatisch auf die neue Version migriert, welche gegenüber dem Test Pilot-Experiment bereits diverse Bugfixes und kosmetische Verbesserungen erhalten hat.

Download Snooze Tabs
Vollständiger Bericht von Mozilla zu Snooze Tabs

Voice Fill

Dieses Experiment ging ebenfalls Anfang des vergangenen Jahres an den Start, ist allerdings auf englischsprachige Nutzer beschränkt gewesen. Voice Fill erweitert die Suchmasken von Google, Yahoo! und DuckDuckGo um eine Schaltfläche zur Spracherkennung. Die Spracheingaben dienen nicht nur dem Nutzer, um sein Ziel zu erreichen, sondern wurden auch genutzt, um Mozillas Künstliche Intelligenz zur Spracherkennung zu trainieren, um so wiederum bessere Resultate liefern zu können.

Spracherkennung ist nach wie vor ein großes Thema für Mozilla. In diesem Zusammenhang existieren bei Mozilla unter anderem das DeepSpeech-Projekt, in dessen Rahmen Mozilla eine Sprache-zu-Text-Engine entwickelt, welche durch Techniken des Maschinen-Lernens dazu lernen kann, basierend auf Baidus Forschung zu diesem Thema, und auch Common Voice, ein Projekt, bei dem jeder seine Stimmen beitragen kann, um Mozillas Spracherkennung zu verbessern. Der serverseitige Proxy-Service, den Mozilla als Teil von Voice Fill entwickelt hat, findet weitere Verwendung in Mozillas IoT Gateway, einem Open Source Connector für Smart Devices.

Voice Fill wird im Rahmen von Test Pilot nicht fortgesetzt werden. Stattdessen steht Voice Fill ab sofort auf addons.mozilla.org als Erweiterung zur Verfügung. Nutzer des Test Pilot-Experiments werden automatisch auf die neue Version migriert.

Download Voice Fill
Vollständiger Bericht von Mozilla zu Voice Fill

Notes und Send noch aktiv

Mit Send und Notes sind zwei Experimente nach wie vor aktiv, die seit dem Start wichtige Verbesserungen halten. So können über Send hochgeladene Dateien nun auch mit einem Passwort geschützt werden und man kann erlauben, dass Dateien mehrfach heruntergeladen werden können. Auch funktioniert Send nun in mehr unterschiedlichen Browsern. Notes wurde um die Fähigkeit erweitert, Notizen über Firefox Sync zu synchronisieren und weitere Änderungen stehen in der Pipeline. So wird es bald unter anderem die Möglichkeit geben, mehrere Notizen anzulegen.

Der Beitrag Firefox Test Pilot: Mozilla beendet drei Experimente erschien zuerst auf soeren-hentzschel.at.