hamsterrad

Wenn neu mit alt spricht / bricht

2011-06-27T23:30:00.007+02:00

Vorwärtskompatibilität ist was Schönes, oder? Alte Versionen ko-existieren neben neuen und kommen auch nicht aus dem Tritt wenn sie mit neuen Formaten gefüttert werden. Praktisch ... Manchmal aber auch praktisch, um sich schön in den Fuß zu schießen und dabei dann doch aus dem Tritt zu kommen.

Die Zutaten: ssh-agent, ssh-add

Aktuell bin ich dabei, mit diversen SSH-Hackereien ein "don't get in my way" Changelog Framework für kleine Umgebungen zu bauen, in denen Puppet & Co Overkill sind, aber Doku in einem lose zusammengestrickten Team ein deutlicher Gewinn ist. Eine der Komponenten: SSH Agent Forwarding um auch über mehrere Hops hinweg passwortlose Authentifizierung nutzen zu können. Der dabei offen werdende Auth Socket auf den Zielsystemen ist eigentlich ne eher ungute Idee, aber mit Hilfe von ssh-adds "Confirmation Constraint" in den Griff zu bekommen (involviert $SSH_ASKPASS bei jedem Zugriff auf den Key). Soweit zur Theorie.

Confirmation überbewertet?

Effekt bei ersten Versuchen: Hinzufügen des Keys wird brav bestätigt (man beachte "The user has to confirm each use of the key"), nachfolgende Verwendung funktioniert jedoch komplett ohne Bestätigung durch den User.

$ ssh-add -c
Enter passphrase for /home/jd/.ssh/id_rsa:
Identity added: /home/jd/.ssh/id_rsa (/home/jd/.ssh/id_rsa)
The user has to confirm each use of the key
$ ssh localhost uptime
  3:54pm  up  8:26,  2 users,  load average: 0.08, 0.04, 0.02
$

Ouch.

Der Schuldige: ssh-agent.c 1.105

Nach reichlich Debuggerei und stillem Fluchen (klassisch übers Ziel hinausgeschossen), fällt dann ins Auge, dass ssh-add aus /opt/csw/bin kommt, während der ssh-agent von der Solaris 10 Installation selbst bereitgestellt wird und beide ein stolzer Versions-Graben trennt.

$ strings /bin/ssh-agent | grep ssh-agent.c
@(#)$OpenBSD: ssh-agent.c,v 1.105 2002/10/01 20:34:12 markus Exp $
$ pkgparam CSWosshclient VERSION
5.4p1,REV=2010.03.25

Die reichlich betagte ssh(-agent) Version von Solaris ist an sich schon interessant, noch interessanter ist, dass "Confirmation constraints" bei OpenSSH erst mit 1.107 Einzug gehalten haben. Ergo kann der ssh-agent von Solaris (bis mind. inkl. Solaris 9/10) schlicht nichts mit der Bitte von ssh-add anfangen, den Schlüssel doch bitte nur nach Bestätigung auszugeben.

Oder doch ssh-add?

Hält jedoch beide Beteiligten (ssh-agent/ssh-add) nicht davon ab, frohgemut zu vermelden: "Alles roger!". Könnten beide Seiten etwas ehrlicher arbeiten. Unter Anbetracht der Uhrzeit denk ich mir jedoch genau das ("Alles roger!"), vermerk die Lektion, steig auf OpenCSW's ssh-agent um und erfreue mich an einem funktionierenden Confirmation Constraint.

E-Mails, hiergeblieben!

2010-08-15T15:59:00.001+02:00

Schonmal ein Entwicklungssystem in der Hand gehabt, das E-Mails verschleudert, die eigentlich nicht Umlauf gehören? Für opencsw.org betreiben wir nen www-dev System, auf dem wir Änderungen testen, bevor wir sie live schalten. Mit den Tests (Anwendungen quer durch die Bank weg, CMS, Bugtracker, Eigenentwicklung, …) gehen auch generierte E-Mails einher, von denen wir zwar mitunter wissen wollen, dass sie verschickt werden und wie sie aussehen, aber tatsächlich sollen sie alle bei uns bleiben.

Mit Postfix auf der www-dev Maschine geht das ratz-fatz. Und zwar Anwendungs-übergreifend, also egal ob die E-Mails aus PHP oder Python generiert, per /usr/lib/sendmail getriggert oder direkt via Port 25 zugestellt werden. Ohne Zusatzkonfiguration an den Anwendungen selbst.

# tail -2 /etc/opt/csw/postfix/main.cf
virtual_maps = regexp:/etc/opt/csw/postfix/virtual
inet_interfaces = localhost

# cat /etc/opt/csw/postfix/virtual
/@/     catchall

# getent passwd catchall
catchall:x:65550:1:catchall account for all outgoing postfix email ...

Alle ausgehenden Mails landen somit schön abgreifbar in /var/mail/catchall und können mit dem Tool der Wahl inspiziert werden. Anstatt dem von uns angelegten Catchall-Rollen-Account könnte man natürlich auch persönliche Accounts verwenden. Wie auch immer, Hauptsache die E-Mails bleiben zuhause und das tun sie hiermit! Jetzt nur nicht vergessen, die Betroffenen zu informieren, ansonsten ist Verzweiflung beim Testen und Warten auf E-Mails vorprogrammiert.

cut und der fehlende Whitespace-Delimiter

2009-12-10T23:32:00.001+01:00

Verdeutlichen wir mal anhand eines scheinbar einfachen Problems ein viel fundamentaleres Problem. cut kann bekanntlich nicht mit einer variablen Menge an Field Delimitern umgehen.

$ echo "1 2 3  4 5 6" | cut -d " " -f 3-5 
3  4

Ist besonders dann ärgerlich, wenn es darum geht einen Bereich an Feldern (also Feld X-Y) auszugeben, den Bereiche von Feldern sind mit cut sonst schnell ausgegeben. Alternative Ansätze kommen dann gerne mit wilden Schleifen in awk daher, die zwar machbar sind, aber IMHO absolut nicht intuitiv - geschweige denn kurz - von der Hand gehen.

Nun liegt die Frage nahe “warum zum Geier kann cut denn nicht einfach mit einer variablen Mengen an Field Delimiteren umgehen?” oder aber dahingehend erweitert werden. Hier z.B. gestellt in einem Debian Bug, der Debian-üblich auch mal auf Prinzipien-Ebene ausgefochten und mit WONTFIX geschlossen wird. “Konnte cut noch nie, ist nicht dafür gedacht, nimm einfach was anderes”. Ahhhh, bitte, kann doch nicht so schwer sein. Andere sehen das pragmatischer und basteln einen Patch gegen textutils, der cut das beibringt.

Manchmal geht es eben nicht um schnelle Fixes

Nun, was ist jetzt richtig? Sucht man etwas weiter, findet man diesen wunderschönen Bug Report gegen coreutils, der das Problem inklusive möglicher Alternativen umfassend aufzeichnet und genauso schön beantwortet wird.

The bar for adding new options is very high. Supposing we added it, you have to remember that it still cannot be used by portable scripts

Und da hat der gute Herr einfach Recht. Bei der extremen Durchsetzungen von Shell-Skripten mit Genossen wie cut, will ich (speziell in gemischten Umgebungen) nicht diffusen Problemen hinterher rennen, nur weil cut von Plattform a ein tolles Feature unterstützt, während gleichnamiges cut von Plattform b noch von der alten Schule ist. Oder noch schlimmer, weil das eine cut klassisch mit einfachen Field Delimitern umgeht, jemand das mit einkalkuliert und drumherum baut, während das andere cut stillschweigende variable Mengen an Field Delimitern zusammenfasst. Unschön.

Und was nun?

Was bleibt also als Alternative? Entweder doch das mächtigere, ggf. nicht intuitive, dafür aber standardisierte awk (bzw. perl) oder aber eine simple tr-Alternative des Bug-Report-Verfassers, die ich ganz pfiffig finde.

$ echo "1 2 3  4 5 6" | tr -s " " | cut -d " " -f 3-5
3 4 5

Das ist zwar immer noch kein Behandlung generischer Whitespace Delimiter (also auch Tabs), aber eingängig ists allemal und für die meisten Fälle wirds auch ausreichen.

$LD_LIBRARY_PATH oder doch nicht?!

2008-10-28T22:05:00.001+01:00

Oft genug, hab ich über 3 Ecken gehört, dass $LD_LIBRARY_PATH böse sein soll. Andererseits habe ich mindestens ebenso oft diverse Oracle-/Notes-/Mozilla-/Foo-Wrapper-Skripte in den Händen gehabt, die genau damit arbeiteten.

Wie gut, wenns dann mal sachte knallt und man nicht nur Genaueres über diese “Böshaftigkeit” lernt, sondern auch noch ein paar Details zum Runtime Linker.

Shared Libraries und der Runtime Linker

Shared Libraries sind was Feines. Wird eine Programm gestartet, dass damit arbeitet (sprich: dynamisch gelinkt ist), sorgt der Runtime Linker dafür, dass die vom Programm benötigten Bibliotheken geladen und Referenzen des Programms auf Bibliotheks-Code passend aufgelöst werden.

Dieser Runtime Linker hört unter Linux auf den Namen ld-linux.so und unter Solaris auf ld.so. Und damit der die gesuchten Bibliotheken auch findet, hat der eine oder andere von uns sicherlich schonmal an /etc/ld.so.conf geschraubt (Linux) oder mit crle (Solaris) gespielt … oder aber auch das “böse” $LD_LIBRARY_PATH gesetzt.

Moment, da war doch noch was

Um jetzt zu verstehen, warum $LD_LIBRARY_PATH böse sein soll, muss man verstehen, wie sich der Runtime Linker seinen Such-Pfad für Bibliotheken zurechtlegt. Konkret gibt es neben den zwei eben angesprochen Varianten, den Linker-Such-Pfad zu beinflussen, noch eine weitere: Im ELF Binary selbst.

Dazu wird beim Kompiliervorgang ein sogenannter RUNPATH definiert, den man sich bei einem fertigen ELF Binary mittels objdump –p (Linux) oder dumpelf –d (Solaris) anzeigen lassen kann.

Dieser RUNPATH reiht sich wie folgt in den regulären Runtime-Linker-Suchlauf ein (siehe man ld-linux.so für Linux und Directories Searched by the Runtime Linker für Solaris):

RPATH (deprecated)
LD_LIBRARY_PATH
RUNPATH
Linux: Konfigurierte Suchverzeichnisse (ldconfig & Co)
Standard-Verzeichnisse (/usr/lib, /lib unter Linux, crle-Konfiguration unter Solaris)

Wie man also sieht steht LD_LIBRARY_PATH an oberster Stelle und hat somit Vorzug vor allen anderen Einstellungen. Womit wir zum Problem kämen.

/opt/csw und $LD_LIBRARY_PATH

Hat man ein Solaris System, auf dem neben der Standard-Installation z.B. noch ein /opt/csw-Ast vorhanden ist, dann liegen “ähnliche” Bibliotheken an vielen Ecken und Enden (/lib, /usr/lib, /opt/csw/lib, …).

Die Anwendungen von /opt/csw haben damit prinzipiell kein Problem, denn die sind mit einem RUNPATH (siehe Punkt 3 in der Liste oben) kompiliert, der dafür sorgt, dass passende Bibliotheken aus dem /opt/csw-Ast angezogen werden.

Außer man setzt sich via .bashrc einen globalen $LD_LIBRARY_PATH (nicht fragen, ich wars nicht) der von /lib und /usr/lib angeführt wird. Abgesehen davon, dass es ziemlich unnötig ist, diese Pfade überhaupt explizit anzuführen (da sie standardmäßig abgesucht werden, siehe Punkt 5), kann es dann dazu kommen, dass der Runtime Linker Anwendungen von /opt/csw mit Standard-Solaris-Bibliotheken aus /lib oder /usr/lib verheiratet.

Obwohl die versionstechnisch eigentlich passen müssten (sonst würde sie der Runtime Linker nicht verwenden), schmeckt das den Anwendungen nicht wirklich. Im beobachteten Fall gabs keine startenden Anwendungen, dafür jede Menge Core Dumps.

Schlecht, aber immerhin ists ziemlich einleuchtend, dass $LD_LIBRARY_PATH nichts in .bashrc & Co zu suchen hat.

Wrapper-Skripte und $LD_LIBRARY_PATH

Bei Wrapper-Skripten sieht das anders aus. Die sind für eine kontrollierte Umgebung einer Anwendung zuständig und somit kann $LD_LIBRARY_PATH ohne Kollateralschaden gezielt eingesetzt werden. Das ist insbesondere deswegen notwendig, weil betroffene Programme (also Programme mit Wrapper-Skripten) oftmals Bibliotheken mitbringen, die nicht an systemweite Orte kopiert werden, sondern im Installationsverzeichnis zu liegen kommen. Damit der Runtime Linker die findet, ist ergo Nachhilfe in Form von $LD_LIBRARY_PATH angesagt.

Ein einkompilierter RUNPATH in der Anwendung wäre ebenso denkbar und mit sowas wie der Angabe $ORIGIN im RUNPATH ist das sogar für Anwendungen denkbar, die an beliebigen Orten installiert werden. So wie das z.B. im Firefox-Wrapper-Skript zu sehen ist.

PCI IDs mit lspci, prtconf & Co

2008-10-22T21:05:00.003+02:00

Von Linux kommend, sucht man bei Solaris ja gerne mal vergeblich nach liebgewonnen Tools. Eines davon ist bei mir eindeutig lspci. Zeige mir eine Liste der im System steckenden PCI-Komponenten (Netzwerkkarten, Storage-Controller, Grafikkarten, …).

Sowas gibts zwar auch unter Solaris in Form von prtconf - und ich mag fast behaupten noch hilfreicher, da es die verwendeten Treiber gleich mit anzeigt -, aber das gibt einem anstatt sprechender Gerätebeschreibungen lediglich PCI IDs aus (hier im Beispiel etwa pci9005,2cf).

$ prtconf -D
System Configuration:  Sun Microsystems  i86pc
Memory size: 8191 Megabytes
System Peripherals (Software Nodes):

i86pc (driver name: rootnex)
    ...
    pci, instance #0 (driver name: npe)
        ...
        pci8086,29f9, instance #1 (driver name: pcie_pci)
            pci9005,2cf, instance #0 (driver name: aac)
                sd, instance #1 (driver name: sd)
                sd, instance #2 (driver name: sd)

...
$

Welche Geräte hinter solchen PC IDs stecken, kann man beim PCI ID Repository oder in der PCI Database nachschauen. Linux Distributionen und lspci nehmen einem das ab, indem von Haus aus eine Offline-Version der PCI ID Repository Datenbank mitkommt, die automatisch zur Umsetzung der “nichtssagenden” IDs auf meist verständliche Gerätenamen verwendet wird.

Von Device und Subsystem IDs

Bei so viel Komfort muss man sich nicht wirklich viel Gedanken über die IDs machen und so kann es vorkommen, dass man plötzlich - mit den ganzen IDs unter Solaris konfrontiert - etwas lernt, was man die ganze Zeit falsch im Kopf hatte: Was genau sind eigentlich Subsystem IDs und was sind sie nicht.

Subsystem IDs sind nicht für Subkomponenten eines Chips, also keine Methode um mehrere Subsysteme auf einer PCI Karte anzusprechen oder so … wie ich bisher dachte.

Vielmehr vergibt ein Chipsatz-Hersteller für den auf einer PCI Karte zum Einsatz kommenden Chipsatz eine eindeutige PCI Device ID. Nun kann es vorkommen, dass dieser Chipsatz von verschiedenen PCI-Kartenherstellern verbaut wird. Sowas geschieht ja besonders gerne bei Storage Controllern diverser Firmen (Adaptec, LSI, …) die dann mit anderer Labelung bei Dell (Cerc, Perc), IBM (ServeRAID) oder sonstwo landen.

Um dann diese verschiedenen Karten (mit dem gleichen Chipsatz, sprich der gleichen Device ID) zu unterscheiden gibts die Angaben Subsystem Vendor ID und Subsystem ID. Das Subsystem in diesem Kontext ist also die konkrete “Verpackung” des Chipsatzes in Form einer PCI Karte.

Genau diese Kenndaten sieht man übrigens oben in der Ausgabe von prtconf. “pci9005,2cf” steht für ein Gerät mit Subsystem Vendor ID 0x9005 und Subsystem ID 0x02cf. Mit etwas Sucherei in der üppigen Ausgaben von prtconf –Dv kann man dann auch die Vendor ID 0x9005 und die Device ID 0x0285 für dieses Gerät in Erfahrung bringen.

                    ...
                    name='vendor-id' type=int items=1
                        value=00009005
                    name='device-id' type=int items=1
                        value=00000285
                    ...

Mit diesen Daten bewaffnet findet man im PC ID Repository folgende Informationen. Der Vendor (0x9005) – von in diesem Fall Chipsatz und Karte - ist Adaptec, der Chipssatz (Device ID = 0x0285) wird generisch als AAC-RAID bezeichnet und die konkrete Karte (Subsystem Device ID = 0x02cf) ist ein 5405 PCIe SAS/SATA Controller.

Device IDs sind wichtig für Treiber

Aus Sicht des Betriebssystems ist die Device ID das eigentlich Wichtige, denn darüber kann der Chipsatz identifiziert und somit der passende Treiber zugeordnet werden. Unter Solaris wird die Zuordnung aus /etc/driver_aliases gelesen. Sucht man dort nach den bisher in Erfahrungen gebrachten IDs kann man sich nochmal verdeutlichen, dass die Device ID die für den Treiber relevante ID ist und nicht die Subsystem Device ID.

$ grep pci9005,2cf /etc/driver_aliases
$ grep pci9005,285 /etc/driver_aliases
aac "pci9005,285"

Das Treiber-Modul “aac” wird für PCI Device ID 9005:0285 verwendet und 0x0285 bezieht sich wie oben zu sehen auf den Chipsatz. Macht ja auch Sinn.

lspci auf Solarisch: scanpci

Wem prtconf zu befremdlich sein sollte, der kann auch auf /usr/X11/bin/scanpci ausweichen. Das hab ich eben bei Ben gefunden, wobei der das als /usr/X11/bin/pciscan erwähnt … YMMV.

# /usr/X11R6/bin/scanpci -v 
...
pci bus 0x0004 cardnum 0x00 function 0x00: vendor 0x9005 device 0x0285
 Adaptec AAC-RAID
 CardVendor 0x9005 card 0x02cf (Adaptec, Card unknown)
...

Wie zu sehen ist, übersetzt scanpci sogar, wie von lspci bekannt, PCI IDs in Gerätebeschreibungen (Adaptec AAC-RAID) oder versucht es zumindest (Card unknown). Die Beschreibungen liegen dabei nicht wie bei lspci in einer separaten Datei, sondern sind in /usr/X11/lib/modules/libscanpci.so hart kodiert (der geneigte Leser kann ja mal ein strings auf die Library abschicken, dann weiß er, was ich meine).

Bei all den Vorzügen darf man nicht verschweigen, dass scanpci im Gegensatz zu prtconf root-Rechte benötigt. Als normaler Nutzer bekommt man lediglich ein lapidares “No PCI devices found” vor die Füße gespuckt. Und auf einem Solaris 10 01/06 für Sparc hab ichs eben überhaupt nicht gefunden.

Zusatz: Wen das Zusammenspiel zwischen Solaris Treibern und PCI IDs genauer interessiert, der findet hier und hier weiteres Lesefutter.

Workaround = Resolution?!

2008-10-10T11:46:00.001+02:00

Eben war ich kurz stutzig und hab mich gefragt, ob ich mich verlesen habe. Sunsolve Document ID 237605: Die Controller einiger (teilweise recht großer) Storage Boxen von Sun verabschieden sich vorübergehend nach 994 Tagen uptime. Auwei, fieser Firmware Bug.

Soweit so gut. Üble Dinge passieren auch anderen Herstellern oder auf anderer Ebene im Storage-Stack. Aber weiter im Text.

Sun schlägt folglich als Workaround vor, die Kisten periodisch (etwa alle 2 Jahre) gründlich durchzubooten. Soweit noch nachvollziehbar. Kurz weitergelesen findet sich dann aber das Folgende als Resolution:

“Please see the “Workaround” section above.”

Ok, das muss man erst mal sickern lassen. Da steht nicht, “we are working on it, in the meantime see …”, sondern einfach nur “schau oben”, Punkt. Wenn das also die Resolution sein soll, ist das dann wahrscheinlich “Durch-die-Blume” für WONTFIX (super Dokument btw.).

Wieder was gelernt. Wie auch immer, falls ihr jemand kennt, der Sun Storage im Einsatz hat, gebt ihm mal ein Heads Up für den Fall, dass er über den Sachverhalt noch nicht Bescheid weiß.

Attacke der Großbuchstaben

2008-10-10T00:39:00.001+02:00

Nun bin ich schon seit ein paar Wochen im Dunstkreis von Sun Microsystems tätig und wenn mich heute jemand nach meinem Ersteindruck fragt, dann lautet dieser mit einem zwinkernden Auge: PSE, CDE, FE, IM, WT* … ahhh … Akronym-Alarm! Ungefähr so wie hier.

Zweifach überladene, mit bekannten TLAs kollidierende Akronyme, teilweise zum Kopfschütteln, teilweise zum Schmunzeln, alles dabei. Und wenn man dann mal den Großteil drauf hat, darf man sich wie das Mitglied eines eingeschworenen Kreises fühlen.

Hier meine persönlichen Top 3:

TZE: Time Zone Engineer. Hört sich an, als würde er an einer Zeitmaschine schrauben, dabei sitzt der Kerl doch nur in einer anderen Zeitzone und kann so 24x7 gewährleisten, während unsereins schläft.
LSD: Last Shipment Date. Ohne Worte. Dann noch ne Runde THC und der IT-ler ist glücklich.
TOI: Nicht zu verwechseln mit TOY. Gemeint ist der Transfer of Information … Wissensaustausch. Na denn mal Toi Toi Toi, sowas hat noch nie geschadet :)

