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.

Vagrant: Timeout mit apt-get

Der Fehler

aus einem Puppet, hier der bemängelte Teil:

kann mit mehr RAM behoben werden. Folgendes in’s Vagrantfile:

Quelle indirekt.

Öfter mal was Neues: Von Strato zu Uberspace

(zu Folge 1)

Wenn ihr das hier lesen könnt, dann ist mein Umzug zu Uberspace komplett (zumindest aus Sicht eures RSS-Readers). Ich bin jetzt ein Ubernaut 😀 Danke an Tobi für den Tipp.

Aber Ernst beiseite. Worum geht’s bei Uberspace? Uberspace (von “Userspace”, nicht Übermensch oder so) ist Webhosting, “klassisch” ohne Domains (meine laufen deshalb jetzt bei InternetWorkX), dafür mit ungefähr allem anderen:

SSH. Perl. PHP. Python. Ruby. node.js. Erlang. Lua. Compiler. FastCGI. MySQL. CouchDB. MongoDB. Cronjobs. HTTPS. IMAP. SMTP. Webmail. qmail. vmailmgr. maildrop. Spam­Assassin. ezmlm-idx. DSPAM. ~/service. runwhen. Eigene Logs. Backups. 10 GB Plattenplatz.

Zuerst war ich skeptisch, denn es gibt kein Backend-UI; alles wird per Shell konfiguriert. Allerdings macht alleine das (hey, Shell-Zugriff!) neugierig, und die Jungs haben ein spitzen Wiki – auch darin rumzustöbern lohnt den Extraufwand.

Hier trotzdem eine Kurzübersicht über das Einrichten von mehreren Domains auf demselben Uberspace, von dem die Jungs eigentlich eher abraten. Ich habe mich trotzdem dafür entschieden, denn: Bei Uberspace bezahlt man “so viel man will, mindestens 1 (!) €, besser 5 bis 10”. Nun hatte ich die Wahl, jeder Domain einen Space zu spendieren. Dann hätte ich das sinnvollerweise aber auch für die Subdomains von crusy.net machen müssen, denn dort “passiert” viel mehr. Gerade das Argument der Sicherheit zwischen Domains/Spaces zieht bei mir eigentlich nur bei den Subdomains von crusy.net. Nur wäre ich damit auf mindestens 13 Spaces gekommen, was erstens viel zu unübersichtlich und aufwendig (und was, wenn eine weitere Subdomain hinzukommt??), und zweitens viel zu teuer gewesen wäre – selbst mit dem 1 €, mit dem ich mir zu guter Letzt auch noch geizig vorgekommen wäre. Wenn ich mal was wirklich kritisches hoste (OwnCloud oder so), dann hole ich mir einen zweiten Space, aber so muss halt einer reichen.

Deshalb: Aufschalten verschiedener (Sub-) Domains geht bei Uberspace wie folgt:

Einloggen:

Host(s) als Webserver konfigurieren (-w)

Host(s) als Mailserver konfigurieren (-m); man beachte den Namespace:

uberspace-add-domain gibt die IPv4- und IPv6-Daten für die Domain aus, die hinterlegt man im DNS-Eintrag bei (in meinem Fall) inwx. Damit steht dann die Verbindung zwischen Domain und Webspace. Allerdings muss man noch je einen Pseudo-Docroot pro (Sub-) Domain anlegen, diese landen nicht in ~/html, sondern parallel dazu. ~/html ist ein Symlink nach /var/www/virtual/username/html; die Pseudo-Docroots kommen also nach /var/www/virtual/username/xy.tld. Das jeweilige Docroot muss genau wie die Domain heißen.

Achtung: “www” ist eine Subdomain! Sie muss also sowohl mit uberspace-add-domain eingetragen werden, wie auch über ein Docroot verfügen. Nun will man nicht jeden Content doppelt halten, deshalb legt man in /var/www/virtual/username/ mittels

einen Symlink an.

Übrigens: Der erste Monat ist kostenlos, und ein neuer Uberspace ist anonym und in weniger als 30 Sekunden eingerichtet. Also gern mal ausprobieren – hach, ich bin jetzt Fan, merkt man gar nicht, oder?

Öfter mal was Neues: Neues Theme

Irgendwie bin ich gerade im Veränderungen-Modus. Anlass genug, daraus eine kleine Serie zu starten, die relativ profan beginnt: crusy.net hat ein neues Theme: Publish. So weit, so uninteressant. Für die Akten möchte ich aber kurz aufstellen, was ich normalerweise alles anpasse an so einem Theme:

  • HTML-Header, header.php:
    • Seitentitel auf “crusy.net” ändern (=Tagline rauswerfen, vgl. unten)
    • Keywords, Description, Sharing-Tags einfügen
  • Blog-Header, hier custom-header.php: Ich habe meinen Gravatar durch ein lokales Bild ersetzt, Stichwort Tracking
  • in Würdigung des cleanen Looks des Themes habe ich die letzten Kommentare und Tweets aus der Seitenleiste geworfen; Tag Cloud und Links sind auf jeweils separate Seite gewandert. Um die Tag Cloud dorthin zu bekommen, habe ich ein neues Page-Template angelegt
  • comments.php, Stichwort “comment_notes_after“: Im Kommentar-Bereich meiner Posts (meine Pages erlauben keine Kommentare) habe ich einen Disclaimer zu Akismet ergänzt (Hintergrund)
  • styles.css:

Wozu den letzten Punkt? Nun, ich habe gerne eine zufällig gewählte “Tag line” in der Seite; eine Spielerei und gute Möglichkeit, Kalauer unterzubringen. Da ja nun meine Tweets rausgeflogen sind (siehe oben), möchte ich diese hier unterbringen, und zwar verlinkt. Optisch soll das aber nicht offensichtlich sein – nennt es ein Easteregg. Da werden sicherlich auch noch welche dazukommen oder rausfliegen.

So viel dazu.

UPDATE:

ich habe schon wieder ein neues Theme: Ari von Elmastudio  🙂

AS3: Optionales Injecten mit Robotlegs/SwiftSuspenders

Injects sind in Robotlegs 1.x/SwiftSuspenders 1.x erst mal verbindlich, so wie ich eine entsprechende Aussage von Till Schneidereit verstehe. Ein [Inject] führt dann zu einer Fehlermeldung:

Error: Injector is missing a rule to handle injection into property “myProperty” of object “[object MyClass]”. Target dependency: “com.acme.some.package::MyInjectType”, named “”

Der dort verlinkte Custom Build (Downloadübersicht siehe hier) enthält SwiftSuspenders 2, und das erlaubt optionale Injects. In meinem Test funktioniert das übrigens ohne ein “(optional=true)”, wie im oben verlinkten Thread vorgeschlagen – der Inject ist einfach null.