Der letzte Beitrag ist schon eine Weile her, in sofern könnte man diesen Artikel hier auch als eine Art RESET bezeichnen, aber eigentlich soll es darum gehen, wie man bei einem APU-Board einen RESET auf sichere Art und Weise mit einem externen Gerät (zum Beispiel RaspberryPi) auslösen kann, ohne das APU-Board oder andere Komponenten zu gefährden, ohne zufällige Resets zu befürchten und ohne festzustellen, dass der Reset nicht geklappt hat, weil ein Kabel falsch steckt.

Warum das ganze? Bei Freifunk Hochstift  möchte man im Rahmen des Out-Of-Band Managements verschiedene APU-Modelle von einem RaspberryPi aus rebooten können. Da die APU sich bei Einschalten der Stromversorgung automatisch einschalten, muss also nur der RESET-Taster automatisiert werden.

Details dazu gibt’s im Vortrag „Out-of-Band-Management für APU-Boards“ beim FreifunkTag19 – Link folgt.

TLDR;

Ich schlage letztlich vor mit möglichst kurzen Kabeln den Reset-Pin und Masse der APU mit einem Relais zu verbinden und darüber den Reset auszulösen, auch wenn es elegantere Lösungen gibt. Warum will ich im Folgenden etwas ausschweifend beantworten. Das ist keine vollständige Einführung in Schaltungsdesign und sicher auch nicht 100% exakt. Hauptaugenmerk liegt auf einer einfachen Erklärung.

Reset und Power-good – was ist das eigentlich?

Das klingt ja erst mal nach einer einfach zu beantwortenden Frage, aber bei genauerer Betrachtung gibt es hier einen Unterschied, der sich auch im Layout der APU-Boards finden lässt, aber dazu später mehr.

Fangen wir mit dem Reset-Signal an. Oder vielmehr damit, was ein Signal eigentlich ist. Mit einem Signal meine ich letztlich nichts weiter als eine „Leiterbahn“ auf der entweder ein HIGH- oder ein LOW-Pegel anliegt. LOW bedeutet, dass das Signal gegenüber GND (idealisiert) eine Spannung von 0V aufweist, HIGH bedeutet, dass eine (positive) Spannung oberhalb eines definierten Pegels anliegt. Vereinfacht: Der Pin wird mittels Widerstand mit Masse oder der Versorgungsspannung verbunden. Mehr dazu siehe: Logikpegel.

Das Reset-Signal dient wenig überraschend dazu, den Prozessor und ggf. weitere Peripherie wie USB-Interface, PCI-Karten, etc. in einen definierten Zustand zu versetzen. Bei einer CPU würde dies bedeuten, dass alle Register gelöscht und der Programmcounter auf die Startadresse, üblicherweise auch 0, gesetzt wird. Der Reset tut also was man erwartet: Alles beginnt bei 0, es ist tatsächlich wie nach dem Einschalten des Systems, weil beim Einschalten genau das passiert: Üblicherweise wird beim Einschalten der Spannungsversorgung der RESET-Pin oder das RESET-Signal für eine bestimmte Zeit „aktiv“ geschaltet. Aber Achtung – beim RESET# handelt es sich in aller Regel um ein active-low Signal! Das bedeutet, dass es aktiv ist, wenn es LOW ist (ach!) – ein Reset wird also ausgelöst, wenn der Pin ‚auf Masse gezogen‘ ist, also mit GND verbunden wird. In Schaltplänen und Datenblättern wird dies meistens durch einen Strich über dem Namen des Signals kenntlich gemacht, bei den APU-Boards hat man sich für eine Raute (#) hinter dem Namen des Signals entschieden.

Das Power-good-Signal ist hauptsächlich bei der Initialisierung eines Systems, also beim Einschalten der Spannungsversorgung von großer Bedeutung. In der Regel sind auf einer Systemplatine verschiedene Komponenten vorhanden, die unterschiedliche Versorgungsspannungen benötigen. Typische Spannungen sind 1.8V, 3.3V, 5V, etc.. Diese Spannungen stehen aber nicht direkt mit dem Einschalten zur Verfügung, im einfachsten Fall kann man sich das so vorstellen, dass erst verschiedene Kondensatoren geladen sein müssen, bis die Spannungsregler funktionieren und eine stabile Ausgangsspannung zur Verfügung stellen können. Es ist auch keine Seltenheit, dass eine 1.8V Spannung aus den 3.3V abgeleitet wird, also zunächst der 3.3V Rail stabil sein muss.  Man muss kein Experte sein um festzustellen, dass in dieser Phase das System noch nicht benutzbar ist.

Das Power-good Signal kann auch benutzt werden, um das System anzuhalten oder zurückzusetzen, wenn die Betriebsspannung unter eine kritische Marke fällt.

Power-on-Sequenz

