WWI

Bekanntermaßen feiert der 1 Weltkrieg dieses Jahr sein Hundertjähriges. Dazu gibt es vermutlich drölf Projekte, allerdings sind mir bisher erst zwei (gute) über den Weg gelaufen:

  • 1914-1918 – Die Entwicklung der Dinge: Julian Finn veröffentlicht auf den Tag genau 100 Jahre später den jeweiligen Tagebucheintrag seines Urgroßvaters Ernst Pauleit.
  • Einen ähnlichen Ansatz fährt @1914Tweets: Eine Echtzeit- (?) Rekonstruktion der Vorgänge des Jahres 1914, bis hin zum Wetterbericht der Hauptstädte der Kriegsparteien und Zeitungsausschnitte

Gerade in der Kombination bekommt man einen guten Eindruck über, ja, “die Entwicklung der Dinge”. Wie schnell es gehen kann, gerade bei vielen beteiligten Parteien, sieht man bei @1914Tweets:

Während man im Tagebuch einen punktuellen, subjektiven, aber tieferen Eindruck bekommt… so scheint die Stimmung bei Ernst Pauleit “jetzt” eher von Aufbruch und Betriebsamkeit, denn von Angst geprägt zu sein:

In der Stadt wogte und wallte es, als wäre Kirmes. […] Essen und Trinken gab es in Menge. Zigarren und Zigaretten qualmten von morgens bis spät in die Nacht.

Das Tagebuch ist übrigens zusehends schlechter erreichbar, bei Gefallen also gerne spenden!

UPDATE

Ah, deshalb ist das so langsam: Ein Artikel auf SpOn

Eine “Google Custom Search Engine” über mehrere Domains

Es gibt (mindestens) zwei Arten, einzelne Domains in Googles “Benutzerdefinierten Suchmaschinen” zu unterscheiden:

  1. Für jede Domain eine eigene Suchmaschine anlegen. Vorteil: Separate Keywords, Description, … für jede Suchmaschine. Nachteil: Jede Suchmaschine kostet separat beim Upgrade auf die kosten­pflichtigen Features
  2. Die Domains alle derselben Suchmaschine hinzufügen, und bei Aufruf per Parameter “as_sitesearch” filtern (Quelle, Docs). Vor-/Nachteile sind genau umgedreht.

PS: Option 2 funktioniert nicht nur für Domains, sondern auch für Verzeichnisse, also etwa “example.com/de” vs. “example.com/en”

Synology: Seinen eigenen DDNS-Service hosten

Achtung: Setzt inwx.de als Registrar voraus!

Der Service

Auf xuad.net gibt es eine entsprechende Anleitung für einen DDNS-Service, auf GitHub liegen die Sourcen. Dabei ist einiges zu beachten:

Man muss dieses Skript unter einer anderen (Sub-) Domain als das DDNS-“Ziel” laufen lassen, klar. Sobald man die DDNS-Domain dynamisch um-mapped, ist das Skript sonst nicht mehr erreichbar.

Wer bei INWX ein Passwort mit Sonderzeichen verwendet, sollte es in der .ini in Anführungszeichen setzen.

Wenn man die IP auslesen möchte, statt sie zu übergeben (siehe Comments in dem Post), und der Server nur schon IPv6 spricht, sollte man den hier beschriebenen “Fix” verwenden, denn INWX erwartet eine v4-Adresse:

Darüber hinaus muss bei INWX ein expliziter Eintrag für die Subdomain angelegt sein. Das Skript ruft diesen bestehenden Eintrag ab, extrahiert eine ID, und updated dann über diese ID. Gibt es keinen Eintrag, gibt es auch keine ID, und das Update kann nicht durchgeführt werden. Ein Wildcard-Eintrag genügt nicht.

Dann sollte das klappen. Falls nicht, kann man im DDNSManager.php Debugging einschalten, um Request und Response an INWX ausgeben zu lassen:

