Forum:Unbefriedigende Situation

Forum > Unbefriedigende Situation

Hinweis: Dieser Fred wurde seit 1052 Tagen nicht bearbeitet. Dieser Fred ist offiziell versandet - die Diskussion damit Geschichte. Bitte nichts mehr hinzufügen.
Bei Bedarf dann halt einen neuen Fred starten oder diesen notfalls reanimieren.

WTF!

Jetzt buddel ich dieses alte Sticky-Thema wieder aus, weil ich grad in größerem Umfang frustriert bin. Anlass der Erregung: Das völlig veraltete Youtube-Widget. Vor geräumlicher Zeit und lange bevor ich zum Kameltreiber geschlagen wurde, habe ich mich hier schon mal darüber geärgert. Unser Youtube-Widget verwendet die inzwischen völlig veraltete APIv1, welche insbesondere in Non-Chromium-basierten Browsern seitens Google stark beschnitten ist. Zum Beispiel zeigt Firefox keine Vollbild-Funktion an.

Also hab ich versucht, ein alternatives Template ("Youtube2") anzulegen, um die neue APIv2 anzusprechen. Das geht aber völlig in die Hose, weil unser Mediawiki weder <object> noch <iframe> erlaubt. Nächste Idee: Die fehlenden HTML-Tags per Javascript-Sideload über die common.js und jQuery hinzubasteln. Da wurde mir erstmal klar, WIE alt unser MediaWiki eigentlich ist (v1.23alpha = 2013!) und da gabs noch nicht mal eine common.js. Also erstmal eine Runde gehirnt, wie das damals war: wikibits.js.

Weil sich MediaWiki hartnäckig weigert, mich als fast-allmächtigen Kameltreiber diese Datei bearbeiten zu lassen (mal wird sie nicht gefunden, mal kackt MediaWiki mit einem Internal Error ab), bin ich beim Herumstolpern darauf gestoßen:

http://kamelopedia.net/skins/common/

Das ist gleich doppelt erschreckend: 1. Das Verzeichnis lässt sich listen und 2. Kamel beachte die Versionsnummer vom Apache-Webserver (2.2.22) - Diese wurde vor fast NEUN JAHREN abgelöst!

Machen wir uns mal keine Illusionen: Ein Apache 2.2.22 ist gar nicht in der Lage, ein aktuelles PHP anzusprechen. MediaWiki 1.23 lief mit PHP 5.3 und das letzte kompatible wäre 5.3.29 gewesen - mindestens SIEBEN JAHRE alt!

Vom PHP kommt man dann zu MySQL, das bei MediaWiki 1.23 @ PHP 5.3 höchstens die MySQL-Version 5.0.x gewesen sein kann - dafür finde ich adhoc noch nicht mal mehr ein EOL Datum. Muss aber vor Dezember 2013 gewesen sein.

Sorry wenn ich jetzt mal deutlich werde: WTF ist das für ein abgefuckter Zustand?!? Eigentlich stellt sich hier die Frage doch schon gar nicht mehr, OB dieser Server gehackt werden KANN. Man kann eigentlich davon ausgehen, dass er längst gehackt IST. Das übernehmen in der Regel bei so alten Versionsständen schon frei verfügbare Bot-Kits.

Also ich stelle jetzt ernsthaft zur Diskussion, die Kamelo zu forken wenn Sloyment sich nicht endlich mal kümmert. Die Situation ist unhaltbar!

--Wüstenspitz (Diskussion) 01:21, 25. Aug. 2021 (NNZ)

Jetzt hab ich eine Nacht drüber geschlafen und nun ist mir noch ein Punkt eingefallen, der mir Sorgen macht. Ich meine mich zu erinnern, dass im Zuge der Übergabe von J* an Sloyment gesagt wurde, die Kamelo liefe auf einem Dedicated Server. Ist der jetzt auch wie die Software sieben bis neun Jahre alt und läuft seitdem durch? Wäre dem so, dann ist das ein sehr hohes Ausfallrisiko. Gibt es überhaupt irgendeine Datensicherung und wenn ja, wurde die mal getestet?

