Captains Log

Also über diesen Beitrag hier muß ich erstmal schlafen. Also vorausgesetzt, daß der nicht gefaket ist. Technisch ist das auf jeden Fall machbar, entsprechende Berichte gibt es jedoch bisher nur aus den USA (SINA-Boxen, verschlossene Nebenräume in Netzwerk- und Technikzentralen...)
 
via Fefe

Gibt es eigentlich sowas wie Internet-Provinzen?
Im wahren Leben kennen wir die alle, die kleinen Dörfer oder Käffer, die man wahrnimmt, wenn man auf dem Weg zu einem x-beliebigen Ziel durch sie hindurch fährt. Ein paar Häuser, die sich an eine Straße schmiegen, dazwischen die lokale Dorfkneipe. Orte, in denen das Leben langsamer läuft, oder in einer gänzlich anderen Zeit zu verharren scheint.
Supermärkte die eher zu groß geratene Tante Emma-Läden sind, und in denen die Freundlichkeit, mit denen einem begegnet wird daran festgemacht wird, wie bekannt das Gesicht ist.
 
Ich glaube, sowas gibt es auch im Netz. Natürlich nicht als Ort. In Zeiten von breitbandigen Anschlüssen kann lediglich ein Netzwerker anhand des traceroutes nachschauen, wie "weit" es zwischen zwei Computern ist - für den Internet-Nutzer macht das keinen Unterschied.
Die Zentren der modernen Computerei, also sprich die Analogie zu den Großstädten, sind Pageranking-Seiten wie technorati, digg und dergleichen. Und die Besucher, die zu hohen Klickzahlen bei den von wem auch immer gekürten A- und B-Bloggern sorgen sind dicke, mehrspurige Autobahnen. Hier, Themen Trends in der Berichterstattung der Bloggosphäre setzen trifft sich der Mainstream, bzw. wird Mainstream gemacht.
Ganz anders geht es da in den Provinzen zu: Hier ist es eher Zufall, wenn über ein Mainstream-Thema berichtet wird, und wird von den Mainstream-Lemmingen auch kaum weiter zur Kenntnis genommen.
Provinzen im Internet, das sind z.B. Blogs deren Besitzer sagen, es handele sich um deren "eigene kleine Ecke im Internet", wo sich das Ego - und damit die Inhalte - um eigene Interessen drehen und nicht versuchen einer Leserschaft zu gefallen.
 
Man selber merkt, dass man in einer Provinz bloggt z.B. daran, dass trotz aller Blogroles ein Thema völlig an einem vorbei gegangen ist. Ich habe mich die letzten Tage desöfteren mal gefragt, wofür wohl die Abkürzung SEO steht, und habe dabei an irgendeine anglizistische Jobbezeichnung gedacht. Bis mir heute aufgegangen ist, dass das eher für Search Engine Optimisation steht...
So gesehen ist so eine Provinz garnichts schlimmes: Bisher hatte ich mit solchen Dingen nicht so die Last, wobei das natürlich auch an twoday.net liegen mag. :-)

Die "Bruteforce-Cat" ist eine bisher unbekannte Unterart der Europäisch Kurzhaar (kurz: EKH), obwohl auch schon Bruteforce-Exemplare anderer Rassen gesichtet worden sein sollen.
Die Bruteforce-Cat ist erstmal in nichts von ihren Verwandten zu unterscheiden, sie frißt normales Katzenfutter und verhält sich im großen und ganzen, wie man das von Katzen gewöhnt ist. Selbst Jagderfolge wurden bei diesen Exemplaren nachgewiesen.
Was die Bruteforce-Cats so einzigartig macht ist Ihr Interesse für IT-Equipment jeglicher Art. So sind vor allem Tastaturen bei laufenden Terminal-Sitzungen nicht vor ihnen sicher. Angesichts ihres Interesses an dem Mauspfeil darf mittlerweile auch bezweifelt werden, dass eben jene Bezeichnung von dem gleichnamigen Eingabegerät abgeleitet worden ist. Viel wahrscheinlicher ist hingegen, dass der Mauspfeil seinen Namen dem vierbeinigen, primären Jagdziel vieler Katzen verdient, da Bruteforce-Katzen diesen ebenso nachhaltig verfolgen wie sie das bei ihrer lebendigen Beute gewohnt sind. Vorsicht ist hier vor allem bei TFT-Displays geboten, die u.U. den Krallen einer Katze nicht so viel entgegen zu setzen haben, wie das bei klassischen Röhrenmonitoren der Fall ist.
 
