Es ist mal wieder Zeit für doofe Ideen mit dem /proc-Filesystem. Heute wollen wir uns eine Fragestellung widmen, die den einen oder anderen bestimmt schonmal beschäftigt hat: Es sei ein Programm gegeben und wir wollen "Pi mal Daumen" herausfinden, ob das Programm eher I/O- oder eher CPU-beschränkt ist. Jetzt kann man das Programm natürlich einfach starten und sich anschauen, wie sich der Server verhält, aber gehen wir mal davon aus, daß uns diese Option nicht wirklich offen steht, z.B. weil noch viele andere Dinge auf der Kiste laufen und wir deshalb keine echte Vergleichsbasis haben. Was tun wir also?

Nun, im "/proc"-Filesystem gibt es für jede PID eine Pseudo-Datei mit Namen "status". In dieser vermerkt der Kernel unter anderem die Anzahl der Context Switches, die dieser Prozess mitgemacht hat. Dabei wird zwischen "voluntary" und "nonvoluntary" unterschieden. Ersteres tritt meistens dann auf, wenn ein Prozess auf I/O wartet - er gibt dann quasi freiwillig die CPU ab und wird vom Kernel - vereinfacht gesprochen - weiter abgearbeitet, sobald die Daten, die er zum Beispiel von der Platte, vom Netzwerk etc. lesen wollte, zur Verfügung stehen. Im Unterschied dazu wird ein Prozess, der die ganze Zeit Berechnungen auf der CPU ausführt, unfreiwillig unterbrochen. Durch einen Vergleich der beiden Counter können wir also ungefähr bestimmen, was ein Prozess an Resourcen braucht.

Zur Demonstration sehen wir uns zunächst das folgende C-Programm an:

Wie wir erwartet haben sehen wir hier eigentlich nur unfreiwillige Kontextwechsel. Das "set +H" steht da übrigens, da wir sonst statt "$!" ein (evt. nicht existierendes) bash-Event ansprechen würden. Als zweites Beispiel sehen wir uns dieses Stück Code an:

Das Programm liest ein einzelnes Zeichen aus einer Datei, dann das nächste usw. Hier würden wir eine deutlich höhere Anzahl an freiwilligen Kontext-Wechseln erwarten. Und tatsächlich:

Obwohl wir auch hier eine große Zahl unfreiwilliger Kontextwechsel sehen, so sind die Mehrzahl der Wechsel doch freiwlliger Natur und das Programm damit eher I/O-beschränkt.

Draußen geht die Welt im Regen unter, für mich wird es damit Zeit, mich Ravels Bolero zuzuwenden. Euch noch einen schönen Sonntag!

Wenn man... und so:

Vielen Dank für diese aussagekräftige Information! Ich würde übrigens "ginstitsch" DNS-Consulting-Dienstleistungen verticken

Ein guter Freund von mir meinte neulich: "Virtualisierung? Das ist doch nur eine Retro-Bewegung, zurück zum Mainframe, diesmal halt auf Commodity-Hardware." Was er vergessen hat zu erwähnen: Oft setzt man nicht nur "Commodity-Hardware" ein sondern eben auch die Betriebssysteme, die man sowieso schon im Unternehmen hat. Unter Linux bietet jede halbwegs aktuelle Distribution hier Virtualisierung auf KVM, der Kernel Virtual Machine. Und obwohl KVM gegenüber anderen Lösungen durchaus den einen oder anderen Nachteil hat - für die meisten Fälle ist es "gut genug". Die Kombination aus leistungsfähiger, vernünftig gepreister Hardware und einer gut etablierten Software-Infrastruktur hat denn auch dazu geführt, daß die Einstiegshürde für die Einführung von Virtualisierungsumgebungen in Firmen massiv gesunken ist. Als direkte Folge davon beobachte ich seit knapp zwei Jahren in meinem persönlichen "Dunstkreis" (IRC, G+, einschlägige Mailinglisten etc.) eine wahre Flut von Support-Anfragen zu Virtualisierungsthemen - soweit nicht verwunderlich. Was mich jedoch mit Sorge erfüllt ist die Tatsache, daß fast 50% der vorgeblich technischen Fragen, die so aufschlagen, ihrer prinzipiellen Natur eigentlich nicht technisch sind. Vielmehr sind sie der Ausdruck einer Sackgasse, in die man sich mit einer Virtualisierungslösung manövriert hat und die man nun mit technischen Mitteln zu lösen versucht.

