Archiv des Autors: Daniel Weber

Überwachung, Shitstorms und Nerds

In seinem Blog kritisiert Peter Tauber dass „unsere Freiheit durch Trolle und böse Menschen im Netz weit mehr eingeschränkt [wird], als durch die vermeintlichen Aktivitäten der Geheimdienste“. Er bezieht sich dabei auf diesen Tweet von Buschsalat:

Nur sind die ausufernde Überwachung durch Geheimdienste und das Verhalten von Trollen im Netz nicht sonderlich gut zu vergleichen:

  1. Die Menge der betroffenen Menschen unterscheidet sich wesentlich:
    Die ausufernde Überwachung durch Geheimdienste betrifft jeden, der telefonisch oder über das Internet kommuniziert, selbst wenn er dabei nur Inhalte konsumiert, recherchiert etc. und selbst nicht als Inhalts- oder Dienstanbieter bzw. „Sender“ (Blog, Twitter, Foren, Usenet, etc.) auftritt.
    Angriffe durch Trolle hat hingegen nur derjenige zu befürchten, der selbst als Inhalts- oder Dienstanbieter auftritt, weil er dadurch erst für andere (außer die vorgenannten Dienste) im Netz „sichtbar“ wird.
  2. Die damit verbundenen Nachteile unterscheiden sich wesentlich:
    Aktionen einen Trolls können ohne Zweifel sehr belasten, allerdings kann man sich ggf. durch die Möglichkeiten des Rechtsstaats dagegen zur Wehr setzen.
    Von der Überwachung durch einen Geheimdienst erfährt der Betroffene nichts, kann also auch keine Gegenmaßnahmen ergreifen und selbst wenn, hat der eigene Rechtsstaat gegen einen fremden Dienst keine Handhabe (Stichwort Merkelphone) und für einen eigenen Dienst „geeignete“ Schlupflöcher geschaffen (Stichwort G10-Gesetz).

Nun noch ein paar Worte zu Peter Taubers Sicht des Nerds: Ein richtiger Nerd bezeichnet niemanden als „gestrig“ oder „dumm“, nur weil er die neuen Medien nicht so gut wie seine eigene Westentasche kennt. Jeder hat sein Spezialgebiet und das ist auch gut so. Ein Nerd reagiert erst dann ungehalten, wenn sich jemand ohne entsprechende Kenntnisse in das Fachgebiet des Nerds einmischen möchte.

Cyrus: „SASL(-1): generic failure: checkpass failed“

Nachdem es mir bei fast jedem Serverumzug wieder passiert, schreibe ich es doch mal so auf, dass ich mich beim nächsten Mal erinnere, es finde oder zumindest Google es findet:

Gegeben ist ein Debian/Postfix/Cyrus-Virtual-User-Setup mit MySQL-Datenbank und Authentifikation über saslauthd. Dass Debian in einem „chroot jail“ läuft und man daher das saslauthd-Socket in /etc/default/saslauthd von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd umbiegen muss (und die entsprechenden Verzeichnisse mit passenden Berechtigungen auch anlegen sollte), daran habe ich mich mittlerweile gewöhnt. Was ich jedoch regelmäßig vergesse, ist, dass man dann auch /var/run/saslauthd als Symlink auf /var/spool/postfix/var/run/saslauthd anlegen sollten… sonst kann man sich herrlich lang die Finger wund suchen.

Für elegantere Lösungen bin ich jederzeit offen.

Update 02.03.2014:

Bei Debian Wheezy ist der Symlink von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd nach jedem Reboot wieder weg, weil /var/run seinerseits nur noch ein Link auf /run ist, was wiederum als tmpfs nach jedem Neustart leer ist. Am besten legt man sich in /etc/rc.local eine Zeile an, die den Symlink wiederherstellt.

Für elegantere Lösungen auch dafür bin ich offen.

Erste Fahrt mit einem Stadler Flirt 3