Die Kamelo ist nur ein Hobby. Aber neben dem vielen GaGa gibt es auch eine Menge tiefgründiger Satire aus vielen Jahren. Ginge das verloren, aus welchem Grund auch immer, es wäre schon ein Verlust.

--Wüstenspitz (Diskussion) 10:41, 25. Aug. 2021 (NNZ)

Bezüglich iframe bin ich mir nicht sicher, ob das in ner neueren MediaWiki-Version anders wäre, denn soweit ich weis akzeptiert der Parser nur Tags zu die explizit erlaubt sind (und da man mit iframe alles mögliche machen kann, bezweifle ich, dass MediaWiki das Tag erlaubt).

Bezüglich der genutzten Software ist Spezial:Version ne hilfreiche Anlaufstelle und laut der Seite ist es MySQL 5.5, wobei die dort angegebene Package Version ebenso wie die Version des php Packages von Anfang 2017 sind (ich erwähne die genauen Versionen bewusst nicht, denn hier lesen vermutlich diverse Crawler mit, während die Spezialseite für die glaube ich gesperrt ist), weshalb ich davon ausgehe, dass der Apache damals mit geupdated wurde (weil es ein Linux Server ist und der Packagemanager in der Regel keine einzelnen Updates zulässt) und die zur Veröffentlichung der entsprechenden PHP/MySQL-Package-Version aktuellste Package-Version für die Version kam Mitte 2016 raus und beinhaltete nen Sicherheitsfix (wurde aber inzwischen von ner weiteren Version abgelöst mit zusätzlichen Fixes). Es wäre also auf jeden Fall mal sinnvoll, den Packagemanager mal ein Update machen zu lassen.

Soweit ich das weis, läuft das ganze auf nem bei Strato gemieteten Server, womit davon auszugehen ist, dass sich Strato um die Hardware kümmert und entsprechende Maßnahmen ergreift um Datenverlusten bei Ausfällen der Hardware zu vermeiden (soweit ich das weis liegen die Daten wegen Ausfallsicherheit in 2 entsprechend voneinander entfernt liegenden Rechenzentren). Das einzige was für uns also ein Problem werden könnte, ist folglich ein Versagen der Software bzw. ein unberechtigter Zugriff auf den Server.

Alles in allem ist es definitiv mal Zeit für ein Update (zumindest auf das aktuellste was die entsprechenden Software-Versionen bieten) und das dringendste ist da vermutlich MediaWiki, weil diese MediaWiki-Version seit damals sicherlich noch ein paar Updates bekommen hat (was allerdings schwer zu sagen ist, denn der Versionsstring aus, als ob er modifiziert worden wäre). Der Rest ist relativ aktuell (und kann recht einfach über den Packagemanager geupdated werden). Mööep KamelPatrick (Diskussion) 13:05, 25. Aug. 2021 (NNZ)

<iframe> jain. Im normalen Editor (mit dem ich grad schreibe...) ist es gesperrt bzw. wird escaped. Die {{Youtube}}-Vorlage verwendet intern ja ein Widget und die unterliegen nicht diesen Tag-Beschränkungen. Die können demzufolge auch <iframe> verwenden. Die Widgets, in dem Fall Youtube-Widget, erzeugen das HTML-Snippet das die Youtube-API anspricht. Diese Snippets haben sich von APIv1 auf APIv2 geändert. Weil so einfache Kameltreiber wie wir keinen Zugriff auf die Widgets haben, können wir nicht von APIv1 auf APIv2 switchen, obwohl das technisch einfach wäre und sogar "inline" mit den bestehenden eingebetteten Videos.

