Larry Wall talking about his suggestion for five programming languages one should know:
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,…).
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.
Update 2019-03-23: Die Webseite https://io.swisscom.com/ ist nicht mehr vorhanden.
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 Kompression 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, dass 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, dass 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.
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.
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?
- Guardian
- de-Wikipedia
- en-Wikipedia
- no-Wikipedia
- ru-Wikipedia
- EFF
- Tim Bray hält es für eine Ente
- Schweizer Regierung warnt vor Speicherung in der Cloud
- 20min.ch
- NZZ.ch
- NSA-Panel (Readme dazu): erlaube NSA vereinfachten Zugriff auf User-Daten in Rails-Applikationen
- Yahoo dementiert
- CIO: How to protect you PC from PRISM surveillance
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.
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.
Große Tabellen
Es ist interessant zu sehen, wie große Tabellen sich in Echtzeit oder zumindest interaktiv ohne gefühlte Verzögerung handhaben lassen.
Vielleicht war es einmal praktisch, dass Telefonnummern oder Nummernschilder in vielen regionalen kleinen Tabellen strukturiert waren, die dann jeweils maximal wenige Millionen Einträge enthielten. Auch Bankkonten wurden an den einzelnen Standorten geführt und man musste zum Abheben bei einer anderen Filiale derselben Bank warten, bis die zuständige Filiale kontaktiert worden war. Fahrkarten konnte man für inländische Zugverbindungen kaufen, aber für ausländische Verbindungen war ein Sonderschalter zuständig, und für Auslandsreservierungen musste man zweimal vorbeikommen. Telefonbuchabfragen im Internet waren möglich, aber man musste doch erst den Ort angeben und dann den Namen, selbst wenn es ein seltener Name war.
Heute sieht man, dass es kein Problem mehr ist, einen flachen Nummernraum für ein ganzes Land für Telefonnummern, Nummernschilder oder andere in ähnlicher Häufigkeit vorhandene Daten zu haben. Praktisch ist das zum Beispiel, weil man innerhalb von der Schweiz umziehen kann, ohne die Telefonnummer zu ändern, aber für die Mobiltelefone hat man ja schon von Anfang an auf regionalisierte Nummern verzichtet, früher weil es so wenige Mobiltelefone gab und heute, weil man mit 100 Millionen Mobiltelefonnummern in Echtzeit umgehen kann.
Some thoughts about ssh
In the good old days, when the participants of the Internet still kind of knew each other, it was reasonable to trust each other, because the bad guys where not likely among the few and they did not have much to gain there from an ordinary user. So it was common to use telnet or rlogin or sethost to connect to other computers. Usually the password was transmitted unencrypted, which was actually quite irresponsible.
Today we have to use ssh instead and it does pretty much what telnet could do in the old days, but also quite a bit more, even much more than can be mentioned in these lines. It is not only important to transmit the password in an encrypted way, but also to ensure that the other side is really the desired node, not some man in the middle, trying to capture the password, which would leave us where we were with telnet.
For this purpose the .ssh-directory contains those certificates, which are files like id_rsa and id_rsa.pub. The id_rsa should be kept safe. They must not be given away, but they should also not be changed, which means that they should not be lost, because they are hard to reproduce, otherwise they would not be secret. The security of the whole protocol depends on this. With ssh-keygen it is possible to create such certificates, optionally in such a way that a password needs to be provided prior to using it. This password remains within the local computer. Certificates have fingerprints, that can be shown with ssh-keygen -l. Exactly this fingerprint will be shown when logging into a node from some other node for the first time and it needs to be confirmed. So it is important to make sure that the fingerprints have been transferred on a safe channel prior to this login, because otherwise we could possibly just confirm the fingerprint of the man in the middle. This is like with infectious diseases. It is necessary to work in a very hygienic way all the way, otherwise the security is at risk. A good way might be to start the first ssh-session to some node in a cabled network, where the cable and network topology is well known and trusted and simple enough to assume that the network traffic really goes to the desired host. Another way is to write down the fingerprint on paper or to print it or to use a USB stick to copy it to the host from which ssh is initiated. With this first login an entry to .ssh/known_hosts is created, which will be used subsequently. As long as .ssh/known_hosts contains no corrupted entries, it will be very hard for a man in the middle to do his evil job and the whole process provides a reasonable level of security.
Now the public key from id_rsa.pub of the own computer can be transferred to the remote computer and added to .ssh/authorized_keys on the remote hosts. This results in the possibility to log into that host without the need to enter a password, unless the local certificate needs a password, which it should in such a case. For convenience this password needs to be typed only once per session by calling ssh-add.
ssh is used even for other purposes, because it supports tunneling of other protocols like subversion or git.
Very beautiful is the possibility to use ssh in conjunction with X11 by calling
ssh -X user@host
This allows to start graphical applications on the remote computer and they are displayed on the local computer. The x11-windowing system is network enabled and uses the ssh tunnel.
Redirection of displays has been common practice in the Unix and Linux-world for more than 25 years, but with ssh it is much more secure than with the unencrypted protocols that ware used in the old days. Who of you still knows xhost +?
All of this is referring to ssh for Linux, but it should work exactly the same way on all kinds of recent Unix systems like Solaris or BSD variants. On MS-Windows-computers it is possible and useful to install putty. Many of the capabilities of ssh can be found in putty as well, just packaged and used in a different way. I actually prefer to use cygwin and its ssh implementation on MS-Windows, which is very similar to the Linux-ssh. It is even possible to build up an ssh-server with MS-Windows using cygwin, but this is not so easy.
PDF mit Ruby erzeugen
Es gibt viele Libraries, die mit Ruby, Perl, Java oder was auch immer man so verwendet, PDF-Dateien erzeugen. Das Prinzip ist oft so, dass man eine Art Formular erstellt, in dem dann Platzhalter mit Daten aus dem Programm gefüllt werden. Im Prinzip sehr ähnlich wie das Generieren von HTML-Seiten in vielen Web-Applikationen.
Heute verwendet man für Webapplikationen mit Ruby on Rails HAML. Die älteren Rails-Entwickler erinnern sich aber noch teilweise daran, dass man früher einmal erb verwendet hat. Man hat also das HTML so hingeschrieben, wie es halt aussieht und die Platzhalter dann mit so etwas wie <%= some_ruby_code => ausgefüllt. Es war sogar möglich, Schleifen und Bedingte Codeteile zu haben, dafür hat man dann so etwas wie
<% number.times do |x| %>
...
<%= function(x) %>
...
<% end %>
geschrieben. In HAML ist das alles viel schöner, weil man eine Syntax hat, die den Ruby und den HTML-Code viel eleganter miteinander integriert. Aber HAML ist für HTML gemacht.
Um nun PDF-Dateien zu generieren, lohnt es sich, Text-Formate anzusehen, die zu PDF konvertiert werden können. Möglich wäre zum Beispiel PostScript, aber auch die Formate heutiger Office-Systeme wie MS-Office und LibreOffice und OpenOffice sind grundsätzlich dokumentiertes XML, also durchaus zugänglich, wenn man viel Zeit hat. Ob nun XML wirklich als Textformat zählt oder doch eher als Binärformat mit einzelnen Merkmalen eines Textformats, muss die Praxis zeigen. Viele XML-Formate sind fast so unzugänglich wie Binärdateien. Wer sich mit diesen Office-Systemen auskennt, kann auch Libraries verwenden, die diese direkt generieren oder die die APIs der entsprechenden Software ansprechen, wenn man eine entsprechende Installation erreichen kann. Auf typischen Serversystemen ist das schon eine gewisse Hürde.
Ein schönes Textformat ist LaTeX oder TeX. Das sind Satzsysteme, die das Layout in einer textbasierten Sprache, man kann sagen einer Programmiersprache, beschreiben. Text wird einfach so geschrieben, für mathematische und chemische Formeln gibt es sehr leistungsfähige Funktionen, die ich hier in diesem Blog auch regelmäßig für Formeln verwende, wenn es nötig ist. Und ansonsten gibt es Macros, die mit „\“ anfangen. Diese Macros machen TeX zu einer vollwertigen, aber nicht sehr zugänglichen Programmiersprache, aber für einfache Layouts kann man sich Muster im Internet oder von Kollegen oder aus Büchern holen und anpassen und das Lernen der Macrosprache weitgehend der Zukunft oder anderen überlassen. Weil das nun wirklich „plain“-Text ist, lässt sich sehr gut mit erb arbeiten und ein LaTeX-Template erstellen, in dem dann die Daten aus der Software eingefüllt werden, einschließlich Dingen wie Tabellen, bei denen z.B. die Anzahl der Zeilen dynamisch ist.
Mit diesem Ansatz generiere ich seit dem Bestehen der Firma IT Sky Consulting GmbH alle Rechnungen, die an Kunden verschickt werden. Es muss wohl funktioniert haben, denn ohne lesbare Rechnungen kann kaum eine Firma mehrere Jahre überleben. 😉