Was passiert also beim Einschalten? Nun, RESET# wird auf Masse gehalten bis die Spannungsversorgung stabil und das Power-good Signal aktiv ist. Man erkennt: beide Signale lassen sich prinzipiell zusammenlegen, weil beide zunächst auf LOW liegen und nach einer kurzen Zeit HIGH gehen sollen. Die APU1 tut auch genau das.

Im einfachsten Fall kann dies über einen Kondensator erfolgen, der über einen kleinen Widerstand aufgeladen wird. Ein Problem kann hier schnelles Aus- und Wiedereinschalten sein – da der Kondensator dann noch geladen ist und kein RESET erfolgt. Wer dazu mehr wissen will sucht nach Schmitt-Trigger und schaut sich die Ladekurve eines Kondensators an.

In der Praxis überlässt man das daher meistens einem designierten Chip, der die Spannungsversorgung überwacht und ein Reset verlässlich auslöst, auch wenn die Spannungsversorgung nur kurz unterbrochen wird oder es zu einem Absinken (Brown-out) der Betriebsspannung kommt. Einige CPUs, gerade im Embedded Bereich, haben Funktionen für den RESET aber auch eingebaut, ansonsten ist das die Aufgabe des Powermanagements.

 

APU-Board Designs

Im Folgenden betrachte ich jeweils Auszüge aus den Schaltplänen der APU1C/1D und APU2C/2D.

Hinweise zum Lesen: Die Schaltpläne sind auf mehrere Seiten verteilt, daher ist es üblich die Signalnamen zu annotieren und durch die Pfeilrichtung anzudeuten, ob es sich um ein eingehendes oder ausgehendes Signal handelt. Neben dem Signalnamen sind dann noch die Seiten im pdf angegeben, auf denen das Signal noch vorkommt.

APU 1 Reset schematic

APU1C Reset schematic

Man erkennt  im ersten Schaltplan (APU1C), dass der Reset-Button an einer 4×1 Pinleiste J2 auf Pin3 lieg. Der Reset soll wohl durch einen Taster erfolgen, der Pin3 und Pin4 verbindet.

Um zu verstehen was dabei passiert, muss man aber auch auf Seite 15 nachsehen. Das Signal ist nämlich nicht nur mit dem RESET# Eingang der CPU der APU verbunden, sondern auch mit dem Power-Good Kreis. Wir sehen, dass das Reset-Signal über die (doppelte) Diode D21 geleitet wird (Erinnerung: wird auf Masse gezogen!) und auf den Eingang des Schmitt-Triggers U39 läuft. Dazwischen ist ein 10kΩ Pull-Up Widerstand zu erkennen (R284). Dieser sorgt dafür, dass bei Vorhandensein einer Versorgungsspannung das PWRGD_FC Signal auf Versorgungsspannung gezogen wird. Gleichzeitig werden über die Dioden aber auch alle anderen verbundenen Signale auf etwa 3V gebracht, auch unsere SYSRST# Leitung. (Über der Diode fallen laut Datenblatt etwa 0.3V ab.)

Der Schmitt-Trigger (Wikipedia) U39 auf der rechten Seite sorgt dafür, dass aus dem Signal PWRGD_FC wieder ein sauberes Logiksignal PWRGD_FCH wird. Das ist wichtig, weil über die Dioden D2, D4 und D21 verschiedene Signale gemischt werden und zwischen 0.8V und 2V nicht definiert ist, ob es sich um HIGH oder LOW handelt. Siehe nochmal  Logikpegel zur Verdeutlichung, mehr dazu auch gleich nochmal.

Schauen wir also, was im Fall eines (manuellen) Resets passiert: Nehmen wir also an, Pin3 und Pin4 an J2 sind verbunden. Dann wird der Kondensator C162 über den 47Ω Widerstand R135 entladen. Dies löst unmittelbar einen Reset der CPU aus, da SYSRST# direkt am Prozessor anliegt. Über die Diode D21 wird außerdem das PWRGD_FC Signal auf Masse gezogen, das vorher von R284 über 10kΩ mit der Eingangsspannung V3A verbunden ist. Damit ist dann auch PWRGD_FCH auf LOW. Hinweis: Es können hier knapp 70mA durch den Taster fließen, bei 3.3V und 47Ω, wenn auch nur kurz!

Wird der Taster losgelassen, so lädt sich der Kondensator C162 über die Diode D21 und den 10kΩ Widerstand R284 wieder auf und sobald die Schwelle des Schmitt-Triggers erreicht ist wird auch PWRGD_FCH wieder HIGH und das Board startet. Der RESET# Eingang der CPU wird in der CPU auch auf einem Schmitt-Trigger enden, so dass die CPU dann auch wieder startet. Ein Problem kann dabei sein, dass auf Grund der Diode D21 die Spannung am SYSRST#-Pin um etwa 0.3V unter der Spannung am Schmitt-Trigger der Power-good Schaltung liegt. Es kann also eventuell sein, dass die CPU schon läuft, während Speicher und Co noch außer Gefecht sind.

 