Und/oder PHP-Fehler anzeigen, klar:

 Den Service aufrufen (lassen)

Interessanter ist die Frage, wie und wann sich das NAS dann registriert. Der hauseigene DDNS-Client bietet zwar drölfzig Anbieter zur Auswahl, aber kein Feld für custom Skripte 🙁

Erste Idee: cron. Zwar bringen die Synologys cron mit, allerdings will man sich mit einem regelmäßigen Cronjob ja nicht seinen Ruhezustand versauen.

Zweite Idee: dhclient-exit-hooks.d (siehe auch), dhcpcdnetworkmanager, oder irgendwas, das einen Hook bei IP-Änderung bietet. Gibt es auf einem Synology offenbar (so) nicht.

Dritte Idee: Den erwähnten DDNS-Dienst pimpen. Google liefert tatsächlich einen Ansatz:

  • per SSH auf dem NAS einloggen, Benutzer “root”, Passwort vom “admin”-Account
  • /etc.defaults/ddns_provider.conf editieren (bsplw. mit vi)
  • Einen neuen Eintrag anlegen a la

Hier wäre übrigens möglich, die IP zu übergeben, dann muss man sie nicht auslesen: Neben __USERNAME__ und __PASSWORD__ sind __HOSTNAME__ und __MYIP__ möglich. Trotzdem: Die IPv6-Übersetzung scheint angebracht, wie gesagt wegen INWX.

htaccess-Authentifizierung habe ich hier nicht hinbekommen, sobald sich das ändert, gibt es hier ein Update.

Nun kann man im DSM seinen neuen DDNS-Service auswählen; “Hostname” kann in diesem Fall mit irgendwas gefüllt werden, da er in der Query-URL ja nicht verwendet wird

HTH

Wowza Media Server: Caching Einstellungen für Amazon CloudFront

Wer mit Wowza einen HTTP-Livestream über CloudFront ausliefern möchte, der sollte die Caching-Einstellungen optimieren:

und

andernfalls nervt insbesondere beim Neustarten des Streams der gecachte Status “kein Video gefunden”

Über einen Domaintransfer

Ich schrub ja bereits, dass ich meine Domains von Strato zu inwx umgezogen habe. Das lief mit meinen .de-Domains auch ziemlich einfach; kein Vergleich zu meinem Umzug von 1&1 zu Strato vor vielen Monden. Ausgerechnet mit crusy.net allerdings war es nicht ganz so einfach:

Analog zu den erfolgreichen Umzügen von bsplw. bentlarsen.de klickte ich auf “AuthCode anfordern” in Stratos übersichtlichem Backend, und wartete ab. Bei Strato bekommt man den AuthCode per Mail (anders als bei inwx, da sieht man ihn direkt im Backend), und auch erst Stunden später. Er kam dann aber auch tatsächlich und ich copy-und-pastete ihn in den entsprechenden Auftrag bei inwx. Aber anders als bei bentlarsen.de wurde der Umzug nicht fast sofort ausgeführt, stattdessen passierte eine Woche lang gar nichts.

Nach dieser Woche erhielt ich eine Mail von inwx mit dem Hinweis

Transfer was not authorized by owner/admin contact. Please check whois email address.

Nun muss man dazu wissen, dass ICH Owner und Admin bin, und meine Emailadresse korrekt hinterlegt ist. Aber der Hinweis auf Whois machte mich stutzig, und siehe da: Als Inhaber der Domain wurde die “Cronon AG, Berlin” geführt, WTF. Kurze Recherche: Cronon ist eine Tochter von – Strato. Strato hatte den Transfer augenscheinlich selber abgelehnt.

Ich wurde ob der verschwendeten Woche etwas ungehalten gegenüber dem Support, was mir immerhin eine schnelle Antwort einbrachte. Ich müsse ein Formular auf Wechsel des Domaininhabers ausfüllen.