Vergleiche ich übrigens unser (glücklicherweise) intern vorhandenes Akronym-Glossar mit dem, das mal jemand unter wikis.sun.com angefangen hat, dann muss das bei wikis.sun.com noch ganz, ganz kräftig aufholen.

Apropos Wiki, vielleicht sollte ich unserem firmeninternen Wiki mal die Glossar-Erweiterung bescheren, so dass man als Neuling nicht ständig zwischen Doku und Glossar hin- und herspringen muss, sondern mit Mouse-Over-Erklärungen verwöhnt wird.

Kenne deine Quellen

2008-10-08T01:22:00.001+02:00

Seit längerer Zeit schon fällt mir auf, dass ich beim Googlen nach Problemen immer öfter auf Blogs lande. Das finde ich auf der einen Seite gut, denn die dort gebloggte, aus dem Arbeitsalltag gegriffene, praxisnahe Second-Hand-Erfahrung kommt dem, wo auch mir gerade der Schuhe drückt, meist recht nahe.

Nicht-Experten am Bloggen …

Andererseits finde ich es mitunter grenzwertig. Wie bekannt, bloggen viele als Nicht-Experten über diverse Themen.

Das ist an sich nicht weiter schlimm. Bloggen auf gleicher Augenhöhe mit anderen dient dem Erfahrungsaustausch und gerade die bei einem neuen Thema anfänglich gemachten Lernerfahrungen sind wertvoll, da sie so in keinem Handbuch nachzulesen sind.

Andererseits stolpere ich viel zu oft über Blog-Artikel, die in auf Google hoch gerankt sind und die einen Hauch von Experten-Wissen um sich haben, obwohl der Artikel-Inhalt keins von beidem gerecht wird. Auch wenn der Autor in anderen Gebieten einen gewissen Ruf hat oder aber der Inhalt ansprechend aufbereitet dargestellt wird, macht all das noch keinen professionellen Artikel-Inhalt.

… und Nicht-Experten am Lesen

Auf der anderen Seite haben wir den suchenden Leser, uns. Auf der Suche nach Wissen / Hilfe saugt der alles auf, was ihm vor die Füße geschmissen wird. Dabei sollte er sich bewusst machen, dass das was er da liest, nicht unbedingt der Weisheit letzter Schluss ist.

Eigentlich offensichtlich und wie an der Uni bei der Literatur-Recherche. Ergo nichts Neues. Aber etwas bei dem es sich meiner Meinung nach lohnt, mal wieder öfter drüber nachzudenken.

Nur weil jemand etwas im Brustton der vollen Überzeugung bloggt oder etwas auf der ersten Google-Treffer-Seite verlinkt ist, bedeutet das noch lange nicht, dass das Gebloggte auch pädagogisch sinnvoll ist.

Und was nun?

Futter zum Nachdenken gibts bei einem Leidgenossen mit “Determining credibitility of web resources” oder aber in einem super Artikel der UCLA-Library (“Thinking critically about World Wide Web resources”) den ich leider nicht mehr finde. Deshalb gibts ersatzweise einen referenzierenden Artikel “How Do We Evaluate Web Resources?” aus dem man sich seine Vorsätze (zwischen den Health-spezifischen Bemerkungen) raussuchen kann.

Meine simplen Favoriten:

- Querchecken. Gibt es eine autoritive / andere Quelle für das was ich gerade lese? Was sagen andere dazu?

- Autor. Wer ist der Autor? Welchen Hintergrund hat er? Was sind seine Qualifikation, über dieses Thema unterrichtet zu bloggen? Was sind seine Motivationen?

- Aktualität. Von wann ist der Artikel? Alt? Dann lieber erstmal anderswo umschauen bzw. bewusst mit dem Wissen lesen, dass das Gelesene überholt sein mag.

Und wofür?

Wenn sowas ins Blut übergeht, kann man beruhigter sein, was den Wahrheits-/Informations-/Nutzgehalt eines Blog-Artikels (sowie sonstiger Informationen im Web) angeht. Gerade Querchecken sorgt meist für ein viel umfassenderes Bild der Realität.

Nützlich ist das auch zur Vorbeugung von Kasperle-Theatern wie dem kürzlich erschienenen Heise-Artikel “Firefox sendet wie Chrome Daten an Google”, bei dem erstmal viele wie von der Tarantel gestochen umhergerannt sind. Was war über den Anti-Phishing-Schutz von Firefox zu lesen: “[…] teilt Firefox in seiner Voreinstellung Google ebenfalls mit, welche Seiten ein Surfer aufruft” … gefundenes Fressen für Überwachungs-Paranoia-Anhänger.