Eine weitere Verhaltensauffälligkeit bei Bruteforce-Katzen ist ihre Angewohnheit, sich bei Herrchen oder Frauchen auf den Schoß oder den Bauch zu legen, während diese mit dem Laptop arbeiten. Dabei wollen sie scheinbar weniger kuscheln sondern vielmehr genau deren Arbeit überwachen.
Allerdings ist noch kein Fall einer Katze bekannt, die ihren Besitzer vor irgendwelchen Dummheiten gewarnt hätte, während dieser als Root auf seinem Unix-System zugange war. Hier steht aber zu vermuten, dass die Katze eine subtile Art des Humors hat und still in sich hinein lacht. Außerdem hortet sie durch die unschuldige Art der Bildschirm-Betrachtung ein imenses Unix-Know How, so dass jedem Admin nur angeraten werden kann die Konsole zu sperren, selbst wenn nur eine Katze in der Nähe ist. Man weiß ja nie...

Eine der "großen Neuerungen" von Solaris 10 war sicherlich SVC, der "init.d-Ersatz". Die lieb gewonnen Runlevel-Scripte bringen in aktuellen Systemen eine Reihe von Nachteilen mit sich. So werden sie streng anhand ihrer nummerierten Reihenfolge ausgeführt, ohne dass Abhängigkeiten berücksichtigt werden.
Das bedeutet zum einen, dass kein Nutzen aus SMP-Systemen gezogen werden, weil immer ein Script nach dem anderen ausgeführt wird. Zum anderen muß ein nachfolgendes Script davon ausgehen, dass seine Vorgänger gestartet worden sind, es gibt vernünftige Möglichkeit, Fehler abzufangen.
Wenn also irgendwo ein Fehler aufgetreten ist bootet das System trotzdem weiter und es kommt zu einer ganzen Reihe Folgefehler. Im Ernstfall kann man kaum abschätzen in welchem Zustand ein System dann ist, und was man noch alles machen muß, nachdem der ursprüngliche Fehler behoben ist.
 
Mittlerweile sind eigentlich alle Unixe von den Runlevel-Scripten entweder abgekommen, oder haben Erweiterungen daran vorgenommen, so definieren z.B. BSDs und Gentoo Dependencies.
Einzig Sun ist den Weg aber komplett gegangen und verwendet nur noch ein paar wenige Init-Scripte im "Legacy_Run". Mit einem Ende ist wohl mit Solaris 11 zu erwarten, wenn ich diversen Stimmchen trauen darf.
Statt dessen tritt SVC auf den Plan, welches anhand der einzelnen Abhängigkeitsdefinitionen ganze Bäume erstellt und diese parallel anfahren kann, auch wenn man über Zeitgewinn streiten kann. Andererseits boote ich meine Server nicht so häufig als das ich für einen Streit Energie verschwenden würde. ;-)
 
In SVC sind die alten Runlevel, vor allem rc3 als Solaris Defaultrunlevel als sogenannte "Milestones" aufgeführt. Ein Milestones besteht aus einem Haufen Abhängigkeitsdefinitionen, stellt aber selber keine Dienste zur Verfügung. Beim Booten der Maschine kann man diese Meilensteine - es gibt natürlich auch einen für Singleuser - gezielt anfahren.
Was SVC von den ganzen Alternativen abhebt ist die Tatsache, dass nach meiner Erfahrung nur Solaris 10 in der Lage ist, einen Abbruch wieder korrekt aufzunehmen und damit einen Bootvorgang richtig fortzusetzen. Anders ausgedrückt: Egal was passiert, SVC bietet zu jeder Zeit einen konsistenten Stand des Systems.
 
Kleines Beispiel: Bei der Netzwerk-Konfiguration ist was schief gelaufen und eine Service-IP fehlt z.B. Eine nachgelagerte Apache-Instanz macht darauf aber einen Bind, da die IP aber nicht existiert schlägt der fehl und der Apache wird nicht gestartet.
Mit SVC werden in diesem Falle alle Netzwerkdienste erst garnicht initialisiert. Die grundlegende Netzwerk-Konfiguration wird durch network-physical abgedeckt. Geht die auf failed, werden weder ssh, noch Apache noch sonstwas durch initialisiert.
Spätestens wenn die User anrufen, dass sie sich nicht auf das System konnekten können, kann Admin also hingehen, sieht den Zustand, und kann network-physical fixen.
In dem Moment, wo das passiert ist und der SVC-Service damit in den Status Enabled wechselt, zieht SVC automatisch alle abhängigen Dienste an, ohne das Admin eingreifen muß. Voila...
 
