Seafile Pro 7.0.9 / Ubuntu 18.04 Problem Zugriff hängt nach kurzer Zeit

mipo · February 4, 2020, 3:02pm

Hallo zusammen,

ich habe die Seafile Pro 7.0.9 Ubuntu Version auf einem Ubuntu 18.04 OS (Strato) gemäß nachfolgender
Installationsanleitung installiert: “How to Install Seafile with Nginx on Ubuntu 18.04 LTS”

Die Installation lief eigentlich problemlos durch. Ich habe nur das Problem, dass der Zugriff per Webbrowser als auch über den Seafile Client nach kurzer Zeit langsam und später abbricht. Nach einem Reboot des Servers ist wieder alles normal schnell.

Ich habe mir schon in den letzten Tagen einiges durchgeschaut, aber nichts schlüssiges gefunden. Ich hoffe, das ist ein gängiges Problem. Ich würde mich, als Newbie in Seafile, über eure hilfreiche Unterstützung sehr freuen!

Ich vermute einmal, es ist die Schnittstelle nginx bzw. die Parametrisierung? …

Viele Grüße
Michael

rdb · February 4, 2020, 4:50pm

Willkommen im Seafile Community Forum! Mal sehen ob wir Dir helfen können.

Das hoffe ich nicht, denn das wäre kein positives Merkmal für Seafile!

Die Fehlerbeschreibung von Dir ist leider nicht eindeutig, kannst Du präzisieren:

Login möglich?
Upload von Dateien über Seahub möglich (zumindest für eine gewisse Zeit)?
Download von Dateien über Seahub möglich
Erzeugung von Freigabelinks und erfolgreicher Abruf darüber?

Ansonsten ist es auch immer hilfreich, wenn Du Deine Config-Dateien und/oder Log-Files hier postest. Weil wie sollen wir analysieren, wenn wir nur eine unpräzise qualitiative Problembeschreibung haben?

Ralf

mipo · February 4, 2020, 5:55pm

Hallo Ralf,

vielen Dank, dass Du Dich gemeldet hast! Ist mein erster Post hier im Forum und wie Du siehst, auch meine ersten Gehversuche mit Seafile Pro …

Nach dem Reboot ist für eine gewisse Zeit ein Login über die Webgui als auch über den Windows und iOS Client möglich. Nach gefühlten 10 Minuten wird der Zugriff immer langsamer und nach einiger Zeit kann man sich überhaupt nicht mehr einloggen. Also der Post der Anmeldemaske bringt die die “Eieruhr”.

Up- und Download geht solange, wie das System reagiert. Die Erzeugung von Freigabelinks habe ich noch nicht getestet, dafür hatte ich bisher keinen Bedarf. Daher habe ich das Thema einmal ausgespart.

Ich weiß ehrlich gesagt auch nicht, welche Logfiles wirklich sinnvoll sind und die Konfigurationsdateien ebenso. Ich habe wie ich oben schrieb, die Konfiguration weitestgehend so durchgespielt wie in dem HowTo beschrieben. Hab natürlich logischerweise den Usenamen “mohammad” entsprechend auf “michael” bzw. für die Seafile Installation “seafile” abgepasst.

Anmerken möchte ich nich, dass der Server Dualstack läuft, also IPv4 +IPv6. DNS weist einen A und AAAA Record auf die Serverurl auf: seacloud xxdomainxx de (Leerzeichen durch “.” ersetzen)

Solltest Du noch weitere Infos benötigen sag welche …

Man kann auch, am Abend eine TeamViewer Session machen …

Viele Grüße
Michael

P.S: So ein Mist, wie kann ich hier die Konfigdateien posten? Sind nur Dateien ohne Link erlaubt

mipo · February 5, 2020, 10:40am

Hallo zusammen,

ich habe schon zwei Seafile HowTo’s durchinstalliert mit mäßigem Erfolg. Könnt ihr mir ein wirklich perfekt funktionierendes HowTo für die Seafile Pro 7.0.9 unter Ubuntu 18.04 empfehlen?