Wenn es sich um MySQL 5.5 handelt, dann ist es zwar besser weil "nur" 2,5 Jahre veraltet. Aber von "gut" kann keine Rede sein. Das Problem zieht ja seine Kreise. Die verschiedenen Versionsstände sind voneinander abhängig. Du kannst das bestehende MediaWiki 1.23 nicht auf ein aktuelles PHP8 setzen und umgekehrt kein aktuelles MediaWiki 1.35 LTS auf ein altes PHP5.

Durch den viel zu langen Tiefschlaf steht nun ein sehr langer Migrationspfad bevor. Wahrscheinlich könnten wir gar nicht in einem großen Schritt von alter auf neue Software wechseln und alles sähe so aus wie vorher. Es kann gut sein, dass der einzig sinnvolle Weg nur noch der eines Fork ist. Heißt: Export der Inhalte und Import in eine aktuelle Softwareumgebung. Das geht mit und ohne Unterstützung von Sloyment sowie mit und ohne dem bisherigen Server.

Wünschenswert fände ich natürlich, dass wir hier bleiben könnten. Das will ich auch noch mal ganz klar sagen: Mir geht es nicht darum, die Kamelo zu "kapern". Vorallem auch, weil meine Freizeit und finanziellen Mittel endlich sind. WiKa und J* sind ja auch nicht grundlos ausgestiegen, denn so ein Wiki macht Arbeit. Ich bin aber ehrlich enttäuscht von Sloyment, weil er sich so gar nicht kümmert oder dazu sagt. Geradezu paradox, weil mir seine eigene Webseite entgegen blökt, dass mein IPv6 "nicht geht" (was ich nebenbei bemerkt nicht in der Hand habe sondern von meinem Provider zugewiesen ist).

--Wüstenspitz (Diskussion) 13:59, 25. Aug. 2021 (NNZ)

Nachtrag: Meine Theorie bzgl. des langen Migrationspfades wird von MediaWiki offiziell bestätigt: "Von Version 1.36 an unterstützt MediaWiki Upgrades nur in Schritten von zwei LTS-Releases (siehe phab:T259771). Upgrades von älteren Versionen müssen dann in mehreren Schritten durchgeführt werden. Das bedeutet: ein Upgrade von 1.23 oder älter auf 1.36 muss über ein Upgrade auf 1.27 (oder 1.35) erfolgen, um dann auf die gewünschte Version 1.36 zu aktualisieren. " --Wüstenspitz (Diskussion) 14:14, 25. Aug. 2021 (NNZ)

Das war schon immer ein Problem hier, diejenigen, welche die Zugriffsrechte hätten, machen nix, diejenigen die es könnten, haben keine Zugriffsrechte. Habt ihr mal versucht, mit @Sloyment über seine andere Webseite Kontakt aufzunehmen, um einen Ausweg zu finden? Ziemliche []e Misere, das! Es wäre auf jeden Fall im Sinne der Sicherheit aller Kamele. Kamillo (Diskussion) 20:44, 25. Aug. 2021 (NNZ)