Vor etwa drei Jahren schrieb ich darüber, dass Veolia Verkehr die Ausschreibung des E-Netz-Rosenheims gewonnen hat. Seit vergangenen Sonntag 15.12.2013 fährt die Bayerische Oberlandbahn – Tochter von Veolia Verkehr – unter dem Markennamen Meridian die Regionalzüge im E-Netz-Rosenheim, muss dabei aber leider noch auf Ersatzgarnituren diverser Bahnen (DB-N-Wagen, ÖBB-CityShuttle, ODEG-KISS, OLA-Talent, FLEX, …) zurückgreifen, da Stadler leider noch nicht alle Flirt 3 Triebzüge fertiggestellt hat. Selbst die Zulassung für die bereits ausgelieferten Züge wurde erst am 13.12.2013 erteilt, also quasi in letzter Sekunde.

Die ersten Betriebstage sorgte der Meridian hauptsächlich für schlechte Presse: Mit den eigenen Neufahrzeugen traten wohl diverse Kinderkrankheiten auf aber auch die älteren, ausgeliehenen Fahrzeuge haben ihre Altersleiden demonstriert. Vor dem Hintergrund war ich gespannt, wie meine heutige „Probefahrt“ mit dem M 79039 von München Hbf ab 18:44 nach Grafing Bf an 19:06 verlaufen (planmäßig mit einem neuen Flirt) würde.

Zuerst zum Fahrzeug: Der Innenraum war sauber, der Sitzabstand sowie die Form und Polsterung der Sitze für mich angenehm, die Gepäckablage ist ausreichend groß dimensioniert um meinen gut gefüllten Rucksack zu verstauen. Erstaunlicherweise waren sogar einige weitere Fahrgäste im Zug, die die Gepäckablagen genutzt haben. In den S-Bahn-Zügen oder SOB-Triebwagen werden diese aus mir nicht nachvollziehbaren Gründen eher gemieden. Ich fand am Platz sogar zwei zugängliche Steckdosen, der Zug ist also Nerd-kompatibel. Erstmal in Fahrt fallen jedoch noch Kinderkrankheiten auf: Selbst bei kleinsten Kurven noch in der Haupthalle des Münchner Hbf sind deutliche „Atemgeräusche“ – ich vermute von den Schlingerdämpfern – zu hören. Bei höheren Geschwindigkeiten ist ein deutliches Schlingern des Fahrzeugs mit Wanken des Wagenkastens zu spüren.

Zur Fahrt: Los ging es am Hauptbahnhof bereits mit +7, wobei die BOB dafür nichts konnte: Ein ÖBB-Railjet wurde vor unserer Nase – die Fahrstrasse kreuzend – gemütlich in die Abstellung geschoben. Ab München Ost standen dann tatsächlich einige Fahrgäste, wobei mindestens 1/3 der Sitzplätze frei war… aber manche Leute stehen scheinbar lieber, wenn sie eine Zweierbank nicht für sich alleine haben können. Nachdem die bisherigen 6-N-Wagen-Garnituren nur 540 Plätze boten, eine Flirt-3-Doppeltraktion nun aber 666 Plätze bietet, wäre es auch verwunderlich. Die Verspätung haben wir bis Grafing Bahnhof nicht aufgeholt, aber mein Übergang zur S-Bahn war ausreichend dimensioniert.

Fazit: Ich hoffe, dass Stadler am Schlingern der Fahrzeuge noch etwas verbessern kann und ich drücke der BOB die Daumen, dass die Kinderkrankheiten mit den neuen Fahrzeugen schnell vergehen und die fehlenden Fahrzeuge ausgeliefert werden, damit die Nachteile der Leihgarnituren sich nicht allzulange bemerkbar machen.

Heap-Corruption mittels „gflags“ untersuchen

