Forum:Das Kamelopedia-Modernisierungs-Blog

aus Kamelopedia, der wüsten Enzyklopädie
Wechseln zu: Navigation, Suche
H Sticky.gif Forum > Das Kamelopedia-Modernisierungs-Blog
Hinweis: Dieser Fred wurde seit 382 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.

Hallo!

Hier in diesem Fred soll über die Weiterentwicklung der Kamelopedia diskutiert werden. Bisher gab es einige Mecker-Freds, wo wir ausgiebig festgestellt haben, was alles doof ist - bezogen auf unsere leicht angestaubte Mediawiki-Software. Hier soll es jetzt vorallem um Konstruktives gehen.

Fortschritte[bearbeiten]

6. Januar 2022[bearbeiten]

Neues Jahr, neue Energie... Sloyment hat den neuen Server bestellt und dieser ist inzwischen bereitgestellt. Ein großes Dankeschön auch an Charly, der den neuen Server für zwei Jahre im Wert von 318 Euro gesponsort hat! --Wüstenspitz (Diskussion) 11:28, 8. Jan. 2022 (NNZ)

25. Januar 2022[bearbeiten]

Wie ist denn der aktuelle Stand, abseits von irgendwelchen Drumsessions? Sind wir schon auf dem neuen Server? Kamillo (Diskussion) 10:14, 25. Jan. 2022 (NNZ)

Neuer Server läuft, alle nötige Software ist drauf, aktuelles (leeres!) MediaWiki 1.35 LTS ist drauf, die Dommel läuft schon. Was fehlt ist der Datentransfer von der alten zur neuen Kamelo. Da wollte KamelPatrick ran. --Wüstenspitz (Diskussion) 12:44, 25. Jan. 2022 (NNZ)

Die neue Buschtrommel a.k.a. Rohrdommel[bearbeiten]

18.12.2021[bearbeiten]

Rohrdommel-Beta1.jpg

Ich habe die letzten drei Tage Abends an einem Ersatz für die Buschtrommel gearbeitet. Warum ist das nötig? Die alte Buschtrommel wurde für ein altes MediaWiki 1.23 entwickelt, welches schon viele Jahre nicht mehr supported wird. Stand heute (18.12.2021) ist die MediaWiki-Version 1.36 (stable) aktuell.

Als Ersatz habe ich eine von Grund auf neu entwickelte MediaWiki-Extension geschrieben. Links seht ihr einen Screenshot dieser frühen Version.

--Wüstenspitz (Diskussion) 03:13, 18. Dez. 2021 (NNZ)

20.12.2021[bearbeiten]

Rohrdommel-Beta2.jpg

Hier seht ihr den Fortschritt der letzten zwei Tage. Im Vergleich zur Beta1 haben wir jetzt neu: Links eine Liste der aktiven Kamele im Chat. Der Chatbereich ist etwas größer geworden und hat unsere Heimat als Hintergrundbild bekommen. Rechts unten seht ihr das neue Optionsmenü.

Was nicht im Bild zu sehen ist: Eine Begrüßungsmusik, wie es sie früher gab wenn man durchs Fenster 95 geschaut hat sowie ein Plopp-Sound wenn eine neue Nachricht eintrifft.

Last but not least: Ganz links oben seht ihr das neue Logo unserer Rohrdommel - Ganz intim fotografiert von unserem Mitkamel Charly, als die Rohrdommel gerade drei kleine Kamele ausgebrütet hat.

--Wüstenspitz (Diskussion) 00:20, 20. Dez. 2021 (NNZ)

25.12.2021[bearbeiten]

Rohrdommel-Beta3.jpg


Nachdem im Forum der Wunsch nach Smilie-Fähigkeiten aufkam, habe ich dieses in der Rohrdommel implementiert. Die oberen Kamel-Smilies sind von mir designed (hier können gern noch Alternativen vorgeschlagen werden!) und basieren auf Text-Smilies wie ":-D" oder ":-(". Die unteren drei Smilies sind Standard-Unicode-Emoticons.

--Wüstenspitz (Diskussion) 15:57, 25. Dez. 2021 (NNZ)

27.12.2021[bearbeiten]

Rohrdommel-Beta4.jpg


Seit ich Zugang zu den Original-Quellcodes der Buschtrommel habe, konnte ich einige versteckte oder unfertige Features entdecken. Darunter ist z.B. auch die Wetterfrosch-Funktion. Für eine richtige Rohrdommel gehören Wetterfrösche zu jeder guter Mahlzeit dazu. Darum habe ich ihr die Fähigkeit beigebracht, das Wetter vorher zu sagen. Und zwar weltweit. --Wüstenspitz (Diskussion) 02:34, 27. Dez. 2021 (NNZ)

