Warum Baumstruktur

Für Dateiverzeichnisse (Filesysteme) hat sich eine Baumstruktur etabliert. Wir haben uns daran gewöhnt und für die meisten Zwecke ist das auch eine sinnvolle Strukturierung.

Relativ oft wird man aber mit dem Problem konfrontiert, dass es zwei oder mehr Aspekte gibt, nach denen man seine Dateien oder Unterverzeichnisse gruppieren will. Machen wir es mal abstrakt mit Farbe, Form und Größe.

Dann kann man etwa so etwas haben wie

$MAINDIR/rot
$MAINDIR/blau
$MAINDIR/gruen
$MAINDIR/gelb

und in der nächsten Ebene dann jeweils so etwas wie

$MAINDIR/rot/quadrat
$MAINDIR/rot/kreis
$MAINDIR/rot/dreieck
$MAINDIR/rot/sechseck
$MAINDIR/blau/quadrat
$MAINDIR/blau/kreis
...
$MAINDIR/gelb/dreieck
$MAINDIR/gelb/sechseck

und darunter jeweils

.../klein
.../mittel
.../gross

Aber manchmal möchte man es genau anders haben haben, also zuerst nach Form differenzieren, dann nach Größe und zuletzt nach Farbe.
Und es kann oft sehr unpraktisch sein, wenn Dinge, die eigentlich zusammengehören und die man zusammen bearbeiten will, verstreut über das Verzeichnissystem herumliegen.

Es hilft sicher, dass man sich vorher gut überlegt, wie man seine Verzeichnisstruktur aufbaut, so dass es zumindest in möglichst vielen Situationen einigermaßen passt. Es gibt sicher Möglichkeiten, damit umzugehen. Man könnte zum Beispiel alle sechs Verzeichnisbäume anlegen und via Hardlinks oder Softlinks die Dateien, die man im ersten Verzeichnisbaum richtig eingetragen hat, von den anderen Verzeichnisbäumen jeweils passend verlinken (Softlink) oder dort auch eintragen (Hardlink). Das geht unter Linux und Unix mit deren eigenen Dateisystemen gut, es kann aber eine Herausforderung sein, das konsistent zu halten.

Man kann auch die Daten auf Dateisystemebene irgendwie ablegen, vielleicht sogar in einer der möglichen Strukturierungen, aber den Zugriff über eine Applikation anbieten, die es ermöglicht, so darauf zuzugreifen, als wären sie in einer der anderen fünf Arten strukturiert. Ein typisches Beispiel sind Musikprogramme (Player), die es ermöglichen, die Musikstücke nach Genre, Sänger, und vielen anderen Kriterien zu strukturieren und dann mit diesen Daten darauf zuzugreifen. Es gibt dann typischerweise irgendwo Metadaten, die diese Zusatzinformationen enthalten. Hier hat man noch den Zugriff über das Dateisystem, was sehr praktisch ist, gerade bei Musik, aber die Applikation muss Änderungen erkennen und gegebenenfalls die Metadaten anpassen oder sogar interaktiv abfragen und ergänzen.

Noch weiter geht es, wenn die Datenspeicherung völlig intransparent ist, im Extremfall sogar unter Benutzung sogenannter „Raw-Devices“, und wenn man dann nur noch über so eine Applikation an die Daten herankommt. Im Grunde genommen sind alle Datenbanken in dieser Rubrik angesiedelt, aber auch die Repositories vieler Versionsverwaltungssysteme oder auch Content-Management-Systeme, die natürlich wiederum eine Datenbank verwenden können. Eine Folge davon ist, dass man an diese Daten nur noch mit der Applikation oder deren Hilfsprogrammen herankommt und nicht mehr wirklich auf Dateisystemebene damit arbeiten kann. Eine kleine Anzahl von Datenbankprodukten und das zugehörige Knowhow leistet man sich gerne, denn das braucht man und es lohnt sich. Aber wenn jetzt Software unnötigerweise ihr eigenes Repository-Format statt einer einfachen Dateispeicherung verwendet, kann es schon schwieriger werden, die ganzen Daten im Griff zu behalten.