Zu dumm nur, dass das nur die halbe Wahrheit war, wie Heise (immerhin) später nachbesserte. Voheriges Querchecken mit der genauen Funktionsbeschreibung des Features auf der dazugehörigen Mozilla-Seite wäre besser gewesen. Neben Heise selbst hätte zumindest ich das mal machen sollen, bevor ich die ersten (falschen) Heise-News etwas irritiert mit meinen Kollegen bequatschte …

Solaris: Wo bist Gnu?

2008-10-02T00:47:00.001+02:00

Schonmal eine Solaris-8/9/10-Installation in den Händen gehabt und verzweifelt nach less gesucht oder geflucht, weil das grep keine Option –r für Rekursion versteht?

Innerlich wundert man sich dann, warum Linux von Solaris-Jüngern belächelt wird, während es auf deren Plattform offensichtlich nicht mal die grundlegendsten Tools gibt.

Wissen, worauf es ankommt

Ian Murdock, seines Zeichens Debian-Begründer und kurzzeitiger Chief OS Strategist bei Sun, hat – passend zur Problematik - letztes Jahr was von sich gegeben, was eigentlich keiner weiteren Erklärung bedarf:

“[…] how many people really care about the Linux kernel underneath? What they care about is the GNU tools, the desktop, the development environment, and all the other things their favorite distro bundles—and the package system that holds it all together.”

So schauts aus. Mich interessiert das, womit ich direkt konfrontiert bin. Da kann der Unterbau (egal welcher) noch so toll oder jahrzehnteweiß binärkompatibel sein. Wenn mich das nur in Form einer offensichtlich angestaubten Anwendungsumgebung erreicht, hält sich meine Begeisterung in Grenzen.

Die Analogie aus dem täglichen IT-Betrieb: Egal wie technisch solide intern gearbeitet wird, wenn das was dem Nutzer / Kunden gegenüber sichtbar ist, nicht passt (und das können dann wirklich Kleinigkeiten sein), kann man sich alle technisch Finesse in die Haare schmieren. Punkt. Übertragbar auf sicherlich viele andere Bereiche. So einfach ist das.

Solaris und GNU. Es geht doch

Während Ian obige Aussage im Rahmen einer Bestandsaufnahme rund um OpenSolaris / Projekt Indiana traf und es dort GNU-Tool-mäßig in die richtige Richtung geht, siehts bei Solaris 10, mit dem ich mittlerweile fast tagtäglich arbeite, wie eingangs geschildert auf den ersten Blick mau aus.

Aber Stopp, was lese ich da kürzlich:

“[…] we've incorporated many GNU commands and libraries into Solaris already, albeit often with name changes, marooned out in /usr/sfw where new users cannot find it, etc.”

Aha, “with name changes […] where users cannot find it”. Bingo. Man werfe einen Blick in /usr/sfw und finde neben vielen anderen Tools ein ggrep (GNU grep), was auch Rekursion beherrscht. Na, geht doch.

Den Präfix g findet man übrigens auch bei Tools aus den CSW-Paketen. Anscheinend immer dann, wenn eine Namenskollision mit offiziell von Sun verfügbaren (aber angestaubten) Tools ausgeschlossen werden soll. Die Tools aus dem findutils-Paket CSWfindutils sind so z.B. alle mit diesem Präfix versehen (gfind, glocate, gupdatedb und gxargs).

Wer jetzt immer noch less vermisst, dem fehlt wahrscheinlich lediglich das Paket namens SUNWless. Das ist eigentlich skurril, weil SUNWless selbst bei der mit ~4GB veranschlagten Solaris-Installationsvariante “End User System Support” nicht von Haus aus dabei ist, aber was solls. Offizielle Pakete gibts leider nicht wie bei Linux-Distributionen gewohnt einfach zum Runterladen, sondern nur auf den Installations-Medien. Diese jedoch gibts seit Solaris 10 zum kostenlosen Download.

Da hat aber was gehörig Historie auf dem Buckel

Der generell etwas verstaubt wirkende Eindruck von Solaris ändert sich mit diesen Erkenntnissen zwar nicht gravierend (zugestanden, immerhin hat das gute Stück einige Jahre auf dem Buckel), aber wenn man weiß, dass mit OpenSolaris die Zeichen der Zeit erkannt wurden, darf man in Zukunft auf Besserung hoffen und sich derweil seines ggreps erfreuen.

Maus ade: Thunderbird

2008-09-28T17:47:00.001+02:00

Vor einiger Zeit hatte ich die Bedienung von Firefox mittels vimperator nahezu komplett auf die Tastatur umgestellt und ich muss gestehen: Ich bin weiterhin begeistert. Verwirrung bei Kollegen, die einem kurz was im Browser demonstrieren wollen ist zwar vorprogrammiert, aber für solche Zwecke kann man das Add-On ja temporär deaktivieren.

In der Zwischenzeit habe ich darüberhinaus wieder viel mit mutt unter Linux gearbeitet und das legte prompt die Frage nahe, warum ich eigentlich im Mail-/News-Client meiner Wahl, Thunderbird, immer noch so viel die Maus schubse.

Thunderbird bringt zwar von Haus aus einige Tastenkürzel mit; was ich jedoch hauptsächlich vermisste, war eine vim-ähnliche Navigation ('k' und 'l'), wie ich sie von so vielen anderen Programmen gewohnt bin und lieben gelernt habe, sowie das einfache Nachrichten-Verschieben / Navigieren zwischen verschiedenen Ordnern, wie es bei mutt mit einigen Tastenkürzeln sehr rasch von der Hand geht.

Auftritt Add-Ons

Schön, dass es sowas wie Add-Ons gibt:

Nostalgy liefert die nötigen Funktionen zum Verwalten verschiedener Ordner. Mit der Taste 'g' gehts in ein "Springe zu Ordner"-Eingabefeld mit (!) Auto-Completion, d.h. um in meinen Mail-Ordner namens "Bestellungen" zu springen, reicht ein 'gbe<Return>'. Gleicher Modus-Operandi gilt für das Verschieben/Kopieren von Nachrichten mittels 's' oder 'c'.

keyconfig ist fürs Neudefinieren von Tastenkürzeln zuständig. Als solches bringt es unter Extras -> Tastenkürzel anpassen (bzw. Strg+Shift+F12) einen einfachen Dialog mit, der sowohl eine Liste der existierenden Tastenkürzeln anzeigt, als auch die Möglichkeit bietet, diese zu ändern.

Ich habe mir damit die Tasten 'j' und 'k' zum Hoch- und Runter-Navigieren belegt, sowie die Taste 'd' zum Löschen einer Nachricht. Mittels 'v' blende ich die Nachrichtenvorschau ein oder aus. Die vorher auf den Tasten liegenden Funktionen benötige ich nicht, habe sie mir also nicht auf andere Tasten gemappt.

Header Toggle macht genau dass, was man von mutt kennt. Mit der Taste 'h' kann man sich die Header einer Nachricht ein- bzw. ausblenden lassen. Sehr praktisch für all diejenigen, die öfter mal die Header einer Mail zwecks Troubleshooting o.ä. inspizieren wollen.

Die Funktionalität von Header Toogle, wollte ich mir zuerst über keyconfig selbst basteln. Für sowas gibts eine keyconfig-Anleitung inkl. Liste der dafür zur Verfügung stehenden Thunderbird-internen Kommandos, aber so richtig funktionieren wollte das bei mir nicht. Dank Header Toggle habe ich mir die Problemsuche erspart.

GMailUI habe ich erst nach keyconfig entdeckt und beide überschneiden sich in Bezug auf meine Anforderungen etwas. Denn GMailUI versieht Thunderbird mit von GMail bekannten Bedienkonzepten und dazu gehört auch das 'j' und 'k' fürs Hoch- und Runternavigieren. Wer also nur danach sucht und sich ansonsten nicht für individuelle Tastenbelegung kümmert, der ist mit GMailUI anstatt von keyconfig gut beraten.

Darüberhinaus modifiziert es das Thunderbird-Suchfeld, so dass es ein Subset der von GMail bekannten Such-Modifier (from: to: usw.) versteht. Dazu gehören natürlich nur die, deren Suchsemantik Thunderbird bereits kennt, sprich eine der speziellen Suchen die auch in der Dropdownliste des Suchfelds angezeigt werden (Absender, Empfänger, Subject, Text). Mit from:johndoe als Suche, suche ich dann also nach Mails von johndoe als Absender. Siehe dazu auch die Einführung auf der GMailUI-Seite. Das Suchfeld lässt sich mit GMailUI übrigens praktischerweise via '/' anspringen.

Kompatibilitätsprobleme mit Thunderbird 2.0.0.17

keyconfig siehts mit der Kompatibilitätsprüfung eng und ist noch nicht als kompatibel mit der just erschienenen Thunderbird-Version 2.0.0.17 ausgewiesen. Als vorübergehenden Workaround dafür (als auch für alle sonstigen "Dieses Add-On ist nicht kompatibel"-Probleme) kann man eine der im mozillaZine vorgeschlagenen Abhilfen verwenden.

Aber Achtung (man überliest den Hinweis, obwohl eigentlich unüberlesbar, leicht): Der Wert extensions.checkCompatibility existiert standardmäßig nicht, muss also erst angelegt werden. Wer, wie ich, den Wert erst mit dem falschen Typ anlegt, muss prefs.js händisch editieren, um ihn wieder los zu werden.

Think Time: Denk mal drüber nach

2008-09-17T01:26:00.002+02:00

Vor einiger Zeit bin ich über einen amüsanten Artikel zum Thema AOL-User und wie sie die Internet-Welt veränderten gestolpert ... Schonmal von Eternal September gehört? Neben jeder Menge Anekdoten wird im AOL-Artikel ein simples Konzept angeschnitten, das seitdem in meinem Kopf fleissig Runden dreht: Think Time.

Es darum, darüber nachzudenken, was man schreibt bzw. von sich gibt. Man könnte es auch als kurze Selbstreflektion bezeichnen oder auch als das, was offensichtlich vielen fehlt, die tagtäglich durch die Foren von golem.de oder heise.de trollen (kleines Beispiel gefällig?).

Think Time und AOL

Die AOL Story, in der Think Time aufgegriffen wird, ist betitelt mit "The Making of an Underclass" und beschreibt die sinnentfreit und ruppig um sich postende AOL-Nutzer-Welle, die Anfang der 90er über das Usenet hereinbrach. Das war zu den Zeiten als auch bei uns jede zweite Woche eine kostenlose AOL-CD mit Teststunden im Briefkasten lag und wenn ich mir überlege, wie viel Ahnung ich damals von Internet hatte (über das AOL-Interface hinaus so gut wie keine), von sowas wie Netiquette ganz zu schweigen, verwunderte mich das geschilderte Aufeinanderprallen von zwei Welten nicht.

Anstatt den Missstand jedoch rein an den neuen Nutzern festzumachen, nahm ein schlauer Mensch mit "AOL Usernet interface: a review" einen Schritt zurück, um sich den AOL-Usenet-Client näher zu betrachten. Dass diesem ein Offline-Modus fehlte, veranlasste den Betrachter zu einer interessanten Folgerung:

"AOL customers, after they use up their five hours per month that are included in the monthly fee, are paying $3.50/hour to read and write news -- and to think about what they write. The latter, I believe, has a profound effect on the way AOL users interact with the net. They are paying for their think time, so they skimp on think time. Followups from AOL users tend to be blunt rather than thoughtful. I blame AOL, not its customers, for this."

AOL-Nutzer waren demnach also nicht per se ungemütliche oder unintelligente Zeitgenossen, sondern der Zeit-/Geld-Druck nahm ihnen den nötige Abstand zu dem, was sie so von sich gaben. Anstatt nochmal kurz drüberzulesen und dabei nachzudenken, verschickte man Postings lieber postwendend.

Wer schon selbst mit etwas Abstand eine Mail revidiert hat, der weiß, was einem mit fehlendem Abstand so durch die Finger gehen kann.

Think Time andernorts

Nicht nur bei Usenet-Postings tut etwas Bedenkzeit gut. Anders verpackt gibts das beispielsweise in Spiele-Entwicklungs-Projekten. Half-Life hatte in den finalen Zügen seiner Entwicklung einen 48-stündigen Cooling-Off-Process, um sicherzustellen, dass im Eifer des Gefechts nichts Wichtiges vergessen wurde. Super Idee.

Heute läuft das sicherlich unter dem Begriff Quality Assurance, aber Cooling-Off-Process bringt die dahinter stehende Notwendigkeit meiner Meinung nach perfekt rüber. Das vermeidet genau das, was man nur zu gut von sich selbst kennt. Schnell noch was in Eile fertiggemacht oder verschickt, nur, um kurz danach zu merken: "Oh Mist, da fehlt noch was bzw. muss eigentlich noch korrigiert werden". Zu spät ...

Etwas Nachdenkzeit fordert auch Simon Tatham, der Entwickler des freien SSH-Clients PuTTY, in seinem Leitfaden "How to Report Bugs Effectively". Er muss feststellen, dass viele der unverständlichen Bug-Reports nicht wie erwartet von fremdsprachigen Nutzern kommen, sondern ganz im Gegenteil von Muttersprachlern:

"All the most unclear reports come from native English speakers who assume that I will understand them even if they don't make any effort to be clear or precise. [...] Read what you wrote. Read the report back to yourself, and see if you think it's clear."

