Opened 16 months ago
Closed 16 months ago
#5587 closed Defekt (erledigt)
Collaboraserver seit heute meistens nicht erreichbar
| Reported by: | Rüdiger Kupper | Owned by: | bau |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Schuljahr 2024/25 |
| Component: | Hardware: Netzwerktechnik | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | netzwerk |
Description
Seit heute gibt es massive Probleme beim Zugriff auf Office-Dokumente in der Kepler-Cloud. Der Collabora-Server ist die überwiegende Zeit nicht erreichbar. In ganz wenige, sporadisch auftretenden Fällen funktioniert der Zugriff aber doch. Bis gestern konnte ich noch ganz problemlos auf meine Office-Dokumente in der Cloud zugreifen, ich habe dort in den letzten Tagen regelmäßig meine Notentabellen bearbeitet und es gab nie ein Probolem. Erst seit heute gibt es diese massiven Störungen.
Attachments (2)
Change History (18)
comment:1 by , 16 months ago
| Cc: | added |
|---|
comment:2 by , 16 months ago
Im Journal des Collaboraservers sehe ich diese Fehler, die ich vorher nie gesehen habe. Es könnte damit zusammenhängen, dass der Name „cloud.kg-fds.de“ auf dem collaboraserver auf eine 129.143-er Adresse aufgelöst wird. (Siehe angehäntes Bild.)
Das kann doch für Verbindungen zwischen unseren Servern nicht richtig sein?
comment:3 by , 16 months ago
Wenn Serverzugriffe nur dann und wann funktionieren, dann deutet das meiner Erfahrung nach auf einen Fehler in der Netzwerkkonfiguration hin. Das passt auch zu den extremen Anmeldezeiten an den Rechnern (siehe die beiden vorangegangenen Tickets). Ich vermute, etwas an der derzeitigen Netzwerkkonfig ist faul und das sollten wir möglichst schnell korrigieren.
comment:4 by , 16 months ago
Namensauflösung in /etc/resolv.conf geht aktuell auf den BelWUE-Nameserver (129.143.2.1), der antwortet mit der externen Adresse 129.143.149.5. In /etc/hosts steht der cloud-Server drin mit 10.16.112.17.
Ich dachte bislang, dass /etc/hosts immer gewinnt?
follow-up: 12 comment:5 by , 16 months ago
Problem ist, dass wir für unsere Dienste externe IPs haben (129.143.2.1 - 129.143.2.5), intern aber die internen Adressen. Aktuell macht der dhcp.kg-fds.de (10.16.112.2) die Namensauflösung für das VLAN6 (Lehrnetz), der löst aber im KISS-Netz keine externen Adressen auf. Ich habe daher auf dem collaboraserver (10.16.112.20) einen weiteren DNS-Server eingerichtet, der die internen Adressen auflöst und zudem alles andere gegen den DNS der Stadt FDS erledigt:
root@collabora:/etc/dnsmasq.d# host cloud.kg-fds.de cloud.kg-fds.de has address 10.16.112.17 root@collabora:/etc/dnsmasq.d# ping -c1 cloud.kg-fds.de PING cloud.kg-fds.de (10.16.112.17) 56(84) bytes of data. 64 bytes from cloud.kg-fds.de (10.16.112.17): icmp_seq=1 ttl=64 time=0.280 ms
/etc/resolv.conf sieht so aus
nameserver 127.0.0.1 # --- BEGIN PVE --- search kg-fds.de nameserver 192.168.150.254 # --- END PVE ---
comment:6 by , 16 months ago
Anscheinend macht die Firewall der Stadt Freudenstadt irgendwas falsch:
root@collabora:~# nslookup freudenstadt.de 192.168.150.254 Server: 192.168.150.254 Address: 192.168.150.254#53 Non-authoritative answer: Name: freudenstadt.de Address: 134.119.0.33 ;; Got SERVFAIL reply from 192.168.150.254 ** server can't find freudenstadt.de: SERVFAIL
Ich habe mal den DNS 8.8.8.8 eingetragen:
root@collabora:~# nslookup freudenstadt.de Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: freudenstadt.de Address: 134.119.0.33 Name: freudenstadt.de Address: 2a00:116a:10a:6ad0::
Melde das an Herrn Notz.
follow-up: 14 comment:7 by , 16 months ago
Ich habe nun den 10.16.112.20 auf den Servern in der /etc/resolv (und in der pve-Konfiguration auf den Proxmoxen) eingetragen:
- nextcloud (10.16.112.16)
- apache (10.16.112.17)
- proxmoxls
- proxmoxls2
- proxmoxls3
- proxmoxls4
- proxmoxls5
Dass was mit der Namensauflösung nicht stimmt, merkt man, wenn der Login auf dem Server ungewöhnlich lange dauert. Das ist aktuell auf dem paedml so, ich denke, das verschwindet, sobald Herr Notz den Fehler auf der SOPHOS behoben hat.
comment:8 by , 16 months ago
Danke sehr!
Momentan lassen sich Office-Dokumente in der Cloud leider weiterhin nicht öffnen, muss da nachher nochmal ins Log schauen. Sehr seltsam, weil es ja bis vor zwei Tagen ging.
comment:9 by , 16 months ago
Jetzt sehe ich im Journal solche Meldungen, wenn ich versuche eine Office-Datei in der Cloud zu öffnen:
ul 16 11:44:35 collabora coolwsd[142]: wsd-00142-00442 2025-07-16 11:44:35.553390 +0200 [ websrv_poll ] ERR #66: Failed or timed-out CheckFileInfo [https://cloud.kg-fds.de/index.php/apps/richdocuments/wopi/files/102985246_ocsten688pqw?access_token=eA1kFp254gY8foCdpbKIboujHd6WtBUB&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:121
Das heißt, der collaboraserver hat von Nextcloud ein Zugriffstoken für die Datei erhalten, kann damit aber nicht auf die Datei zugreifen (bzw. es dauert zu lange).
Lange Zugriffszeiten sehe ich momentan auch generell in Nextcloud: Wechsle ich zur "Dateien"-App, dann dauert es lange Zeit, bis meine Dateien angezeigt werden. Früher ging das instantan.
Nextcloud hat also vielleicht das gleiche Problem wie die Rechner im LZ.
comment:10 by , 16 months ago
Kann ich auch an der Kommandozeile reproduzieren:
time wget "cloud.kg-fds.de/index.php/apps/richdocuments/wopi/files/102985246_ocsten688pqw?access_token=Fa5uHt5mjC47Qpg0qHi1Lssjwe501VQH&access_token_ttl=0" URL transformed to HTTPS due to an HSTS policy --2025-07-16 11:56:02-- https://cloud.kg-fds.de/index.php/apps/richdocuments/wopi/files/102985246_ocsten688pqw?access_token=Fa5uHt5mjC47Qpg0qHi1Lssjwe501VQH&access_token_ttl=0 Resolving cloud.kg-fds.de (cloud.kg-fds.de)... 10.16.112.17 Connecting to cloud.kg-fds.de (cloud.kg-fds.de)|10.16.112.17|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1417 (1.4K) [application/json] Saving to: '102985246_ocsten688pqw?access_token=Fa5uHt5mjC47Qpg0qHi1Lssjwe501VQH&access_token_ttl=0.2' 102985246_ocsten688pqw 100%[===========================>] 1.38K --.-KB/s in 0s 2025-07-16 11:56:42 (75.2 MB/s) - '102985246_ocsten688pqw?access_token=Fa5uHt5mjC47Qpg0qHi1Lssjwe501VQH&access_token_ttl=0.2' saved [1417/1417] real 0m40.374s user 0m0.008s sys 0m0.004s
Der Nextcloud Server liefert die Datei aus, es dauert aber 40 Sekunden, bis er antwortet! In der Zeit gibt der Collaboraserver vermutlich einfach auf.
comment:11 by , 16 months ago
Ja, collabora wartet genau 15 Sekunden lang und zeigt dann die Fehlermeldung an, dass die Datei nicht geöffnet werden kann. Das Problem ist derzeit also, dass der Nextcloudserver viel zu langsam antwortet.
Und da hab ich wiederum die Netzwerkkonfig im Verdacht …
comment:12 by , 16 months ago
Replying to bau:
Problem ist, dass wir für unsere Dienste externe IPs haben (129.143.2.1 - 129.143.2.5), intern aber die internen Adressen. Aktuell macht der dhcp.kg-fds.de (10.16.112.2) die Namensauflösung für das VLAN6 (Lehrnetz), der löst aber im KISS-Netz keine externen Adressen auf. Ich habe daher auf dem collaboraserver (10.16.112.20) einen weiteren DNS-Server eingerichtet, der die internen Adressen auflöst und zudem alles andere gegen den DNS der Stadt FDS erledigt:
root@collabora:/etc/dnsmasq.d# host cloud.kg-fds.de cloud.kg-fds.de has address 10.16.112.17 root@collabora:/etc/dnsmasq.d# ping -c1 cloud.kg-fds.de PING cloud.kg-fds.de (10.16.112.17) 56(84) bytes of data. 64 bytes from cloud.kg-fds.de (10.16.112.17): icmp_seq=1 ttl=64 time=0.280 ms/etc/resolv.conf sieht so aus
nameserver 127.0.0.1 # --- BEGIN PVE --- search kg-fds.de nameserver 192.168.150.254 # --- END PVE ---
Hast Du die resolv.conf wieder geändert?
root@collabora:~# less /etc/resolv.conf # --- BEGIN PVE --- search kg-fds.de nameserver 129.143.2.1 # --- END PVE ---
Oder ist der Eintrag nicht dauerhaft? Habe vorhin neu gebootet.
comment:13 by , 16 months ago
Oh, interessante Erkenntnis: das Problem scheint nur mich zu betreffen?!
Hill kann Dokumente öffnen und sieht auch die Dateienübersicht sofort. Mit dem "Testschüler" geht es genauso.
comment:14 by , 16 months ago
Replying to bau:
Ich habe nun den 10.16.112.20 auf den Servern in der /etc/resolv (und in der pve-Konfiguration auf den Proxmoxen) eingetragen:
- nextcloud (10.16.112.16)
- apache (10.16.112.17)
- proxmoxls
- proxmoxls2
- proxmoxls3
- proxmoxls4
- proxmoxls5
Da ist noch etwas faul, der DNS-Zugriff vom nextcloud-Server funktioniert nicht:
root@cloud:~# host rcloud.dynv6.net ;; communications error to 10.16.112.20#53: timed out ;; communications error to 10.16.112.20#53: timed out ;; no servers could be reached
comment:15 by , 16 months ago
| Cc: | removed |
|---|
Ach so, klar, die /etc/resolv.conf hat sich ja auch wieder geändert, siehe comment:12 oben.
comment:16 by , 16 months ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
Namensauflösung funktioniert jetzt, Problem tritt nicht mehr auf.
@bau:: ich kann mir nur vorstellen, dass das mit den heute stattgefundenen Notenkonferenzen zusammenhängt. Hast Du dafür irgendwelche Netzwerkrouten umgestellt? Wenn ja gibt es sehr wahrtscheinlich ein Problem bei der Netzwerkkonfiguration. Fällt Dir dazu etwas ein?