Ich bohrte nach: Warum das Ganze? Und vor allem: Wechsel von was auf was? Ich war ja schon Inhaber und wollte es auch bleiben! Ja, nee, das müsse sein, damit die Daten beim neuen Registrar genau zu denen bei Strato passten. Nun gut, das klang plausibel. Also gesagt, getan.

Kurze Zeit später die Antwort von Strato:

Wie ich in Ihren Kundendaten entnehmen konnte, stimmen diese schon mit dem Formular überein.

Was bedeutet das nun wieder? War jetzt irgendwas passiert, dass mich meine Domain übertragen lassen würde? Es klang nicht so. Und tatsächlich: Auf erneute Nachfrage erklärte man mir

Nach mehrfacher Überprüfung konnte ich feststellen, dass die Daten wie auf Ihren Formular übereinstimmen.

Das war nicht die Frage, verdammt!

Das das Vertragsende, der 08.06.2014 ist, bekommen Sie den Auth Code 1 Monat vor Vertragsende zugesandt. Wenn Sie den Auth Code schon vorher benötigen, dann haben Sie die Möglichkeit über den Kundenservicebereich wenn Sie bei Ihrer Domain sind, den Auth Code anzufordern.

Kurzfassung: Es war NICHTS geändert worden, da meine Daten bereits aktuell waren. Ich solle den AuthCode verwenden, der schon beim ersten mal nicht funktioniert hat. Meine Verärgerung wuchs. Der Support dazu:

Infolge meiner Überprüfung auf internic.net ist ersichtlich, dass unsererseits kein Registrarlock mehr auf der Domain crusy.net vorhanden ist. […] Dies teile ich Ihnen mit, da hierbei erwiesen ist, dass unsererseits einem Umzug Ihrer Domain nicht verhindert wird. Der AuthCode für die vorgenannte Domain wurde heute vormittag nochmal neu angefordert.

Aha. Wer genau hat den AuthCode denn nochmal angefordert? Ich jedenfalls nicht.

[…] von meinen beiden Kollegen, welche bereits den Schriftverkehr mit Ihnen führten.

Mmmkey… tatsächlich trudelten nun im Stundentakt AuthCodes bei mir ein 🙂 An welcher Stelle in der bisherigen Kommunikation das für nötig befunden wurde (denn aus Strato-Sicht ging es ja zwischenzeitlich um meine Kundendaten, nicht um AuthCodes) erschließt sich mir zwar nicht, aber wenn es denn so sein soll, probiere ich halt einen davon aus.

Und siehe da: 30 Minuten später bekomme ich eine Mail, dass ich über ein Webformular meinen Umzug bestätigen möge; 5 Stunden später ist die Domain umgezogen! So eine Mail hatte ich vorher nicht bekommen (nicht für bentlarsen.de und erst recht nicht für crusy.net) – was war dieses mal anders als beim ersten mal?

So richtig werde ich das nicht mehr rausbekommen, aber ich kann mir zwei Szenarien vorstellen:

  1. Strato hat doch irgendwas geändert, vielleicht meine Emailadresse korrigiert, so dass ich die beschriebenen Mails dieses mal erhalten habe.
  2. inwx hat einen Bug in ihrem Robot. Beim ersten Versuch habe ich eine .de-Domain und crusy.net gleichzeitig umgezogen – eine Möglichkeit, die das entsprechende Formular explizit vorsieht. Aber vielleicht kommt der Robot durcheinander, wenn für die .net-Domain ein anderes (komplizierteres!) Prozedere nötig ist, als für die .de-Domain aus demselben Auftrag, und schickt die genannten Mails nicht los, bzw fordert sie nicht ab.

Anyways: Unterhaltsame Anekdote aus der Service-Wüste Deutschland. Denn hätte Strato nicht nur nach Buzzwords in der jeweils letzten Mail gesucht, und/sondern mal die davor gelesen, wäre mir einiges an Zeit erspart geblieben.