Lese dir deinen Report selbst vor und versuche zu verstehen, was du da geschrieben hast. Denke drüber nach. Think Time also. Und das hilft meiner Meinung nach nicht nur bei Bug-Reports, sondern auch bei sonstiger E-Mail-Kommunikation.

Das Beste zum Schluss

Infiziert vom Think Time Virus habe ich natürlich "think time" direkt an google verfüttert, was einen wahren Augenöffner in Form einer wissenschaftliche Abhandlung zu Tage förderte: Using "Think-Time" and "Wait-Time" Skillfully in the Classroom.

Erforscht wurde die Auswirkung von Frage-Antwort-Pausen in einem Klassenraum-Szenario auf die Qualität der Antworten.

Was dabei herauskam finde ich interessant und einleuchtend zugleich: Verordne dir eine kurze Zwangspause vor Antworten (idealerweise mindestens 3 Sekunden) und die Qualität deiner Aussagen / Herangehensweisen an Dinge wird sich verbessern. Anders formuliert: Anstatt gleich loszuplappern erstmal innehalten und DENKEN!

Hört sich absolut simpel an, aber wenn ich mal beobachte, wer diese einfache Regel im (Arbeits-)Alltag einhält, sich also die Zeit nimmt, eine Frage oder Aussage auf sich wirken zu lassen (und sich damit die Chance gibt, etwas mit Abstand zu betrachten), bevor er den Mund aufmacht, dann sind das nicht allzuviele. Auch mich darf ich da nicht immer ausnehmen, aber immerhin gebe ich mir seit Kurzem bewusst Mühe und gönne mir und meinem Mitmenschen etwas Nachdenkzeit.

OpenSolaris, Project Indiana, Nevada & Co

2008-09-09T22:38:00.002+02:00

Seit kurzem habe ich beruflich verstärkt mit Sun Solaris zu tun und auch wenn dem sicherlich nicht so ist, könnte man stark meinen, dass es Sun mit neuen Benutzern nicht gut meint. Konkretes Beispiel: Das OpenSolaris Projekt.

Unter OpenSolaris verstand ich bis dato die quelloffene Variante von Solaris, also eine Art Solaris-Distribution für jedermann mit der dazugehörenden Entwickler-Community und Sun als großem Bruder im Rücken. Ganz ähnlich wie das z.B. beim Fedora Project von RedHat der Fall ist. Nun durfte ich lernen, dass das so nicht ganz korrekt ist (und darüberhinaus, dass das OpenSolaris-Projekt bereits einiges an Turbulenzen hinter sich hat).

Die Anfänge

OpenSolaris ging 2005 an den Start und begann als eine schrittweise Offenlegung verschiedener Solaris Komponenten (im Sun-Jargon Consolidations genannt). Den Start machte die Consolidation DTrace, gefolgt von anderen Consolidations wie z.B. der prominenten OS/Net (ON), was dem Solaris Kernel und Netzwerkstack zuzüglich Treiber, Filesysteme & Co entspricht.

Wichtig dabei: Zum damaligen Zeitpunkt war das kein komplett offengelegtes Betriebssystem, sondern wie gesagt nur ein Sammelsurium von Komponenten aus denen sich kein komplettes OS bauen lies. Entwickler konnten an den Komponenten werkeln und Sun stellte dazu eine Entwicklungsplattform bereit.

Das waren die Anfänge. Aus den so entwickelten Komponenten wurden unabhängige Solaris-Distributionen wie Schillix oder BeleniX gebaut.

OpenSolaris selbst setzte sich also anfangs aus zwei Sachen zusammen:

Die offen liegenden Komponenten und
Die darum entstandene Entwickler-Community

Beides zu finden unter opensolaris.org. Sowas wie OpenSolaris als Distribution gab es zu diesem Zeitpunkt nicht.

Erster Anlauf gefloppt, Enter Project Indiana

Das war wohl nicht nur für mich verwirrend, somit hob Sun Mitte 2007 das Project Indiana aus der Taufe. Erklärtes Ziel: Die schönen Technologien von OpenSolaris der breiten Masse in Form einer offiziellen Distribution zugänglich machen. D.h. die bisherigen zwei Dimensionen von OpenSolaris (Quellcode, Community) um eine dritte zu erweitern: Eine offizielle Distribution (aka OpenSolaris OS).

Das Projekt heißt also Indiana und arbeitet daran, eine offizielle OpenSolaris Distribution zu bauen, die schöne Dinge enthält, wie ein netzwerk-basiertes Paketmanagement (IPS) a la apt-get oder yum, einen generalüberholten Installer oder aber auch einfach von Haus aus sowas wie die GNU-Tools.

Als Zielklientel gelten dabei speziell all diejenigen, die bis dato Linux am Laufen haben und sich unter Solaris nicht wohl fühlen. Ein großer Markt, der bisher von OpenSolaris trotz toller Technologien wie ZFS und DTrace unerschlossen ist.

Die OpenSolaris-Community genunix.org bringts in der Problembeschreibung zur Motivation von Indiana ohne Drumherumreden auf den Nenner: "we're not presenting OpenSolaris as crisply as we could be [...] the goal is to make what Solaris has to offer available to the larger market that by and large is more familiar with Linux as things stand today.".

Steiniger Weg zu OpenSolaris 2008.05

Um Project Indiana zum Laufen zu bekommen, holte Sun 2007 Ian Murdock, den Begründer von Debian GNU/Linux, mit ins Boot. Knapp ein Jahr später, im Mai 2008 sah das Kind mit dem ersten Release (OpenSolaris 2008.05) das Licht der Welt.

Der Weg dahin war steinig, denn er war verbunden mit einem Umdenken in der Projektausrichtung. Anstatt sich auf den Quellcode zu konzentrieren und nebenbei viele unabhängige Distributionen wachsen zu lassen, ruderte Sun zurück und fokusiert mit OpenSolaris plötzlich eine eigene Distribution. Das sich damit viele vor den Kopf gestoßen sahen, war fast vorprogrammiert. Die Diskussion zur Namensfindung für die offizielle OpenSolaris Distribution lässt tief blicken. Ben Rockwood sieht das Geschehen rund um Project Indiana und das erste offizielle Release einhergehend mit einem radikalen Umbruch in der OpenSolaris Community.

Anstatt Freibier und Mitbestimmungsrecht für alle, gibts ein "Ihr dürft mitprogrammieren, aber Sun ist am Ruder". War ja eigentlich abzusehen, oder?! Nicht nur das, meiner Meinung nach, machts auch deutlich mehr Sinn. Wenn ich etwas will, dann die Technologie und ein stabiles und nachvollziehbares Distro-Modell. In einem ein lose gekoppelten Netz aus Sun ohne transparenten Fahrplan und einer angebauten Entwickler-Community mit einem halben Dutzend Distributionen schwer vorstellbar.

Neue Versionen von OpenSolaris sollen übrigens in halbjährlichem Turnus erscheinen. Deutlicher Wink mit dem Zaunpfahl, dass Sun weiterhin Solaris als die zu favorisierende Plattform sieht, wenn es um den Geschäftseinsatz geht.

Project Nevada und Solaris Express Community Edition

Fehlt noch was auf der Liste der zu klärenden Begrifflichkeiten: Project Nevada und Solaris Express Community Edition (SXCE). Beides Begriffe, über die man zwangsläufig stolpert, wenn man die Nase in OpenSolaris hängt.

Zu Project Nevada gibs interessanterweise keine eigene Projektseite, so wie es sie z.B. für Project Indiana gibt. Daher muss ich mit einem Auszug aus der OpenSolaris FAQ dienen, der gleich beide Begrifflichkeiten klärt:

Solaris Express Community Edition: This is Sun's unsupported binary release of OpenSolaris plus additional technology not released as source. The release is also known as Nevada and it is updated every two weeks, available as a free download.

Ok, Sun nimmt das was in der OpenSolaris Community entwickelt wird, ergänzt das um die noch verschlossen gehaltenen Komponenten und veröffentlicht das Gesamtpaket in Binärform alle zwei Wochen. Das dient zum einen als Entwicklungsplattform für OpenSolaris selbst und zum anderen als Bleeding-Edge Momentaufnahme für all diejenigen, die wissen wollen, was Nevada gerade so kann. Versionierungstechnisch sieht man dort dann Konstrukte wie "SXCE based Nevada Build 97".

Ursprünglich gabs noch ein Release namens Solaris Express. Das war weniger hochfrequent als SXCE und somit nicht ganz bleeding-edge. Mittlerweile ist das Historie, wenn man über Links stolpert, die noch darauf verweisen, wird man zur OpenSolaris Distro weitergeleitet.

Perspektivisch wird Sun auch SXCE fallen lassen. Ich schätze mal, dass wird dann soweit sein, wenn mit der OpenSolaris Distro selbst als Entwicklungsplattform gearbeitet werden kann. Damit gibts dann einen Namen weniger einzuordnen (super!). Die regelmäßigen Builds wirds zu Entwicklungszwecken jedoch weiterhin geben. Schließlich sollen die Entwickler ja wissen, wo sie stehen.

So und wo ist nun das Problem?

Man verinnerliche das bisher gesagte bzgl. den drei Dimensionen von OpenSolaris und gehe auf opensolaris.org. Dass dies die Seite der OpenSolaris-Entwickler-Community ist, weiß ich mittlerweile, aber wie sieht es für Nicht-Initiierte aus? Was steht dort so schön:

OpenSolaris is an operating system that provides a rich, coherent platform for building and running applications.

Was bitte? Auf der Entwickler-Seite würde ich als prominentes Hinweis-Schild eines von zwei Dingen erwarten:

Einen direkten Verweis für End-User wie mich: "This is the OpenSolaris developer community page. For information on the OpenSolaris Distro please see opensolaris.com".
Eine klare Aussage, was OpenSolaris genau ist (Quellkomponenten, Community, Distro)

In der FAQ stehts schließlich (What is OpenSolaris?: "OpenSolaris is an operating system (OS), a source base, and a community."), aber um da hinzukommen, brauche ich drei Klicks. Auf der Hauptseite wäre das m.E. besser aufgehoben. Nicht sehr einsteigerfreundlich.

Aber auch genunix.org, die OpenSolaris Community Plattform machts nicht besser. Auf deren Startseite findet sich kein einziger "Über uns" Link. Nicht-Eingeweihte dürfen also erstmal auf eigene Faust rausfinden, worum es bei genunix überhaupt geht ... Selbst ein absolut bekanntes Projekt wie das des Apache HTTP Servers beginnt seine Projektseite mit einer Erklärung, worum es überhaupt geht.

Ist ein erstes Hier-gehts-lang bzw. An-die-Hand-Nehmen von Neulingen zuviel verlangt?

Kanonisch?

2008-08-22T10:49:00.001+02:00

Ich kann mich noch gut entsinnen, wie einer meiner ehemaligen Kollegen in Zusammenhang mit DNS immer von kanonischen Hostnamen sprach. Ich kratzte mir derweil mental am Kopf, "Kanonisch? Was das?". Geklärt haben wir das seltsamerweise nie und heute gabs dann sowas wie ein Deja-Vu.

Ich blättere in meinen LPIC-2 Vorbereitungsunterlagen und siehe da, Postfix kennt eine Datei namens /etc/postfix/canonical. Canoncial? Gut, Zeit zu klären, was es mit kanonisch bzw. canonical auf sich hat. Und zwar generell und nicht nur im Postfix-/DNS-Kontext.

The usual state or manner of something

Das Jargon File von Eric Raymond bietet eine feine Abhandlung über die Abstammung des Begriffs canonical: canonical kennt mehrere Kontexte (religiös, mathematisch, technisch, ...), ist also differenziert zu betrachten. Für den technischen Kontext, der uns interessiert, gilt laut Jargon File:

"it (canonical) is implicitly defined as the way hackers normally expect things to be."

Das passt gut zusammen mit der Definition, die den Artikel einleitet: "The usual or standard state or manner of something" und auch mit dem, was "DNS for Rocket Scientists" zu canonical im Kontext DNS zu sagen hat: "Canoncial means expected or real name".

Es geht also um eine Art Lingua Franca, ein Verwenden von Begriffen, so wie es jedermann erwartet und bei dem jeder weiß, worum es geht. Eindeutig, allgemeingültig und ohne individuelle Eigenheiten. Die Progammiererwelt kennt das sogar als Design Pattern und auch bei URLs kennt man den Ausdruck kanonisch.

Kommen wir also zurück zu den anfänglichen Unklarheiten: Kanonisch bei DNS und canonical bei Postfix.

Kanonisch für DNS

Wenn man die Erklärung von canonical nimmt und drei und drei zusammenzählt, kann sich jetzt wohl schon fast denken, was kanonische Hostnamen sind. RFC 1034 "Domain Names - Concepts and Facilities" hält in Abschnitt 3.6.2 "Aliases and canonical names" die offizielle Erläuterung bereit. DNS ist ein Namensgebungssystem und für solche gilt:

"Most of these systems have a notion that one of the equivalent set of names is the canonical or primary name and all others are aliases. The domain system provides such a feature using the canonical name (CNAME) RR."

Ok, mehre Namen, davon ist einer kanonisch und die anderen werden als Aliase erachtet / definiert. Realisiert wird die Aliaserei im DNS über die CNAME Resource Records. War klar, ab sofort muss ich nur auf meine Terminologie aufpassen.