Mein obiges Problem ist nach kleineren Änderungen deutlich stabiler geworden, aber vielleicht doch noch nicht perfekt. Änderungen in der Konfig mit ** makiert **.

/etc/nginx/sites-available/seafile

server {
    listen 80;
    **listen [::]:80;**
    server_name  seacloud.xxdomainxxx.de;
    rewrite ^ https://$http_host$request_uri? permanent;
    server_tokens off;
}
server {
    listen 443 ssl http2;
    **listen [::]:443 ssl http2;**
    server_name seacloud.xxdomainxxx.de;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/seacloud.poremski.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/seacloud.poremski.de/privkey.pem;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:5m;

    ssl_dhparam /etc/nginx/dhparam.pem;

    #SSL Security
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_ecdh_curve secp384r1;
    ssl_prefer_server_ciphers on;
    server_tokens off;
    ssl_session_tickets off;

    proxy_set_header X-Forwarded-For $remote_addr;

    location / {
        proxy_pass         http://127.0.0.1:8000;
        proxy_set_header   Host $host**:8001**;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_read_timeout  1200s;

        # used for view/edit office file via Office Online Server
        client_max_body_size 0;

        access_log      /var/log/nginx/seahub.access.log;
        error_log       /var/log/nginx/seahub.error.log;
    }

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        proxy_pass http://127.0.0.1:8082;
        client_max_body_size 0;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;
        send_timeout  36000s;
    }
    location /media {
        root /home/seafile/seafile-server-latest/seahub;
    }
}

ccnet.conf

[General]
USER_NAME = Seacloud-Server
ID = ecbfc7e16876axxxxxxxxxxxx54415077661f30
NAME = Seacloud-Server
#SERVICE_URL = https://seacloud.xxxdomainxxx.de:8000
**SERVICE_URL = https://seacloud.xxxdomain.xxx.de:443**


[Client]
PORT = 13419

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = seafile
PASSWD = blablablabla
DB = ccnet-db
CONNECTION_CHARSET = utf8

seahub.error.log
War gestern vor der Änderung der Ports in ccnet.conf und seafile (siehe oben)

2020/02/04 13:56:56 [error] 12411#12411: *5 upstream prematurely closed connection while reading
response header from upstream, client: xx.xx.xx.xx, server: seacloud.xxxdomainxxx.de, request: "GET
/ HTTP/2.0", upstream: "http://127.0.0.1:8000/", host: "seacloud.xxxdomainxxx.de", referrer:
"https://seacloud.xxxdomainxxx.de/accounts/login/?next=/"

Frage:
Vorher war als SERVICE_URL in der ccnet.conf der Port 8000 angegeben. Ist hier meine Änderung korrekt auf 443?

Viele Grüße + Dank
Michael

rdb · February 5, 2020, 11:48am

Hi Michael,

warum vergleichst Du nicht einfach Deine Konfiguration mit der offiziellen Anleitung unter manual.seafile.com. Da wirst Du gleich mehrere Abweichungen finden. Nichts anderes würde ich machen.

Beispiel:

Dazu steht hier was: https://download.seafile.com/published/seafile-manual/deploy/https_with_nginx.md#user-content-ccnet%20conf . Konkret war der Port 8000 natürlich Quark. Den Port 443 kannste weg lassen, das ist der Standardport bei https.

Ich komme übrigens problemlos auf https://seacloud.poremski.de/

Ralf

mipo · February 5, 2020, 12:24pm

Hallo Ralf,

ganz herzlichen Dank für den Tip mit der offiziellen Doku. Die arbeite ich einmal durch
Genau danach habe ich gesucht, aber wohl (wie immer) den Wald vor lauter Bäumen nicht gesehen.

Bei der Gelegenheit:
Es gibt zwei Seafile Pro 7.0.9 Installationsarchive. Ich installiere unter Ubuntu 18.04 LTS und ich nehme doch einmal sehr stark an, dass ich das mit dem Zusatz “Ubuntu” nehmen muss. Sind die Unterschiede so groß, dass ein eigenes Archiv genutzt werden muss?