Das eingangs erwähnte Zitat spricht von "Commodity-Hardware" und ich ergänzte das um "vernünftig gepreist". Doch was genau steckt hinter diesen Aussagen eigentlich? Nun, zum einen natürlich, daß man im Jahr 2012 also Plattform für Virtualisierung in den meisten Fällen im Prinzip die gleiche Hardware-Architektur einsetzen kann, die man wahrscheinlich eh schon im Unternehmen hat. Man braucht keine Power- oder Sparc(haha!)-Prozessoren, keine NUMA-Architektur und ganz allgemein keine Hardware, die ein ganzes Rack in Beschlag nimmt. Dies vereinfacht natürlich ganz erheblich den Beschaffungsprozess: i386/x86_64-Serverhardware mit Unterstützung für Virtualisierung bekommt man beim gleichen Hänlder, bei dem man auch die letzten 20 Applikationsserver gekauft hat. Das einzige, was man tun muß, ist ein paar mehr Cores und deutlich mehr RAM reinzubauen. Der Sprung ist dabei nur auf dem Papier groß: Eine mir bekannte Firma kauft Standardserver für ihre Applikationsserver meist mit Hexacores und 6GiB RAM. Während der Vorüberlegungen zur Virtualisierung einer größeren Testumgebung hat besagte Firma als Virtualisierungshost die exakt selber Hardware-Plattform angedacht, nur mit zwei statt einem Prozessormodul (also 12 statt 6 Cores), einem anderen Prozessor-Typ und 96GiB RAM (Faktor 16). Ohne Frage: Da bekommt besagte Firma eine HW-Plattform, mit der sie jede Menge Erfahrung hat. Also alles gut? Sehen wir uns mal die Kosten an (alles laut Herstellerseite): Für einen normalen Applikationsserver legt besagte Company recht gemäßigte 2.844,10€ hin. Für die große Hardware zahlt man mindestens 13.548,15€. Während man hier also schon Faktor vier hat, ist das leider noch nicht alles an Kosten: Will man Virtualisierung nämlich mit mehr als einem Server betreiben, so kommen ganz schnell weitere Posten hinzu: Pro Server ein FC-Controller. Mindestens eine Storage mit FC-Anschluß. Wenn man mehr als zwei Server und eine einzelen Storage hat: Mindestens ein SAN-Switch. Keine Frage: Jede einzelne dieser Komponenten ist "vernünftig gepreist" - in ihrer Summe stellen sie jedoch durchaus eine erhebliche Investition dar. Und egal bei welchem Unternehmen man arbeitet: Investitionen müssen einen wirtschaftlichen Nutzen haben. Man würde nun annehmen, daß die meisten Firmen angesichts dieser Tatsache ihre Virtualisierungs-Projekte genauestens planen, um zu verhindern, daß sie noch in der Planungsphase an die Wand gefahren werden. Die traurige Realität ist aber oft eine andere. Und die Tatsache, daß Virtualisierung nicht mehr komplex ist, ist nur ein Faktor dabei.