Denn wenn ich bisher von einem CNAME sprach, meinte ich damit oft den Alias (also die linke Seite des CNAME Records). Per Definition ist der aber gerade kein Canonical NAME ... uff. Ungünstiger Sprachgebrauch, das hat auch RFC 2181 "Clarifications to the DNS Specification", Abschnitt 10.1.1 "CNAME terminology" erkannt.

"It has been traditional to refer to the label of a CNAME record as "a CNAME". This is unfortunate, as "CNAME" is an abbreviation of "canonical name", and the label of a CNAME record is most certainly not a canonical name."

Merke: RR sind danach benannt, auf was sie zeigen. Ein MX Record zeigt auf einen Mailserver, ein NS Record zeigt auf einen Nameserver und ein CNAME Record zeigt eben auf einen Canonical NAME. Die linke Seite der Gleichung wird bei allen Records generisch als Label bezeichnet und im speziellen Falle eines CNAMEs als Alias.

Das hindert keinen daran, Aliase nach wie vor als CNAME zu bezeichnen. Selbst Sendmail spricht in seiner Doku von CNAMEs, wenn es eigentlich einen Alias meint. Nun gut, immerhin wissen wir das nun auseinanderzuhalten und verstehen auch unsere Kollegen, wenn die mal wieder von kanonischen Hostnamen sprechen.

Kanonisch für Postfix

Auch wenns jetzt spezifisch für eine Software wird, die nicht jeden interessieren mag, untermauert die folgende Beschreibung das Verständnis vom Begriff kanonisch nochmal und ist somit auch für Nicht-Postfix-Jünger interessant.

Postfix spricht auch DNS, aber darum gehts hier nicht, sondern vielmehr um eine der vielen Möglichkeiten in Postfix E-Mail-Adressen umzuschreiben: Die Datei /etc/postfix/canonical.

Besagte Datei dient als letzte Instanz zum Adress-Umschreiben vor dem Einspeisen von Emails in die Queue. Hier kann also nochmal Hand an die Adressen (Header und Envelope, siehe The envelope versus the letter) gelegt und dafür gesorgt werden, dass ein kanonisches oder einheitliches Adressformat vorliegt.

Kyle Dent erklärts in Postfix - The Definitive Guide als: "If different mail systems on your network create addresses in different ways, you can relay them all through your Postfix gateway and have it fix up the addresses into your standard format".

Betonung liegt auf "your standard format", kanonisch also.

(Anmerkung für Postfixler: Im Gegensatz zu den anderen Umschreibemöglichkeiten bei Postfix (virtual, aliases) gilt canonical nicht nur für Empfänger- sondern auch für Absenderadressen. Weiterhin kümmet sich canonical um Header- und Envelope-Adressen, virtual und aliases kümmern sich lediglich um Header-Adressen.)

MTAs im Überblick

2008-08-19T14:11:00.003+02:00

Message Transfers Agents (MTAs) sind nicht nur Schaltstellen für unsere E-Mails, sondern auch ein Lernziel für die LPIC-2-Prüfung. Und als ob dabei ein MTA nicht genug wäre, sollens gleich alle der üblichen Verdächtigen sein:

The following is a partial list of the used files, terms and utilities:
Configuration files and commands for postfix, qmail, exim and sendmail

Wie schön, dass es die MTA Comparison von Dan Shearer gibt. Dort findet man zwar keine konkreten Konfigurationsoptionen, dafür aber einen schönen Abriss mit Historie, Blick über den Tellerrand und persönlichem Vergleich.

Dabei fällt direkt auf, dass die vier MTAs mehr gemeinsam haben, als man denkt: Maildir stammt vom qmail Autor Dan Bernstein, PCRE wurde vom Exim-Autor Phil Hazel geschrieben und Sendmail X bzw. dessen Nachfolger MeTA1 schauen sich die Modularität an postfix ab. Prima, kommen wir zu den Unterschieden.

Seitenhiebe auf Sendmail

Wer sich schonmal beim Anblick einer Sendmail .cf-Datei (auch bekannt als Explosion in a Punctuation Factory) geschüttelt hat, der wird bei Dan's Seitenhieben auf Sendmail schmunzeln: Neulinge sollten Sendmail einfach nicht mehr erlernen, dann wäre Sendmail in einer Generation gegesessen, so sein Tipp.

Zugegeben, die .cf-Dateien sind nicht intuitiv, aber während viele die mal gesehen haben und nie wieder was mit Sendmail zu tun haben wollen (mich eingeschlossen), ist ebenso vielen sicherlich nicht klar, dass man in den .cf Dateien im Regelfall garnichts mehr schrauben muss.

Dank m4 schreibt man eine Datei, die deutlich mehr an Konfigurationsdateien erinnert und verwandelt diese dann in die wirr aussehende .cf-Datei. Und zugegeben, die sieht teilweise auch nicht viel anders aus, als manche Sektionen einer Exim-Konfiguration. Andererseit, hat man mal mit Exim und dessen vorbildlicher Doku gearbeitet, findet man die Doku von Sendmail etwas mau.

Kleine Entwicklerkreise und ihre Folgen

Weiter im Programm. Beim Vergleich der MTAs kreidet Dan zurecht Postfix den kleinen Entwicklerkreis an. Was passiert mit Postfix, wenn der Herrscher über Postfix, Wietse mal nicht mehr ist?

Das Beispiel qmail hat gezeigt, was passieren kann, wenn der Vater hinter der Software aufhört, an dieser zu wirken. Das letzte offizielles Release 1.03 wurde am 15. Juni 1998 (!) freigegeben und seitdem tummeln sich Patchsets über Patchsets. Dan kommentiert dazu, dass einen wahren qmail-Guru das Wissen über diese verschiedenen Patchsets ausmacht.

Gute Frage also nach der Falle "kleiner Entwicklerkreis". Aber die Frage muss man nicht nur Postfix stellen: Was für einen Entwicklerkreis hat beispielsweise Exim? Ist nicht Philip Hazel hauptverantwortlich für Exim ähnlich wie Wietse Venema für Postfix?

Adieu Mr. Exim

Im Exim Bug-Tracker sind neben Phil eine Hand voll Entwickler unterwegs (Magnus Holmgren, Tony Finch, Nigel Metheringham, Tom Kistner), also nicht nur ein Entwickler. Aber hoppla, was muss ich lernen: Anfang des Jahres wurden alle offenen Bugs, die auf Phil liefen, von Nigel übernommen. Grund dafür: Phil Hazel ist in den Ruhestand gegangen und zieht sich aus der Exim-Entwicklung zurück.

Na das kann ja interessant werden. Selbst Nigel war letztes Jahr etwas überfragt, wo genau es hingeht und Mitte 2008 malt er die Situation nicht gerade rosig. Phil hatte über die letzten Jahr full time an Exim gearbeitet und ein kräftiges Vakuum hinterlassen (er selbst hats kommen sehen). Na dann mal toi toi toi, bin gespannt, wo das hingeht.

Für mich auf jeden Fall ans Eingemachte, d.h. das konkrete LPIC-Know-How zum Thema MTAs.

OpenVPN: Cannot open /dev/net/tun

2008-08-12T22:34:00.004+02:00

Bin eben beim Spielen mit OpenVPN auf einer Debian Sarge Maschine über die obige Fehlermeldung gestolpert. Die Gerätedatei /dev/net/tun ist nicht zu finden, soviel ist klar. Aber woran genau hängt das?

Tue Aug 12 14:49:42 2008 OpenVPN 2.0 i386-pc-linux [SSL] [LZO] [EPOLL] built on Jan  7 2007
Tue Aug 12 14:49:42 2008 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Tue Aug 12 14:49:42 2008 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Tue Aug 12 14:49:42 2008 Cannot allocate TUN/TAP dev dynamically
Tue Aug 12 14:49:42 2008 Exiting

Alle, die es eilig haben, bitte einen Blick in die OpenVPN man page werfen (Abschnitt TUN/TAP DRIVER SETUP) oder direkt zum Ende dieses Artikels springen. Für alle anderen hier ein paar Rahmeninformationen zur Orientierung.

OpenVPN Grundlagen

OpenVPN als Userspace-Programm arbeitet mit den TUN/TAP-Treibern des Kernels zusammen. Diese Treiber gaukeln dem System reguläre Netzwerk-Schnittstellen (/dev/tunX, /dev/tapX) vor und bilden das Bindeglied zu OpenVPN. Wenn vom System etwas in eine von OpenVPN verwendete TUN/TAP-Schnittstellen geschoben wird, landet es nicht auf einer Leitung, sondern über den TUN/TAP-Treiber bei OpenVPN. Das wiederum nimmt die erhaltenen Daten und schickt sie über eine SSL-verschlüsselte Verbindung zur Gegenstelle. Dort wird das Prozedere umgekehrt.

OpenVPN liest die erhaltenen Daten aus der SSL-Verbindung, gibt sie an den TUN/TAP-Treiber weiter, der sie über die vorgegaukelten Netzwerk-Schnittstellen ins System einspeist. Für das System sind demnach OpenVPN und die Verschlüsselung vollkommen transparent, die Pakete/Frames werden über /dev/tunX oder /dev/tapX genau so gesendet / empfangen, wie es über ein reguläres Interface der Fall wäre.

Genau das macht den Reiz von OpenVPN aus: Insofern eine Plattform über TUN/TAP-Treiber verfügt, ist das schon die halbe Miete zur Portierung von OpenVPN. Eine tiefes Einklinken in den TCP/IP-Stack ist nicht notwendig.

Treiber, Gerätedateien, Major-/Minor-Nummern

Zurück zu OpenVPN unter Linux. Damit die Kommunikation zwischen OpenVPN und dem TUN/TAP-Treiber von statten gehen kann, müssen ein paar Voraussetzungen erfüllt sein.

Der TUN/TAP-Treiber muss geladen sein (modprobe tun).
Der TUN/TAP-Treiber muss über eine Gerätedatei ansprechbar sein.

Punkt 2 lohnt einer genaueren Betrachtung. Traditionell identifiziert sich jeder Treiber gegenüber dem Kernel über eine eindeutige Major-Nummer. Die gibt der Treiber beim Laden entweder fest vor oder bekommt sie vom Kernel dynamisch zugewiesen. Weiterhin gibts eine Minor-Nummer, die innerhalb eines Treibers zur Unterscheidung verschiedener Geräte oder Subsysteme dient.

Eine Übersicht der vergebenen Nummern-Kombination findet sich in den Kernel-Sourcen des Systemes unter Documentation/devices.txt und hier oder hier. Offizielle Vergabestelle ist die Linux Assigned Names And Numbers Authority (LANANA). Wie dort zu lesen ist, hat der TAP/TUN-Treiber die Major-Nummer 10 und die Minor-Nummer 200.

Sind Major- und Minor-Nummer bekannt, kann eine entsprechende Gerätedatei angelegt werden, die für Userspace-Programme zur Kommunikation mit dem Treiber bzw. dem vom Treiber betriebenen Gerät dient. Klassischerweise mit mknod per Hand oder aber in Zeiten von udev und sysfs halbautomatisch.

Am Rande: Das Konzept der Nummernvergabe ist mittlerweile etwas aufgeweicht. Der Kernel ist in der Lage, mehrere Treiber mit der selben Major-Nummer zu verwalten, die Unterscheidung findet dann über die Minor-Nummer statt. Weiterhin sind Treiber-Entwickler angehalten, keine festen Major-Nummern mehr anzufragen, sondern mit dynamischen Major und Minor Nummern zu arbeiten. Linux Device Drivers Kapitel 3 "Char Drivers" hält mehr Details bereit.

So, und was war nun kaputt?

Tue Aug 12 14:49:42 2008 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

OpenVPN findet also /dev/net/tun zur Kommunikation mit dem TUN/TAP-Treiber nicht. Der Pfad lässt sich prinzipiell anpassen (Option --dev-node), wichtig ist jedoch, dass es die Datei mit dem passenden Major-/Minor-Nummernpaar überhaupt gibt und genau das war auf dem System nicht der Fall. Ein mknod schaffte Abhilfe.

# mkdir /dev/net
# mknod /dev/net/tun c 10 200
# ls -l /dev/net/tun
crw-r--r--  1 root root 10, 200 2008-08-12 15:24 /dev/net/tun

Das Ganze fand wohlgemerkt auf einem System ohne udev statt. Mit udev kommen Gerätedateien auf andere Art und Weise zustande.

LPIC-Vorbereitung

2008-08-12T12:38:00.001+02:00

Zur Vorbereitung auf die LPIC-Prüfungen gibts Webseiten wie Sand am Meer und noch mehr. Man könnte meinen, das Not Invented Here Syndrom hat zugeschlagen.

Aktuell?

Was man bei allen Seiten im Kopf behalten sollte, ist die Aktualität. Denn Anfang 2006 hat das LPI die Lernziele fürs LPIC-Programm umgekrempelt, viele (alle?) der Vorbereitungsseiten sind aber noch auf dem Stand von vor dieser Zeit.

Das heißt nicht, dass man völlig am Ziel vorbeilernt, aber Vorsicht ist angesagt. Man lernt so z.B. nichts über OpenVPN, was mittlerweile Bestandteil der 202 Prüfung ist. Oder aber man taucht wie bei Wikibooks in die (Un-)Tiefen von gettys und iptables ein, ohne vom Rest der relevanten Lernziele im Umfeld Netzwerkkonfiguration etwas mitzubekommen. Man schaue nur mal hier ... auweia.