Gruß
Michael

mipo · February 7, 2020, 1:27pm

Hallo Ralf,

kurze Rückmeldung. Nach der Anpassung an die offizielle Doku läuft das System deutlich stabiler. Ein “Hänger” kam zwar noch 1-2 mal vor, aber das ist schon 2 Tage her. Mal schauen.

Viele Grüße
Michael

rdb · February 7, 2020, 2:55pm

Sehr gut. Danke für die Rückmeldung.

mipo · February 13, 2020, 11:35am

Hallo Ralf,
Hallo @ALL,

das Problem besteht weiterhin, sobald ich auf dem Strato VServer IPv6 aktiviere. Unter IPv4 lief es deutlich stabiler, habe ich ja oben beschrieben, aber auch nicht absolut störungsfrei.

Die Login Maske kommt in 85% aller Fälle, nach dem Login dauert es nach dem Reboot des Servers wenige Sekunden bis zur Anwendung. Nach einer Weile dauert der Login gefühlt “ewig” bis funktioniert gar nicht. Auch wenn ich mich Anfangs erfolgreich in Seafile Anwendung einloggen konnte, “hängt” die Anwendung nach einer Weile z.B. beim Wechsel der Menüs …

Ich kenne natürlich noch nicht die Funktionsweise von Seafile im Detail. Ich vermute einmal, da NGINX der Dreh- und Angelpunkt ist, was die https:// Kommunikation betrifft hier ein Problem vorliegt. Gibt es hier ggf. ein Resourcenproblem? Wie kann man das Problem gescheit debuggen?

Ich kann mir doch kaum vorstellen, dass die 7.0.9 Pro Version einen gravierenden Bug hat, der nur bei mir auf dem Strato VServer auftritt. - Bei einem Singleuser mit 5 Endgeräten.

Ich suche schon seit Tagen nach dem Fehler …

Viele Grüße
Michael

mipo · February 13, 2020, 1:11pm

Nachtrag:

Ich habe in den Logs mal ein wenig gestöbert:

[02/13/20 14:06:50] seafile-controller.c(109): spawned /home/seafile/seafile-server/pro/elasticsearch/bin/elasticsearch, pid 7431
[02/13/20 14:07:00] seafile-controller.c(594): pid file /home/seafile/pids/seafdav.pid does not exist
[02/13/20 14:07:00] seafile-controller.c(631): seafdav need restart...
[02/13/20 14:07:00] seafile-controller.c(94): spawn_process: /usr/bin/python2.7 -m  wsgidav.server.run_server --log-file /home/seafile/logs/seafdav.log --pid /home/seafile/pids/seafdav.pid --port 8080 --host 0.0.0.0
[02/13/20 14:07:00] seafile-controller.c(109): spawned /usr/bin/python2.7, pid 7489
[02/13/20 14:07:00] seafile-controller.c(594): pid file /home/seafile/pids/elasticsearch.pid does not exist
[02/13/20 14:07:00] seafile-controller.c(637): elasticsearch need restart...
[02/13/20 14:07:00] seafile-controller.c(94): spawn_process: /home/seafile/seafile-server/pro/elasticsearch/bin/elasticsearch -Epath.logs=/home/seafile/logs -Epath.data=/home/seafile/pro-data/search/data -Enetwork.host=127.0.0.1 -p /home/seafile/pids/elasticsearch.pid
[02/13/20 14:07:00] seafile-controller.c(109): spawned /home/seafile/seafile-server/pro/elasticsearch/bin/elasticsearch, pid 7490
[02/13/20 14:07:10] seafile-controller.c(594): pid file /home/seafile/pids/seafdav.pid does not exist
[02/13/20 14:07:10] seafile-controller.c(631): seafdav need restart...
[02/13/20 14:07:10] seafile-controller.c(94): spawn_process: /usr/bin/python2.7 -m wsgidav.server.run_server --log-file /home/seafile/logs/seafdav.log --pid /home/seafile/pids/seafdav.pid --port 8080 --host 0.0.0.0
[02/13/20 14:07:10] seafile-controller.c(109): spawned /usr/bin/python2.7, pid 7549
[02/13/20 14:07:10] seafile-controller.c(594): pid file /home/seafile/pids/elasticsearch.pid does not exist
[02/13/20 14:07:10] seafile-controller.c(637): elasticsearch need restart...
[02/13/20 14:07:10] seafile-controller.c(94): spawn_process: /home/seafile/seafile-server /pro/elasticsearch/bin/elasticsearch -Epath.logs=/home/seafile/logs -Epath.data=/home/seafile/pro-data/search/data -Enetwork.host=127.0.0.1 -p /home/seafile/pids/elasticsearch.pid