Das Problem ist also in der Praxis dort, wo es eine große Rolle spielt, häufig irgendwie gelöst. Trotzdem wäre es manchmal schön, wenn die Verzeichnisstruktur nicht wie ein Verzeichnisbaum aufgebaut wäre, sondern zumindst in manchen Teilbäumen wie ein dünn besetzter Hyperquader, wo man nach einer Reihe von Kriterien die passenden Dateien suchen und in einem temporären virtuellen Verzeichnisbaum zugänglich machen könnte. Diese Mehrfachindizierung war übrigens auch in Datenbanken vor etwa 30 Jahren eine Herausforderung, wenn die einzelnen Indizes für sich genommen nicht selektiv genug sind. Man hat wohl das Konzept des Z-Index (oder der Z-Kurve) entwickelt, womit eine Verflechtung von verschiedenen Indizes möglich ist, die für sich genommen nicht selektiv genug sind, um für einen bestimmten Indexwert nur noch eine so kleine Menge von Daten zurückzuliefern, dass eine erschöpfende Suche in diesen Daten unproblematisch wäre.

In der Systemadministration stellt sich diese Frage häufig. In der Linux- und Unix-Welt ist es üblich, größere Applikationen so zu installieren, dass etwa 4-6 Orte im Verzeichnissystem verwendet werden:

  • ausführbare Programme in /usr/bin oder /usr/local/bin oder /bin o.ä.
  • Bibliotheken und statische Hilfsdaten dazu in /usr/lib oder /usr/local/lib oder /opt. Zum Teil architekturunabhängige statische Hilfsdaten und Bibliothken auch in /usr/share. Oft ist die ganze Applikation unter /opt installiert und es gibt softlinks nach /usr/local/bin
  • Man-Seiten unter /usr/man, /usr/local/man, /opt/man o.ä.
  • Konfiguration unter /etc
  • Variable Daten (z.B. Tablespaces für Datenbanken) unter /var/lib, /var/opt o.ä.
  • logs unter /var/log

Das ist das, was sich eigentlich etabliert hat und wie die Software, die mit Linux-Distributionen mitkommt, üblicherweise installiert wird. Man hat so nicht die ganze Applikation zusammen in einem Verzeichnis, aber dafür hat man eine Trennung in statische und dynamische Daten und kann auf Servern viel gezielter Entscheidungen darüber treffen, welche Daten in welches Backup kommen, welche Raid-Konfiguration man verwendet, ob man die Daten lokal oder remote hält, ob man sie mit anderen Servern teilen kann und ob man SSDs einsetzt oder auch wer Schreib- und Leseberechtigungen hat. Diese Fragen wird man eher für alle Daten in /var/lib gleich beantworten als für alle Daten unter /tomcat.
So wird die zweitbeste Vorgehensweise, eben alles, was zu einer Applikation gehört, komplett in einem Unterverzeichnis zu halten, trotz ihrer offensichtlichen Reize, eher selten gewählt. Hier wäre so eine Matrixstruktur für das Dateisystem schön, man könnte also Zeilen für die Applikationen haben und Spalten für die Art der Daten (lib, bin, share, var, log, conf, man,…).

Share Button

iO

Niemand liest Zeitungen wie „Blick“ und „Bild“, aber jeder weiß was drinsteht. Jedenfalls wenn man die Titelseite überall rumliegen sieht. Mal ein interessantes Informatik-Projekt, das dort auf die erste Seite geschafft hat, auch wenn es nur eine Zeitung ist, die niemand liest. Warum braucht man noch ein weiteres Skype oder Whatsapp? Das muß die Swisscom wohl selber wissen, aber nach PRSIM ist ein System, das von einer Schweizer Firma betrieben wird, einfach vertrauenswürdiger als eines von einer amerikanischen Firma.

Share Button

Kompressionsprogramme

Jeder kennt diese Kompressionsprogramme wie gzip, arj, (win)zip, 7z und noch mehr. Sie sind praktisch, um Daten platzsparend aufzubewahren, bandbreitensparend zu übermitteln oder auch einfach nur um Daten zu einer Datei zusammenzupacken. Dabei hat die letzte Aufgabe eigentlich gar nicht viel mit Kompression zu tun, wird aber von manchen Werkzeugen zusätzlich zur Kmpression auch noch unterstützt. Ein weniger bekannter Grund für Kompression, der aber recht wichtig ist, ist im Bereich der Kryptographie. Wenn man Daten vor der Verschlüsselung komprimiert, ist es schwieriger, den Schlüssel zu erraten.

Witzigerweise hat sich in der Linux-Welt als Archivformat das .tar.gz-Format weit verbreitet, während in der MS-Windows-Welt eher die zip-Dateien üblich sind, obwohl beide Formate auf beiden Plattformen relativ gut unterstützt werden:
Unter Linux kann man zwei Programme, zip und unzip finden oder einfach installieren, die ZIP-Dateien erzeugen und auspacken. Unter MS-Windows kann man z.B. cygwin installieren und hat dann auch tar und gzip dabei, oder man kann mit Winzip auch tar.gz-Dateien zumindest auspacken.