APU 2 Reset schematic

APU2 Reset schematic

 

Ein Blick in den Schaltplan der APU2 Reihe zeigt nun witzigerweise, dass SYSRST# und SYS_PWRGD nicht mehr miteinander verbunden sind – es gibt einen nicht bestückten Widerstand R357. Der Taster ist immer noch über einen Kondensator nach Masse entprellt, aber der Widerstand wurde auf 150Ω erhöht. Das begrenzt den Entladestrom über den Taster auf etwa 23mA.

Falls mir jemand erklären kann, warum sie bei den neuen Boards eine Brownout-detection einbauen und mit dem PWRBTN# Eingang des SOC verbinden und nicht mir PWRGD oder SYSRST#, würde ich mich freuen.

Externer Reset

Kommen wir nun zum eigentlichen Thema des Blogposts. Ich hatte ja angedeutet, dass ich etwas ausholen werde.

Es gibt mehrere Rahmenbedingungen, die beachtet werden müssen. Zum einen der Logikpegel des Geräts, mit dem der Reset ausgelöst werden soll, aber auch Robustheit gegen Störungen und versehentliche Fehlbedienung und elektrische Sicherheit – man will ja nicht dass die APU in Rauch aufgeht.

Zunächst sollte man sich klar werden, dass man eine galvanische Trennung zwischen APU und dem auslösenden Gerät erreichen will. Nur wenn beide Geräte am selben Netzteil und idealerweise im selben Gehäuse untergebracht sind, würde ich darauf verzichten. Schon weil ein Defekt an einem Gerät nicht gleich das andere ins Jenseits befördern soll, auch Masseschleifen können Probleme verursachen.

Dann muss man schauen, welchen Logikpegel das auszulösende Gerät hat. Einige Arduino arbeiten mit 5V Pegeln auf den GPIO Pins, andere ebenso wie der RasperryPi mit 3.3V.

Und schließlich ist noch die Robustheit der Lösung zu bedenken. Wenn das Kabel an der APU verdreht wird oder ein neues APU-Modell auf den Markt kommt, sollte die Lösung immer noch funktionieren. Und das ist letztlich der Hauptgrund, warum ich die Lösung mit einem Relais vorgeschlagen habe. Das Relais verhält sich gegenüber der APU wie ein Taster, es ist verpolungssicher, man bekommt es sehr günstig fertig aufgebaut mit einem 3.3V oder 5V Eingang und man kann es leicht erweitern für mehrere APUs oder um den Power-Button ebenfalls zu steuern.

Im Detail

Welche Möglichkeiten gibt es nun also, einen Reset extern auszulösen, also den RESET Pin auf Masse zu ziehen?

  1. MOSFET oder Bipolar Transistor
  2. Optokoppler
  3. Relais
  4. Taster der durch ein Servo betätigt wird (nur der Vollständigkeit halber)

Transistor

Eine mögliche Schaltung ist ein bipolarer npn-Transistor, bei dem der Kollektor an den RESET-Pin und der Emitter an GND angeschlossen wird. Über einen Widerstand wird der Strom in die Basis begrenzt und je nach Logikpegel und Transistortyp muss dieser berechnet werden. Nachteile sind: der Eingang ist empfindlich gegen statische Aufladung, man sollte ihn also mit einem Kondensator und Pulldown Widerstand sichern, um nicht versehentlich einen Reset auszulösen. Verwendet man einen MOSFET ist dies noch kritischer, da hier keine Ströme ins Gate fließen müssen um zu schalten.

Nachteile sind außerdem die fehlende galvanische Trennung und dass bei einem Verpolen des Steckers kein Reset erfolgen kann, da die Transistoren wie eine Diode nur in einer Richtung Strom fließen lassen. Ein Brückengleichrichter löst das Problem wegen des Spannungsverlustes über den Dioden übrigens nicht, man kann aber möglicherweise mit 2 FET eine Lösung finden, muss man aber auch ausrechnen und testen.

Hinweis: Der Transistor muss im Fall der APU1 sicher 70mA aushalten können die kurzzeitig aus dem Kondensator fließen können!

Ob die Lösung mit einer neueren APU oder einem anderen Gerät funktionieren wird: muss man im Einzelfall sehen.

Optokoppler

Ein Optokoppler bietet galvanische Trennung, ist unempfindlich gegen statische Aufladung oder offene Eingänge, allerdings ist er ebenfalls nicht verpolungssicher und man muss auch hier je nach Logikpegel den Vorwiderstand ausrechnen. Wäre in meinen Augen die sauberste Lösung, hat nur den Nachteil mit dem Verpolen – und nichts ist ärgerlicher als festzustellen, dass der remote-Reset nicht funktioniert und aus einer Lapalie wie kernel-update eine Rettungsmission mit 30 Minuten Anfahrt wird. Es sollte möglich sein zwei Optokoppler antiparallel zu schalten um eine Lösung zu finden die Verpolungssicher ist.