Heap-Corruption-Fehler (Buffer-Overruns, Double-Frees, …) sind naturgemäß sehr schwer zu debuggen, da der eigentliche Fehler i.d.R. lange vor dem tatsächlichen Programmabsturz stattgefunden hat. Windows bietet für diesen Fall jedoch eine Hilfestellung an, sofern man das Programm „gflags“ aus den „Debugging Tools“ installiert hat:

gflags.exe -p /enable binary.exe [/full]

Das Programm binary.exe wird von nun an in einem Modus ausgeführt, bei dem jede unerwünschte Veränderung des Heaps sofort zu einem Absturz führt. Dadurch kann man der Ursache per Debugger oder Dump-Analyse deutlich schneller auf den Grund gehen.

Der Speicherverbrauch ist in diesem Modus etwas höher und die Arbeitsgeschwindigkeit etwas geringer. Beendet wird dieser Modus wieder mit folgendem Befehl:

gflags.exe -p /disable binary.exe

How-To: IPv6-Adressen der Telekom-DNS-Resolver ermitteln (Update am 27.12.2013)

Bei Twitter tauchte neulich die Frage nach den IPv6-Adressen der Telekom-DNS-Resolver auf. Zufälligerweise habe ich mir die Liste der Resolver wenige Wochen zuvor selbst zusammengesucht. Da die Liste nicht offiziell ist und sich auch möglicherweise ab und an ändert, hier eine kleine Anleitung, wie man sich die Liste selbst ermitteln kann.

Vorab sollte man sich anschauen, wie es mit den IPv4-Resolvern aussieht: Diese sind identisch mit den regionalen HTTP-Proxy-Servern, d.h. wenn man sich die IP-Adressen zu www-proxy.t-online.de ermittelt, hat man die Liste der IPv4-Adressen der Resolver. Per Reverse-Lookup kann man zu jedem Resolver auch recht gut den Standort bestimmen. Das Namensschema der Server ist hier sehr aussagekräftig.

Genauso kann man sich über www-proxy.t-online.de die Liste der IPv6-Adressen der Resolver ermitteln, allerdings kann man dazu nicht einfach per Reverse-Lookup die Standorte bestimmen… mit einem Trick geht es aber doch:

Man nehme einen Webserver mit IPv6-Anbindung und führe nun von einem Telekom-Anschluss aus über die IPv4-Proxy-Adressen Aufrufe auf den Webserver mit IPv6-Anbindung durch. Da die Proxies ihrerseits Dualstack-konform ausgehend wenn möglich IPv6 verwenden, kann man nun im Logfile des Webservers bequem die IPv6-Adresse zum jeweiligen regionalen Proxy zuordnen (genaugenommen sind es je Standort mehrere, da vermutlich ein Load-Balancing zum Einsatz kommt). Leider entsprechend die abgehenden IPv6-Adressen der Proxies nicht 1:1 der hinter www-proxy.t-online.de stehenden Adressen, jedoch kann man über das /64-Prefix den richtigen finden.

Update am 27.12.2013

Zwischenzeitlich hat die Telekom die DNS-Resolver wohl von den HTTP-Proxies getrennt, als DNS-Resolver für IPv6 gelten nun folgende Server:

  • b-dnslb-a01.isp6.t-ipnet.de [2003:180:2::53]
  • d-dnslb-a01.isp6.t-ipnet.de [2003:180:2:1000::53]
  • do-dnslb-a01.isp6.t-ipnet.de [2003:180:2:2000::53]
  • hh-dnslb-a01.isp6.t-ipnet.de [2003:180:2:3000::53]
  • h-dnslb-a01.isp6.t-ipnet.de [2003:180:2:4000::53]
  • k-dnslb-a01.isp6.t-ipnet.de [2003:180:2:5000::53]
  • l-dnslb-a01.isp6.t-ipnet.de [2003:180:2:6000::53]
  • m-dnslb-a01.isp6.t-ipnet.de [2003:180:2:7000::53]
  • f-dnslb-b01.isp6.t-ipnet.de [2003:180:2:8000::53]
  • f-dnslb-a01.isp6.t-ipnet.de [2003:180:2:8100::53]
  • n-dnslb-a01.isp6.t-ipnet.de [2003:180:2:9000::53]
  • s-dnslb-a01.isp6.t-ipnet.de [2003:180:2:a000::53]
  • ul-dnslb-a01.isp6.t-ipnet.de [2003:180:2:b000::53]

