Bloke on the Go

Zwei auf einen Streich…

Verfasst von

Bloke On-the-Go

in

Hallo zusammen. mit dieser kleinen Schimpftirade kann ich gleich zwei Themen auf einmal los werden, die mich die letzten Tage beschäftigt haben.

  • Die Unterscheidung zwischen Information und Wissen
  • Die Arbeit, die es macht, einen Server zu betreiben

Wie die Themen zusammen hängen? Ich zeig’s euch…

In einer Unterhaltung kam es neulich zu der Äußerung, dass ein (Nextcloud) Server, wenn er denn mal installiert ist, eigentlich keine Arbeit mehr macht. Allerdings stehen meine Erfahrungen aus dem Betrieb dieses Blogs (zugegeben, das ist WordPress, nicht Nextcloud) und meiner eigenen Nextcloud Instanz in einem starken Widerspruch zu der geäußerten Ansicht. Und ich will die Gelegenheit nutzen mal grob zu überschlagen, welche Themen mich die letzten Tage/Wochen so beschäftigt haben

Außerdem hatte ich vor einiger Zeit eine komische Diskussion, in der jemand der Meinung war, man müsste heute ja nichts mehr wissen, da man mit dem Smartphone „das gesamte Wissen der Welt“ immer dabei habe. Ich glaube, manche Leute müssen erst den Unterschied zwischen „Wissen“ und „Information“ lernen. Denn das, was ich im Handy nachschauen kann, ist erst mal nur Information. Jede Menge Information – zugegeben. Aber Information ohne Verständnis und ohne Kontext ist nur Informationsmüll.

Und darum gibt’s hier heute eine Menge Informationen. Vielleicht ja als Ausgangspunkt für eine Google Suche zum Nachlesen für alle, die daraus Wissen machen wollen. Aber zwei Punkte vorab, die man als Schnell-Lektion mitnehmen kann:

  • Es ist immer gut, ein Backup zu machen, bevor man an lebenswichtigen Konfigurationen herumdoktert, vor allem wenn es das Produktivsystem ist und keine Test-Instanz.
  • Wer wirklich wenig Arbeit mit Nextcloud haben will, der nutzt am Besten die Docker-basierten Lösungen des Herstellers, Nextcloud AIO (All In One)

Ausgangspunkt

Ich habe vor ein paar Tagen an einem Artikel hier im Blog geschrieben. Es war ein Entwurf, den ich schon vor einigen Monaten begonnen hatte und ich habe mich echt gewundert: Das Artikelbild konnte nicht geladen werden. Seltsam. Und auch die Pflege der Schlagworte und Kategorien war nicht möglich. Was war da los?

Ein kurzer Check hat gezeigt: Die JSON-API funktionierte nicht. Ich habe Plugins aktiv, die diese für nicht-angemeldete Benutzer blockieren, aber ich war ja am Artikel Schreiben – also angemeldet.

Vom Hölzchen aufs Stöckchen

Nach weiteren Analysen (und jetzt kommen die Informationen, die noch kein Wissen sind) hat sich ergeben:

  • Es war nicht das JSON Plugin, sondern W3 Total Cache, dass JSON außer gefecht gesetzt hat
  • Beim Wechsel auf eine Alternative habe ich gesehen, dass mit dem neuen Cache-Plugin die Antwortzeiten besser sind.
  • Beim Versuch das zu verstehen ist mir aufgefallen, dass die Webseiten nicht „gepackt“ also nicht via gzip ausgeliefert werden (auch Nextcloud nicht)
  • Nach langem Hin und Her habe ich das gzip-Probem gelöst, „gzip_types“ sind kleine Arschlöcher. Aber der TLS-Connect war noch auffällig langsam. Wieso eigentlich? Ich habe doch TLS 1.3 konfiguriert.
  • Bei der Auswahl der ecdh-curve, mit der festgelegt wird, wie die Schlüssel für eine sichere Verbindung ausgetauscht werden, wird nicht die BESTE gewählt, sondern vom Anfang der Liste die erste, die passt. Es hilft, den optimalen Algorithmus an den Anfang der Liste zu stellen.
  • Beim Versuch, das ursprüngliche Cache-Plugin – für das es zwischenzeitlich eine Korrektur gab – wieder zu nutzen und besser zu konfigurieren ist mir aufgefallen, dass mir das Zusammenspiel zwischen Cache, gzip und dynamischen Seiten (PHP) zu kompliziert und fehleranfällig ist. Wann werden Dateien durch den PHP-Code der Anwendung gepackt und abgelegt? Wann durch den Webserver selbst ausgeliefert, ohne durch den Code zu laufen? Was ist wann schneller? Also bin ich bei den ursprünglich als Übergangslösung gedachten Cache-Plugins geblieben.
  • In dem Zusammenhang habe ich die local (APCu), remote (REDIS) und File-Locking (REDIS) Caches der Nextcloud-Konfiguration überarbeitet und den OPCache für PHP angepasst.
  • Dabei sind mir zwei weitere Parameter aufgefallen, die noch aus der Steinzeit meiner Installation stammen und eigentlich an den seit einem Jahr im Einsatz befindlichen Server angepasst hätten werden müssen:
    • Das PHP Memory Limit saß noch bei 512 MB, was bei 8GB RAM Sinn ergibt. Seit einem Jahr stehen aber 64GB zur Verfügung, daher hab ich auf 1GB erhöht.
    • Die Anzahl der im OPCache maximal vor zu haltenden Dateien wurde von 10.000 auf 30.000 erhöht.

Merke: Wenn man sich auch nur halbwegs um eine vernünftige Konfiguration kümmern und diese aktuell halten will, dann ist das NICHT kein Aufwand.

Merke auch: ChatGPT und Gemini sind dabei nicht uneingeschränkt zu gebrauchen. Sie liefern oft halb-richtige Konfigurationsvorschläge, die man am Ende doch noch gegen die offizielle Dokumentation und Fachforen abgleichen muss. Es kotzt mich ehrlich an, dass dann bei Nachfragen der Standardsatz kommt: „Du hast Recht, da habe ich mich wohl geirrt…“. Ich habe der KI mehr als einmal gesagt, dass sie ein unnützer, CO2 verbrauchender Haufen Elektroschrott ist.

So, jetzt geht’s besser 😉
Bloke

P.S.: Und ganz nebenbei kann man sich ja auch noch um die Physik kümmern. Unser Heimnetz hat vor ein paar Wochen einen neuen Switch bekommen, der den Backbone beschleunigt – der silberne Kasten in der Mitte. Der Vorgänger war schon ein bisschen am Limit.

P.P.S.: Das Bild oben zeigt den bis vor Kurzem im Einsatz befindlichen Switch im Keller. Der war nicht nur komplett belegt sondern auch phasenweise beim Durchsatz voll ausgelastet.