Aber auch hier gilt: Man muss passende Optokoppler finden, die Vorwiderstände berechnen und mit der APU testen. Bis zu 70mA sind kurzzeitig zu bewältigen und wenn andere Geräte angeschlossen werde sollen muss man gegebenenfalls wieder in die Designphase.

Taster und Servo

Für die ganz paranoiden – was als Druckluftschnellschalter in der Hochspannungstechnik existiert kann für uns nicht verkehrt sein oder so… Nein, einfach nur nein.

Relais

So sehr es mich wurmt, unter den gegebenen Voraussetzungen ist eine Lösung mit einer fertigen Relais-Platine mit Jumper um von 3.3V zu 5V Eingang umzuschalten die einfachste, robusteste und billigste Lösung.

Es ist kein Verpolen möglich, die APU wird wie vorgesehen von einem Taster in Form der Relaiskontakte zurückgesetzt, man kann auch andere Geräte damit zurücksetzen ohne vorher den Schaltplan zu studieren und ganz wichtig: die Platinen gibt es schon fertig für sehr kleines Geld zu kaufen.

Fazit

Nicht jede Lösung ist elegant, wenn sie robust sein muss – und manchmal sind 80% Lösungen die in 100% der Fälle funktionieren besser, also 100% Lösungen.

 

 

Heute ist mir hier wieder einmal ein Stück Hardware in die Finger gefallen und hat sich dort spontan desintegriert – das Gehäuse war aufgeplatzt, also habe ich einen Blick in das Innere gewagt.

Es handelt sich um ein Netzteil mit 12V/2A – wenn man dem Typenschild glauben schenken mag. Gekauft hatte ich es vermute ich mal als Ersatz für eine externe Festplatte aber bisher noch nicht benutzt. Und das war vielleicht auch gut so.

Auf die inneren Werte kommt es an!

Hier also meine Eindrücke vom ‚Teardown‘ – Vorab: Ich wundere mich wirklich, warum es nicht häufiger zu Wohnungsbränden oder Stromschlägen kommt.

Das Typenschild lässt schon einmal nichts gutes erahnen. Bei der Stromaufnahme ist das Ampere klein geschrieben, und rechnet man nach kommt man auf 40 Watt (100*0.4A) maximale Leistungsaufnahme – für 24 Watt am Ausgang.  Die Annahme dabei ist, dass 0.4 der maximale Strom sind und der tritt bei der geringsten Betriebsspannung auf. Aber gut, als maximum rating geht das von mir aus durch. Viel wichtiger aber ist: Es sind keinerlei Prüfzeichen vorhanden, einzig CE – auch ‚China Equipment‘ genannt – doch das bringt der Hersteller selbst an.

Betrachtet man dann die Platine wie sie im Gehäuse liegt fällt sofort auf, dass sie offenbar für etwas anderes gebaut wurde – sie ist viel zu klein und es ist ein Westernstecker verbaut für den keine Öffnung im Gehäuse existiert. In Position gehalten wird das ganze von Schaumstoff, der zwischen Deckel und Platine geklemmt ist und diese auf das Plastik pressen. Die Kabel verschwinden auf der Unterseite und das lässt nichts Gutes erahnen.

Und richtig, dreht man die Platine um offenbart sich das ganze Grauen. Die Netzspannung wird über zwei sehr dünne Drähte mit nur wenigen Kupferadern die schnell brechen zur Platine geführt, es gibt keine Isolierung auf der Unterseite, zu lange Drähte von der Platine können die Pins des Steckers direkt berühren. Löst sich einer der Anschlussdrähte kann die Netzspannung über das lose Ende direkt auf den Sekundärteil gelangen. Zudem sind die beiden blauen Drähte so lang, dass sie unter dem Sekundärteil verlaufen. Da die Platine vom Schaumstoff unter Druck gehalten wird, werden die beiden Zuleitungen direkt auf die Ausgangspins des Übertragers gedrückt. Doch damit nicht genug.

Bei näherem Hinsehen kann man erkennen, dass die Kabel für die 12 V auf die Pins des Ausgangskondensators gelötet wurden. Dabei sind sie so lang dass sie überstehen, die 12V Leitung kommt einem SMD Widerstand bedenklich nahe und kann diesen leicht berühren – damit landen dann 12V irgendwo. Mechanisch stabil ist das ganze natürlich auch nicht – die Drähte sind nicht durch die Platine geführt, die Löststellen schlecht ausgeführt.

Die Highlights habe ich auf den letzten beiden Bildern markiert – offenbar musste ein Bauteil gebrückt werden um die 12V zu bekommen, auf dem Western Stecker liegt die Ausgangsspannung immerhin über eine Sicherung an. ein anderer SMD Widerstand wurde mit einem zweiten Huckepack gebrückt und es gibt einzelne Lotperlen die zu Kurzschlüssen führen können.