1&1 – IPv6 für dedizierte Server

Bei 1&1 konnte man bereits relativ früh auf halboffiziellem Weg einen 6in4-Tunnel bekommen, um dem eigenen Mietserver IPv6-Unterstützung zu „spendieren“. Vor einigen Monaten tauchten dann im „Control-Center“ Optionen für IPv6-Adressen auf, die jedoch deaktiviert waren und nach einiger Zeit auch wieder verschwunden sind. Außerdem kann man seit einiger Zeit auf dem besagten halboffiziellen Weg ein natives IPv6-/56-Netz erhalten, für das man aber leider noch kein Reverse-DNS konfigurieren kann.

Durch Zufall (bei einem meiner Server war der IPv4-Reverse-DNS-Eintrag plötzlich wieder auf der „Werkseinstellung“) habe ich nun gesehen, dass bei manchen dedizierten Servern nun bereits IPv6-Netze im „Control-Center“ erscheinen und konfigurierbar sind. Wenn nur endlich die Access-Provider mit einem ernsthaften IPv6-Rollout voran kämen…

Update 6. Juli 2013:

Mittlerweile sind bei allen unter meiner Obhut stehenden Mietserver bei 1&1 die IPv6-Daten im „Control-Center“ konfigurierbar. Das auf dem halboffiziellen weg beantragte /56-Netz wurde übernommen.

Telekom: Schrittweiser Rückzug von der Drosselung oder nur ein Ablenkungsmanöver?

Nachdem die Telekom bereits am 8.5.2013 einen ersten Rückzieher gemacht hat und auch für die Zeit ab 2016 echte, ungedrosselte Flatrates gegen Aufpreis versprochen hat, folgte heute ein weiterer Rückzieher: Statt auf 384 KBit/s soll laut einer aktuellen Pressemitteilung nur noch auf 2 MBit/s gedrosselt werden. Auf den ersten Blick ein deutliches Entgegenkommen, schaut man genauer hin stellen sich aber auch neue Fragen:

  • Ist das vielleicht nur der Versuch, einen Teil der Kunden, die man mit dem fadenscheinigen Fairness-Argument nicht über den Tisch ziehen konnte, zu beruhigen und damit die Stimmen aus der Netzgemeinde, die eine gesetzliche Festschreibung der Netzneutralität wünschen, zu schwächen?
  • Ist das eine Reaktion auf die Bedenken der Bundesnetzagentur? Diese hatte angedeutet, dass 384 KBit/s möglicherweise nicht mehr als Breitbandanschluss betrachtet werden können.

Auf jeden Fall ist die Ankündigung, nur auf 2 MBit/s zu drosseln, nichts wert, solange sie nicht in die Leistungsbeschreibung aufgenommen wurde. Die Telekom hat in den letzten Jahren zu oft Versprechen gebrochen bzw. getätigte Aussagen später nicht mehr eingehalten. Darüberhinaus sollte die Netzgemeinde trotzdem am Ziel der gesetzlichen Festschreibung der Netzneutralität festhalten: Das hindert die Telekom nicht daran mittels einer moderaten Drossel mehr Einnahmen zu generieren, verhindert aber die Aufsplitterung des bisherigen Internets in eine Schar von managed Services.

Drosselgeiseln der Telekom

