Kategorien
WebTech

Einfach mal schnell machen: Mediasite und varnish

Mein Kollege Joachim hat ja schon einen oder zwei erste Einblicke in die Arbeiten am Videoportal der Bergischen Universität gegeben. Ich würde mit euch nun gerne einen Blick unter die Motorhaube werfen und zeigen, dass das, was wir am Vergaser (IIS) nicht einstellen konnten, einfach durch einen ordentlichen Turbo (varnish) wieder wettgemacht haben. 😉 Nun aber genug der Autobilder, starten wir mal…

Der Aufbau des Videoportals der Uni Wuppertal ist nicht so ganz trivial, hier sind eine Menge Server im Spiel, welche miteinander interagieren und sich gegenseitig beeinflussen. Folgend daher nur die schematische Darstellung der für die Auslieferung wichtigen Server. Nur diese sind für uns relevant, schließlich ist ja hier der Flaschenhals zu erwarten.

Das Setup des Videoportals schematisch vereinfacht

Bei jedem Aufruf eines Videos werden die Elemente, die die Webseite des Videoportals ausmachen, von den beiden Webservern ausgeliefert. Die Fragmente der Videos, also das, worauf es ankommt, werden durch die Videoserver und einen Loadbalancer an die User geschickt. Aber eben leider nicht an besonders viele gleichzeitig, relativ schnell kam das System ins Stolpern, das hätte den Anforderungen von Uni@Home in der Form nicht standgehalten.

Da musste also mehr Power rein und das ganze sollte dann auch redundanter werden. Wir haben aus diesem Grund Kontakt mit der Firma varnish AB gesucht, da wir das Hauptprodukt, den varnish cache, schon für unsere TYPO3 Server verwenden und damit sehr zufrieden sind. varnish AB hat uns dann sehr zeitnah und absolut unbürokratisch nach Auftrag einen Techniker zur Seite gestellt. Lucas hat dann unser Setup umgebaut und vor unsere Video- und Webserver des Videoportals eine redundante varnish pro Installation realisiert.

Schematische Darstellung des varnish Video Streaming und VoD Setups

Die Architektur basiert auf einem 1-tier Aufbau mit zwei varnish Servern, die so konfiguriert sind sowohl die Web- als auch MediaSite Server zu erreichen. Das Setup ist in der Lage, die beiden Varnish Instanzen in einer aktiven/aktiven Konfiguration vorzuhalten. In normalen Situationen ist varnish01 für den Webseiteninhalt zuständig und varnish02 wird für das Streaming bzw. die Video on Demand Auslieferung verwendet. In Ausfallsituationen ist jede Instanz in der Lage mit den anderen Inhalten (Web und Video) umzugehen.

Die dahinterliegende Konfigurationsdatei in VCL (Varnish Configuration Language) für die beiden Server ist ziemlich schlank gehalten und konzentriert sich auf das Caching der Videofragmente. Die Webseite des Videoportals wird hierbei kaum zwischengespeichert, hier handelt es sich hauptsächlich um statische HTML und CSS Dateien, welche auch von einem IIS schnell ausgeliefert werden können. 😉 Die Videofragmente jedoch sind gut zu cachen und werden durch die beiden Server für drei Tage zwischengespeichert.

//#dont cache manifests
if (bereq.url ~ ".mpd|.m3u8|manifest") {
	set beresp.uncacheable = true;
} else {
//#cache video fragments for max 3 days
	set beresp.ttl = 3d;
}

Wichtig ist, die manifest Dateien nicht zu cachen, daher werden diese auf uncacheable gesetzt.

Weiterhin verlassen wir uns auf die „Probe“-Funktionalität von varnish. Damit können wir feststellen, ob die entsprechenden Mediasite-Server (Web und Video) denn überhaupt betriebsbereit sind oder ob varnish diese erstmal als „krank“ markiert und nicht mehr darauf zugreift.

probe mediasite_stream {
	.url = "/Deliver/OnDemand/MP4Video/33504616.mp4;
	.timeout = 1s;
	.interval = 5s;
	.window = 5;
	.threshold = 3;
}

Für die Streamingserver lassen wir varnish ein sehr kleines .mp4 Video anfragen ;), die Webserver (siehe unten) werden auf die funktionierende API geprüft.

probe mediasite_web {
	.url = "/API/v1";
	.timeout = 1s;
	.interval = 5s;
	.window = 5;
	.threshold = 3;
}

Interessant ist sicherlich auch noch die Skalierung der Maschinen, wir verwenden hier je Maschine einen RAM Cache in der Größe von ca. 112 GB, insgesamt verfügen die beiden Server jeweils über 128 GB Arbeitsspeicher. Varnish arbeitet hier mit dem brandneuen Memory Govenor in Verbindung mit der Massive Storage Engine.