Eine Sicherung auf der Primärseite habe ich in dem Netzteil nicht gefunden, nur einen 10 Ohm Lastwiderstand am Eingang, der etwa 1.5 Watt an Leistung verbraten kann.

Ich bin immer wieder erschrocken, wenn ich daran denke wie viele von diesen Geräten irgendwo unter Schreibtischen im Dauerbetrieb sind.

Fazit: Finger weg von billigen Netzteilen!

Das Fehlen von VDE, TÜV und sonstigen Prüfzeichen ist in meiner Erfahrung ein starkes Indiz für gefährliches Equipment.

Im vorliegenden Fall hat die Platine selbst ein Prüfzeichen und sie ist bis auf die fehlende Sicherung auch sicher aufgebaut – nur alles drumherum und die nachträglichen Änderungen machen das zunichte. Ich habe derartiges schon häufiger erlebt. Inklusive einem Netzteil, bei dem die alten Anschlusskabel nur abgeknipst wurden und neue darübergelötet.

Es besteht nicht nur die Gefahr dass die daran angeschlossenen Geräte kaputt gehen, es kann auch zu Feuer oder Stromschlägen kommen.

Gibt es da keine Gesetzte gegen?

Doch, die gibt es. Verkauft bzw. in Verkehr gebracht werden dürfte das Gerät in der EU nicht, meist handelt es sich um Importe über das EU Ausland, wo teilweise keine Kontrollen stattfinden.

Das in Berlin zuständige Amt für die Produktsicherheit erklärte mir auf Nachfrage, dass diese Waren z.B. oft über England eingeführt werden und dort werde schlicht nicht auf Produktsicherheit kontrolliert. Von dort kam auch meine LED-Lampe die unisolierte 230V auf der Außenseite anliegen hatte.

Letztlich kommt es auf die Verbraucher an: Wenn man immer nur auf den Preis achtet setzt man sich und seine Umgebung nicht unerheblichen Gefahren aus, produziert unnötigen Elektroschrott und hat auch nur für kurze Zeit etwas von den Produkten.

Seit einiger Zeit bietet die Initiative letsencrypt.org nun kostenlose SSL-Zertifikate an und nachdem sich die anfängliche Verwirrung über die benötigten Rechte des ACME-Clients gelegt haben, sieht das ganze sogar halbwegs brauchbar aus. Was liegt also näher, das ganze mal auszuprobieren – eigentlich nicht viel.

(mehr …)

I did a best-effort backport of the wheezy patches against GHOST (CVE-2015-0235) for Debian GNU/Linux squeeze-lts, as is seems there are not official packages yet available. Use at your own risk!

Ich habe einen ‚best effort‘ Backport der wheezy patches gegen GHOST(CVE-2015-0235) für Debian GNU/Linux squeeze-lts gebaut, da es scheinbar bisher keine offiziellen Pakete gibt:

https://mail.streibelt.net/secure-downloads/squeeze-glibc/

update: the patches are obsolete – official packages are available now!

The following text is a blogpost explaining my Diploma Thesis and the paper Exploring EDNS-Client-Subnet Adopters in your Free Time published in 2013.

The article was intended for publication in the corporate blog of one of the CDNs we studied, but after verizon bought the CDN the article never got published. (mehr …)

Getagged mit: , ,

I recently bought a „LogiLink USB2.0 Video Grabber with Snap Shot“ – Model VG0005B v.1.0 – (EAN 4052792002102)