Nachdem seit dem 22. April 2013 offiziell ist, dass die Telekom bei Ihren Call & Surf und Entertain Tarifen die Übertragungsgeschwindigkeit ab einem bestimmten Volumen auf nur noch 384 KBit/s drosseln möchte, hat man versucht das losgetretene PR-Desaster wieder abzumildern und dabei ein paar interessante Zahlen genannt, mit denen ich im folgenden etwas rechnen möchte. Zuerst eine Zusammenfassung der von der Telekom auf verschiedensten Wegen mitgeteilten Zahlen:

  • Es sollen 8 Milliarden Euro in den Netzausbau investiert werden, deswegen muss man Intensivnutzer stärker zur Kasse bitten.
  • Die Drosselung wird frühestens ab 2016 technisch umgesetzt werden, bis dahin rechne man mit 4mal so viel Datenaufkommen wie bisher.
  • Es wird im kleinsten Tarif ab 75 GB monatlichem Traffic gedrosselt werden.
  • Nur 3% der Breitbandkunden seien von der Drosselung betroffen, diese würden aber etwa 30% des Datenaufkommens generieren.
  • Der durchschnittliche Breitbandkunde generiert derzeit 15 bis 20 GB Datenaufkommen im Monat.
  • Auch 2016 soll es noch echte Flatrates geben, die dann aber 10 bis 20 EUR mehr kosten würden.
  • Die Telekom hat derzeit 12 Millionen Breitbandkunden.

Wenn wir nun ein bisschen mit diesen Zahlen rechnen fallen ein paar Diskrepanzen auf.

„8 Milliarden für den Netzausbau“

Wenn von 12 Millionen Breitbandkunden nur 3% einen Aufpreis von 20 EUR im Monat zahlen müssen, dann sind das im Jahr Mehreinnahmen von 43,2 bis 86,4 Millionen Euro pro Jahr. Der angedachte Netzausbau wäre daher erst nach 92 Jahren finanziert. D.h. die Behauptung, man müsse den Schritt gehen um den Netzausbau zu finanzieren, ist falsch.

„Alternative wäre Preiserhöhung für Alle gewesen“

Wenn von 12 Millionen Breitbandkunden nur 3% einen Aufpreis von 20 EUR im Monat zahlen müssen, dann entspräche dies einer allgemeinen Preiserhöhung von 60 Cent für Alle. Stattdessen könnte man auch Rabattaktionen für Neukunden oder Onlinebesteller abschaffen und hätte sich die negative Publicity erspart.

„Nur 3% der Kunden sind betroffen“

Wenn der Durchschnittskunde derzeit 15 bis 20 GB pro Monat generiert und sich das Datenaufkommen bis 2016 vervierfachen soll, dann generiert der Durchschnittskunde 2016 bereits 60 bis 80 GB pro Monat. Entweder sind also mit technischer Einführung der Drosselung 2016 bereits weitaus mehr Kunden betroffen als man heute behauptet oder aber irgendeine der Zahlen ist falsch.

Woher kommen diese Diskrepanzen?

Spätestens nach der Lektüre der beiden Heise-Artikel „Der stille Machtkampf“ (c’t 24/09) und „Schmalspur“ (c’t 08/11), die sich beide beinahe wie das Drehbuch zu den aktuellen Aktionen der Telekom lesen, drängt sich der Verdacht auf, dass man mit der angedrohten Drosselung eigentlich ein ganz anderes Ziel anstrebt und daher Zahlen gewählt hat, welche die breite Masse in Scheinsicherheit wiegen soll.

Man möchte die eigenen Breitbandkunden als „Drosselgeiseln“ missbrauchen, um damit große und erfolgreiche Content-Anbieter (z.B. YouTube) an den Verhandlungstisch zu zwingen. Diese sollen zukünftig für den zum Kunden transportierten Traffic bezahlen und sich somit von der Drosselung freikaufen (Stichwort „managed Services“, die die Telekom den Content-Anbietern zur Verfügung stellen will).

