Reverse Proxy + Let`s Encrypt

Guten Abend,

ich spiele derzeit mit dem Gedanken von Nextcloud auf Seafile zu wechseln und teste derzeit Seafile. Die Installation hat so weit geklappt und ich kann Seafile intern über die IP-Adresse aufrufen, nachdem ich in der gunicorn.conf den Eintrag auf bind = “0.0.0.0:8000” geändert habe.

Seafile nutzt “gunicorn” als eigenen Webserver und per Default ist dort die IP-Adresse auf 172.0.0.1:8000 gesetzt. Ist diese Einstellung dafür vorgesehen das ein Separater Reverse Proxy angewandt wird?

Mein Setup sieht folgendermaßen aus:

VM1 = Apache Reverse Proxy
VM2 = Nextcloud_1
VM3 = Nextcloud_2
VM4 = Nextcloud_3

Was wäre in meinem Fall der Best practise von der Konfiguration auf dem Reverse Proxy sowie den Seafile VM’s. Mir fehlt gerade das Verständnis wie ich das ganze konfigurieren soll. Ob ich es über gunicorn einrichten soll oder auf den Seafile VM´s auch Apache installieren soll. Dann wäre die nächste frage: Welcher angaben benötigt der Reverse Proxy VM und was die Seafile VM’s

Ich hoffe, ihr könnt mir etwas licht ins Dunkle bringen.

Liebe Grüße Synnefo

Ich bin sicher, dass ist 127.0.0.1:8000, nicht 172…

Idealerweise wird Seafile definitiv mit einem Reverse Proxy wie nginx oder Apache betrieben. Die Anleitung dazu findest Du im Seafile Manual. Den Teil für die Einrichtung des Proxys mit Apache findest Du hier: https://download.seafile.com/published/seafile-manual/deploy/deploy_with_apache.md Alternativ wird in diesem Video-Tutorial auch erklärt, wie man den Zugriff auf Seafile per Reverse Proxy einrichtet (in dem Video aber mit nginx).

Kurz gesagt musst Du einfach einen zusätzlichen VirtualHost (Apache) bzw. Server Block (nginx) in der Webserver Konfiguration anlegen.

Probiers doch mal. Dann kann man Dir auch spezifischer helfen.

Ja ich meinte 127.0.0.1…

Die Manual habe ich mir angeschaut. Korrigiere mich wenn ich falsch liege…
in der Manual wird auf den localhost verwiesen aber mein Reverse Proxy liegt nicht auf der selben vm wie Seafile.

Siehe: <VirtualHost :80>
ServerName meinecloud.com
DocumentRoot /var/www
Alias /media /home/user/haiwen/seafile-server-latest/seahub/media

RewriteEngine On

<Location /media>
Require all granted


#
# seafile fileserver
#
ProxyPass /seafhttp http://127.0.0.1:8082
** ProxyPassReverse /seafhttp http://127.0.0.1:8082
*
RewriteRule ^/seafhttp - [QSA,L]

#
# seahub
#
SetEnvIf Authorization “(.*)” HTTP_AUTHORIZATION=$1
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8000/
** ProxyPassReverse / http://127.0.0.1:8000/**
</VirtualHost

Mein Reverse Proxy ist eine eigene VM 192.168.178.201. Hierüber laufen mehrere Webdienste: 3 x Nextcloud und bitwarden, piHole etc.
Die Seafile VM ist 192.168.178.202.
Habe es mehrmals neu installiert und konfiguriert. Ich erreiche entweder nix oder nur den Reverse Proxy. Dieser leitet es aber nicht weiter. Das Seafile mit einem eigenen Webserver kommt schaffe ich es nicht es richtig zu konfigurieren -_-! Wie im ersten Thread fehlt mir gerade das Verständnis. Hat hier jemand eine ähnliche Konfiguration und kann mit paar Tipps geben ?
Oder soll ich statt auf der Seafile VM bind 127.0.0.1 bind auf die von mir vergebene IP der Seafile vm setzen (192.168.178.202)?

Oder liegt das Problem beim non Root User Seafile ?

Danke & Liebe Grüße Synnefo

Was deine Konfiguration für den Reverse Proxy aktuell tut, ist, dass sie alle Anfragen, die seahub bekommen soll an 127.0.0.1:8000 weiterleitet. Alle Anfragen für den Fileserver gehen an 127.0.0.1:8082. Die IP-Adresse 127.0.0.1 ist für die lokale Maschine reserviert, das heißt, die gesamten Anfragen leitet der Reverse Proxy nicht an die Seafile-VM, sondern an sich selbst auf die Ports 8000 und 8082.

Zusätzlich dazu, versucht der Reverse Proxy auch noch alle Dateien unter /media im lokalen Dateisystem zu finden.

Ich gehe davon aus, dass das insgesamt dein Problem ist.

Es gibt nun zwei Möglichkeiten, das zu lösen:

  1. Du richtest auch noch auf der Seafile-VM einen Reverse Proxy ein und dein eigentlicher Reverse Proxy leitet dann alles an diesen weiter.
  2. Du leitest von deinem Reverse Proxy direkt an Seafile Fileserver bzw. Seahub weiter.

Die 1. Lösung hätte den Vorteil, dass dadurch nicht der eingebaute Webserver von Seafile (gunicorn) die Anfragen unter /media bedienen müsste, allerdings entsteht durch den zusätzlichen Reverse Proxy natürlich auch wieder Konfigurationsaufwand.

Deswegen hier mal die 2. Lösung etwas genauer:
Wie schon oben geschrieben, darf dein Reverse Proxy nicht an sich selbst, sondern er muss an die Seafile-VM weiterleiten. Die wichtigen Änderungen hierzu sind dann:

# ...
# Das muss raus, da der Reverse Proxy keinen Zugriff  auf diese Dateien hat. 
# Stattdessen liefert gunicorn (der eingebaute Webserver) diese Dateien dann selbst.
# Also einfach auskommentieren oder entfernen: 
# Alias /media /home/user/haiwen/seafile-server-latest/seahub/media

# genauso wie:
# <Location /media>
# Require all granted

# ...

#
# seafile fileserver
#
# An Fileserver auf Seafile-VM weiterleiten:
ProxyPass /seafhttp http://192.168.178.202:8082
ProxyPassReverse /seafhttp http://192.168.178.202:8082

# ...

#
# seahub
#

# ...

# Normale Anfragen an gunicorn auf Seafile-VM weiterleiten
ProxyPass / http://192.168.178.202:8000/
ProxyPassReverse / http://192.168.178.202:8000/

# ...

Alle anderen Zeilen, die ich nicht erwähnt habe, einfach so lassen.

Ich persönlich benutze allerdings nginx, weshalb ich das nicht testen konnte. Es müsste aber so funktionieren.

Bei gunicorn auf der Seafile VM solltest du tatsächlich noch für diese Lösung (bei Lösung 1 bräuchte man das nicht) das bind auf 0.0.0.0:8000 setzen, damit man das auch von außerhalb der VM erreicht.

Interessant wäre dann natürlich auch noch HTTPS, was allerdings dann nicht mehr so schwer ist (einfach die relevanten SSL-Parameter in der Configuration von Apache hinzufügen und den Port ändern). Da kann man dann eigentlich den Eintrag aus dem Seafile Manual verwenden: https://download.seafile.com/published/seafile-manual/deploy/https_with_apache.md

Ich hoffe, ich konnte dir weiterhelfen. Wenn es doch noch Probleme geben sollte, einfach melden :slight_smile:.

1 Like

Guten Morgen,

Ich habe jetzt soweit alles zum laufen bekommen. Jedoch funktioniert seit dem ich auf https:// gewechselt bin der Avatar nicht mehr.
Alles andere funktioniert tadellos (Upload, Download, Share)

Habt ihr dort eine Idee?

Edit: Habe WebDAV konfiguriert. Anmeldung funktioniert es fehlt jedoch oben Links nach der Anmeldung im WebDAV ein Bild/Avatar.

Liebe Grüsse Synnefo

Schön zu hören, dass es jetzt klappt.

Für die Avatar Problematik habe ich vier Tipps:
1.) lokalen Browser Cache löschen
2.) Seahub Cache in /tmp/seahub_cache löschen
3.) Memcached Cache löschen (falls im Einsatz)
4.) Prüfen ob das Default Avatar Bild in /seahub_data/avatars ggf. defekt ist bzw. die Berechtigungen richtig sind

1 Like