Das ist einer der Gründe, warum ich gerne neue Manifests für Anwendungen schreibe, die wir unter Solaris 10 produktiv nehmen. Dabei offenbaren die Manifests meiner Meinung nach einen Pferdefuß, da es sich hierbei um XML-Dateien handelt.
Ich mag kein XML.
Meiner Meinung nach hat XML bis heute noch nicht bewiesen, daß es das kann, wofür es geschaffen worden ist. Die Import-Funktion, mit der ein neuen Manifest ins SVC-Repository integriert wird, ist da ein gutes Beispiel für. Statt einer ordentlichen Fehlermeldung, weil der Parser irgendwas nicht verstanden hat, kommt nur eine höchst ominöse Meldung a la "es ist ein Fehler aufgetreten".
Aber irgendwas ist ja immer, und ich habe die Hoffnung noch nicht aufgegeben, dass Sun in einer der zukünftigen Versionen dem Parser ein paar ordentliche Meldungen implantieren kann.

Als Sysadmin bekomme ich einiges zu sehen. Da hätten wir z.B. unsere eigenen Entwickler und ihre Begierden, die zu Auswüchen wie "Du mußt mal den Server auf Deutsch umstellen" und dergleichen führen.
Wie, den gesamten Server? Stundenlange Diskussionen über die Verwendung von Locales in der Umgebung des Users oder der Umgang mit Locales in der Anwendung selbst folgen.
 
Mein Verständnis schlägt aber in entsetzen oder wahlweise in einen Lachanfall um, wenn ich mir die kommerziellen Produkte diverser Hersteller anschaue.
IBM hat mit ihrem Backuptool aus der eierlegenden Wollmilchsau Tivoli-Familie so ein Ding im Angebot: Da wird die Anwendung brav in ein eigenes Verzeichnis installiert, und im Anschluß die Konfigurationsdateien dsm.sys und dsm.opt nach /usr/bin verlinkt.
Puh, und ich rege mich auf, wenn Open Source Makefiles auf den gcc ausgelegt oder für Linux "optimiert" sind. Nun gut, die Links muß man nicht haben, aber auch unterhalb des Anwendungsverzeichnisses gibt es ein ./bin, in dem die Files rumfliegen. Wobei die hier von anderen Textdateien Verstärkung erhalten, die man ebenfalls als "Konfigurationsdatei" bezeichnen könnte. Die wird aber nicht verlinkt. Warum das so ist verstehen aber wohl nur die Programmierer. Das sind wohl auch die einzigen, die erklären können, warum sowas nicht in ein ./etc-Verzeichnis landet.
 
BMC kann das auch, wie ich gerade gesehen habe. Bei diesem dreibuchstabigen Hersteller ist man wohl der Ansicht, "bin" steht für "alles, was binär ist". Um die Sache also nicht allzusehr zu verkomplizieren findet man bei deren Software auch gleich noch die Libraries in eben diesem Verzeichnis. Dann muß man sich auch keine Gedanken über den dynamischen Linker machen.
Oder aber die Programmierer arbeiten unter und primär für Windows. So sieht das nämlich aus, wenn unter ./bin auch ein ganzer Haufen Textdateien und jars liegen. Schaut unter Windows ja eh keiner rein, und da gibt es keine festgelegten und seit Jahrzehnten gut abgehangenen Verzeichnisstrukturen.
 
Ich wundere mich dann immer, warum ich unter /etc/rc3.d keinen Eintrag finde wie ./Verknüpfung mit unserhauptprogramm. Aber stimmt, es ist mir aufgefallen, weil ich noch ein SVC Manifest für die Software schreiben muß.
 
Wobei das wirklich positiv ist, denn die Software braucht keine Root-Rechte zur Installation, sondern nur ein Verzeichnis, in dem sie sich entladen darf. Und zwischendurch weist sie dann darauf hin, dass der Root mal aktiv werden darf.
Ist also nicht alles schlecht. ;)
 
Umgekehrt sollte es aber bei so einer Software aber nicht schwer sein eine Paketierung zu verwenden, die auch den Standards gerecht wird, oder? Bei solchen Äußerlichkeiten möchte ich manchmal garnicht wissen, was der eigentliche Programmcode so alles für Überraschungen bereit hält.