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.

Ö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  🙂

Amazon: S3 Upload und CloudFront Invalidierung

Amazon macht die Sache aber auch spannend. Hier eine Doku:

S3 Upload:

An Bordmitteln habe ich nur den Upload per Webinterface gefunden (man möge mich korrrigieren). Der “kann” aber keine Ordner, und wer nicht den ganzen Verzeichnisbaum von Hand erstellen möchte, verwendet ein Tool wie zB Cyberduck. Dazu benötigt man die “Access Key ID” und den “Secret Access Key”.

Ersteren findet man, wenn man im Menu unter seinem Namen auf “Security Credentials” geht:

Man landet auf einer Seite, wo der Key unter “Access Keys (Access Key ID and Secret Access Key)” versteckt ist. Der (jeweils, man kann zwei IDs haben) zugehörige Key findet sich allerdings nicht dort, sondern auf der unter den IDs verlinkten Seite. Der Key wird jedes mal neu erzeugt, also gut wegspeichern. Quelle.

Cyberduck bringt ein Preset für S3-Verbindungen mit, dort trägt man die Access ID als Benutzernamen ein; der Key dient als Passwort:

“Publishen” der hochgeladenen Files nicht vergessen m(

CloudFront Invalidierung

Invalidieren kann man seine Distribution in der Console, unter den “Distribution Settings”->”Invalidations”. Allerdings muss man wissen, dass man nicht mit Wildcards arbeiten kann – man muss jede URL explizit angeben:

You must explicitly invalidate every object and every directory that you want CloudFront to stop serving. You cannot use wildcards to invalidate groups of objects, and you cannot invalidate all of the objects in a directory by specifying the directory path.

Also erstelle ich mir vor dem Upload ein Listing des Ordners:

Und trage das dann dort ein.

Muss man wissen.