Ach so, wenn ihr damit fertig seid, könnte jemand eine Hover-Ansicht machen? Ich bin kein Programmierer :( ☭Mondelieu (Diskussion) 10:09, 26. Nov. 2021 (NNZ)

Tja... Ich hatte Sloyment eine Tüte Mehl geschickt, aber leider keine Antwort erhalten. --Wüstenspitz (Diskussion) 15:14, 26. Nov. 2021 (NNZ)

Ich hoffe wenigstens, dass die Mühle hier vom Patchstand wenigstens für die log4j-Bombe zu alt ist... Kamillo (Diskussion) 11:30, 13. Dez. 2021 (NNZ)

Zusammenfassung der Probleme

Es ist ja schon ein bisschen unübersichtlich geworden mit den technischen Problemen und den Diskussionen darüber. Es verteilt sich ja auch über mehrere Threads im Forum. Darum möchte ich hier ein wenig zusammen fassen. Ergänzungen sind ausdrücklich erwünscht!

1. Die Serversoftware ist veraltet (Ubuntu, Apache, PHP, MySQL, MediaWiki) und zwischen 2,5 bis 9 Jahren alt -> Hohes Sicherheitsrisiko
2. Einige veraltete MediaWiki-Plugins (z.B. Youtube, Twitter) machen Probleme, weil sie veraltete APIs der externen Dienste ansprechen
3. Wegen der extrem alten Software nun nur noch ein komplizierter Migrationspfad mit wahrscheinlich einigen Verlusten möglich
4. Unbekannt, ob es sich um einen betreuten oder unbetreuten Server handelt -> Hardware möglw. seit 9 Jahren im Dauerbetrieb
5. Es gibt kein HTTPS, weder erzwungen (Umleitung von HTTP) noch indirekt (Direkter Aufruf per Browser-Adresszeile) -> Downranking in den SuMas und auf Twitter
6. Datensicherung/Backup vorhanden? Unklar!
7. Irgendein Cache läuft voll, sodass das Abspeichern von Edits immer länger dauert (wurde kurz vor der Übergabe J* -> Sloyment das letzte Mal behoben)
8. Vorhandene Kompetenzen einiger Kamele werden nicht genutzt
9. Außer Sloyment derzeit kein Serverkamel vorhanden (korrigieren wenn falsch!) und dieses eine Serverkamel kümmert sich nicht genug
10. Es gibt nicht mal einen Plan, an der Situation etwas zu ändern
11. Custom-Skins für einzelne Seiten lassen sich nicht mehr erstellen/bearbeiten.

--Wüstenspitz (Diskussion) 08:46, 26. Aug. 2021 (NNZ)

Alte Diskussion

Kurz zusammengefasst:

• Seit der Übergabe des Staffelstabes beim Kamelo-Betrieb ist Sloyment meines Wissens das einzige verbliebene Serverkamel hier.
• Die Spammer und gelangweilten Kiddies blasen zum Sturm auf die Bastille.
• Eine Handvoll Kameltreiber halten hier mit ener Zahnbürste und einem Teelöffel bewaffnet den Stall sauber.
• Sloyment war seit sechs Wochen nicht mehr hier und antwortet leider auch nicht auf seine Kamelbox.

Ergebnis: Möh.

Eure Meinung dazu?

--Wüstenspitz (Diskussion) 05:42, 13. Okt. 2020 (NNZ)

• Hm, tja... Kamillo (Diskussion) 22:42, 12. Okt. 2020 (NNZ)
  (Anmerkung eines Kamels der alten Schule: Diskussionsbeiträge bitte immer mit den vier Schlangenlinien ~~~~ unterzeichnen, damit andere Kamele ohne Blick in die Versionshistorie sehen können, wer da möht.)

Schuldchung :-) Oben ergänzt. --Wüstenspitz (Diskussion) 05:42, 13. Okt. 2020 (NNZ)

• Auf den zweiten Blick: Sloyment zahlt den Serverbetrieb, also bestimmt er auch, wer noch Serverkamel wird. Ab und zu mal gucken muss aber auf jeden Fall sein, alleine wegen der Sicherheit des Servers, nicht dass der noch gehackt wird... Also gelegentlichregelmäßig updaten ist schon wichtig.
  Was die Spammer angeht, ich würde vorschlagen, die Kamelo vorerst nicht mehr durch IPs bearbeiten lassen zu können. Für Neu-Kamele wäre auch eine Bilder-Upload-Sperre sinnvoll, erst nach X Editis, die darüber hinaus auch noch erfolgreich moderiert werden müssen, können Bilders hochgeladen werden.
  Wie denkt ihr darüber? Kamillo (Diskussion) 00:44, 14. Okt. 2020 (NNZ)

