Der eigene URL-Shortener

Mar­kus erklärt in sei­nem Blog, war­um es Sinn macht, einen eige­nen URL-Shor­tener zu ver­wen­den. Ich kann dem wenig hin­zu­fü­gen und habe es ihm fast gleich­ge­tan – allein für ein neu­es Mul­ti­do­main-SSL-Zer­ti­fi­kat habe ich noch nicht die Muße gefun­den. Für den eige­nen URL-Shor­tener neh­me man

  1. Jeden 0815-Webs­pace mit PHP, MyS­QL und mod_­re­wri­te-Unter­stüt­zung – das bie­tet heu­te fast jedes Ein­stei­ger-Paket.
  2. Eine mög­lichst kur­ze Domain. Es gibt noch zahl­rei­che Drei­buch­sta­ben-DE-Domains. Eine DE-Domain buche ich z.B. über mei­nen gemie­te­ten Robot in Echt­zeit für 3,90 Euro/Jahr.
  3. Ein fer­ti­ges Script, z.B. Yourls.

lighttpd-User wie ich haben es nur unwe­sent­lich schwe­rer, da die Rewri­te-Engi­ne etwas anders funk­tio­niert. Für den ent­spre­chen­den vhost trägt man hier ein:

$HTTP["host"] == "domain.tld" {
        server.document-root = "/pfad/zu/yourls"
        url.rewrite-once = (
        "^/([0-9A-Za-z]+)?$" => "/yourls-go.php?id=$1",
        "^/([0-9A-Za-z]+)?\+$" => "/yourls-infos.php?id=$1" )
}

… und schon hat man nach ein wenig Doku den eige­nen Kurz-URL-Dienst (lei­der klappt der Auf­ruf der Haupt­do­main so noch nicht). Mei­ner hört auf

http://www.m9r.de

und ist genau wie Mar­kus‘ Instal­la­ti­on nicht öffent­lich zugäng­lich, um Ärger mit bestimm­ten Zeit­ge­nos­sen zu ver­mei­den. Dass das klappt, lässt sich ganz gut mit mei­nem momen­ta­nen Lieb­lings­nach­denk­ar­ti­kel über Face­book zei­gen: http://m9r.de/3 (mit Dank an Andre­as Kalt).

Man han­delt sich in der Grund­ver­si­on wie­der eini­ge Daten­schutz­her­aus­for­de­run­gen ein, die sich aber lösen las­sen. Neben­bei weiß ich jetzt, wie oft mei­ne Kurz-URLs auf Twit­ter tat­säch­lich geklickt wur­den und es ent­steht qua­si neben­bei eine hüb­sche Link­samm­lung in der Daten­bank. Jetzt noch ein paar Tags und schon braucht es oben­drein auch kaum noch Book­marks.

Etherpad, nochmal Etherpad

Lighttpd ver­mit­telt jetzt den Kon­takt zu unse­rem Ether­pad, das nur nur unter local­host zu errei­chen ist:

$HTTP[„host“] =~ „^(.+\.)?etherpad.schuldomain.tld“ {

auth.require = ( „“ => ( „method“ => „basic“,
„realm“ => „Ether­pad – Log­in mit Schul­netz­werk­da­ten“,
„requi­re“ => „valid-user“ )
)

proxy.server = (
„“ => (
„ether­pad“ => (
„host“ => „127.0.0.1“,
„port“ => 9000,
„fix-redi­rects“ => 1
)
)
)

}

Mit­tels HTTP_AUTH, dass gegen den LDAP läuft, ist das Sys­tem nur Netz­werk­nut­zern der Schu­le zugäng­lich (auth.require-Sektion). Das Pro­xy­mo­dul von lighttpd (proxy.server-Sektion) sorgt dann dafür, dass der Brow­ser ohne Port­an­ga­be direkt auf die Pads zugrei­fen kann und dafür, dass die Sub­do­mains für die Team­si­tes funk­tio­nie­ren.

Ich habe die Pads für ein Web­quest zur Regel­fin­dung zur Getrennt- und Zusam­men­schrei­bung in Klas­se 9 ein­ge­setzt. Im ers­ten Teil der Dop­pel­stun­de haben wir eine Regel für eine Zusam­men­set­zung (Adjek­tiv + Verb) anhand von Mate­ri­al selbst erar­bei­tet und for­ma­le Kri­te­ri­en fest­ge­legt. Im zwei­ten Teil der Dop­pel­stun­de habe ich je einer Grup­pe einen Aspekt (z.B. Schrei­bung von Tages­zei­ten) zuge­wie­sen, ein paar hilf­rei­che Sei­ten ver­linkt und kol­la­bo­ra­tiv eige­ne Regel­for­mu­lie­run­gen im Pad erar­bei­ten las­sen.  Die Auf­ga­ben­stel­lung und die Links befan­den sich in einem Mood­le­kurs.

Am Fol­ge­tag haben wir die Ergeb­nis­se – dies­mal auf Tot­holz aus­ge­druckt – bespro­chen und anhand der Regeln, die sicher for­mu­liert waren, klei­ne Übungs­sätz mit gehäuf­ten Schwie­rig­kei­ten zur Getrennt- und Zusam­men­schrei­bung erson­nen. Die­se Metho­dik war zumut­bar, weil das The­ma für die Klas­se ein „Wie­der­ho­lungs­fall“ ist, es also mehr um eine Reak­tua­li­sie­rung ging.

Ether­pad ver­brauch­te bei 15 akti­ven Cli­ents ca. 200MB RAM und etwa 9% CPU-Zeit – beschau­lich…

lighttpd und PositiveSSL-Certs

Ich habe gera­de die lite-Ver­si­on der auf http://www.psw.net feil­ge­bo­te­nen SSL-Certs aus­pro­biert. Es gibt kei­ne direk­te Anlei­tung für die Instal­la­ti­on des Zer­ti­fi­ka­tes inner­halb von lighttpd (ligh­ty) und die in der Bestä­ti­gungs­mail ange­ge­be­nen Links sind mei­ner Erfah­rung nach bes­ten­falls irre­füh­rend.

Der Bestell­pro­zess

Zunächst ist ein Ser­ver­key für die Domain www.domain.tld mit OpenS­SL zu erstel­len. Im wah­ren Leben ist natür­lich der Aus­druck „www_domain_tld“ durch eine eige­ne, rea­le Domain zu erset­zen. Das geht auf der Kom­man­do­zei­le z.B. durch Ein­ga­be von:

opens­sl req ‑new ‑nodes ‑key­out www_domain_tld.key ‑out www_domain_tld.csr

Dabei wer­den eini­ge Infor­ma­tio­nen abge­fragt, die man mit sinn­vol­len Daten füt­tern soll­te. Immens wich­tig ist die Ein­ga­be

Com­mon Name (eg, YOUR name) []: www.domain.tld

Nur dann schützt spä­ter das aus­ge­stell­te Zer­ti­fi­kat die Domains http://domain.tld und http://www.domain.tld (das ist bei der ver­wen­de­ten CA Posi­ti­ve­SSL auto­ma­tisch so).

Für den Bestell­pro­zess wird der Inhalt der Datei www_domain_tld.csr benö­tigt. Für die Instal­la­ti­on des Zer­ti­fi­ka­tes brau­chen wir spä­ter noch die Datei www_domain_tld.key.

Wei­ter­le­sen