Forum:Unbefriedigende Situation

Forum > Unbefriedigende Situation

Hinweis: Dieser Fred wurde seit 973 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)

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)