Ich stimme dir da in eigentlich allem zu. Ähnliche Vorschläge habe ich ja auch schon gemacht. Es braucht (leider!) bessere Werkzeuge als wir im Moment zur Verfügung haben. Nur dafür sind die Befähigungen eines Serverkamels notwendig soweit ich weiß. Ich kann mir nicht vorstellen, dass es für den Review-Modus von IP-Edits ein Mediawiki-Update braucht. Denn das wird in der Wikipedia schon seit Ewigkeiten so gehandhabt. Womöglich müsste es hier nur eingeschaltet werden. Evtl. kann man das mit Neukamelen genauso machen. So wäre es für die Spammer und Vandalen mehr Aufwand zu spammen und zu vandalieren als für uns das Aufräumen. Im Moment ist es nämlich umgekehrt. --Wüstenspitz (Diskussion) 18:20, 14. Okt. 2020 (NNZ)

Wie anfangen?

Ja, die Situation ist blöd. Die Kamelopedia läuft seit einem Jahr auf meinen Namen, und ich hab es noch nicht einmal geschafft, mir einen Überblick zu verschaffen. Irgendwelche anderen ToDos rücken immer in der Priorität höher. :-( Ich hatte ein Telefonat mit J*. Der hat mir einiges erklärt und eine E-Mail geschrieben, aber sonst ist noch nicht viel passiert.

Okay, wie kann man das ändern?

Ein wichtiger erster Schritt wäre auf dem V-Server User-Accounts einzurichten. Dazu müssten sich Wüstenspitz, Kamelurmel, KamelPatrick und Tinysaurus bei mir persönlich melden. Ich kann ja die Zugangsdaten nicht hier ins Forum posten, wo sie jeder mitlesen kann. Bitte geht auf Einstellungen und gebt eine E-Mail-Adresse an, um die E-Mail-Funktion der Kamelopedia nutzen zu können. Ich hoffe, sie funktioniert.

Um nicht missverstanden zu werden: Ich habe die Accounts noch nicht eingerichtet. Jetzt in der Nacht mache ich das auch nicht, morgen hab ich keine Zeit, und übermorgen denke ich wahrscheinlich nicht mehr dran. Deshalb noch eine Bitte: Ruft mich an! Telefonieren ist quasi der nullte Schritt. -- Sloyment (Diskussion) 03:52, 29. Aug. 2021 (NNZ)

Hallo Sloyment, schön dass du wieder da bist. Ich möchte auch nicht missverstanden werden: Ich bin dir nicht böse. Mir machen die Probleme nur Sorgen. Emailadresse hat doch denke ich jeder von uns hinterlegt, höchstens dass sie nicht mehr aktuell ist müsste jeder nachschauen. Meine ist es.

Ich schlage mal folgende Vorgehensweise vor:

1. Bestandsaufnahme machen was los ist. Dazu zählen Vertragssituation (was ist das genau für ein Hosting?), Hardware (wie alt ist der Server und wird er betreut?) sowie Software
2. Strategie überlegen, wie ein Upgrade am einfachsten machbar ist
3. Testumgebung mit aktuellem LAMP-Stack starten (hängt vom Hosting ab ob das auf dem selben Server machbar ist) und Migration so lange testen, bis sie möglichst reibungslos funktioniert
4. Nicht migrierbare Teile (alte Widgets die nicht mehr supportet werden usw.) identifizieren und Seiten die sie verwenden überarbeiten bzw. in einer Kategorie (z.B. "Upgrade-Probleme") sammeln
5. Proprietäre Teile (z.B. Buschtrommel) überarbeiten bis sie auf dem neuen Stack laufen
6. Diskussion über Teile, die sich nicht migrieren lassen
7. Kamelo vorübergehend readonly schalten, um Edits während der Migration zu verhindern
8. Migration zum neuen Stack durchführen
9. Edits freigeben und Problem-Kategorie überprüfen

Vorallem aber sollten wir nicht die Fehler wiederholen, welche die Stupidedia gemacht hat. Dort wollte man einen großen Relaunch mit neuem Design und am Ende fühlte sich keiner wohl damit. Die Kamelo sollte bleiben wie sie ist, denn Kamele sind Gewohnheitstiere.

--Wüstenspitz (Diskussion) 14:17, 29. Aug. 2021 (NNZ)