Das Internet, würde somit zu einer Ansammlung von „managed Services“ degenerieren, über die dann aber die Telekom und der Content-Anbieter gemeinsam volle Kontrolle hätten. Kleine Startups mit innovativen Ideen hätten kaum eine Chance, sich gegen die bestehenden Platzhirsche zu bewähren, weil die Einstiegshürden in die „managed Services“ zu hoch wären. Private Content-Anbieter (Blogger oder auch ganz normale Homepage-Betreiber) wären möglicherweise nur noch über eine „Kriechspur“ erreichbar. Das Internet, wie wir es heute kennen, würde nicht mehr länger existieren.

Nachtrag vom 06.06.2013:

Laut einem Artikel in der Welt vom 31.05.2013 gab die Telekom gegenüber des Bundesnetzagentur nun erstmals konkrete Zahlen heraus. Der Interessierte Leser kann obige Rechnungen ja mit den angepassten Zahlen nochmal selbst durchrechnen. 😉 An der löchrigen Argumentation ändern diese allerdings nichts.

Statt *.dip.t-dialin.net jetzt *.dip(0|1).t-ipconnect.de

Seit den guten alten T-Online-Zeiten war man es als T-Online-, T-Home- und Telekom-Zugangskunde gewohnt, dass der Reverse-DNS-Eintrag zur zugeteilten IPv4-Adresse dem Muster *.dip.t-dialin.net entsprach. Kunden von Telekom-Resellern (z.B. 1&1 je nach Anschluss) sowie von Telekom-Business-Zugängen hingegen hatten IPv4-Adressen nach dem Muster *.dip(0|1).t-ipconnect.de.

Seit dem 19. April 2013 (zumindest sehe ich in den Logs „meiner“ Server bis 18. April 2013 noch Zugriffe von *.dip.t-dialin.net) ist das nun anders, nun haben auch die direkten Telekom-Privatzugänge Reverse-DNS-Adressen aus *.dip(0|1).t-ipconnect.de.

Was ist daran nun bloggenswert? Die Telekom scheut unnötigen Aufwand wie der Teufel das Weihwasser (siehe den Mini-IPv6-Rollout für All-IP-Neuverträge), d.h. man hat das höchstwahrscheinlich nicht ohne Notwendigkeit getan. Aber was war der Grund dazu? Hat es gar irgendwas mit der häufig bemängelten YouTube-Performance bei der Telekom zu tun, zu der es am 18. April 2013 einen Blog-Eintrag des Telekom-Hilft-Teams gab? Sachdienliche Hinweise sind willkommen.

Nachtrag: Natürlich haben sich auch die Reverse-DNS-Adressen der neuen IPv6-Blöcke entsprechend geändert.

“Casting-Show” mit dem MS SQL Server – Teil 2

Vor gut zwei Monaten hatte ich über unterschiedliche Ergebnismengen bei prepared vs. non-prepared Statements berichtet. Zwischenzeitlich kam ein weiteres Phänomen dazu, was an das erste Phänomen erinnert:

Seit mehreren Monaten fallen uns immer mal wieder prepared Queries auf, deren Performance deutlich (Faktor 10 bis 100) schlechter ist, als das entsprechende non-prepared Queries. Alle Queries hatten gemeinsam, dass in einer wichtigen Bedingung eine VARCHAR-Spalte verwendet wird, auf der es einen Index gibt. Ein Blick auf die Ausführungspläne zeigte, dass die non-prepared Query einen performanten Index-Lookup durchführte, die prepared Query jedoch einen langsamen Index-Scan.

Als Ursache stellte sich der als Unicode-Wert übergebene Parameter der Bedingung auf der VARCHAR-Spalte (also keine Unicode-Werte) heraus. In so einem Fall scheint der SQL-Server – warum auch immer – keinen Lookup im Index machen zu wollen.

Lösungen:

  1. Ein Umstieg auf NVARCHAR-Spalten. Das ist unser bevorzugtes, mittelfristiges Ziel aber wie immer im Leben leider nicht sofort umsetzbar.
  2. Den JDBC-Treiber auf Non-Unicode-Parameterübergabe umschalten (sofern möglich).