Hinter diesen beiden Formaten und den zugehörigen Werkzeugen stehen zwei verschiedene Ansätze. In der Linux-Welt und früher noch mehr in der Unix-Welt war es üblich, Werkzeuge zu haben, die eine Aufgabe sehr gut erfüllen und die sich mit anderen Werkzeugen kombinieren lassen. Herausgekommen ist gzip, das nur eine einzelne Datei oder einen Datenstrom komprimiert, nicht aber mehrere Dateien in ein Archiv zusammenführt, wofür andere Werkzeuge, z.B. tar herangezogen werden können. Man kann das aber mit einem Aufruf erledigen, indem man tar mit einer Option mitgibt, das das Archiv nach der Erstellung noch durch gzip geschickt werden soll oder vor dem Lesen durch gunzip. Dagegen mach zip alles in einem Werkzeug.

Bei genauerem Hinsehen gibt es aber noch eine subtilen, aber doch manchmal wichtigen Unterschied, der eigentlich wenig mit der Frage zu tun hat, ob man ein Werkzeug hat, das beide Aufgaben verbindet.

Im ZIP-Format werden die Dateien einzeln komprimiert und dann die komprimierten Dateien zu einem Archiv zusammengefügt. Bei .tar.gz ist es umgekehrt. Oft ist die Wahl durch Gewohnheiten oder durch Kommunikationspartner ein Stück weit eingeschränkt, aber es lohnt sich doch, diesen Unterschied zu kennen: Beide Ansätze haben ihre Vorteile in verschiedenen Situationen und deshalb ist es eigentlich gut, dass man auf beiden Plattformen auch beide verwenden kann.

Der Vorteil, erst zu archivieren und das Archiv zu komprimieren ist einfach, dass man dabei eine bessere Kompression erzielen kann. Da die Kompression ja darauf basiert, irgendwelche Gemeinsamkeiten, Regelmäßigkeiten oder allgemein Redundanzen von verschiedenen Sequenzen innerhalb der komprimierten Datei zu finden, ist es plausibel anzunehmen, dass man die Kompression manchmal verbessern kann, wenn dies über alle archivierten Dateien gemacht werden kann und nicht nur über die einzelnen archivierten Dateien. Als Beispiel habe ich einmal das /bin-Verzeichnis komprimiert:

$ ls -l bin.tar.gz bin.zip
-rw-r--r-- 1 bk1 brodowsky 3909375 2013-06-20 22:23 bin.tar.gz
-rw-r--r-- 1 bk1 brodowsky 7568659 2013-06-20 22:24 bin.zip

Man sieht also, daß die Wiederholungen und Ähnlichkeiten zwischen den Dateien dazu führen, dass trotz gleichem Kompressionsalgorithmus die tar.gz-Datei nur etwa halb so groß wie die zip-Datei ist.

Der Vorteil, erst zu komprimieren und dann die einzelnen komprimierten Dateien zu archivieren besteht darin, dass man leichter auf einzelne Dateien aus dem Archiv zugreifen kann. Bei tar.gz muss man alles vom Anfang bis zu der gesuchten Datei dekomprimieren, im Durchschnitt also etwas mehr als die Hälfte des Archivs, bei zip nur die eine Datei, die man wirklich will. Aus diesem Grunde wurde das zip-Format auch für die Programmiersprache java verwendet, um die Bibliotheken (jar-Dateien) zu speichern. Das sind ZIP-Dateien mit einem zusätzlichen Verzeichnis META-INF, das Metainformationen enthalten kann. Man kann jar-Dateien mit unzip auspacken und zip-Dateien mit jar xfvv.

Wenn man nun aber eine Datenbankspalte oder -tabelle komprimieren will, sind diese beiden Ansätze nicht so attraktiv. Im einen Fall werden die Zugriffe unakzeptabel langsam, im anderen Fall hat man mit einem einzelnen Datenbankattribut in einer einzelnen Zeile selten genug Masse, um von der Kompression profitieren zu können. Wie könnte man das trotzdem lösen? Vielleicht wäre eine Möglichkeit, daß man ab einer gewissen Datenmenge in der Spalte, also wenn es genug Zeilen gibt, bei denen dieses Attribut nicht null ist, die Daten analysiert und in einem mit der Tabelle assoziierten Bereich Metadaten zur Kompression ablegt, die etwa aus mehrfach vorkommenden Bit- oder Byte-Sequenzen bestehen und diese auf andere Bit- oder Byte-Sequenzen abbilden, so dass die häufigeren kürzer sind als die selteneren gleicher Originallänge. Solange die neu hinzukommenden Daten etwa den schon vorhandenen entsprechen, kann man sie damit auch komprimieren und tatsächlich die Datenbank kleiner machen, aber vor allem in manchen Fällen schneller und in Kombination mit Verschlüsselung vielleicht sogar sicherer.