1.1.2022[bearbeiten]

Rohrdommel-Beta5.jpg


Heute zeige ich euch noch einige neue Features, die mir zwischenzeitlich noch eingefallen sind. Zum Beispiel die Datumszeile beim Tageswechsel, die fehlte bisher noch. Die Zufallsfunktion wählt jetzt wirklich aus den gegebenen Möglichkeiten aus. Möh und Mööepp werden jetzt optisch wie aktustisch hervorgehoben (Sounds einzeln abschaltbar). Dommbot gibt jetzt Tips für die Lottozahlen. Die gelbgrüne Hervorhebung vom eigenen Namen funktioniert jetzt (ebenfalls mit eigenem Sound). Die Igno-Funktion kann zeitlich begrenzt werden. --Wüstenspitz (Diskussion) 20:39, 1. Jan. 2022 (NNZ)

2.1.2022[bearbeiten]

Rohrdommel-Beta6.jpg


Hier noch einige Details zum Thema Verlinkung. Wie man sieht, kann die Rohrdommel sowohl interne als auch externe Links auflösen. Dabei werden, sofern vorhanden, die Seitentitel der verlinkten Seiten als Linktext angezeigt. Am Rande wird hier auch gezeigt, wie sich die KI der Rohrdommel durch <nowiki>-Tags abschalten lässt. --Wüstenspitz (Diskussion) 00:43, 2. Jan. 2022 (NNZ)

4.1.2022[bearbeiten]

Rohrdommel-Beta7.jpg


Was mit dem Wetter möglich ist, das geht auch mit dem Fußball. Die Rohrdommel hat jetzt einen direkten Draht zum Fußballgott und kann die Ergebnisse des aktuellen Spieltages abrufen. Bei allgemeiner Frage wird zufällig eines der Tagesergebnisse ausgegeben. Fragt man konkret nach einer Mannschaft, dann bekommt man genau das Ergebnis. Für den Screenshot habe ich den Spieltag intern geändert, weil heute bekanntlich nicht gespielt wurde. --Wüstenspitz (Diskussion) 01:10, 4. Jan. 2022 (NNZ)


Rohrdommel-Beta8.jpg


Mit freien API kann kamel allerhand Blödsinn anstellen. Hier seht ihr, wie die Kamel-Intelligenz der Rohrdommel mit Fragen zu Währungen umgeht. --Wüstenspitz (Diskussion) 23:06, 4. Jan. 2022 (NNZ)

5.1.2022[bearbeiten]

Rohrdommel-Beta9.jpg


Noch ein schönes Beispiel für freie API. Eigentlich lag das ja auf dem Huf, aber naja... Wenn kamel mal wieder mit dem Dommbot allein sein sollte, kann dieser nun mit allerlei Fachwissen aufwarten. Und JA, ich hab auch an die Stupi gedacht, nur wurde nichts daraus, weil dort das entsprechende API entweder defekt oder abgeschaltet ist - es bringt jedenfalls kein Ergebnis. --Wüstenspitz (Diskussion) 18:58, 5. Jan. 2022 (NNZ)

8.1.2022[bearbeiten]

Rohrdommel-Beta10.jpg


Ja, der Dommbot kann ein echter Couch Potatoe sein. Mit ein bisschen Recherche fand sich auch eine freie API für eine Filmdatenbank. Schwuppdiwupp kennt sich die Dommel auch mit Film & Fernsehen aus. Aus den verschiedenen mitgelieferten Ratings bildet sich Dommbot eine Meinung über den jeweiligen Film bzw. Serie und hält damit auch nicht hinterm Berg. Wenn kamel möchte, lassen sich auch Plakate bzw. Bilder abrufen. --Wüstenspitz (Diskussion) 00:05, 8. Jan. 2022 (NNZ)

Fehlende Extensions[bearbeiten]

Im Vergleich zu seinem frisch installierten aktuellen MediaWiki 1.37 fehlen folgende Extensions. Wo es gleichnamige Extensions gab, habe ich diese als vorhanden angenommen und nicht mitgezählt.

Die mit +++ markierten Extensions sind nun manuell im neuen Wiki installiert. --Wüstenspitz (Diskussion) 17:25, 30. Jan. 2022 (NNZ)

