Unser letztes stable Release 13.0 fand hier kaum Erwähnung. Veröffentlicht haben wir es bereits vor beinahe einem halben Jahr auf den Kieler Linux Tagen. Die meisten Neuerungen habe ich bereits in verschiedenen Blogposts beschrieben. Wenig Berücksichtigung fand die Überarbeitung des Apache-Webserver Setups. Nicht zuletzt deswegen, weil sie in die Hose gegangen ist.
Ziel dieser Überarbeitung war es Dinge, die im Laufe der Zeit, nennen wir es „natürliches Wachstum“, mehr und mehr aus dem Ruder gelaufen sind, wieder auf Vordermann zu bringen. Der erste Ansatz – in Version 13.0 – enthalten hat zwar reichlich Arbeit bedeutet, brachte allerdings nur wenig.
Beim Zugriff auf das Web-Portal des invis-Servers (invis-Portal) unterscheiden wir schon immer zwischen Zugriffen aus dem lokalen Netzwerk und Zugriffen via Internet. Der Zugriff via Internet sollte natürlich entsprechend der Gefährdungslage besser abgesichert sein als Zugriffe aus dem lokalen Netz. Zu den Schutzmechanismen zählen Verschlüsselung, Schutz gegen Deep-Linking und auch die Verwendung abweichender Ports für den Zugriff.
Mit der Weiterentwicklung des invis-Servers griffen manche Mechanismen nicht mehr und andere erwiesen sich als zunehmend kontraproduktiv. Ein paar Beispiele:
Möchte man via ownCloud Dateien oder Verzeichnisse für Dritte freigeben, die via Internet auf den Server zugreifen, muss dafür Sorge getragen werden, dass die generierten Links konsistent sind. D.h. Zugriffe von intern müssen über die gleiche URL erfolgen wie von extern. Dafür haben wir für ownCloud einen eigenen Apache vHost eingeführt. Auch dabei haben wir einen vom Standard für „HTTPs“ abweichenden Port genutzt. Genau letzteres bereitet in der Regel Probleme, wenn der Internetzugang des externe Dritte über einen Proxy-Server realisiert wird. Abweichende Ports für HTTPs werden dort meist blockiert.
Die Kopano-DeskApp, ein lokaler Kopano Client, erfreut sich zunehmender Beliebtheit. Dieser Client ist allerdings kein sogenannter „Fat-Client“ sondern nutzt seinerseits wieder die Kopano-WebApp. Unterscheiden sich die URLs für den Zugriff auf die WebApp bei externem und internem Zugriff auf den Server, funktioniert die DeskApp jeweils nur in einem Szenario. Die Kopano-DeskApp auf ein Notebook welches stationär und mobil genutzt wird kann die DeskApp also nur in einem Fall nutzen. Hinzu kommt, dass die DeskApp selbst Probleme mit vom Standard abweichenden Ports hat.
Für die Nutzung bzw. automatische Aktualisierung von Let’s Encrypt wurde ein auf Port 80 lauschender vHost eingeführt. Dieser vHost hebelte den Deep-Linking Schutz teilweise aus und ermöglichte auf installierte Webapplikationen einen unverschlüsselten Zugriff via Internet.
Die Anpassungen in invis-Server 13.0 konnten die Probleme nicht beheben. Grund genug für eine vollständige Überarbeitung.
Mit 13.1 wird der invis-Server keinen eigenständigen Apache-vHost für ownCloud mehr mitbringen. Statt dessen werden der Zugriff auf ownCloud, die Kopano-WebApp und z-Push (ActiveSync) in einem Apache vHost zusammen gefasst. Dieser vHost lauscht auf dem Standard-Port 443. Damit wird der Zugriff auf ownCloud nicht mehr von Proxy-Servern blockiert und die Kopano DeskApp kann so konfiguriert werden, dass der Zugriff sowohl von intern als auch via Internet funktioniert.
Weiterhin haben wir den vHost für das Auffrischen der Let’s Encrypt Zertifikate um einen Deep-Linking Schutz erweitert.
Wir haben alle Applikationsbezogenen Apache-Konfigurationen konsequent in Apache Server-Flags gesetzt. Das ermöglicht ein flexibles aktivieren und deaktivieren einzelner Applikationen.
Diese und einige weitere kleinere Konfigurationsanpassungen sollten das Setup übersichtlicher und sicherer gestalten.
Wie Sie manuell auf das neue Setup umsteigen können, haben wir bereits in unserem Wiki beschrieben.
Das offizielle Release des invis-Servers 13.1 steht kurz bevor. Spätestens zu den Chemnitzer Linux Tagen sollte es soweit sein. Als unstable Paket steht die Version bereits zum Testen über unsere Repositories zur Verfügung.