Im Falle meiner Vorbereitung für LPIC-2 liegt hier also die gedruckte Version der aktuellen Lernziele, anhand der ich mir schrittweise das Wissen zusammensuche, was mir noch fehlt.

Papierform

Das Vorbereitungswissen gibts auch in Buch-Form und ich gehe davon aus, dass man damit besser durch die Vorbereitung geführt wird, als auf den obigen Webseiten.

Ergo hab ich mir das gerade in der aktuellen Auflage von 2008 auf ebay für ca. 30 Euro geordert. Danach wirds wieder verkauft und ich hab ein gutes Gewissen, wenn ich dann zum Test die 130+ Euro Prüfungsgebühr in die Hand nehme.

Weiblich, Männlich, Linux, BSD ...

2008-08-07T14:36:00.001+02:00

Bei Stellenangeboten ist ja immer der ein oder andere Schmunzler dabei. So gerade gesehen auf der Job-Seite eines Europa-weit aktiven Webportals.

Wenn bei der ersten Stelle weibliche und männliche Bewerber gesucht sind, was wollen die dann für die zweite Stelle? *schmunzel*

Terminals unter Linux: tty, pty, pts und Co

2008-08-04T22:44:00.004+02:00

Im Zuge der Aufbereitung des Themas PPP ist mir vor Augen geführt worden, dass die serielle Schnittstelle unter Linux omnipräsent ist. Egal ob man tatsächlich eine RS232-Schnittstelle an seinem System hat, oder nicht, ttys, ptys & Kollegen tummeln sich an allen Ecken und Enden.

Schonmal ein /dev/pts/X gesehen und überlegt, woher das kommt? Oder nicht so richtig gewusst, wo ein Pseudo-Terminal einzuordnen ist? Mit etwas historischem Hintergrundwissen lässt sich das in Null-Komma-Nix erklären. Los gehts.

Es war einmal: Teletype

Es waren einmal Großrechner die als großer Klotz raumfüllend vor sich hin summten und jede Menge Leute mit Datenverarbeitungsdiensten versorgten. Ok, ihr kennt die Story, ich fass mich kurz. Der Krux dabei: Es gab keinen Monitor und keine Tastatur, wie wir sie heute kennen.

Dafür gab es ein sogenanntes Teletype (kurz TTY), eine Kombination aus Tastatur und Drucker, die mit dem Großrechner verbunden und zur Interaktion genutzt wurde. Eingaben auf der Tastatur wurden zeichenweise an den Rechner geschickt und dieser lieferte Zeichen zurück, die auf dem Drucker ausgegeben wurden.

Neben tatsächlich zu druckenden Zeichen gabs spezielle Zeichen, die zur Steuerung des Druckers verwendet wurden (Steuer- oder Kontrollzeichen genannt). CR und LF sind ein Beispiel dafür. Einmal Druckkopf auf den Anfang der Zeile zurücksetzen (CR) und Papier eine Zeile weiter schieben (LF) ... alles klar.

Terminals

Das Rad der Zeit drehte sich und die Teletypes wurden weiterentwickelt. Der Drucker als Ausgabemedium wurde durch ein Display ersetzt und somit waren die sogenannten Terminals geboren. Das Funktionsprinzip blieb gleich, Zeichen hin, Ausgabe zurück, nur ab sofort auf einem grün schimmerenden Display und nicht mehr auf Papier.

Betriebssysteme und Programme mit Benutzerinteraktion verinnerlichten diesen Modus Operandi. Aus ihrer Sicht kommunizierten sie über eine zeichenorientierte Schnittstelle, aus der sie aufeinanderfolgende Eingaben vom Terminal lesen konnten und umgekehrt Ausgaben aufs Terminal zurück senden konnten.

Fast forward zu Linux. Selbst wenn wir heute nicht mehr mit grün leuchtenden Terminals arbeiten, hat sich am architektonischen Ansatz nichts geändert. Direkt am Rechner sitzend, werkeln wir nun mit virtuellen Terminals oder xterm(inals) und ebenso wie ihre greifbaren Vorgänger nehmen diese Eingaben von uns entgegen, speisen sie in zeichenorientierte Schnittstellen und stellen über die gleiche Schnittstelle empfangene Ausgaben dar. Die Schnittstellen sind lediglich nicht mehr physikalisch greifbar, sondern systemintern.

Am anderen Ende einer solchen Schnittstelle hängen übrigens Programme, die wir von der täglichen Arbeit auf Text-Basis kennen: Shells, Editoren und vieles mehr.

Gerätedateien

Wir haben also die beteiligten Gegenstellen ausgemacht, fehlt noch die tatsächliche Schnittstelle (in Form einer Gerätedatei), über die kommuniziert wird. Gehen wir davon aus, wir würden tatsächlich ein altes Terminal an die erste RS-232 Schnittstelle eines Linux-Systems anschließen. In diesem Fall ist das Terminal über /dev/ttyS0 ansprechbar. Ein

echo a > /dev/ttyS0

schickt ein a ans Terminal. Am Terminal eingegebene Zeichen kommen auch bei /dev/ttyS0 an und können mittels

cat /dev/ttyS0

anzeigt werden. Simpel! Natürlich würde ein Terminal nicht für solche simplen Spielereien verwendet werden, sondern dazu, um sich darüber auf dem Linux-System einzuloggen und daran zu arbeiten. Hier gehts aber erstmal nur ums grundlegende Verständnis für die Schnittstellen.

Man beachte übrigens die historisch bedingte Namensgebung. Das tty im Dateinamen rührt aus den Zeiten, als es noch tatsächlich Teletypes (TTY) gab und diese über serielle Schnittstellen angeschlossen wurden.

Gehen wir einen Schritt weiter: Virtuelle Terminals unter Linux - das sind die, die man über ALT + F1, ALT + F2, ..., ALT + FX (X abhängig von der genauen Konfiguration) aufrufen kann. Aus Programmsicht sind diese Terminals über die Gerätedateien /dev/tty1 ... /dev/ttyX ansprechbar und obwohl dahinter keine richtigen Terminals mehr stehen, sondern der Kernel-Terminal-Treiber, ist das den auf dem System arbeitenden Programmen total egal. Für die ist lediglich wichtig, dass aus ihrer Sicht die Schnittstelle /dev/ttyX genauso funktioniert, wie sie es von z.B. /dev/ttyS0 gewohnt sind. Zeichen rein, Zeichen raus.

Dass man dieses Konzept weiterspinnen kann, zeigt openssh. Für jede SSH-Verbindungen wird ein sogenanntes Pseudo-Terminal angelegt, was über /dev/pts/X ansteuerbar ist. /dev/pts/X verhält sich für Programme wie eine konventionelle, zeichenbasierte Schnittstelle, während openssh hinter der Schnittstelle lauscht und Umsetzer auf die SSH-Verbindung spielt.

Realisiert ist das ganze über gekoppelten Gerätedateien, bestehend aus Slave und Master. Die Gerätedatei /dev/pts/X stellt den Slave eines solchen Pärchens dar und wird von normalen Programmen gefüttert. Der Master, an dem openssh hängt, ist /dev/ptmx. Das gleiche Konzept kann einem mit anderen Gerätedateinamen über den Weg laufen, dann beginnt der Name des Slaves mit /dev/tty[p-z] an und der des Masters mit /dev/pty[p-z].

Diese Funktionsweise nutzen übrigens auch Programme wie screen und xterm. screen vermittelt zwischen einem (virtuellen) Terminal und mehreren Sitzungen/Shells, die alle ihr eigenes Pseudo-Terminal bekommen. Ein xterm fungiert als Bindeglied zwischen der grafischen X11-Umgebung und einer Shell, die nach bekanntem Muster an ein Pseudo-Terminal angedockt wird.

Ansichtsweise

Aus Sicht der Anwendungen stellen sich die verschiedenen Terminals also (fast) gleich dar. Lediglich die Terminal-Gerätedatei ist jeweils eine andere.

/dev/ttySX für via RS-232 angeschlossene Terminals
/dev/ttyX für virtuelle Terminals
/dev/pts/X für SSH-Verbindungen

Daher rühren dann auch die unterschiedliche Angaben zum Terminal einer Benutzersitzung, wie man sie von tty, w oder aber von Log-Einträgen kennt.

Der Vollständigkeit halber sollte noch erwähnt sein, dass die Anzeigefähigkeiten verschiedener Terminals variieren. Manche können Farben und blinkende Zeichen darstellen, nicht-scrollende Statusleisten einblenden, verschiedene Zeichensätze oder Terminalbreiten unterstützen sowie vieles Lustiges mehr. All diese Fähigkeiten werden über Escape-Sequenzen gesteuert, die vom System ans Terminal geschickt werden. Damit das System weiß, welche Fähigkeiten ein Terminal unterstützt (und mit welchen Escape-Sequenzen es umgehen kann) gibts sowas wie termcap bzw. terminfo und eine gesetzte $TERM Umgebungsvariable die angibt, welche Art von Terminal gerade zum Einsatz kommt. Hier sind die Begriffe VT100 & Co einzuordnen.

Mehr zur Historie von TTYs und vielen von dem, was hier angesprochen wurde, bietet ONLamp unter TTYs and X Window: Unix Now and Then.

Weitere URLs

Text-Terminal-HOWTO: Terminal Special Files such as /dev/tty http://tldp.org/HOWTO/Text-Terminal-HOWTO-7.html

Maus ade: Firefox - Teil 2

2008-07-31T22:30:00.004+02:00

Erst verkünde ich noch großlaut, dass mir vimperator zu viel Umgewöhnung sei und kurze Zeit später bin ich in dessen Bann gefangen.

Denn mit vimperator kann ich in ohne zur Maus zu greifen, Links öffnen und Formularfelder ansteuern (und zwar ruck-zuck) - ähnlich wie Mouseless Browsing oder Hit-a-Hint. Darüberhinaus können Suchmaschinen gefüttert und Bookmarks verwaltet werden. Oder wie wärs mit Textauswahl zum Copy & Paste ohne Maus? Geht alles ratz-fatz von der Hand und spart Zeit, da der Griff zur Maus entfällt.

Es funktioniert ohne Macken und ist voll kompatibel mit FF3. Damit hat es Mouseless Browsing (muckt) und Hit-a-Hint (derzeit nicht FF3-kompatibel) also was Vorraus.

Zugegeben gibts eine Eingewöhnungsphase, aber alleine die Funktionsweise zum Links Öffnen, der sogenannte Hints-Modus, macht die Eingewöhnung m.E. vollkommen wett. Ich vermisse so eine effiziente Art der Tastatur-only-Bedienung jetzt schon bei anderen Anwendungen (und nein, ALT + Menükürzel + Menüitemkürzel find ich nicht effizient).

Der Hints-Modus

Hier erstmal ein Screenshot, damit rüberkommt, wie das Ganze denn so aussieht:

All die kleinen, roten Zahlenboxen und die gelbe Hinterleung werden von vimperator auf Anfrage (Taste f) eingeblendet (stören also nicht dauerhaft die Optik). Will ich nun einen gekennzeichneten Link öffnen, gibt es zwei Wege: 1) Die Nummer aus der roten Box eingeben. 2) Einen Suchtext eingeben. Sobald dieser Text für einen der Links eindeutig ist, wird der geöffnet. Im obigen Beispiel könnte man also für den Google-Artikel entweder "privatsphäre" oder aber die Nummer 83 eingeben.

Beides Mal wird der Link im aktuellen Tab geöffnet. will man den Link in einem neuen Tab öffnen, verwendet man zum Aktivieren des Hints-Modus anstatt dem f ein Shift + f.

Kickstart

Um die Eingewöhnungsphase etwas kürzer zu gestalten, hier ein paar essentielle Tastenkürzel / Kommandos.

f, F	Hints-Modus zum Öffnen von Links aktivieren (siehe oben)
gi	Fokus auf erstes Eingabe-Feld setzen
o URL	URL öffnen, lässt sich mit TAB anhand der History autovervollständigen. Anstatt einer tatsächlichen URL kann auch ein Suchbegriff eingegeben werden, der dann auf google.com gesucht wird.
t URL	Funktioniert wie o, öffnet die URL aber in einem neuen Fenster
:help	Die Hilfe aufrufen
y	Die URL der aktuellen Seite kopieren

Darüberhinaus tut es gut, dass Bookmark-Handling zu verstehen. Ein Bookmark für die aktuelle Seite wird mit :bmark angelegt und mit :bmarks! suchbegriff kann man die Bookmarks zum Öffnen durchsuchen. TAB springt von einem Suchergebnis zum nächsten, einmal Eingabetaste und der Link wird im aktuellen Tab geöffnet.

Für die Online-Bookmark-Haltung der Wahl, delicious, hält das vimperator-Wiki eine Anleitung bereit, die Front ist also auch abgedeckt.

Editor für Input-Felder

Zu guter letzt gibts noch die Sahnehaube oben drauf: vimperator ermöglicht es, Text-Feldern auf Webseiten mit einen externen Editor, z.B. VIM zu bearbeiten. Auf meinem Windows-System setze ich dazu den Pfad zu meiner VIM-Installation mittels :set editor c:\programme\vim\vim70\gvim.exe und sobald ich im Browser in einem Textfeld arbeite, katapultiert mich ein STRG + i in eine VIM-Sitzung, in welcher der Text fürs Textfeld zum Editieren bereit steht.

Hilfe, die Leisten fehlen!