-s mse,/etc/varnish/mse.conf -p memory_target=112G

Die o.a. Parameter im Startaufruf von varnish in Verbindung mit folgenden Zeilen in der mse.conf

env: {
	id = "myenv";
	memcache_size = "auto";
};

sorgen dafür, dass varnish im Rahmen des memory_targets seinen Bedarf selbstständig an die Begebenheiten anpassen kann.

Alles in allem ein einfaches wie bestechendes Setup, welches wir ohne die tatkräftige Hilfe der Mitarbeiter*innen bei varnish AB sicherlich nicht in der Kürze der Zeit so elegant realisiert bekommen hätten. Also Charlotte, Lucas und Jonatan: You rock! Danke!

Kategorien
Sicherheit WebTech

Hitch, der TLS Doktor

Ein Einblick tief in den Maschinenraum unserer Webserver – Obacht es wird technisch:

Bis heute wurden fast alle Webseiten der Bergischen Universität über das nicht verschlüsselte Protokoll HTTP ausgeliefert. Nur bei Seiten, welche sensible Daten erheben und von denen wir darüber hinaus Kenntnis hatten, wurden verschlüsselt per HTTPS an die Anwender gebracht. Das ist nun anders – alle Webseiten, welche durch das zentrale CMS TYPO3 ausgeliefert werden und auf eine Domain mit der Endung .uni-wuppertal.de hören, werden standardmäßig verschlüsselt. Siehe hierzu unsere Meldung von Heute.

Damit das funktioniert, haben wir eine neue Software im Einsatz, welche die notwendigen Zertifikate verwaltet und gleichzeitig unseren Webbeschleuniger varnish beliefert: Hitch!

Nicht der Date-Doktor, sondern eher der TLS Doktor. Hitch ist ein sogenannter terminierender SSL-Proxy. Das bedeutet, er nimmt SSL-Verbindungen entgegen, entschlüsselt diese, reicht das ganze weiter an unseren Webproxy varnish, wartet auf Antwort, verschlüsselt diese wieder und liefert die Webseite an den Kunden aus. Hitch ist ein sogenannter „dummer“ Proxy, kann also im Gegensatz zu HAProxy keinerlei Manipulationen vornehmen oder gar regelbasiert Unterscheidungen treffen, sondern nur „auspacken-weiterleiten-einpacken-ausliefern“ betreiben 😉

Nachfolgend unsere Config dazu, da ist nahezu Standard und nix besonderes:

frontend = {
  host = "*"
  port = "443"
}
backend = "[127.0.0.1]:6086"    # 6086 is the default Varnish PROXY port.
workers = 2                    # number of CPU cores

daemon = on
user = "nobody"
group = "nogroup"
syslog-facility = "daemon"

# Enable to let clients negotiate HTTP/2 with ALPN. (default off)
#alpn-protos = "http/2, http/1.1"

# run Varnish as backend over PROXY; varnishd -a :80 -a localhost:6086,PROXY ..
write-proxy-v2 = on             # Write PROXY header

# List of PEM files, each with key, certificates and dhparams
pem-file = "/path/to/pemfile.pem"

# Which ciphers do we support:
ciphers = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

Hitch lauscht auf 443, leitet intern alles an varnish auf Port 6086 weiter. Dazu verwendet er das PROXY V2 Protokoll. Damit nun alle Seiten der Universität aus TYPO3 verschlüsselt werden, weisen wir varnish an, alle auf Port 80 einkommenden Verbindungen für die Domains, welche auf uni-wuppertal.de enden, auf HTTPS, also Port 443, weiterzuleiten:

import std;

sub vcl_recv {
    if (std.port(local.ip) == 80 && req.http.host ~ "(?i)uni-wuppertal.de$" ) {
        if (req.http.host !~ "^(www.)?(ausnahmen|kommen|hierhin).uni-wuppertal.de$" ) {
            set req.http.x-redir = "https://" + req.http.host + req.url;
            return(synth(301));
        }
    }
}

Hier gibt es allerdings im zweiten if-Statement einen Ausnahmeblock, da wir für einige Domains im Namensraum uni-wuppertal.de derzeit keine Umleitung vornehmen. Diese lassen sich aber an zwei Händen abzählen.
Die eigentliche Umleitung wird dann in sub vcl_synth vorgenommen:

sub vcl_synth {
    if (resp.status == 301) {
        set resp.http.Location = req.http.x-redir;
        return (deliver);
    }
}