GoogleAnalytics brauchen wir meines Erachtens nicht (Ich persönlich hab die Domain im Heimnetz sowieso gesperrt), Variables braucht es meines Erachtens auch nicht, da Variablen (wenn nötig) über Lua möglich sind. Beim Rest müssten wir mal genauer schauen was die machen. Mööep KamelPatrick (Diskussion) 19:40, 22. Dez. 2021 (NNZ)

Zur Erinnerung: Über die Unmöglichkeit der Modernisierung der momentan aktiven Kamelopedia-Installation[bearbeiten]

Wir müssen wohl noch weiter studieren an der Uni Gühlen, um das witzenschaftliche Modernisierungsprojekt zu stemmen. Denn die bestehende Umgebung macht Updates und Ergänzungen unnötig riskant, und infolge dieser Erkenntnis womöglich im Zweifelsfall gar nötige Reparaturen ebenso.

Beispielhaft versuchte ich gerade, der jetzigen Kamelopedia eine neue extension zu verpassen. extensions, ist das nicht der Schmuddelkram aus dem üblichen Spam? Üblicherweise ja, aber bei diesem Thema hier Nein - eine extension verleiht einer Wiki-Installation neue Fähigkeiten. Ich wollte nun die HitCounters-Extension haben. Auf Umwegen gelang es mir, das aktuelle Hit-Counters-Archiv in das extensions-Verzeichnis des Kamelo-Servers zu entpacken. Dabei hab ich auch ein tool verwendet, und dabei fiel mir auf, dass viele UNIX-/Linux-Tools garnicht vollständig installiert werden können auf dem alten Server - da fehlt fast immer was von dem, von dem was für das Tool zur als Voraussetzung für dessen Funtionieren notwendig ist - ein Installationsversuch erzeugt höchstens einen Zombie von dem was man braucht. In der Testkamelo-Umgebung war das Problem nicht, weshalb ich von Umwegen sprach :-) Nun liegt die neue extension also in der Theorie vor, aber in der Praxis bräuchte es theoretisch einen Aufruf von einem gewissen "update.php", um sie zu aktivieren. Das kann aber nur derjenige machen, der auch Datenbank-Sicherung beherrscht! Denn Mediawiki verlangt, dass vor Gebrauch dieses Mediawiki-Tool-PHPs die Datenbank gesichert werden muss, v.a. wenn die Wiki-Umgebung schon eine gewisse Komplexität erreicht hat, was für die Kamelopedia wohl der Fall sein dürfte! Denn allzuoft würde update.php sonst in der Datenbank alles durcheinanderwerfen. Tja, Glück gehabt, Kamelo, dass ich da erst nachgeschaut habe! Fazit: Sowohl Linux-Erweiterungen als auch Mediawiki-Erweiterungen sind auf der alten Umgebung bestenfalls abenteuerlich. Kamelurmel (Diskussion) 09:52, 9. Apr. 2022 (NNZ)

Warnschuss[bearbeiten]

Da war er nun, der lang befürchtete Warnschuss unseres aktuellen - alten - Servers: Am 8. März 2023 war er über längere Zeit down. Ursache unbekannt. Hat sich einfach verabschiedet. Sloyment hat ihn über die Management-Oberfläche neu gestartet und er ist zum Glück wieder hochgefahren. Darum BITTE BITTE keine Konfigurationsänderungen an den PHP-Scripts des ALTEN Servers machen. Das Ding ist maximal fragil. Also auch KEINESFALLS mit update.php hantieren! Never change a running system!

Zur Sicherung/Rücksicherung der Datenbank des ALTEN Servers: Aussichtslos! Nicht genug Platz auf dem Server, nicht genug RAM im Server. Die Backup/Restore-Scripts steigen einfach mit Fehlermeldungen aus. Deshalb wird die Idee von @Sloyment (Mounten eines NFS-Share auf dem neuen Server als Backup-Ziel) vermutlich auch nicht so funktionieren, dass automatische Backups wieder funktionieren. Das einzige was derzeit noch funktioniert ist das Backupscript, das ich vor einem Jahr geschrieben hatte.

Zum neuen Server: Ich habe nicht mehr verfolgt, was da zwischenzeitlich gemacht wurde. Fakt ist, das was dort schon mal lief, läuft jetzt nicht mehr. Das Mediawiki steigt mit Fehlermeldungen aus. Wir könnten den NEUEN Server komplett neu aufsetzen, also nochmal bei Null anfangen. Nur hat sich am Grundproblem der Migration nach wie vor nichts geändert: In der Mediawiki-Datenbank des ALTEN Servers gibt es Fehler, die eine Migration in ein aktuelles Mediawiki erschweren und dort zu Fehlermeldungen führen. Hier kann ich nicht helfen, weil mir das Fachwissen über die MW-Interna fehlt, vorallem historisches Wissen über die Methusalem-Version auf dem ALTEN Server.