vimperator schaltet per Default die Adress- und Toolbar-Leiste aus. Wem das zu irritierend ist oder wer Addons verwendet die dort beheimatet sind, der zaubert die Leisten mit :setguioptions+=mT wieder hervor. Dann finden sich auch Besucher oder die Freundin noch mit dem nun ziemlich gepimpten Browser zurecht.

Maus ade: Firefox

2008-07-31T19:04:00.001+02:00

Hab die letzten paar Tage direkt an meinem Notebook gearbeitet ... keine gute Idee. Unergonomische Sitzhaltung vorprogrammiert. Grüße von meinem steifen Hals.

Ergo habe ich eben die lang nicht benutzte Docking-Station hervorgekramt, auf den Schreibtisch gestellt und das Notebook eingedockt. Eine Tastatur war schnell gefunden, eine Maus leider nicht. Ich fand mich also öfter zum Touchpad langen als mir lieb war und in Zeiten Shortcut-schwangerer Programme sollte das doch nicht nötig sein, oder?!

Nehmen wir Firefox: STRG + L bringt mich in die Adressleiste, STRG + K in die Suchleiste. Die Shortcuts zur Tab-Steuerung gehen vollautomatisch von der Hand und Pfeil oben / unten lassen mich über die Seiten huschen. Aber wie "klicke" ich auf Links? Oder springe in Formularfelder?!

Link-Klickerei via Keyboard

Lifehacker hält mit "Hack Attack: Mouse-less Firefox" - neben einer feinen Auswahl anderer Shortcuts - die Antwort auf die erste Frage bereit: Mit ' lässt sich in einen speziellen Suchmodus springen, der nur Links durchsucht. Ist der gesuchte Link gefunden, wird er via STRG + ENTER in einem neuen Tab geöffnet. Von einem Suchtreffer zum nächsten gehts mit STRG + G. Very nice!

Was ich auch noch nicht kannte war / für den normalen Suchmodus. VIM-Jünger müssen also nicht zwangsläufig zu STRG + F oder zum vimperator greifen.

Die Suchfeatures nennen sich offiziell übrigens "Begin finding when you begin typing".

Formularfelder

Problem 1 gelöst, kommen wir zu Frage 2: Wie springe ich zu Formularfeldern?

Die Kommentare aus obigem Lifehacker-Artikel erwähnen diesbzgl. Hit a Hint, Mouseless Browsing und natürlich auch den vimperator. Uihh, die Qual der Wahl. Allen gemein: Man muss eine Extension installieren und hat verinnerlichte Bedienweisen damit nur auf den Systemen zur Verfügung, auf denen die Extension auch tatsächlich installiert ist.

Bei einfach gehaltenen Seiten, die ein Label vor jedem Formularfeld haben, gehts ohne Extension: Mittels / Labelname suchen, TAB drücken, fertig. Für alles andere muss dann doch eine Extension her.

Hit-a-Hint ist leider noch nicht mit FF3 kompatibel und damit erstmal außen vor. Nutzer beklagen zwar die spärliche Doku, sind aber sonst begeistert.
Mouseless Browsing blendet zu Links (Text & Bild), Formularen und Frames eindeutige IDs ein, die dann via Keypad oder Tastenkombination geöffnet werden können. Hatte ich vor ewigen Zeiten schonmal drauf und habs mir jetzt wieder installiert.

Konfigurationsdialog per STRG + Shift + ALT + M geöffnet und ein paar Settings angepasst. Lasse mir die IDs nun nur bei Bedarf anzeigen (Tastenkombination STRG + ^ zum Aktivieren) und habe den Modifier für das Öffnen in einem neuen Tab auf STRG + ALT gesetzt, um mit ALT + ID ganz normal im aktuellen Tab zu bleiben und dabei die rechte Hand nicht übers Keypad bewegen zu müssen (was ich aufm Notebook eh nicht hab).

Seltsamerweise funktionieren die angezeigten IDs nicht mehr, wenn man einen Tab einmal wechselt und wieder zurückkommt. Weiterhin zerreists bei Seiten wie amazon.de das Layout, sobald die IDs eingeblendet werden.
vimperator überschreibt nahezu alle Firefox-Tastenkombination, blendet die Menü- sowie Toolbar aus und ist mir damit einfach zu krass. Ich will meinen Browser effizienter nutzen und nicht Stunden ins Umgewöhnen versenken.

Da greife ich dann doch lieber ein paar mal zum Touchpad. Immerhin ists dank ' schon deutlich weniger geworden.

Angestaubt oder aktuell?

2008-07-29T16:10:00.001+02:00

Beim Arbeiten am PPP-Artikel hatte ich ambivalente Gefühle. Zum einen macht es absolut Spaß, wenn bei einer Thematik endlich mal der Groschen fällt. Andererseits muss man sich fragen, ob man das Gelernte zukünftig überhaupt brauchen kann.

Bei PPP an sich bin ich mir da, abseits von der Notwendigkeit für die LPIC-2-Prüfung, nicht sicher. Time will show. Dafür haben sich beim Lernen zwei wertvolle, PPP-unabhängige Erkenntnisse ergeben:

Erkenntnis 1: ttys überall

Die serielle Schnittstelle ist in Linux omnipräsent - egal ob tatsächlich was an seriellen RS-232-Ports angeschlossen ist oder nicht. Das ist historisch bedingt und wenn man diese Historie versteht, wird einem schnell klar, wie vieles tickt und wo Begriffe wie tty, pty, pts & Co einzuordnen sind.

Schonmal von einem Pseudo-Terminal gehört und nie so richtig verstanden, was das ist. Willkommen im Club, aber das ist jetzt anders. Ich schiebe dazu noch einen Artikel hinterher.

Erkenntnis 2: PPP, LCP, NCP. Was bitte?!

PPP hatte sich mir früher nie erschlossen. Spätestens beim Studieren von LCP/NCP-Nachrichtendefinitionen und einer ellenlangen pppd manpage war Schluss. Wer soll das alles verstehen? Ähnlich ging es mir übrigens auch bei einigen anderen Protokollen. In Frame-Format-Definitionen und Erklärung von diversen Feldern unterzugehen, ist ein Leichtes.

Diesmal war die Herangehensweise eine ganz andere und siehe da, der Groschen ist gefallen: Anstatt direkt in die Protokoll-Erklärung einzusteigen, kam ich über historisch gewachsene Anforderungen (serielle Leitungen, SLIP, PPP) ans Protokoll. Also genauso, wie die Designer des Protokolls und siehe da ... es hat prompt Klick gemacht.

Hört sich erstmal komisch an, denn eigentlich fängt man doch immer mit: "Was leistet das Protokoll?" an und da geht es doch auch um Anforderungen. Aber habt ihr schonmal hinterfragt, was man da in aller Regel so liest und wie man selbst darauf reagiert?

Zumindest mir ist da was Interessantes aufgefallen. Auch dazu demnächst mehr.

Und nun?

Der aktuelle Wert von Wissen über PPP sei mal dahingestellt. Bringt Netzwerk-Technikern im Tagesgeschäft sicherlich mehr, als Sysadmins. Dafür gibts zwei Erkenntnisse, die sich im Kern ums Gleiche drehen: Aktuelle Technologien haben Wurzeln und diese Wurzeln zu verstehen, zahlt sich aus.

Nicht umsonst fangen Vorlesungen zur Prozessortechnik oft mit dem 8086 an, bevor sie sich aufs Detail aktueller Prozessoren stürzen. Erstmal die Grundlagen schaffen und diese dann ausbauen.

Zugegeben: So manchen, in Sackgassen geendeten Technologien kann man sicherlich gnadenlos den Stempel "angestaubt" aufdrücken und kann diesbezügliches Wissen reuefrei aus seinem Gedächtnis streichen bzw. erst gar nicht aufbauen. Abgesehen davon bin ich mit der Kategorisierung "angestaubt oder aktuell?" ab sofort vorsichtiger.

ifconfig versus ip

2008-07-27T23:37:00.007+02:00

Weiter gehts in der Vorbereitung für LPIC-2 und schon wieder läuft einem etwas über den Weg, um das man bisher erfolgreich einen Bogen gemacht hat: /bin/ip

Warum sollte man das überhaupt verwenden, wenn es doch mit /sbin/ifconfig und /sbin/route alte Bekannte gibt? Hört man auf die Jungs vom Linux Advanced Routing & Traffic Control HOWTO, dann deswegen, weil das Netzwerksubsystem mit Kernel 2.2 komplett überholt wurde und ifconfig/route dessen volle Funktionalität nicht ausreizen kann.

Ausgefeilte Setups wie Source-basiertes Routing oder Traffic-Shaping fallen unter den Tisch ... für Otto-Normal-Verbraucher eher uninteressant.

Also bleiben wir bei simplen Dingen: Schonmal versucht IP-Adressen in CIDR-Notation mit ifconfig/route zu verwenden? Während CIDR mit route einwandfrei funktioniert

# route add -net 10.0.0.0/16 dev pppX

  findet ifconfig daran keinen Gefallen. Lässt sich sowohl auf einer Debian sarge Installation mit net-tools 1.60-10 als auch auf einem etch mit net-tools 1.60-17 nachvollziehen.
  # ifconfig eth0:1 192.168.10.100/24
SIOCSIFNETMASK: Cannot assign requested address        
# ifconfig eth0:1 192.168.10.100 netmask 255.255.255.0
  Mit ip überhaupt kein Problem. Ein Tool, ein einheitliches Verständnis für Notationen.
  # ip route add 10.0.0.0/16 dev pppX        
# ip addr add 192.168.10.100/24 dev eth0
  Weiter im Programm. Ich will nicht den Eindruck erwecken, zum ip-Jünger verkommen zu sein, aber schaut euch einfach mal die Ausgabe der Routing-Tabelle von route an ...
  # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.110.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.110.2   0.0.0.0         UG    0      0        0 eth0
  Fällt euch was auf? Mir bisher nie. Warum zum Geier kommt die Netzmaske erst nach dem Gateway? Es interessiert doch erstmal der komplette Zieladressenbereich (d.h. Adresse UND Netzmaske) ... nicht erst die eingeschobene Gateway-Adresse. Seltsam.
  Die Ausgabe von "ip route list" ist - da wohl unbekannt - erstmal ungewohnt, aber in jeder Hinsicht logischer zu lesen.
  # ip route list
192.168.110.0/24 dev eth0  proto kernel  scope link  src 192.168.110.130
default via 192.168.110.2 dev eth0
  Runden wir die Vorstellung mit einem Unterschied ab, der sicherlich als Geschmackssache abgeheftet werden kann, der aber das sehr aufgeräumtes Bedienkonzept von ip zeigt.
  ip trennt die Konfiguration / Darstellung von Layer 2 und Layer 3 Parametern. Kommandos die mit "ip link" anfangen kümmern sich um Layer 2, "ip addr" hingegen um Layer 3. Bei ifconfig wird das nicht so differenziert verwendet, ein ifconfig erschlägt einen hingegen regelrecht mit Layer-übergreifenden Informationen, so dass nicht selten etwas wie
  # ifconfig | egrep "^[^ ]|inet addr"
herhalten muss, um die Informationsflut zu reduzieren. Ein "ip addr list" sieht anders aus. Probierts mal.