Nebenbei bemerkt, dass es viele Werkzeuge gibt, die ähnlich wie die hier erwähnten Vertreter funktionieren:

  • lha, zoo und 7z funktionieren z.B. ähnlich wie zip.
  • compress, bzip2 und xz funktionieren ähnlich wie gzip
  • cpio funktioniert ähnlich wie tar

Weil compress in den 90er-Jahren auf patentierten Algorithmen basierte, hat man es praktisch vollständig durch gzip ersetzt, was auch die bessere Kompressionsraten auf Kosten des Zeitaufwands zum Komprimieren erzielt hat. Dann kam bzip2, das noch besser und noch langsamer komprimiert und xz, noch besser und noch langsamer.

tar hieß ursprünglich „tape archiver“, konnte als Bandlaufwerke ansprechen. Es wird aber seit 20 Jahren in meiner Erfahrung ganz überwiegend für Archivierung in Dateien verwendet und sehr selten für Bandlaufwerke. Dafür kam dann irgendwann cpio, das aber auch für beide Zwecke verwendbar ist, wie tar. Nur ist cpio weniger verbreitet und man muss wohl als durchschnittlicher Linux-Anwender häufiger die man-Seite anschauen, wenn man das verwendet, während man bei tar eher die wichtigsten Optionen auswendig kennen könnte.

Share Button

Dockingstation für Mobiltelefone

So eine Dockingstation für Mobiltelefone wäre nicht schlecht. Heutige Smartphones haben eine Rechenleistung, die mit einem Laptop von vor ein paar Jahren durchaus mithalten kann. Warum sollte man also überhaupt noch einen Laptop oder einen Desktop-Rechner kaufen? Könnte man nicht einen Dockingstation mit externer Tastatur, Maus, Bildschirm und eventuell USB-Festplatte haben und dann bräuchte man ein Gerät weniger bezahlen, unterhalten und irgendwann entsorgen?

Wie es scheint, haben auch andere diese Idee gehabt und es gibt so etwas von Samsung.

Hier stellt sich aber jetzt auch die Frage nach dem Mobiltelefon-Betriebssystem neu. Diejenigen, die konsequent Mobiltelefon- und Desktop-Betriebssystem voneinander getrennt entwickelt haben, wie z.B. Apple mit IOS und Mac OS X sind im Nachteil, weil ein IOS einfach nicht als Desktopsystem ausreicht. Android ist sicher schon besser geeignet für diesen Einsatzzweck, aber hier können Mobiltelefon-Betriebssysteme, die näher an gängigen Linux-Distributionen sind, wie z.B. Sailfish OS, Tizen oder Ubuntu Touch punkten.

Share Button

PRISM – 1984

Hat uns George Orwells Phantasie bezüglich des Überwachungsstaats aus dem Buch 1984 doch noch eingeholt?
Haben wir eine „demokratisch legimitmierte“ Stasi 2.0?
Oder ist das eine Ente und reine Panikmache?

Schon wegen gelegentlicher Software-Fehler oder Bedienfehler ist es auf jeden Fall sinnvoll, in diesen Social-Media-Netzwerken auch mit Sichtbarkeit „nur Freunde“ keine Dinge zu schreiben und hochzuladen, bei denen die Sichtbarkeit für einen größeren Personenkreis (z.B. „öffentlich“ oder „nur Freunde plus NSA“ oder „nur Freunde plus Firma XY plus NSA“ statt „nur Freunde“) sehr tragisch wäre.

Bekannt ist sicher, dass man aus der Gesamtheit der Daten eine ganze Menge herauslesen kann. So liest man, dass in einem großen nordamerikanischen Staat einer der vielen Präsidentschaftskandidaten in sehr viel höherem Maße gute Informatiker für sein Wahlkampfteam mobilisieren konnte als der am Ende Zweitplazierte Kandidat. Das hat es diesem Kandidaten erlaubt, die Ressourcen im Wahlkampf bevorzugt bei den unentschlossenen Wählern einzusetzen, wo deren Einflußnahme wirklich zu einer Änderung des Stimmverhaltens führen konnte. Der Kandidat der anderen großen Partei musste seine Ressourcen viel mehr mit der Gießkanne einsetzen und wusste weniger darüber, welche Wähler den Einsatz lohnen und welche Wähler man mit welchen Themen ansprechen kann.

Share Button

Betriebssystem-Images kopieren