Der schlimmste Fehler (der betroffene Admin wird gerade in ##linux im freenode-Netz verarztet) wird dabei interessanterweise gar nicht auf technischer, sondern auf Management-Ebene gemacht (ein weiteres Zeichen dafür, daß Virtualisierung kein technisches Problem ist): Dem Auftrag, Virtualisierungstechniken einzuführen, fehlt es oft an Abgrenzung und Commitment. Mit "Abgrenzung" ist die klare Definition des Ziels gemeint, quasi das Festlegen der Parameter, an denen sich die zu realisierende Infrastruktur zu orientieren hat. Interessanterweise erlebe ich immer wieder, daß hier selbst die Basics "verkackt" werden. Man sollte annehmen, daß der Mindestsatz an Fragen, die man im Projektauftrag beantwortet finden würde, unter anderem die zwei grundlegendsten umfasst:

• Wie viele Systeme sollen virtualisiert werden?
• Welche Art(en) von Systemen soll virtualisiert werden?

Von besonderem Interesse ist dabei die zweite Frage: Eine saubere Anforderungsdefinition ermöglicht es jeder halbwegs technisch kompetenten Person, auf Anhieb eine Reihe von Fragen zu beantworten:

• Wieviel CPU, Speicher und I/O muß ich pro Gast bereitstellen?
• Welche Performance-Garantien muß ich - wenn überhaupt - sicherstellen?
• Muß ich Maschinen in einem oder in Dutzenden von VLANs bereitstellen können?
• Wie muß ich die Netzwerkanbindung dimensionieren?
• Was ist der Personenkreis, der Zugriff auf die Management-Interfaces der Virtualisierungslösung bekommen soll? (oder anders: Brauche ich ACLs und eine GUI?)
• Welche Maßnahmen muß ich - wenn überhaupt - zur Erhöhung der Verfügbarkeit treffen?
• Welche Abhängigkeiten haben die virtualisierten Server untereinander?
• Welche Abhängigkeiten bestehen zwischen den virtualisierten Systemen und dem Rest meiner IT-Infrastruktur?

Die Bantwortung dieser Frage kann natürlich extreme Unterschiede in der Dimensionierung der Umgebung haben: Der Anwendungsfall "ein Admin will RPM-Pakete für verschiedene Distributionen/Architekturen bauen und benötigt dazu mehrere Systeme, auf denen er nach belieben Development-Tools nachinstallieren kann" lässt sich mit einem mehrere Jahre alten Server mit minimalem RAM abdecken: VM mit CentOS 5/i386 starten, Paket bauen, VM stoppen. VM mit CentOS5/x86_64 hochfahren, RPM bauen, VM stoppen. Da capo al fine, "Management" der VMs mit virsh. Die Anforderung "Virtualisierung von 60 Applikations- und acht Telco-Servern, welche Zugriff auf ISDN-Hardware benötigen, mit mehr als 99.9% Verfügbarkeit, für vier Organisationseinheiten innerhalb des Unternehmens" dürfte eine gänzlich anders geartete Lösung erfordern. Und wenn besagte 60 Applikationsserver dann mal laufen und man feststellt, daß die zentrale, nicht-virtualisierte Datenbank unterdimensioniert ist und das Jahresbudget keine Erweiterung selbiger hergibt, hat man einen wunderbaren Shitstorm geschaffen.

Mit "Commitment" ist gemeint, daß eine klare Aussage dazu getroffen wird, wie lange die unter dem Punkt "Abgrenzung" gemachten Aussagen gültig sein sollen und wie verbindlich sie sind. Wenn ich weiß, daß die einzuführende Plattform innerhalb von zwei Jahren wachsen wird, dann kann ich von Anfang an eine Struktur aufbauen, die dies leisten können wird - muß aber natürlich oft eine höhere Anfangs-Investition tätigen. Anders gesagt beschreibt "Anbrenzung" den kurzfristig herzustellenden Zustand, "Commitment" die langfristge Situation.

Spätestens hier merkt man, worauf ich hinaus will: Vielen Unternehmen (und ich bin mal wieder in der glücklichen Situation, daß das bei meiner Firma nicht der Fall ist!) fehlt es an einer gesunden Strategie, was Virtualisierung angeht. Über die Gründe dafür kann ich nur spekulieren, aber meines Erachtens nach sind es vor allem zwei Dinge, die hier oft verkehrt laufen: Durch die allgegenwärtige Berichterstattung in der "einschlägigen Fachpresse" wird das Thema als relativ trivial wahrgenommen - was auf einer rein atomaren, technischen Ebene durchaus richtig ist. Die intrinsische Komplexität ergibt sich nämlich aus der Anforderung, mit der Lösung das bestmögliche Ergebnis für das Unternehmen zu realisieren. Die Definition, was dieses Ziel sein soll, ist jedoch kein technisches, sondern ein Management-Problem. Funktioniert hier die Kommunikation zwischen den an einem Projekt beteiligten Technikern und Managern nicht, zeigt sich das Management gegenüber den Ratschläge der Techniker uneinsichtig, fehlt es den am Projekt beteiligten Architekten/Engineers an technischer Erfahrung oder Überblick über vorhandene Lösungen oder zeigt sich die Firmenleitung unfähig, langfristige Strategie-Ziele zu formulieren - um Andreas zu zitieren, "von der Hand in den Mund" - so wird jedes Virtualisierungsprojekt noch vor der ersten HW-Bestellung scheitern.

Der zweite Grund, warum man oft keine guten Strategien findet, ist meiner Ansicht nach nicht so gewichtig wie das bereits genannte, ich will ihn aber nicht unerwähnt lassen: Virtualisierung wird oft als Allheilmittel gesehen. Egal ob es um die Senkung von TCO ("Total Cost of Ownership") geht, das "Konsolidieren" von Altlasten oder das Erhöhen von Verfügbarkeit: Für viele Manager und Techniker scheint die Antwort stets "Wir virtualisieren!" zu lauten. Dabei könnte nichts falscher sein als das: Wenn uralte Legacy-Software anstatt auf eigene Hardware plötzlich in einer virtualisierten FreeDOS-Umgebung läuft, dann ist das keine "Konsolidierung" - im Gegenteil, das einzige was man damit getan hat, ist den Schmerz zu reduzieren, den eine IT im angesicht solcher Altlasten empfinden sollte - denn nur Schmerzen werden eine IT dazu bewegen, sich ernsthaft nach Alternativen umzusehen.

Was mich ebenfalls immer zum Lachen bringt sind die Behauptungen, mit Virtualisierung würden sich auch die Bestandteile der TCO, die von den Posten "Deployment" und "(Konfigurations-)Management" verursacht werden, drastisch reduzieren. Wie man im Jahr 2012 zu solch grenzwertigen Aussagen kommen kann, ist mir völlig unverständlich. Während man ganz klar sagen muß, daß eigentlich jede Virtualisierungslösung eine Methode bietet, um schnell eine bestimmte Art von Gast aus Images ("Systemabbildern") oder Templates ("Vorlagen") zu erstellen, so benötige ich nur für das schnelle Deployment von neuen Servern ganz sicher keine Virtualisierung. Und das ist jetzt nicht unbedingt eine neue technische Errungenschaft: Ich habe schon im Jahr 2000 Dutzende von IBM PowerPC-Workstations unter AIX über Netz deployed. Ohne Interaktion. In Zeiten, in denen jeder "Billo-Server" PXE-Boots kann und Frameworks wie cobbler/foreman/koan mir die automatisierte Installation von fast allem erlauben löst die Behauptung, das Deployment von Systemen sei mit Virtualisierungsumgebungen signifikant einfacher, bei mir nur ein belustigtes Schnauben aus.

Nicht anders verhält es sich mit dem Punkt "(Konfigurations-)Management": Wer im Linux-Bereich nicht in der Lage ist, ein zentrales Konfigurationsmanagement auf real existierender Hardware zu nutzen, der wird durch Virtualisierung seine Management-Kosten nicht senken können. Und nur am Rande: Das Thema Backup ist hier kein anderes. Ja, mit Virtualisierungslösungen kann man ein System meist als Image sichern und auch schnell wieder herstellen. Aber auch dafür muß es ein existierendes Backup-Konzept geben, und wenn man nicht nur Nullen in seiner Technik hat, dann kann jedes Backup-Konzept sicherstellen, daß man ausgefallene Maschinen schnell wieder zum Leben erwecken kann. Ich habe neulich für meinen Chef einen "proof of concept" zu einem speziellen Virtualisierungs-Thema gebaut - und als ich ihm das dann vorgestellt habe, war das erste, was ich erwähnt habe, daß die Implementierung exakt die selben Tools verwendet, die wir auch zum Deployment und Management von echter Hardware benutzen (was übrigens auch für das zentrale Verteilen von Software oder Updates gilt). Eine gute Infrastruktur wird Virtualisierung umarmen, aber Virtualisierung ist nicht in der Lage, aus dem Nichts heraus eine gute Infrastruktur aufzubauen.

Wo also stehen wir? Ähnlich wie im Zeitalter von Mainframes haben wir heutzutage die interessante Situation, daß der Einsatz einer neuen Technologie kein technisches Problem mehr ist. Hand in Hand damit geht einher, daß das Management in einem sehr viel höheren Maß als gewöhnlich direkt über Erfolg oder Misserfolg von Virtualisierungsprojekten entscheidet. Hier erleben wir einen Paradigmenwechsel, der die Belastung von Führungskräften nicht unerheblich erhöht: Die Anforderungen an sie wachsen enorm, wenn die einzuführende Lösung wirtschaftlich rentabel sein soll. Erschwerend kommt hinzu, daß in der "einschlägigen Fachpresse", aber auch in den Werbematerialien der Hersteller, kaum hilfreiche Hinweise zu finden sind, wie sie diese Herausforderung meistern können. Hier besteht für die Industrie als ganzes Nachholbedarf - und bis sich die Situation ändert ist das beste, das Thema Virtualisierung wie einen Mainframe zu behandeln:

Mit Respekt vor dessen Komplexität.

Ich höre mir jetzt "Pictures at an Exhibition" von Mussorgski an. Euch einen schönen Sonntag!

Was könnte man zum Thema "/proc" und "/sys" noch so erzählen... ah, ich weiß! Kennt ihr so Dreckstools, die sich einfach weigern, von STDIN zu lesen? Egal, ob man sie mit einem "-" als letztem Parameter oder ganz ohne Eingabefile aufruft, sie können es einfach nicht? Tja, dank "/proc" entlockt uns sowas nur ein müdes Lächeln:

Und das ganze geht natürlich nicht nur mit FD 0 aka STDIN, sondern auch mit anderen FDs. Warum auch immer man das tun wollen würde.

Und eigentlich könnten wir noch was scripten, irgendwas in pseudo-bunt. Kennt ihr z.B. "dialog"? Nein? Solltet ihr aber! Stellt Euch mal vor, ihr habt nen großen Copy-Job angestoßen und wollt nicht immer "watch ls -lh..." benutzen, weil's langweilig ist, scheiße aussieht und man im Kopf rumrechnen muß. Dann zieht ihr Euch aus "/proc/$PID/fd" einfach den Filedeskriptor und übergebt ihn an das folgende Skript ("Danke" übrigens an den KSPLICE-Typen):

Der erste Parameter ist dabei die PID und der zweite der FD. Ich hoffe, das war bunt genug!

Als Nachtrag zu meinem Rant gegen die Filmindustrie und ihrem Beharren auf veralteten Vertriebswegen und ihrer Unfähigkeit, sich an neue technische Gegebenheiten anzupassen: Maxdome ist unglaublicher Müll. Man kann das in einer Web 2.0-Welt gar nicht fassen, was die da abziehen.

Hintergrund: "rink" hat mir gerade gesagt, der Film, dessen Titel mir in dem ursprünglichen Artikel nicht eingefallen ist, heisst Dangerous Minds. Vielen Dank, rink! Na ja, auf jeden Fall habe ich gerade gedacht: Ach, eigentlich könnten wir den heute anschauen - weibliche Zustimmung war auch vorhanden. Also schnell nachgeschaut, ob es den gibt... und das glaubt ihr mir jetzt nicht.

1. Suchanfrage "Dangerous Minds". Als Ergebnis unter anderem: Dangerous Lady - Verführt in Cannes (NSFW!).
2. Suchanfrage "Michelle Pfeiffer". Im Ergebnis unter anderem "We are Family - Staffel 9, Folge 178".
3. Suchanfrage "Michelle Pfeiffer Dangerous Minds". Ergebnisse eine Seite "Criminal Minds", alle mit dem Tag "OFFLINE" markiert.
4. Suchanfrage "Michelle Pfeiffer Wilde Gedanken" - und SCHON WIEDER EIN PORNO ("Wilde Jungs im ...")!

Sagt mal, liebe Filmindustrie, merkt ihr eigentlich noch was? Ihr verdient - nach Euren Verhältnissen - so wenig Kohle, weil ihr nichtmal ANSATZWEISE in der Lage seid, Euren Kunden ein vernünftiges Konsumerlebnis zu schaffen. Mit Raubkopien und Kostenlosmentalität hat das nichts zu tun, eher mit absoluter Unfähigkeit auf Eurer Seite. Solange ihr es nicht hinkriegt, Euch auch nur ein kleines bißchen zu bewegen, geschieht es Euch ganz recht, wenn ihr keinen müden Cent mehr verdient!

Eigentlich hätte ich es nach der Aktion mit dem gestauchten Bild auf meinem Fernseher ja wissen müssen...

Zum Thema /proc und /sys sollte man eigentlich noch viel mehr schreiben - gesagt, getan.

Fangen wir mal mit /sys an. Aufgabe Nummer eins, die ich jedes Mal wieder verplane: Man hat gerade irgendwo ne LUN ruasgeschnitzt, ein FC-Kabel angesteckt oder sonstwas, aber das OS kriegt nix davon mit. Wohin muß man also treten, damit man den saftigen neuen Speicherplatz sieht?

Oder wenn man echt mutig ist:

(Und wehe jemand macht mich für negative Folgen verantwortlich...!)

Manchmal interessiert man sich dafür, wie sich eine Anwendung verhalten würde, wenn sie weniger oder mehr CPUs zur Verfügung hätte (ich nenne jetzt keine Beispiele, wer mich kennt, weiß was ich meine). Unter halbwegs modernen Kerneln ist es relativ einfach, eine CPU on- oder offline zu setzen:

Wenns knallt, ich war's nicht!

Ich hatte neulich schon einmal das "/proc"-Filesystem erwähnt, und natürlich kann man in Linux damit noch andere Sachen machen - z.B. STDOUT oder STDERR eines laufenden Prozesses umleiten (ein bißchen Hilfe braucht man allerdings dabei schon).

Schauen wir uns mal ein Beispiel an: Der folgende Prozess schreibt STDERR in das Terminal, indem wir ihn gestartet haben, und STDOUT nach "/tmp/foo":

Hilfreicherweise zeigt mir die Shell auch gleich die Prozess-ID an, so daß es ein leichtes ist, herauszufinden, wohin STDOUT (FD 1) und STDERR (FD 2) zeigen:

Es ist jetzt an der Zeit, den "GNU Debugger" zu bemühen. Wir "attachen" uns an die Prozess-ID 4767 und geben dem Debugger als "Hint" auch gleich noch mit, welches das Binary ist, das den Prozess erzeugt hat (wir kanonisieren diesen Namen hier noch, da "nc" unter Debian über eine Kette von Symlinks auf verschiedene Binaries zeigen kann):

Unser Ziel ist es nun, STDOUT zuerst zu schließen - worfür wir close(2) benutzen - und danach mit neuem Ziel zu öffnen - wofür wir creat(2) nutzen werden. Das geht eigentlich relativ einfach:

Mit der "p"-Funktion lassen wir uns den Rückgabewert von "close" auf den FD 1 - also STDOUT - anzeigen. Hier wird eine 0 zurück geliefert, es hat also alles funktioniert. Danach verwenden wir den gleichen Mechanismus, um die Datei "/tmp/bar" zu erzeugen, mit den Rechten "0644". Und tatsächlich:

Wenn wir schonmal im Debugger sind hätten wir übrigens noch Dutzend andere Sachen machen können - aus aktuellem Anlass sei hier mal gezeigt wie man herausfindet, welche "umask" ein laufender Prozess hat:

Der erste Aufruf von "umask" gibt uns als Ergebnis den Wert an, der bis zu diesem Aufruf aktuell war. In diesem Fall war das eine 18. Nach Oktal umgewandelt ergibt das '0022'. Mit dem zweiten "umask"-Aufruf setzen wir übrigens wieder den alten Wert - das sollte man nicht vergessen. In diesem Sinne!

In den letzten Tagen wurde ja wieder viel disktuiert von wegen Urheberrechten, Verwertungsgesellschaften und Raubkopierer-kostenlos-Mentalität. Angefangen hat das mit einem offenen Brief von 51 Tatort-Autoren, in dem sie zu einem Rundumschlag gegen die nach ihrer Ansicht vorherrschende "kostenlos"-Mentalität ausgeholt haben. Schnell folgte dann eine eine Diskussion auf Google+, gestarten von einem Herrn Dirk Baranek, gefolgt von einer Antwort von 51 Hackern des CCC, und auch Reaktionen einzelner Piraten gab es.

Die ganze Diskussion hinkt, und nicht nur, weil dauernd ungeeignete Vergleiche gebracht werden (n.b: "Nicht alles, was hinkt, ist ein Vergleich"). Wir müssen uns zunächst einmal die Frage stellen, warum diese Diskussion geführt wird. Und da können wir jetzt einmal nur vermuten, daß eine oder mehrere Seiten in diesem wohlwollend "Interessenskonflikt" genannten Umfeld nicht genug Geld verdient. Diese Vermutung liegt vor allem aus einem Grund nahe: Wenn sich Urheber und/oder Verwerter an geschaffenen Werken dumm und dämlich verdienen würden, dann müsste man keine Diskussion über Urheberrecht führen. Und wenn man sie doch führen würde, so würde sie nicht von Vertretern der Urheber/Verwerter initiiert, sondern von Verbrauchern. Wie die Dinge jedoch liegen wird das Thema Urheberrecht und der ganze damit verbundene Sumpf ("Three Strikes") eigentlich so gut wie nie von den Konsumenten auf den Tisch gebracht. Also nehme ich an dieser Stelle an, daß die Urheber oder die Verwerter mit dem Produzieren und Vermarkten von Werken zu wenig Geld verdienen. Und da der aktuelle Anlass sich im Bereich "TV" bzw. "Filme" findet, will ich im folgenden auf die Filmindustrie eingehen.

Zu Anfang und in der ersten Hälfte dieses Jahrtausends hatten wir schonmal heftige Diskussionen um das Urheberrecht. Damals war es jedoch nicht die Filmindustrie, die das Thema regelmäßig angesprochen hat, sondern die Musikindustrie. Zum einen hat das garantiert mit der technischen Entwicklung zu tun: Jeder, der ein bißchen klar denken kann, muß einsehen, daß es leichter ist, ein Musikstück über das Internet zu übertragen als einen Film. Einzelne Lieder sind normalerweise kürzer als Kinofilme, das heisst, es fallen weniger Daten an. Zudem ist es weniger aufwändig, ein Musikstück in ein Format zu überführen, welches einen digitalen Austausch ermöglicht als es das bei einem Film ist - muß man bei einem Film ja neben dem Ton auch noch die Bilder irgendwie umwandeln. Und vor zehn Jahren hatten viele Menschen halt einfach noch nicht die Internet-Bandbreiten, die die Übertragung eines Films praktikabel gemacht hätten. Davon abgesehen hat auch die Softwareseite seit dem Jahr 2000 Fortschritte gemacht, was das Kodieren von bewegtem Bildmaterial angeht. Und so hatten wir in dem Eingangs genannten Zeitraum die Situation, daß es zwar ohne großen Aufwand möglich war, Musik über Internet zu beziehen, aber eben noch nicht ganze Filme.

Nun erinnern wir uns, daß wir damals von den Urhebern und Verwertern im Prinzip die gleichen Argumente gehört haben, wie wir es heute tun. Auch damals hat man in drastischen Tönen beschrieben, wieviel Gewinn der Branche entgeht, wenn Musik kostenlos getauscht wird. Auch damals haben wir die Forderung nach härteren Strafen und leichter durchsetzbarem Urheberrecht gehört. Irgendwann kam dann Apple mit iTunes, und wer sich noch erinnern kann - wenn man damals Musik im iTunes Store gekauft hat, dann hat man eigentlich immer Werke mit DRM erhalten. Die sich dann nur auf bis zu vier oder fünf Geräten abspielen ließ. Die an eine Hard- und Software-Architektur gekoppelt war. Und trotzdem hat sich das ganze für Apple und die Musikindustrie anscheinend schon damals gelohnt, denn sonst wäre das ganze garantiert eingestampft worden. Also muß man sich die Frage stellen: Warum haben einzelne Spieler auf dem Markt damals plötzlich Geld mit Musik verdient, obwohl wir doch schon damals die Infrastruktur hatten, um alles untereinander zu tauschen?

Wer pessimistisch ist, der mag sagen, daß es die Angst vor Strafen war, die uns davon absehen ließen, "~/Music" via Bittorrent etc. frei zu geben. Aber ich glaube, das ist Bullshit. Die eigentliche Trendwende war, daß "die Massen" mit dem Einstieg von Apple das erste Mal die Möglichkeit hatten, auf bequeme Art und Weise und für einen vernünftigen Preis Musik zu beziehen. Gehen wir in das Jahr 1995 zurück: Am 6. Oktober lösen "Die Fantastischen Vier" mit ihrem Album "Sie ist weg" die Gruppe "Technohead" in den Album-Charts ab und verteidigen ihre Position bis zum 27. Oktober. Da übernimmt dann "Coolio" mit "Gangsta's Paradise" (den Film mit MP als Lehrerin, dessen Name mir nicht mehr einfällt, würde ich echt gerne mal wieder sehen!). Und das waren alles Alben. Natürlich gab es schon damals Single-Auskopplungen aus einzelnen Alben, aber in den meisten Fällen war das Pricing (damals alles noch in DM) so, daß sich Singles nur gelohnt haben, wenn einem aus dem ganzen Album wirklich nur ein Stück gefallen hat - bei mehr als einem Track war es dann meist günstiger, das Album zu kaufen. Jetzt schauen wir mal, wieviele unterschiedliche Alben 1995 auf Platz eins der Charts waren: 30 Stück. Wenn einem aus jedem zweiten Album ein Titel gefallen hat, dann wären das 15 Singles gewesen, die man hätte kaufen müssen. Und wer sich noch an die Preise damals erinnert, der weiß, daß das eher unrealistisch für z.B. Schüler war.

Fast Forward (nicht "Flash Forward", gute Serie, übrigens) in das Jahr 2012: Die Studios (also die Verwerter) haben in den letzten 17 Jahren offensichtlich bemerkt, daß ihr altes Modell, Musik auf CDs zu Pressen und im Zwangs-Bündel zu verkaufen, nicht mehr funktioniert. Die an der technischen Seite des Vertriebs beteiligten Spieler haben bemerkt, daß DRM bei ihrer Kundschaft nicht so gut angekommen ist. Und in letzter Zeit haben einige Künstler gar bemerkt, daß die Musik selbst kostenlos sein kann, solange das Paket außenrum stimmt (Einnahmen durch Konzerte, Werbung etc.). Heute kann ich aus dem Kopf mehr als ein Dutzend Seiten nenne, auf denen ich legal Musik kaufen kann, die kein DRM hat, meistens auch kein Wasserzeichen. Die ich auf meinem Fernseher abspielen kann, meiner Workstation, in der Cloud, auf meinem Handy und die ich meiner Schwester per Mail schicken kann, wenn sie sie haben will. Und, oh Wunder, es wird immer noch Musik produziert und verkauft. Es gibt Leute, die sich offensichtlich mit dem Schaffen oder Vertreiben von Musik ihren Lebensunterhalt verdienen können, den Unkenrufen vom Ende der Musikkultur zum Trotz, die wir uns vor zehn Jahren anhören dürften.

Aus der Verfügbarkeit von technischer Infrastruktur und Musik ohne DRM und der Tatsache, daß es noch eine Musikindustrie gibt, folgt ganz klar, daß Konsumenten offensichtlich durchaus bereit sind, für Werke zu zahlen. Was die Musikindustrie also gerettet hat war nicht eine schärfere Gesetzgebung, sondern die Tatsache, daß sie sich auf neue Vertrbeiswege eingelassen hat. Daß sie sich einem Paradigmenwechsel gebeugt hat, in dem der Konsument durch die Macht seines Geldbeutels klar gemacht hat, daß er sich Freiheit und Bequemlichkeit beim Konsum von Musikstücken wünscht. Hier hat also ausnahmsweise einmal wirklich der Markt die heutigen Realitäten geformt - zum Gewinn aller, wie es aussieht. Hätten die Vermarkter damals auf ihren überkommenen Vertriebsstrukturen, bei denen sie dem Verbrauche zu diktieren versucht haben, welche Form dessen Konsum haben soll, bestanden, so hätten wir heute wahrscheinlich deutlich weniger Labes/Studios.

Warum ich Euch solche alten Kamellen erzähle? Weil die Filmindustrie heute genauso wenig in die Pötte kommt wie die Musikindustrie vor zehn Jahren. Die Vertriebsstrukturen sind immer noch viel zu einseitig auf althergebrachten Wegen festgefahren: Eine Film erscheint zuerst im Kino, dann auf DVD/BR, dann im Fernsehen. Eine Serie wird in den USA ausgestrahlt, dann in Europa, dann erscheint sie auf DVD/BR. Der am Anfang genannte Dirk Baranek schreibt dazu auf Google+ zwei eigentlich sehr schöne Kommentare:

Abgesehen davon, daß ich seine Ausdrucksweise/Wortwahl mag: Er hat recht. Die Urheber/Verwerter müssen die freie Entscheidung darüber haben, was mit ihren Werken geschieht. Und es kann nicht sein, daß Konsumenten, weil sie mit dieser Entscheidung nicht einverstanden sind, sich besagte Werke beschaffen, ohne dafür ihren Obulus zu entrichten. Aber: Freiheit funktioniert in beide Richtungen! So wie die Urheber/Verwerter das Recht haben, ihre Distributionskanäle frei zu bestimmen, so haben die Konsumenten das Recht, die Angebote einfach nicht wahr zu nehmen, wenn sie ihnen nicht gefallen. Das heisst nicht, dass es hier einen Freibrief gäbe, sich die Inhalte sonstwie zu beschaffen. Aber ich bin mir auch gar nicht sicher, daß das in so signifikantem Umfang passiert: Vielleicht, liebe Filmindustrie, müsst ihr Euch mit dem Gedanken anfreunden, daß ihr weniger Einnahmen habt, weil einfach wirklich niemand mehr Euren Kram anschaut - weder legal noch ohne zu zahlen. Und damit sind wir wieder bei der im zweiten Absatz gestellten Frage: Warum führen wir diese Diskussion? Weil zu wenig Geld verdient wird. Oder nicht genug. Und das geschieht offensichtlich, weil den Konsumenten die angebotenen Distributionskanäle nicht gut genug sind. Die Filmindustrie ist also aufgrund des technischen Fortschritts dort angekommen wo die Musikindustrie vor Apple iTunes war.

Es gibt erste, winzige Anzeichen dafür, daß hier langsam, ganz langsam, ein Umdenken stattfindet. So kann man mittlerweile selbst in .de und ohne Provider-Bindung an das rosarote T Filme "on demand" beziehen. Wie das aussieht konnte ich gestern im Selbstversuch erleben: Gewünscht wurde der Film War aus dem Jahr 2007. Und tatsächlich war das im Bereich des machbaren: Vor einiger Zeit habe ich mir einen neuen Fernseher (ja, liebe Plasma-Fraktion, das ist kein High End-Gerät. Aber mir reicht es!) gekauft. Der Fernseher ist Internet-fähig, und kann die Software des Anbieters maxdome ausführen. Somit hatte ich gestern die Möglichkeit, selbigen Film im HD anzusehen - für 2.99€ für 48h. Was jetzt gut klingt war dann aber leider eine Lachnummer (das Photo habe ich mit dem Handy aufgenommen, als der Vorspann lief):

Ja, genau (jetzt wisst ihr auch, woher der Titel dieses Eintrags stammt). Zusammengestaucht auf etwas weniger als die Hälfte der zur Verfügung stehenden Fläche. Tut mir leid, liebe Filmindustrie, wenn das das Beste ist, was ihr uns zur Verfügung stellt, dann verzichte ich dankend. Weitere Anzeichen, das hier ein Umdenken statt findet, muß man schon genau suchen, aber wenn man das tut, so findet man z.B.Netflix. Da kann man sich, Wohnort in Amerika oder einen geeigneten VPN-Endpunkt vorausgesetzt, für die Gebühr von acht Dollar im Monat anschauen, was man will. Auch Netflix hat noch nicht alles, auch Netflix bringt die Filme noch nicht für jedes Endgerät, hat DRM - aber dafür wenigstens Vollbild. Es kommt also Bewegung in den Markt.

Nur leider, wie das immer ist, wenn Unternehmen mit großem Marktwert beteiligt sind: Es ist zu langsam, es dauert zu lange. Das erkennt übrigens auch Dirk Baranek

TLDR-Version ("too long, didn't read"): Die Filmindustrie macht die gleichen Fehler wie sie die Musikindustrie schon gemacht. Wenn man Filme/Serien zeitnah nach erscheinen über zeitgemäße Vertriebskanäle beziehen könnte, müsste man nicht diskutieren, denn dann würde wieder Geld verdient werden. Und vor allem würden diese Vertriebkanäle wieder einmal beweisen, daß die oft bekalgte "Kostenlos-Mentalität" ein Mythos ist. In diesem Sinne: Einen schönen Sonntag!

An manche Menschen ist Ironie einfach verschwendet:

Ich komm mit den Amis manchmal echt nicht klar:

Oder eher "s/Amis/religiösen Fanatikern/". WTF...

Frage: Was tut man, wenn man sich aus Versehen ein wichtiges Logfile gelöscht hat? Also z.B. "/var/log/httpd/access_log"?

Antwort: Wenn man den Dienst, der das Logfile offen hält, neu gestartet oder ihm ein SIGHUP (SIGUSR1, $WHATEVER der Prozess halt braucht, um Logfiles neu zu öffnen) geschickt hat, dann tut man gar nichts, denn dann hat man verloren. Hat man das aber nicht getan, dann gibt es das File noch auf der Platte - denn "ein offenes Filehandle ist ein offenes Filehandle ist ein offenes Filehandle", wie Frank sagen würde. Und wir kommen da jederzeit über das "/proc"-Filesystem ran. Das vorgehen ist denkbar einfach - im ersten Schritt suchen wir die Prozessnummer und die Nummer des FD raus:

In der ersten Spalte steht dabei der Prozessname, in der zweiten die PID und in der vierten der FD. Angenommen, die PID sei "1710" und das Filehandle "11w", dann finden wir das File hier:

Alles halb so wild

Es gibt ein paar Techniken, die habe ich während meiner Zeit in der IT sehr zu schätzen gelernt - besonders solche, die mir das Leben leichter machen. Für diesen Blog-Eintrag relevant sind unter anderem:

1. der Pacemaker-Cluster
2. libvirt als einheitliche Schnittstelle zu Virtualisierungstechniken
3. KVM als zuverlässige und im Kernel integrierte Virtualisierungstechnik
4. der Device Mapper im allgemeinen und Multipathing im speziellen
5. der Cluster LVM und der Cluster Manager CMAN von RedHat

Seit der Version 6 von RHEL (RedHat Enterprise Linux) ist Pacemaker in der Distribution als Tech-Preview enthalten. Und während man auch früher schon über Repositories von Dritten sehr leicht eine Umgebung aus Corosync(also Kommunikationsschicht) und Pacemaker aufbauen konnte, so ist die wirklich große Neuerung in dieser Version die Integration von Pacemaker in den bestehenden CMAN-Stack. Diese Integration ermöglicht es nämlich endlich, Dinge wie geclustertes LVM oder GFS2 zu nutzen (die beide auf den DLM, den "Distributed Lock Manager" angewiesen sind), ohne auch nur ein Stück Zusatzsoftware von dritter Seite aus beschaffen zu müssen. In diesem Eintrag möchte ich mal zeigen, wie einfach es im Prinzip geht, einen Cluster aufzubauen, den man dann z.B. benutzen kann, um unwichtige Systeme zu virtualisieren.

Das Prinzip soll dabei so KISS wie möglich bleiben:

1. Jede virtuelle Maschine bekommt einen eindeutigen Namen.
2. Jeder Maschine wird als "Systemplatte" mindestens ein eigenes LV zugewiesen (die Maschine "brownout05" bekommt das LV "kvm_brownout05").

Die eine Sache, auf die ich nicht genauer eingehen werde, ist die Einrichtung des Resource Agents "VirtualDomain" - dazu gibt's Wiki-Dokumentation. Ich will hier wirklich nur über die Einrichtung des Clusters sprechen.

...die einem das Leben leichter machen. Aus dem "Grundkurs bash" (und mehr soll das jetzt auch gar nicht sein):

Und ich muß zugeben, daß mir seit SecureCRT auch keine SSH-Clustershell mehr abgeht - zumindest nicht mehr all zu sehr, dank "send chat to all tabs"

Neulich war es dann so weit, der erste KSK-Rollover stand an:

Nachdem mein Provider die in Rekordzeit weitergegeben hatte konnten die DNSSEC-Tools wie in der Doku beschrieben dazu gebracht werden, den Rollover abzuschließen:

Es kommt viel zu selten vor, daß mal was auf Anhieb funktioniert, wie es sollte - das hier war eine angenehme Ausnahme.

Im Gegensatz zu dem, was man im Netz so findet, ist es nicht korrekt, "set password/m5 null" zu nutzen. Richtig sieht es so aus:

Also "clear" statt "set ... null". Und man sollte mehr als einen Test-Durchlauf machen um zu sehen, ob die Konfiguration funktioniert, gerade "ins" und die Reihenfolge von "clear" und "set" können durchaus beim ersten Mal funktionieren, aber Mist bauen, wenn die Datei bereits angepasst wurde.

Guten Rutsch!