Point-to-Point-Protokoll / LPIC-202 2.205.1
2008-07-26T15:12:00.004+02:00
Schonmal mit PPP(oE) hantiert ohne HOWTOs und schnelles Copy & Paste zu Hilfe zu ziehen? Ich nicht, aber das sollte sich dank LPIC-202-Lernziel 2.205.1 "Basic Network Configuration" ändern. Auszug:
     Use and configuration of modems, ISDN interface cards and ethernet interfaces as dialup devices. 
    Authentication protocols such as PAP and CHAP. 
 
  Modems? ISDN interface cards? Dialup? Auweia! Über dem Ganzen schwebt implizit PPP(oE) und es hört sich erst mal leicht abschreckend an, denn wer hantiert heute noch groß mit Modems oder ISDN-Karten zu Einwahlzwecken? 
  Was jedoch nicht gleich ersichtlich ist, ist die Tatsache, dass es im Kern um ein Thema geht, welches auch deutlich abseits von Modems/ISDN-Karten von Relevanz ist: Zwei Systeme / Rechner tauschen über eine direkte Verbindung (Punkt-zu-Punkt-Verbindung) Daten aus und das ist garnicht mal so einfach, wie es sich anhört. 
  Warum eigentlich? Warum brauche ich etwas anscheinend super-komplexes (man schaue sich nur mal ein Konfigurations-Howto zu pppd & Co an), um über eine Verbindung zu kommunizieren, die doch sowieso ein Punkt-zu-Punkt-Verbindung ist - ist da die Verbindung nicht schon so gut wie automatisch da?! Können Daten nicht einfach über die Leitung geschoben werden, weil auf der anderen Seite lediglich ein Ansprechpartner steht? 
  Anfängliche Verwirrung wie bei diesem Leidensgenossen ist da fast vorprogrammiert. 
    Begriffsklärung 
    Klären wir eingangs ein paar Begriffe. Unter einer Punkt-zu-Punkt-Verbindung versteht man eine direkte Verbindung zwischen zwei Systemenen. Sobald ein System über eine solche Verbindung also was von sich gibt, landet es beim gegenüberliegenden System. 
    Eine Punkt-zu-Punkt-Verbindung kann so etwas einfaches wie eine direkte serielle Verbindung sein, oder eine über ISDN hergestellte ISDN-Verbindung zwischen zwei Systemen. 
    Wenn eine Punkt-zu-Punkt-Verbindung vorliegt, dann hat das nicht automatisch was mit dem Point-to-Point-Protokoll (PPP) zu tun. Das kann eingesetzt werden, um diverse Funktionen zu ermöglichen, die im Weiteren erläutert werden, muss aber nicht. Einleuchtend?! 
    Zeichenorientierte Verbindungen 
    Kehren wir zurück zu den Herausforderungen beim Übertragen von Daten über Punkt-zu-Punkt-Verbindungen und fangen simpel an. Bei zeichenorientierten Verbindungen wie z.B. einer einfachen seriellen Verbindung zu aktiven Komponenten oder Computersystemen geht es darum, Zeichen für Zeichen zu übertragen (Tastenanschläge hin bzw. Konsolenausgaben zurück). 
    Dazu reicht das "Verständnis" der seriellen Hardware. Sie weiß, ein Zeichen (wir gehen von 8 Bit, d.h. 1 Byte pro Zeichen aus) beim Sender so einzupacken, dass dieses beim Empfänger als solches erkannt wird - stimmige Konfiguration (Baudraute sowie 8N1 o.ä.) auf beiden Seiten vorausgesetzt. Ein auf einer Seite ein-/ausgegebenes Zeichen kommt also als solches auf der anderen Seite an. 
    Für Netzwerkprotokolle verwendete Verbindungen 
    Wenn man sich jedoch via Modem-/ISDN beim Provider einwählt und dann IP Pakete über die so hergestellte Verbindung jagen will, dann ändern sich die Anforderungen. Anstatt einem Zeichen als Einheit/Nutzdaten soll nun ein IP Paket übertragen werden und das gestaltet sich schon schwieriger, denn ein IP Paket hat im Gegensatz zu einem Zeichen keine fest definierte Länge. 
    Würde das IP Paket lediglich Byte für Byte (Funktionsweise wie bei den zeichenorientierten Verbindungen) übertragen werden, kann der Empfänger nicht wissen, wann Ende der Übertragungseinheit IP Paket ist, wann also ein komplettes IP Paket empfangen wurde und weiterverarbeitet werden kann. 
    Der Empfänger könnte sich zwar mit der Längenangabe im IP Header weiterhelfen, deren Position relativ zum Beginn eines IP-Pakets bekannt ist. Wehe aber, es treten Übertragungsfehler auf und die Längenangabe wird verfälscht übertragen. Ein Empfänger der nicht mehr weiß, bis wohin ein IP Paket geht und wann das nächste anfängt, ist vorprogrammiert. 
    Framing / Einkapseln 
    Was also her muss, ist eine eindeutige Signalisierung für den Start und das Ende von übertragenen Nutzdaten, ein sog. Framing. Dabei werden die Nutzdaten zum Versenden mit Zusatzinformationen versehen, die es dem Empfänger ermöglichen, vollständige Übertragungseinheiten (z.B. ein IP Paket) im Datenstrom zu identifizieren und zu verarbeiten. 
    Das in einer solchen Weise über eine Verbindung übertragene Gesamtkonstrukt (Nutzdaten + Zusatzinfos) wird Frame genannt. 
    Ethernet - was OSI-technisch auf der gleichen Ebene wie PPP spielt - geht das ganze pragmatisch an. Ein Frame wird durch eine spezielle Sequenz eingeleitet, d.h. der Empfänger weiß, wann eine Übertragung beginnt. Weiterhin ist vorgeschrieben, dass zwischen zwei Übertragungen eine Pause von mindestens 9,6ms liegen muss (der sog. Interframe Gap). Sobald also kein Signal mehr anliegt, ist Frame-Ende angesagt. 
    Dass ein Ethernet Frame den Nutzdaten noch weitere Informationen zur Seite stellt (MAC-Adressen, etc.) und somit weitere Funktionen ermöglicht sollte klar sein und hier nicht für Verwirrung sorgen. Erstmal gehts nur um die Möglichkeit, ganze Übertragungseinheiten (IP Pakete oder Pakete anderer Netzwerkprotokolle) für den Empfänger eindeutig zu kennzeichnen. 
    Serial Line IP 
    Kommen wir wieder zur Punkt-zu-Punkt Verbindungen, bei der auch PPP angesiedelt ist. Serial Line IP (SLIP), der Vorläufer von PPP, adressiert genau die eben beschriebene Aufgabenstellung - Nutzdateneinheiten bei der Übertragung über eine Punkt-zu-Punkt-Verbindung als solche kenntlich zu machen. 
    SLIP schiebt die Nutzdaten (ein IP Paket) über die Leitung und schickt einen spezielles Byte zum Signalisieren des Endes hinterher - ähnlich dem "Over" beim Funken. Der Empfänger weiß also, dass ein komplettes IP Paket übertragen wurde und kann dieses weiterverarbeiten. 
    SLIP arbeitet demnach als Schicht unter IP, auf Ebene 2 des OSI-Modells. Wenn ein IP Paket über eine von SLIP verwaltete Punkt-zu-Punkt-Verbindung geschickt werden soll, sorgt die SLIP-Implementierung im Netzwerkstack für das oben beschriebene Verhalten: IP Paket über die Leitung jagen und das END-Byte hinterherschicken. 
    Auf der anderen Seite gilt der umgekehrte Weg: Die SLIP-Implementierung liest die eingehenden Daten, erkennt die vollendete Übertragung des IP Pakets anhand des Stop-Bytes und reicht die gelesenen Daten ans IP-Subsystem im Netzwerkstack zur Verarbeitung weiter. 
    Sehr simpel, aber zur Zeit der Einführung eine riesige Neuerung. Über eine Einwählverbindungen konnte man sich bis dato lediglich zeichenorientiert auf dem System am anderen Ende der Punkt-zu-Punkt-Verbindung einloggen. Mit SLIP war plötzlich die direkte IP-technische Anbindung ans Internet möglich. 
    Als improvisierte Lösung ins Leben gerufen, hatte SLIP jedoch einige Defizite, was auch den Urhebern klar war. SLIP ist unmissverständlich als NONSTANDARD gekennzeichnet und der RFC enthält einige Verbesserungsvorschläge. 
    Übertragungsfehler und Gegenmaßnahmen 
    So gibt es z.B. keine einleitende Signalisierung für die Übertragung eines IP-Pakets. Wenn vor dem Beginn eines Pakets Störsignale auf der Leitung liegen, werden diese als Bestandteil des IP Pakets interpretiert. 
    Darüberhinaus schützt SLIP nicht vor Übertragungsfehlern, da keine Prüfung der Nutzdaten nach erfolgter Übertragung stattfindet. Bei Ethernet kennt man sowas als CRC-basierte Frame-Check-Sequence (FCS): Auf Basis der im Frame enthaltenen Daten wird eine Prüfsumme berechnet, die als Bestandteil des Frames mit übertragen wird und anhand der Fehler bei der Übertragung festgestellt werden können. 
    Protokolle ohne Prüfsumme - wie SLIP - überlassen solche Fehlerprüfung höher gelegenen Protokollen ... was schief gehen kann. Bei TCP ist eine Prüfsumme vorgesehen, bei UDP auch, dort jedoch als optional. Bei SLIP in Kombination mit nicht geprüfsummten UDP gibts also keine Sicherheit, dass Daten ordnungsgemäß übertragen werden. Kommunizierende Anwendungen können sich gegenseitig also unbewusst korrupte Daten füttern, wenn die Leitung störungsbehaftet ist. 
    Point-to-Point-Protokoll 
    Um das rudimentäre SLIP abzulösen, wurde das Point-to-Point-Protokoll (PPP, RFC1331) in die Welt gerufen. Neben dem Framing von IP-Paketen zur Erkennung von Start und Ende, bietet es deutlich mehr Optionen, unter anderem: 
         Framing mehrerer Protokolle, nicht nur IP 
      Aushandeln verbindungsspezifischer Optionen, wie z.B. erforderliche Authentifizierung der Gegenstellen 
      Fehler-Prüfung der übertragenen Daten durch eine mit übertragene Prüfsumme 
   
    Schauen wir uns zuerst das Framing an. PPP kennt ein spezielles Byte, das sog. Flag Byte. Dieses beginnt UND endet einen PPP-Frame. Es ist dem Empfänger also einwandfrei möglich, die übertragene Nutzdateneinheit (im Regelfall IP) aus dem kompletten Datenstrom heraus zu erkennen. 
    Dabei kann PPP nicht nur IP Huckepack nehmen, sondern eine Vielzahl weiterer Protokolle. Jeder übertragene PPP Frame enthält dazu ein Protokoll-Feld, welches der Gegenstelle signalisiert, was denn da genau übertragen wurde. Protokolle werden dabei anhand einer von der IANA festgelegten Nummer identifiziert. Der Empfänger wertet dieses Feld aus und entscheidet darauf, wie die Nutzdaten weiter zu behandeln sind. Ähnliches kennt man vom Ethernet Type Feld. 
    Link Control Protocol / Verbindungsaufbau 
    Dieser Mechanismus wird nicht nur dazu genutzt, IP & Co zu transportieren, sondern auch für PPP eigene Subprotokolle, die zur Abstimmung der kommunizierenden Gegenstellen eingesetzt werden. Daten des PPP-Subprotokolls LCP (Link Control Protocol, Protokollnummer: c021) werden also nicht an den Netzwerkstack zum Weiterversand gereicht, sondern von der PPP-Implementierung des Empfängers ausgewertet. 
    Genau genommen müssen solche LCP Nachrichten ausgetauscht werden, um den Nutzdaten-Austausch zwischen zwei PPP-Implementierungen erst zu ermöglichen. Die Gegenstellen einigen sich dabei zu Beginn einer PPP-Verbindung auf diverse Verbindungsparameter wie die maximal zu übertragende Frame-Größe, optionale Authentifizierung oder Header-Kompression. 
    So werden die genauen Kommunikationsparameter zwischen den beiden PPP-Implementierungen festgesteckt, um in Folge sicher zu gehen, dass sich beide auch verstehen. 
    Microsoft hält im Artikel "PPP Link Negotiation with LCP" Detailwissen zu LCP sowie einen beispielhaften LCP-Dialog bereit. Ebenso beschreiben Wolfgang Barth und Jens Banning in ihrem Buch "Netzwerkanalyse unter Linux" PPP inkl. LCP sehr anschaulich und halten auch einen LCP-Mitschnitt bereit, der noch mehr ins Detail geht, als der von Microsoft. 
    Sicher ist Sicher 
    Bei LCP finden dann auch die eingangs in den LPIC-2 Lernzielen erwähnten Protokolle PAP und CHAP ihr Plätzchen. Will eine der beiden Seiten eine Authentifizierung durchführen, so zeigt sie dies im LCP-Dialog an. Einigen sich beide Seiten auf die zu verwendenden Parameter, geht die Authentifizierung von statten.
    Bei dauerhaft direkt verbundenen Systemen ist das überflüssig, da die Gegenstelle bekannt ist. Bei einem Zugang auf den prinzipiell jeder zugreifen kann (Einwahlnummer von Providern zum Beispiel), kann man PPP-Verbindungen somit auf einen ausgewählten Kreis einschränken.
    Werden über die aufgebaute PPP-Verbindung dann Daten übertragen, schützt PPP durch eine im Frame enthaltene Prüfsumme vor Übertragungsfehlern. Der Empfänger kann mittels dieser Prüfsumme feststellen, ob Daten während der Übertragung verfälscht wurden und kann so einen beschädigten Frame identifizieren und entsorgen. 
    Fazit 
    Letztendlich geht es bei PPP also darum einen verlässlichen Übertragungskanal für Netzwerk-Protokolle (IP, IPX, ...) zwischen zwei direkt verbundenen Systemen zu schaffen. PPP-Implementierungen ermöglichen genau das. Sie übernehmen die Kommunikation über eine Punkt-zu-Punkt-Verbindung und sorgen dafür, dass Pakete sicher am anderen Ende landen und dort als solche erkannt werden. 
    Wie genau das von statten geht, ist dann für Systeme die via IP o.ä. über eine solche Verbindung kommunizieren übrigens irrelevant. Sie nutzen das von der PPP-Implementierung (z.B. pppd unter Linux) bereitgestellte Interface (pppX oder ipppx) wie jedes andere Interface auch. 
   


Worum gehts hier?
2008-07-11T11:01:00.009+02:00
"We live in a sea of data. Our challenge is knowledge and its management."Dieses Blog dient primär als mein externer Gedankenspeicher und ersetzt somit in der Gegend verstreute Notizzettel. Notizzettel auf denen Erlerntes und Ideen stehen, die aber meist irgendwo untergehen und nicht wieder genutzt werden.

Vergeudet also ... und so findet man sich oft in einer Situation wieder in der man denkt: Das hab ich doch schonmal gemacht, wie war das doch gleich?

Ganz im Sinne von Personal Knowledge Management bzw. Persönlichem Wissensmanagement nutze ich dieses Blog also zum Ausformulieren meiner im Kopf schwirrenden Ideen / Erfahrungen.

Das hilft mir dabei, meine Ansichten während des Schreibens zu überdenken, Wissen zu erweitern und wiederauffindbar abzulegen. Wenn es zeitgleich anderen hilft, Fragen zu klären oder Neues kennenzulernen, umso besser.