Sofern @KamelPatrick hier nicht weiter kommt, fällt mir nur noch ein, uns professionelle Hilfe zu suchen. Vielleicht kennt ja jemand jemanden aus dem Umfeld der Mediawiki-Programmierer? Ich glaube, es gibt wirklich nicht so sehr viele Leute mit den hier nötigen Hard Skills. Mittlerweile denke ich, dass die Notwendigkeit einer Migration so wichtig ist, dass wir notfalls übergangsweise auf ein Standard-08/15-Mediawiki umziehen sollten. Heißt, erstmal nicht das gewohnte Look&Feel der Kamelo, fehlende Extensions/Addons/Skins in Kauf nehmen. Kann man nach und nach wieder integrieren. Hauptsache unsere über Jahrzehnte gesammelten Werke sind drüben.

Wir sollten auch nicht vergessen, dass Sloyment seit über einem Jahr zwei Server bezahlt, von denen aktuell keiner vernünftig läuft. Das gehört abgestellt, allein schon der finanziellen Fairness halber.

--Wüstenspitz (Diskussion) 18:49, 9. Mär. 2023 (NNZ)

Soweit ich das sehe läuft der neue Server ohne grundsätzliche Probleme, bis auf die Sache mit den kaputten Revisions wo ich noch schauen muss (eventuell könnte es helfen mit ner neueren MediaWiki Version zu arbeiten, sofern es da schon eine neuere LTS Version gibt oder man müsste die Datenbank über eine oder mehrere Versionen zwischen der bisherigen und der Zielversion updaten).
Was man bezüglich dem alten Server machen könnte wäre per rsync die Daten direkt vom alten auf den neuen Server zu schieben. Ob das angesichts des begrenzten RAMs im alten Server gut funktioniert ist aber unklar (insbesondere weil Datenbank-Dateien selbst (im Gegensatz zum dump mit dem Skript von Wüstenspitz) zum Teil sehr groß sind und ich vor einigen Monaten den Versuch die runterzuladen abgebrochen habe, weil es seeeeehr lange gedauert hat). Mööep KamelPatrick (Diskussion) 21:03, 12. Mär. 2023 (NNZ)
Als ich ins neue Wiki geschaut hab, dann kam bei einem Klick auf "Zufällige Seite" immer eine fette rote Fehlerseite. Jetzt nicht mehr. Gibs zu, da hast du was gespielt :-D
Was ich aber bis heute nicht verstehen kann: Warum willst du die Binärdateien von MySQL kopieren? Das führt doch zu gar nichts, weil auf dem neuen Server gar kein MySQL läuft. Was soll MariaDB mit dem Binärformat von MySQL anstellen? Der einzige kompatible Weg sind die SQL-Dumps.
--Wüstenspitz (Diskussion) 12:04, 13. Mär. 2023 (NNZ)

@Sloyment: Bezgl. deiner Frage zu der lkm/klm-Warnung: Nimm die PID die da genannt wird, setze sie beim cd /proc/{PID}/ && cat cmdline ein und du siehst, das ist nur der Prozess von MariaDB der ein paar Dateien permanent offen hält. Guckst du hier. Also ich bleibe bei meiner Vermutung, das ist einfach ein False Positive.

--Wüstenspitz (Diskussion) 12:04, 13. Mär. 2023 (NNZ)

Datensicherung[bearbeiten]

Ich habe gerade den kompletten Inhalt des alten Servers per Rsync runtergeladen.

rsync -auv root@kamelopedia.net:/ Kamelopedia-Backup/

Ich hab danach ein chroot in das Verzeichnis gemacht und wollte MySQL starten:

service mysql start

Allerdings kam da folgende Fehlermeldung:

start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused

Was mache ich verkehrt?

…Und was muss ich noch beachten? Ich nehme mal an, ich müste eigentlich auch auf dem Server MySQL stoppen, bevor ich Rsync mache, und hinterher wieder starten, damit sich die MySQL-Datenbank nicht verändert, während Rsync sie runterlädt? …???

Okay, ich oute mich gerade als Noob und als DAU. :-P :-) -- Sloyment (Diskussion) 21:13, 30. Mär. 2023 (NNZ)

