Pydio wird vom LD-Server in einem LXC Container als Virtuallisierungsschicht mitgeliefert. Nur dumm, dass die gesamte Konfiguration des LD-Servers immer über Subdomains läuft, was den Einsatz eines günstigen Zertifikats für nur eine Domain unmöglich macht, will man nicht auf self-signed zurückgreifen. Self-signed verbietet sich jedoch im schulischen Umfeld für die Dienste, die alle nutzen können sollten, weil man so die LuL und SuS dazu erzieht, Zertifikatswarnungen nicht ernst zu nehmen. Meine Lösung verwendet nun einen Apache Reverse Proxy [1], um die interne Pydio Domain extern in einem Unterverzeichnis der SSL-verschlüsselbaren Schuldomain einzublenden. Damit das klappt, müssen der Reverse Proxy Pound des LD-Servers mit dem Reverse Proxy Apache und dem NGinx im LXC-Container in Reihe geschaltet werden. Das geht so:

1. Kontrollieren ob der Symlink auf /etc/apache2/sites-available/pydio in /etc/apache2/sites-enabled weg ist (die Konfiguration findet an anderer Stelle statt).

2. In der /etc/apache2/sites-enabled/000-default die folgenden Einträge in den Abschnitt für VirtualHost * und auch in den Abschnitt für VirtualHost *:443 vornehmen:

ProxyRequests Off
   <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>
ProxyPass /pydio http://pydio/
ProxyPassReverse /pydio http://pydio/

3. In der /etc/logodidact/service.conf Pydio für die Domain, die man schon mit SSL versorgt, einschalten:

[Pydio]
Host sub.domain.tld
Alias pydio.sub.domain.tld
AllowExternalHTTPS yes
URL sub.domain.tld/pydio
RedirectExternalHTTP https://sub.domain.tld/pydio

4. Die beteiligten Dienste neu starten:

ldfirewall restart
update_pound_config -r
/etc/init.d/apache2 restart

Ein

host pydio

auf dem LD-Server muss eine Antwort liefern, sonst braucht man nicht weiterforschen, sondern muss die DNS Probleme in den Griff bekommen. Auch ein

links2 http://pydio
links2 https://pydio # weniger relevant, s.U.

sollte Ergebnisse liefern – mindestens eine Zeile HTML Code sollte zu sehen sein, mehr schafft links2 nicht, weil es kein JavaScript kann.

Der Aufruf von Pydio funktioniert dann reibungslos, wenn man den „trailing slash“ im URI zu Pydio nicht vergisst. Ohne diesen sieht man nur ein leeres Fenster. Alle Links für die Kolleg/innen und Schüler/innen sollten also so aussehen:

https://sub.domain.tld/pydio/

Jetzt funktioniert das Setup durchgehend ohne Zertifikatswarnungen und zumindest bis zum internen Reverse Proxy Pound auch verschlüsselt.

Wie und ob Pound dann dem Apache Reverse Proxy (als Übersetzer zwischen Internet und virtueller Pydio Maschine m LXC Container) die Daten verschlüsselt weiterreicht habe ich nicht geprüft. Ich vermute aber, auf Grund der Konfiguration, dass dem nicht so ist. Das sollte aber kein Problem darstellen, da an diesen Datenstrom nur root direkt auf dem Server rankommt.

Zu empfehlen ist eine Konfiguration von Pydio durch den Benutzer admin. Auf Pydio ist dieser mit den nötigen Rechten ausgestattet, weil der LXC Container über LDAP am LD-Server hängt. Hier sollte man alles abschalten was geht – vor allem die Funktionen zum unbegrenzten Teilen per Link und ohne Passwort. Denn: LD stellt Pydio extrem offen zur Verfügung. So offen, dass man aus Urheberrechts- und Datenschutzsicht Einschränkungen vornehmen muss, will man seine Schule und Schüler nicht ausliefern.

Weiter ist die Pydio Installation auch komplett veraltet (Version 5.0.4 – aktuell ist 6). Damit muss man wohl leben bei dieser Schulserverlösung. Deren Marketingabteilung wird das Konzept sicherlich als „bewährte Software“ verticken. Auf den bekannteren Exploit-DBs fand ich aktuell aber nichts, was Skript-Kiddies auf die Schnelle gegen Pydio einsetzen könnten.