Um mehrere Rechner mit identischer Hardware aufzusetzen, ist es verlockend, einfach einen komplett aufzusetzen und dann diese Installation einfach byteweise auf die Platten der anderen zu kopieren. Man muss dann nur noch 2-3 Parameter wie Rechnername ändern.

Erst einmal ist die Frage, wie das überhaupt geht. Ich würde empfehlen, den Rechner mit einem USB-Stick oder einer DVD mit einem Linux zu booten, das komplett im Memory läuft und nichts auf die Festplatten des gebooteten Rechners schreibt. Knoppix ist ein bekanntes und schon seit vielen Jahren verfügbares System für diesen Zweck, aber grundsätzlich eignen sich viele Linux-Varianten dafür und die Mechanismen sind auch etwa dieselben.

Die Installation befindet sich oft auf einem der ersten Laufwerke (Festplatte oder SSD), lässt sich also typischerweise mit /dev/sda oder /dev/sdb ansprechen. Mit fdisk -l /dev/sda und fdisk -l /dev/sdb kann man die Partitionierungen und die Partitionstypen und -größen erkennen, eventuell kann man auch eine Partition mounten, wenn es unklar ist. Nehmen wir also an, dass /dev/sda die gesamte Installation enthält. Nun braucht man Platz, um das Image abzulegen. Vielleicht ist ein USB-Stick oder eine externe USB_Festplatte groß genug, aber man kann das auch direkt über das Netz auf einem geeigneten Server ablegen, wenn man nur die Verbindung und die Zugriffsrechte hat.
Das Image lässt sich nun mit so etwas

dd if=/dev/sda of=- |gzip -9 > /directory/of/mounted/device/image-name-date.gz

oder sogar so etwas

dd if=/dev/sda of=- |gzip -9 |ssh user@server "cat > /directory/of/server/image-name-date.gz"

gewinnen und speichern.

Umgekehrt läßt es sich mit

zcat /directory/of/mounted/device/image-name-date.gz |dd if=- of=/dev/sda

oder

ssh user@server "cat /directory/of/server/image-name-date.gz" | zcat |dd if=- of=/dev/sda

einspielen. Es wird nicht gefragt, sondern eiskalt alles überschrieben, was vorher dort war, einschließlich Partitionstablle. Die Festplatten oder SSDs sollten also gleich groß sein, sonst gibt es böse Überraschungen.

Zunächst fällt einmal auf, dass das Image jede Menge Datenmüll von längst gelöschten Dateien oder von ungenutzten Partitionen enthält. Man kann diese Bereiche aber weitgehend mit Nullen ausfüllen, um das zu verhindern. Dazu muss man jede der Partitionen einmal mounten und mit so etwa wie

dd if=/dev/zero of=/mnt/mounted_partition/zero

eine große Datei anlegen, die die jeweils leeren Bereiche ausnullt. Einige alte Dateisysteme kennen relevante Größenbeschränkungen für Dateien. Dann muss man mehrere Dateien anlegen. Und einige Dateisysteme komprimieren ihre Inhalte, da sollte man schauen, ob sich diese zero-Datei davon ausnehmen läßt, sonst bringt die Aktion nichts und man kann sie sich sparen. Bei verschlüsselten Dateisystemen bringt diese Null-Datei auch nichts. Ist das Image eine MS-Windows-Installation, dann kann man das mit cygwin machen oder von Linux aus die NTFS-Partitionen mounten, um diese zero-Datei anzulegen.
dd bricht ab, sobald der freie Platz verbraucht ist. Dann muss man die zero-Datei gleich wieder löschen. Das Komprimieren mit gzip funktioniert danach viel besser.

Die grundsätzlichere Frage ist aber, ob dieser brutale Ansatz überhaupt funktionieren kann. Erstaunlicherweise funktioniert das recht gut, sowohl für Linux als auch für MS-Windows und wenn man einmal etwas Übung oder eine gute Checkliste oder gute Skripten zur Automatisierung dieser Vorgänge hat, geht es auch recht flott. Nur gibt es für MS-Windows eine Einschränkung, die dieses Verfahren für typische Desktopumgebungen in Organisationen praktisch verbietet. Wenn die MS-Windows-Rechner an eine „Domain“ teilnehmen sollen, dann wird ein interner Rechnername relevant. Im Gegensatz zu dem leicht änderbaren „hostname“ oder „Computername“ ist dieser leider an so vielen Stellen in der Registry eingetragen, dass es nicht einfach ist, diese internen Namen zu ändern. Vielleicht gibt es auch inzwischen Werkzeuge, die diese Aufgabe zuverlässig bewältigen können? Sonst sollte man in diesem Fall andere Mechanismen benutzen.

Share Button