When I bought it I did not realize, that it is officially not supported in Linux (also see http://www.linuxtv.org/wiki/index.php/SilverCrest_USB_2.0_Video_Grabber_SVG_2.0_A2) – because I missed some part of the product name when searching for support.

Kernel fun

After spending the whole day trying to recompile a new kernel, stumbling over various oddities, it finally worked.
capture

I don’t know how such drivers can be published, but the nvidia drivers at first would not compile, stating that my 3.0.x kernel is not compatible (only 2.6 an newer are supported, you know). The reason in pseudo code: if [ major -lt 2 -o minor -lt 6 ]; … yes, thats an OR in the middle and yes, the 0 in 3.0 is smaller than 6.

Also all the version magic included in modules is p.i.t.a. when you try to compile one module for a destirbution kernel – so I recompiled the whole kernel and modules because although my module had been built fine, it failed to load the video grabber module because the version magic did not match.

Getting it to work

My idea was, that there are not many reference designs out there for this chip and that the manufacturer hopefully does not reinvent the wheel in his chips either. And it seems I was right.

What is needed for this to work is a 2 line patch to the cx231xx driver to tell it that the chip is supported and what configuration to use:

So in drivers/media/video/cx231xx/cx231xx-cards.c go to struct usb_device_id cx231xx_id_table[] and add these two lines e.g. at the beginning of the definition:

        {USB_DEVICE(0x1D19, 0x6109),
         .driver_info = CX231XX_BOARD_PV_XCAPTURE_USB},

Here the lucky part is, that the LogiLink people use the exact same design thats used by the board mentioned above. Caveat: I have not tested the audio part.

And yes, I will now try to get that upstream and included into the kernel.

Update: capturing audio crashed my systen…

Manchmal gibt es Tage, an denen mir richtig bewusst wird, warum ich seit über 15 Jahren versuche überall wo es möglich ist freie Software einzusetzen, mit allen Vor- und Nachteilen.

Ich habe in der vergangenen Woche gleich mehrere schöne Erlebnisse mit dem Ökosystem gehabt, dass sich rund um Linux und freie Software in den vergangenen Jahren etabliert hat. Und ich wünsche mir, dass dies auch weiterhin so bleibt und noch viele andere Menschen so positive Erfahrungen mit FOSS machen dürfen.

Claws

Zum Einen war da ein kleine Problem mit Claws, dem Mailclient den ich derzeit benutze. Man kann claws auf der Kommandozeile so aufrufen, dass ein neues Compose Fenster aufgeht, das eine auf der Kommandozeile übergebene Email samt Anhang enthält. Leider wurde dabei der Account nicht automatisch anhand der Absenderadresse ausgewählt, so dass die Email dann im Sent-Ordner eines anderen Accounts landen konnte.  Im IRC-Channel der Developer dauerte es dann nicht einmal eine halbe Stunde vom Melden des Problems bis ich einen Patch hatte. Nachdem ich diesen getestet hatte, wurde die Änderung auch schon direkt in Claws übernommen und wird im nächsten ist im aktuellen Release enthalten sein. Undenkbar bei proprietärer Software.

Terminator

Dann gab es da einen Bug in Terminator, den von mir exzessiv genutzten Terminalemulator. Beim De-Maximieren wurde das Fenster bis zur Unkenntlichkeit verkleinert. Dank des öffentlich zugänglichen Debian Bugtrackers und der Möglichkeit per apt-get source den Quellcode zu bekommen, konnte ich zum Einen jemanden mit demselben Problem finden und dann auch noch selbst einen Hotfix bauen, der das Problem erstmal behoben hat. Da ich außerdem selbst im Bug diesen Hotfix beschreiben konnte ist den Entwicklern geholfen und dem anderen Anwender eventuell auch. Undenkbar bei proprietärer Software.

CMS-Suche

Für eine Webseite suche ich derzeit nach einem neuen CMS mit guter Unterstützung für mehrsprachige Seiten – was sich als gar nicht so kleines Problem darstellt. Ich konnte an einem einzigen Tag 5 verschiedene Systeme installieren und im irc mit dem Entwicklern die Features diskutieren. Und dabei ist es kein Tabu die verschiedenen Systeme direkt zu vergleichen und von den Entwicklern von System A den Hinweis zu bekommen sich doch mal C anzusehen. Und das alles ganz ohne Probelizenzen oder Supportvertrag. Undenkbar bei proprietärer Software.

Linuxkernel

Schon etwas länger ist es her, als ich zufällig über einen Fehler im Linuxkernel stolperte. Auch hier gab es die Situation, die ich bei Claws oben beschrieben hatte. Nur 4 Stunden nachdem ich den Bug im Ticketsystem geöffnet und mich im irc channel des Projekts gemeldet hatte, gab es einen Fix und er war im nächsten Release des Kernels enthalten. Ihr wisst schon was jetzt kommt: Undenkbar bei proprietärer Software.

Direkter Draht aka Rotes Telefon

Was mich bei alledem am meisten fasziniert ist, dass man per irc und mail eigentlich überall noch direkten Kontakt mit den Entwicklern bekommt. Diese können mit mir als Kunde direkt sprechen und Rückfragen stellen. Vor genau diesem Kontakt aber scheinen andere Angst, ja geradezu Panik zu haben. Ich frage mich woher das kommt.

Bedrohungen

Kommen wir zum zweiten Teil meines Titels. Was bedroht dieses Ökosystem?

In den vergangenen Monaten kämpfte ich mit einem Storagesystem eines größeren Herstellers und der proprietären Variante von Xen und musste festellen, dass hier doch einiges im Argen liegt.

Warum das proprietäre Xen?

Nun, das ist gewissen Rahmenbedinungen geschuldet, denn natürlich ging dem eine Evaluation voraus, bei der die Mitbewerber aus verschiedenen Gründen ausschieden. Sei es dass nicht verhindert wurde das zwei virtuelle Maschinen auf denselben iSCSI Storage zugriffen und damit das Dateisystem nachhaltig zerstörten oder das die Verwaltungssoftware einfach abstürzte. Beides ist in einer Produktivumgebung auf der alle zentralen Dienste laufen sollen nicht hinnehmbar.

Wir entschieden uns also für das proprietäre XenCenter, von dem es eine kostenlose Lizenz gibt wenn man gewisse Features nicht benötigt. Und ich muss sagen das funktioniert sogar relativ gut alles.

Aber was tötet nun FOSS?

Es sind direkt oder indirekt Firmen wie RedHat und SuSE/Novell. Und hier kommen wir zu einem zweischneidigen Schwert. Denn einerseits fördern beide direkt durch die Finanzierung und indirekt durch ihre Marktmacht die Entwicklung vieler Projekte und machen das Eine oder Andere gerade erst möglich. Schließlich müssen auch die Entwickler von Freier Software jeden Tag etwas essen und ein Dach über dem Kopf ist der Softwareentwicklung im Allgemeinen auch eher zuträglich.

Are you (in) the Enterprise?

Aber dann versucht man mit dem Hersteller eines Storage Systems nachzuvollziehen, warum denn die Performance weit hinter den Erwartungen bleibt. Und alles was diesem Hersteller einfällt ist an einem bestimmten Punkt die Probleme auf das eingesetzte Debian zu schieben – denn man unterstützt nur RedHat Enterprise Linux oder SuSE. Und natürlich keine der kostenlosen Varianten wie OpenSuSE oder CentOS.

Und dann stellt man fest, dass die Webseiten beider ‚Hersteller‘ es einem nicht einfach machen so etwas wie eine Testlizenz zu bekommen – jedenfalls nicht ohne die Eingabe persönlicher Daten und Emailadressen.

Binäres Rauschen

Fatal ist, dass der Hersteller zudem einige seiner Treiber tatsächlich nur für die genannten Plattformen anbietet. In der Praxis sieht das dann so aus, dass Binaries des device mappers ersetzt werden. Diese und die zugehörigen Bibliotheken wandern dann in das System und lassen sich natürlich auf anderen Systemen nicht nutzen. Ob und was der Hersteller an der Software geändert hat ist natürlich auch nicht dokumentiert. Anhand der Copyrighthinweise kann man aber erahnen, dass schlicht nur neuere Versionen des devicemappers auf die teilweise antiken aber voll unterstützten Enterprise-Umgebungen portiert wurden.

Schade ist auch, dass der Hersteller des Storage bei der Unterstützung der Plattformen so engstirnig vorgeht, dass sich sogar die plattformunabhängige Verwaltungssoftware (Java!) nur unter den genannten Betriebssystemen installieren lässt, was nicht nur an der Verfügbarkeit nur als rpm-Archiv liegt. Man könnte also wenn man wollte – man will nur nicht.

Fazit

Nicht nur als Privatanwender kämpft man immer wieder mit der Ignoranz vieler Hersteller – auch im so genannten ‚Enterprise‘-Markt gibt es massive Probleme mit Herstellern, die keinen offenen und transparenten Entwicklungsprozess pflegen. Das diese Abschottung aber gerade die Vorteile der von den Herstellern genutzten  Plattformen unterminieren ist ihnen scheinbar nicht klar oder schlicht egal. So ist es weder bei  dem Hersteller des Storage noch bei Xen möglich in irgendeiner Form direkt mit Entwicklern zu sprechen, geschweige denn Informationen zu erhalten, die nicht durch den Konzern freigegeben sind.

Und hier lauert im  ‚Enterprise‘-Markt eine Bedrohungen, die uns die kommenden Jahre denke ich noch beschäftigen wird. Die eigentlich offenen und freien Systeme werden vernagelt und verrammelt,  Treiber durch die Hersteller weiterhin nur als binärer Müll weitergegeben und Support für Fremdsysteme verweigert. So kann keine Innovation entstehen.

Schade eigentlich.

 

Aus aktuellem Anlass..

Vollmar.net hat ein Netz innerhalb von 31.0.0.0/8 – warum erwähne ich das heute? Ich betreibe für einige Domains einen seconndary nameserver – und einer dieser Kunden zog gerade zu Vollmar um.

Plötzlich kamen aber nicht mehr alle Zonenupdates durch, die Fehlermeldung lautete:

 

soa_query: zone xxxx/IN/external-in: dns_request_createvia2() failed: address blackholed

Hintergrund ist, dass der bind dort eine Uralte default blacklist hatte für private Netze, etc.

Eine whois-Orgie später weiss ich nun, das folgende Netze offenbar seit einiger Zeit aktiv sind, und nicht mehr dort hinein gehörten:

  • 2.0.0.0/8
  • 5.0.0.0/8
  • 14.0.0.0/8
  • 23.0.0.0/8
  • 27.0.0.0/8
  • 31.0.0.0/8
  • 36.0.0.0/8
  • 37.0.0.0/8
  • 42.0.0.0/8
  • 46.0.0.0/8
  • 49.0.0.0/8
  • 50.0.0.0/8
  • 100.0.0.0/8
  • 101.0.0.0/8
  • 105.0.0.0/8
  • 107.0.0.0/8
  • 175.0.0.0/8
  • 176.0.0.0/8
  • 177.0.0.0/8
  • 180.0.0.0/8
  • 181.0.0.0/8
  • 182.0.0.0/8
  • 183.0.0.0/8
  • 223.0.0.0/8

Also, updated mal eure bind config 😉

 

Wer sich diese Frage schon häufiger gestellt hat, freut sich vielleicht, dass ich am 22. Februar genau dazu nochmal einen Vortrag im AFRA Berlin halten werde. Geplant ist der Start so gegen 19:00.

Beim AFRA handelt es sich weder um die Kartoffel noch die Schutzpatronin der Stadt Augsburg sondern den rauchfreien Hackerspace in Berlin, siehe auch http://hackerspaces.org/wiki/AFRA

Worum wird es inhaltlich gehen? Gute Frage. Beim letzten Mal artete der Vortrag in eine 3h-Session aus, die DNS, SMTP, IMAP, POP3, SSL und noch diverse andere Protokolle und Gemeinheiten beleuchtet hat.

Damit das ganze nicht zu langweilig wird verteile ich wieder rote und grüne Karten, die während des gesamten Vortrags zum Beeinflussen der Tiefe in den Einzelthemen genutzt werden sollen.

Daher richtet sich der Inhalt ziemlich nach dem anwesenden Publikum und kann beliebig ausgedehnt werden.

 

Wir haben bei der Freitagsrunde von diesem Modell zwei Server in Betrieb. Sie dienen uns als physikalischer Host für eine Reihe von virtuellen Maschinen.

Aber wirklich glücklich sind wir mit ihnen nicht.

Der Serviceprozessor

Die Geräte haben einen integriertes Managementmodul. Leider Segfaulten die Linuxtools dazu vor sich hin und im Kernellog kommen auch lustige Meldungen zu Tage. Immerhin findet check_mk hin und wieder die Temperatursensoren – was in einem klimatisierten Rechenzentrum wenig informativ ist – und bedingt durch das hin und wieder des Erkennens zu vielen Mails von Icinga führt. ’18 Grad OK – kein Sensor gefunden – 18 Grad OK – kein Sensor…‘.

Im Kernellog findet sich derweil soetwas:

[228481.713931] IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 35, got netfn 5 cmd 2d
[228601.715547] IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 35, got netfn 5 cmd 27
[228661.769703] IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 35, got netfn 5 cmd 2d

Und die Ethernetschnittstelle des Controllers bekommt auch keinen Link.

Das Ethernet

In den Geräten verbaut sind zwei Gigabit-Ethernet NICs:  „Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)“ – Dummerweise vergisst eth0 fast sofort den Promiscious Mode – so dass der Betrieb einer Softwarebridge für xen unmöglich wird, weil die Pakete an die virtuellen Maschinen auf Grund der anderen MAC-Adresse sofort gefiltert werden. Und nein, die Hardware meldet nicht, dass sie den Promiscious Mode verlassen hat. Mit der zweiten On-Board-Karte funktioniert es. Treiber: tg3.