Warum werden die *.pids nicht angelegt bzw. die Services nicht gestartet?

Viele Grüße
Michael

mipo · February 18, 2020, 3:12pm

Hallo @ALL,

keiner eine Idee oder eine Lösung?

Ich habe zwischenzeitlich den Server komplett neu eingerichtet und etliche Stunden mit Recherche und Fehlersuche verbracht. Das System läuft deutlich stabiler, aber ich musste den Server heute im Laufe des Tages 3 x booten, da weder der Seafile Client synchronisierte noch die Webgui aufgerufen werden konnte.

Ich vermute einfach einmal, dass es bestimmte Abhängigkeiten oder Inkompatibilitäten im Bereich Phyton 2.7 und deren Module gibt. Auch der oben genannte Webdav Fehler geht meines Erachtens in diese Richtung. Bin ich wieder einmal zu “modern”, dass ich auf Ubuntu 18.04 LTS gesetzt habe?

Was mich wundert ist, dass der WEBDAV Dienst wohl nicht gestartet werden kann, wohl aber ich übers Mobilfunktelefon (Enpass Passwortmanager) darauf zugreifen kann. Ich nehme einmal an, dass die ganze “spawnerei” das System irgendwann zum Absturz bringt. X-Leute berichten darüber, aber keiner hat eine Lösung gepostet …

Kätzerische Frage: Bin ich mal wieder der Einzige, der diese Probleme hat? Das muss doch in den Griff zu bekommen sein!

Würde mich auf Hilfe von der Community bzw. @rdb sehr freufen.

Viele Grüße
Michael

shoeper · February 18, 2020, 6:15pm

Welche Virtualisierung wird denn verwendet? Bei OpenVZ sind beispielsweise oft sehr leicht zu erreichende Ressourcen Limits konfiguriert.

mipo · February 18, 2020, 6:36pm

Hallo Sven,

das ist eine sehr gute Frage. Läuft auf einem Strato V30-8 Server. Ich vermute einmal, da Plesk installiert werden könnte, dass es sich um einen Virtuozzo VM handelt. Müsste ich klären. Die Idee hatte ich auch
schon, das irgendein OS Limit hier überläuft.

Hast Du eine Idee, wie man das herausbekommt?

Währenddessen ist eigentlich einen “Single-User-Anwendung”. Aber sind doch einige Prozesse die hier im Hintergrund laufen.

Gruß
Michael

rdb · February 19, 2020, 8:53am

Ich kann aus eigener Erfahrung sagen, dass wir im Jahr 2018 und 2019 duzende Seafile Systeme (CE und PE) auf Strato V-Servern eingereichtet haben. Und ja, wir haben Ubuntu 18.04 verwendet. Damals wurde von Strato auch Virtuozzo verwendet.

In jüngster Vergangenheit haben wir auf netcup VServer umgestellt. Daher habe ich keine direkte Erfahrung mehr. Würde mich aber wundern, wenn sich da so schnell etwas geändert hat.

Zu Deiner Frage: Ich kenne Deine Probleme nicht aus anderen Fällen. Seafile als Schuldigen zu identifzieren ist einfach - viel zu einfach. Aufgrund unserer guten Erfahrungen mit Strato VServern vermute ich weiterhin Konfigurationsfehler. Die geringere Stablität bei Aktivierung von IPv6 spricht ganz klar dafür.

