close Warning: Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.

#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)

IMG_0948.jpeg​ (144.3 KB ) - added by Rüdiger Kupper 16 months ago.
Fehler im Journal von collaboraserver
IMG_0949.jpeg​ (134.0 KB ) - added by Rüdiger Kupper 16 months ago.
Diskrepanz bei der Namensauflösung

Download all attachments as: .zip

Change History (18)

comment:1 by Rüdiger Kupper, 16 months ago

Cc: hill netzwerk added

@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?

by Rüdiger Kupper, 16 months ago

Attachment: IMG_0948.jpeg​ added

Fehler im Journal von collaboraserver

by Rüdiger Kupper, 16 months ago

Attachment: IMG_0949.jpeg​ added

Diskrepanz bei der Namensauflösung

comment:2 by Rüdiger Kupper, 16 months ago

Im Journal des Collaboraservers sehe ich diese Fehler, die ich vorher nie gesehen habe (siehe Anhang). 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 Anhang).
Das kann doch für Verbindungen zwischen unseren Servern nicht richtig sein?

Version 3, edited 16 months ago by Rüdiger Kupper (previous) (next) (diff)

comment:3 by Rüdiger Kupper, 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 bau, 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?

comment:5 by bau, 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 bau, 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.

comment:7 by bau, 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 Rüdiger Kupper, 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 Rüdiger Kupper, 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 Rüdiger Kupper, 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 Rüdiger Kupper, 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 …

in reply to:  5 comment:12 by Rüdiger Kupper, 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 Rüdiger Kupper, 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.

in reply to:  7 comment:14 by Rüdiger Kupper, 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 Rüdiger Kupper, 16 months ago

Cc: hill removed

Ach so, klar, die /etc/resolv.conf hat sich ja auch wieder geändert, siehe comment:12 oben.

comment:16 by Rüdiger Kupper, 16 months ago

Resolution: → erledigt
Status: new → closed

Namensauflösung funktioniert jetzt, Problem tritt nicht mehr auf.

Note: See TracTickets for help on using tickets.