Wer also einen leistungsfähigen SSL Proxy benötigt, dem sei der leichtgewichtige Hitch durchaus an’s Herz gelegt. Das er aus dem selben Hause wie varnish kommt, ist für uns natürlich noch ein weiterer Vorteil.

Kategorien
Allgemein Lehren und Lernen Moodle WebTech

Der Extra-Klick im Adobe Connect Moodle-Plugin

In unserer Lernplattform Moodle ist die Online-Meeting Software Adobe Connect integriert. Lehrende können z.B. Online-Sprechstunden in Ihrem Moodle-Kurs einrichten oder externe Referenten zum Fachgespräch einladen. Dieser Online-Konferenzraum bietet auch die Möglichkeit die Veranstaltung aufzuzeichnen und den Teilnehmern/-innen eines Kurses zur Verfügung zu stellen. Das ist sehr praktisch, da auch Studierende, die nicht teilnehmen konnten die Aufzeichnung später anschauen können – wenn Sie einen Extra-Klick machen.

Das Adobe Connect Plugin für Moodle hat einen kleinen Fehler (Bug). Man kann eine Aufzeichnung eines Online-Meetings erst dann anschauen, wenn man zunächst den Meeting-Raum betreten hat. Das kann man auch nachträglich machen, bzw. muss man machen, ansonsten kann die Aufzeichnung nicht abgespielt werden. Anscheinend werden erst durch das Betreten des Online-Meetingsraum die notwendigen Berechtigungen übertragen.

Hierzu folgende Abbildung:

extraklick-adobe-connect-aufzeichnung

Kategorien
WebTech

Twitter Cards für tt_news

Lösung einer Twitter Cards Implementation für TYPO3 und tt_news.

Einzubinden beispielsweise als Extension Template auf der Single-View-Seite von tt_news.

### Twitter Card:
page.headerData.500 = TEXT
page.headerData.500.value (
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@" />
)
 
 
temp.twitterTitel = COA
temp.twitterTitel {
 10=CONTENT
 10.table= tt_news
 10.select {    
   selectFields = title
   pidInList = {$news_pid.value} # set constant or insert PID
   andWhere {
     # grab the querystring vars and assign it to uid
     data = GP:tx_ttnews|tt_news
     wrap = uid = |
     intval = 1
   }
 }
 #10.orderBy = sorting
 10.renderObj =COA
 10.renderObj {
   10=TEXT
   10 {
     field = title     
     stripHtml = 1
     crop = 70 | ...    
   }
 }
  wrap = <meta name="twitter:title" content="|" />
}
 
page.headerData.505 < temp.twitterTitel 
 
temp.twitterDescription = COA
temp.twitterDescription {
 10=CONTENT
 10.table= tt_news
 10.select {    
   selectFields = bodytext
   pidInList = {$news_pid.value} # set constant or insert PID
   max = 1
   andWhere {
     # grab the querystring vars and assign it to uid
     data = GP:tx_ttnews|tt_news
     wrap = uid = |
     intval = 1
   }
 }
 10.renderObj =COA
 10.renderObj {
   10=TEXT
   10 {
     field = bodytext     
     stripHtml = 1
     crop = 200 | ...    
   }
 }
  wrap = <meta name="twitter:description" content="|" />
}
 
page.headerData.510 < temp.twitterDescription

Wichtig ist, dass <meta name="twitter:site" content="@" /> noch mit einem Twitteraccount gefüllt werden kann, der als Ansprechpartner dient. Dies ist jedoch nicht mehr zwingend erforderlich. Daher kann die Zeile 5 auch einfach entfernt werden, so denn kein Account angegeben werden soll.

Eine Erweiterung um die Bilder, die in der News benutzt werden, wäre relativ einfach nach o.a. Schema umzusetzen. Das META-Tag, welches hier von Twitter erwartet wird, ist <meta name="twitter:image" content="" />.

Kategorien
PHP Programmierung WebTech

Umlaute im E-Mail-Header

Um einen Text mit Umlauten zu verschicken reicht i.d.R. die Angabe des Charsets UTF-8 aus:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Die From-Zeile dieses Headers wird dennoch nicht korrekt dargestellt:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
From: Geräteausleihe <mail@domain.tld>

Umlaute im Header sind von der Charset-Angabe nicht betroffen und müssen über eine UTF-8-Codetabelle mit Unicode-Zeichen direkt codiert werden:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
From: =?UTF-8?Q?Ger=c3=a4teausleihe?= <mail@domain.tld>

Erst auf diese Weise wird das ä im Header beim Empfänger korrekt dargestellt.