Mir wär das neu dass rsync ein bootfähiges System ziehen kann. Das selbe hat doch Kamelpatrick auch versucht. Wenn man nur die Datenbankdateien von Mysql zieht und die versucht mit einer anderen als exakt der selben Mysql-Version wie auf dem Originalserver zu laden, gibts Rohrbruch.
Die besagte Fehlermeldung kommt womöglich daher, dass dein Linux-System neuer ist und gar nicht mehr mit Upstart arbeitet sondern mit Systemd? Was war denn das Ziel der ganzen Maßnahme?
Das einzige das bisher funktioniert hat war mein Dumpscript. Und mehr brauchts ja eigentlich auch nicht. Neben den Bilderverzeichnissen aus Mediawiki versteht sich.
--Wüstenspitz (Diskussion) 14:36, 31. Mär. 2023 (NNZ)
Datenbank? Spezial:Exportieren!!! Da einfach eine Liste aller Seitennamen eingeben (Wenn das so einfach wär ;-) Und dann den Knopf drücken! Leider nur so einfach für den textlichen (teils code-lichen) Seiteninhalts-Kram. Bei den hochgeladenen Dateien ist das nicht so einfach. Da müssen alle dazu gehörigen Datenbank-Einträge gesichert werden. Weil die auf die konkreten Dateien in dem komplizierten Verzeichnissystem verweisen. Wir brauchen für die Textsicherung über die Exportieren-Schnittstelle nur einen Generator vollständiger Seitennamenlisten, wenn so gesichert werden soll. Es ist quasi die Forking-Schnittstelle für Dummies. Das Gegenteil ist Spezial:Importieren Kamelurmel (Diskussion) 17:48, 1. Apr. 2023 (NNZ)
Es sieht so aus, als müsste man für alles außer Bilder "nur" sämtliche Kategorien ins Feld "Seiten aus folgender Kategorie hinzufügen" eintragen. Das wäre aber immer noch eine Menge Arbeit.
Alternativ könnte man eine Liste aller Artikel vielleicht mit dpl erstellen, wenn man eine Möglichkeit findet, dass nicht nach ca. 500 Ergebnissen Schluss ist. Alpenalpaka (Diskussion) 20:36, 1. Apr. 2023 (NNZ)
Wenn man die Seiten exportiert und in ein frisches Wiki importiert, hat man noch nicht die Benutzeraccounts. D.h. es gibt dann Seiten, die Sloyment erstellt hat, aber es gibt keinen passenden User-Account „Sloyment“ dazu. Aber da der Name frei ist, kann jeder kommen und sich diesen Account registrieren. Das gibt ein Chaos. -- Sloyment (Diskussion) 22:25, 1. Apr. 2023 (NNZ)

@Wüstenspitz: Meine Idee war: Wenn für die MySQL-Binärdaten eine spezielle MySQL-Version benötige, dann kopier ich mir die gleich mit vom Server. Aber ich bekomme MySQL ja nicht gestartet in der chroot-Umgebung Hmmm… Auf dem Server läuft Ubuntu. Wenn ich jetzt rausfinde, welches Ubuntu läuft, könnte ich mir doch genau dieses Ubuntu zu Hause in einer VM installieren. Dann müsste das doch klappen, oder? -- Sloyment (Diskussion) 22:30, 1. Apr. 2023 (NNZ)