mipo · February 19, 2020, 9:26am

Hallo Ralf,

ich vermute auch kein direktes Problem mit Seafile. Das Produkt an sich macht einen sehr guten Eindruck.

Wie bewertest Du denn das WEBDAV Problem:

seafdav.log

[2020-02-19 10:00:27,694]:  Init seahub database...
[2020-02-19 10:00:37,743]:  Init seahub database...
[2020-02-19 10:00:47,714]:  Init seahub database...

wiederholt sich endlos ...

controller.log

 [02/19/20 10:01:17] seafile-controller.c(94): spawn_process: /usr/bin/python2.7 -m wsgidav.server.run_server --log-file /opt/seafile/haiwen/logs/seafdav.log --pid /opt/seafile/haiwen/pids/seafdav.pid --port 8080 --host 0.0.0.0
 [02/19/20 10:01:17] seafile-controller.c(109): spawned /usr/bin/python2.7, pid 1494
 [02/19/20 10:01:27] seafile-controller.c(594): pid file /opt/seafile/haiwen/pids/seafdav.pid does not exist
 [02/19/20 10:01:27] seafile-controller.c(631): seafdav need restart...
 [02/19/20 10:01:27] seafile-controller.c(94): spawn_process: /usr/bin/python2.7 -m wsgidav.server.run_server --log-file /opt/seafile/haiwen/logs/seafdav.log --pid /opt/seafile/haiwen/pids/seafdav.pid --port 8080 --host 0.0.0.0

pip list

asn1crypto (0.24.0)
certifi (2018.1.18)
chardet (3.0.4)
cryptography (2.1.4)
enum34 (1.1.6)
idna (2.6)
ipaddress (1.0.17)
keyring (10.6.0)
keyrings.alt (3.0)
mysqlclient (1.3.10)
olefile (0.45.1)
Pillow (5.1.0)
pip (9.0.1)
pyasn1 (0.4.2)
pyasn1-modules (0.2.1)
pycrypto (2.6.1)
pygobject (3.26.1)
PyICU (1.9.8)
pyOpenSSL (17.5.0)
python-ldap (3.0.0)
python-memcached (1.53)
pyxdg (0.25)
requests (2.18.4)
SecretStorage (2.3.1)
setuptools (39.0.1)
six (1.11.0)
urllib3 (1.22)
wheel (0.30.0)

Viele Grüße + Dank
Michael

mipo · February 21, 2020, 7:03pm

Hallo zusammen,

habe den Server seit gestern Abend zum Laufen bekommen.

Es lag ganz offensichtlich an dem Java Paket V11?, was installiert wurde. Ich habe den Server nochmals komplett platt gemacht und wie ich in einem Forenbeitrag las, openjdk-8-jre installiert. Danach lief (fast) alles wie am Schnürchen!

Einzig und allein, der Elastic Search Service muss nach einem Neustart des Servers manuell einmal gekillt werden. Doch hier half ebenfalls ein Beitrag aus dem Forum. Warum dieses Problem überhaupt noch existiert ist mir schleierhaft. Aber man muss nicht alles verstehen

Danke nochmals an ALLE hier im Forum, die mir versucht haben zu helfen.

Was in der Doku scheinbar fehlt, ist eine echte Dokumentation welche (getesteten!) Linux Pakete in welcher Reihenfolge installiert werden müssen. Also im Prinzip ein schlüssiges Installations-HowTo was wirklich funktioniert.

Übrigens: Auch Fail2Ban funktioniert nicht. Auch wenn die Zeitzone auf Europe/Stockholm steht, kann ich mich x-mal mit einem falschen Passwort versuchen einzuloggen. In den Logdateien wie seahub.log und fail2ban.log erscheint kein Hinweis.

In den nächsten Tagen werde ich mich mal an die Erweiterungen machen.

Habt ihr hier vielleicht ein paar Tips für mich? / Elastic Search und File2Ban Problem …

Viele Grüße + Dank
Michael