CPU complex error

Diesen hätten wir auch noch anzubieten. Taucht im Log des ILOM im BIOS auf – die Kiste steht danach. Grund unbekannt – man soll mal alle Firmwares des Servers updaten.

Rebooting due to unexpected NMI at B0ED:F000

Der kam bei uns zustande, wenn auf der Festplatte der GRUB vermutlich nicht korrekt installiert war. Szenario: Raid1, eine Platte ist defekt und wird ausgetauscht, der Versuch von der verbliebenen funktionierenden Platte zu booten (Software Raid) scheitert mit dieser Meldung. Der Server steht danach natürlich und rebootet nicht.

Das hat mich heute abend knapp 3 Stunden Lebenszeit im Rechenzentrum gekostet. Das Booten eines grml von einem USB-Stick war dann auch eine Herausforderung – bis sich ein Bootmenü vom Stick zeigte dauerte es 2 Minuten, die geduldig vor einem schwarzen Bildschirm gewartet werden musste – ein zweiter USB-Stick wurde vom Bios falsch erkannt und wollte gar nicht booten, weil angeblich auf dem image Dateien zum boot fehlten.

Finally{}

Finden tut man zu all diesen Problemen im Netz natürlich wenig bis nichts. Daher mal dieser kurze Artikel… Auch wenn die Hardware auf Grund des Alters kaum noch eingesetzt werden sollte – aber wer weiss.

Alles in allem überzeugt der Server mich nicht wirklich – wir haben einen wesentlich älteren Server im Dauerbetrieb der am Anschlag läuft und wesentlich stabiler daherkommt was derartige Zicken angeht: P4SBR supermicro.