Es müsste ein Ubuntu vor Version 14.10 sein. Trotzdem wird dir das nicht viel nützen. Es ist eine lange bekannte Problematik bei Mysql CE. Deshalb wurde die Bezahlversion um Replikationsfähigkeit erweitert. Falls auf unserem Server eine Bezahlversion läuft, dann ist die für deinen Homeserver nicht lizensiert. Wenn es eine CE ist, dann lassen sich die Datenbankdateien nicht kopieren ohne dass die Kohärenz verloren geht. Es ist ein häufiger Trugschluss dass Mysql freie Software wäre. Dahinter steht Oracle und zu dem Laden brauch ich ja nicht viel erklären.
Irgendwie drehen wir uns im Kreis. Mit meinem Dumpscript bekommt man die DB in jede Mysql- und MariaDB-Version. Das Problem ist, dass das Original bereits inkonsistent ist und daran ändert keine der verschiedenen Exportmethoden etwas. Und das Reparaturscript von Mediawiki steigt wegen Speichermangel auf dem alten Server aus. Wer weiß ob es überhaupt funktionieren würde wegen der vielen proprietären Patches längst verschollener Serverkamele in grauer Kamelo-Vorzeit. Wir müssen halt damit leben dass ein kleiner Teil der Artikel-Historie verloren gehen wird.
--Wüstenspitz (Diskussion) 10:32, 2. Apr. 2023 (NNZ)
Nachtrag zum besseren Verständnis: Nehmen wir diese Historie als Beispiel. Sie beginnt 2004 mit einem Edit eines bestehenden Artikels. Was vor 2004 war sieht man nicht. Bei anderen Artikeln ist das 2017 passiert. Ich erinnere mich dunkel, dass die Kamelo damals technische Probleme hatte und das Speichern von Edits ewig dauerte. Ein damaliges Serverkamel hat dann irgendwas gemacht. Keine Ahnung was. Ich war damals ja noch nicht mal Treiber, geschweige denn Serverkamel. Kurz gesagt verlieren wir bei der Migration keine Artikel sondern nur das, was jetzt schon nicht mehr sichtbar ist in der Historie.
--Wüstenspitz (Diskussion) 10:54, 2. Apr. 2023 (NNZ)
Ein bootfähiges System zu ziehen ist bei Linux grundsätzlich möglich, aber dazu muss man wissen, welche Pfade tatsächlich so auf der Platte existieren und welche nicht (manche Verzeichnisse z.B. das für den System init sind nämlich technisch gesehen in einer Datei enthalten, die anderswo im Dateisystem liegt und beim Start gemounted wird und andere Verzeichnisse existieren nur temporär während das System läuft) und wenn das System virtualisiert ist das vermutlich nochmal komplizierter, denn dann liegt die Datei vom System Init vermutlich in nem Verzeichnis auf das nur die Admins des physikalischen Servers Zugriff haben. Grundsätzlich rausfinden, was da wohin gemounted ist und wohinter tatsächlich eine Partition auf ner Festplatte steht, kann man über mount und wenn du nicht versehentlich was per rsync kopieren willst, was von deinem Startpunkt aus betrachtet dazugemounted ist, kannst du das mit der Option x sicherstellen. Und nur einzelne Programme rüberziehen ist etwas tricky, weil zugehörige Dateien eventuell an verschiedenen Stellen liegen (grade was binaries und libraries betrifft) und notwenige externe Bibliotheken üblicherweise über den Package Manager bei der Installation so installiert werden, dass sie auch von anderen Programmen genutzt werden können.
Das Kopieren der MySQL Dateien hatte ich damals abgebrochen, weil es viel zu lange gedauert hat, die Dateien zu kopieren (die eine Datei hatte glaube ich 5GB). Und ja, bevor man die kopiert, sollte man idealerweise MySQL erstmal stoppen, denn nur dann ist sichergestellt, dass alles wirklich vollständig in die Dateien geschrieben ist (und nicht auch zwischendrin was geändert wird, wenn das kopieren länger dauert).
Es ist schon etwas her, seitdem ich die MediaWiki Codebase von Kamelo mit denen aus dem MediaWiki git Repo verglichen habe, aber soweit ich mich erinnere (ich glaub ich hatte das auch mal irgendwo angemerkt), wurden im MediaWiki-Code laut git-diff lediglich ein paar Kleinigkeiten verändert (Benutzer wurde beispielsweise durch Kamel ersetzt). Alle anderen Abweichungen von offiziellen MediaWiki Releases sind darin begründet, dass damals keine Release Version eingesetzt wurde und zusätzliche Dateien wurden dadurch verursacht, dass man die Version vermutlich einfach in die damals bestehende Installation reinkopiert hat.
Die History von Kreide sieht eigentlich ganz normal aus zumindest wenn man auf die Byte-Änderungen und das Erstelldatum der Seite schaut. Kann aber natürlich trotzdem sein, dass da irgendwas kaputt gegangen war, denn die Version hat keinen Kommentar (könnte aber sein, dass es das damals noch keinen automatischen Kommentar gab, wenn man selbst nix reingeschrieben hat oder das entsprechend Kamel das deaktiviert hatte).
Generell denke ich, dass der einfachste Weg das Dump-Script von Wüstenspitz ist, wobei ich mal noch schauen muss, was genau da das Problem mit den kaputten Revisions verursacht. Mööep KamelPatrick (Diskussion) 18:49, 7. Apr. 2023 (NNZ)
Von „http://kamelopedia.net/index.php?title=Forum:Das_Kamelopedia-Modernisierungs-Blog&oldid=609647“