Forum:Unbefriedigende Situation

Forum > Unbefriedigende Situation

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

Stand Ende 2021

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)

Log4J bzw. Log4Shell betrifft ja zunächst mal Java, was bei MediaWiki IMHO nie verwendet wurde. Was aber nicht heißt, dass nicht irgendwo auf dem Server doch Gebrauch davon gemacht wird. Das Schlimme an solchen Sicherheitslücken ist ja, dass, selbst wenn man sie schlösse, nicht ausgeschlossen werden kann dass ein Server bereits exploited wurde. Irgendwo in alten Disku-Seiten habe ich gelesen, dass es in 2013/14 schon mal so eine Malaise gegeben hat und die Kamelo nur teilweise restauriert werden konnte (z.B. geht kein Editlog weiter zurück). Geschähe ähnliches heute wieder, wäre es wohl das Ende der Kamelo. Denn keins der Fachkamele von damals ist noch aktiv und keins der aktiven Fachkamele ist befähigt/bemächtigt, solche Dinge zu tun. Mehr als anbieten kann ich es ja nicht. Aber keiner sollte erwarten, dass in einer Desastersituation irgendetwas rettbar wäre, wenn man erst dann und nicht vorher zu Rate gezogen wird. Das Schlimmste an der Situation ist, dass dieses MediaWiki hier als proprietär anzusehen ist, weil niemand weiß/sagen kann, ob nicht Scripte gepatched wurden. Spezialseiten wie die Buschtrommel deuten darauf hin. Schon beim letzten Desaster wurde nicht alles repariert, siehe oben erwähnte Stylesheet-Funktionen.

Angesichts all der Probleme bin ich inzwischen nach reiflicher Überlegung zu dem Ergebnis gekommen, dass eine Pflege der vorhandenen Kamelo-Software aussichtslos wäre. Der einzige Weg einer Rettung mit überschaubarem Aufwand wäre ein Fork über die XML-Schnittstelle. Das müsste aber getan werden bevor ein Desaster gewesen sein wird (Futur III, also JETZT) und es müsste allen klar sein, dass dabei auch wieder alle Editlogs verloren gingen und es einer Spaltung der Community gleich käme. Das war und ist eigentlich nicht meine Ambition. --Wüstenspitz (Diskussion) 13:38, 13. Dez. 2021 (NNZ)

Könnte man wenigstens zeitnah einen Komplett-Dump aller Beiträge inklusive Bilder machen, und dann gelegentlich mal einen Delta-Dump (alles seit dem letzten Dump), so dass man das alles mal in eine aktuelle frische Installation reinpumpen könnte? Alte Logs und Versionshistorie finde ich jetzt nicht ganz so wichtig wie die Inhalte. Kamillo (Diskussion) 21:43, 13. Dez. 2021 (NNZ)

Texte? Ja. Bilder? Dank ungeschützter Verzeichnisse zumindest "zu Fuß". Aber auf dem Weg würde einiges fehlen, z.B. die ganzen Vorlagen, die Stylesheets, das ganze Look&Feel was die Kamelo ausmacht. Und es würde eine Menge Handarbeit bedeuten. --Wüstenspitz (Diskussion) 08:54, 14. Dez. 2021 (NNZ)

Noch vergessen: Delta-Dump dürfte nicht möglich sein. Es gibt zwar ein Pythonscript das solches tut, aber erst ab Version 1.50 und wir hängen auf 1.23 rum. --Wüstenspitz (Diskussion) 08:56, 14. Dez. 2021 (NNZ)

In WP wird gerne „Import“ gemacht... ist zwar sehr aufwändig, weil für etwa 20 bis 30 tausend Datenbankeinträge wird das ziemlich lästig. Und leider: die Buschtrommel geht flöten! --Charly (Diskussion) 12:21, 14. Dez. 2021 (NNZ)

Ich hab mir das jetzt mal ein bisschen angeschaut. Inhalte dumpen dürfte kein großes Problem sein, sogar mit History bis 5000 Einträge je Artikel. Ist ein bisschen Fuddelarbeit, weil kamel das für jeden Namespace einzeln machen und die Artikellisten hufisch zu Linklisten umarbeiten muss. Aus dem Artikel-Namensraum liegen mir bereits alle Dumps vor. Das hab ich mal gemacht um zu sehen, wie viel Aufwand das ist und welche Datenmengen zusammen kommen (ca. 880 MB an XML-Dumps). Downloadzeit etwa 4 Stunden.

Bilder bin ich mir noch nicht so sicher - die reinen Dateien sollte kein Problem sein und die Beschreibungsseiten aus dem Datei-Namespace auch. Aber ob man hinterher beides wieder verheiratet bekommt, keine Ahnung. Das Downloaden der Dateien ist aber sehr lahm, keine Ahnung warum.

Die Buschtrommel ist proprietär, ja, aber auch ziemlich simpel. Soweit ich sehen kann, beherrscht die nur eine Handvoll Antworten, das lässt sich leicht nachprogrammieren. Da ich den Chat aber sehr selten genutzt habe, fehlt mir da der Überblick. Gut möglich dass ein Nachbau sich ganz anders "anfühlen" würde. Andererseits könnte man sie dann auch leicht aufbohren und kommunikativer machen.

Es stellen sich aber wieder die selben Fragen wie damals, als J* das Ende angekündigt hat: So ein großes Wiki kann man nicht mal eben auf einem billigen Shared Webspace hochziehen. Das würde niemandem Freude bereiten, weil lahm. Ein angemessenes Hosting würde etwa 50 Euro im Monat kosten. Wie finanzieren? Krautpfanding wäre ja eine Möglichkeit.

Aber nochmal, um es deutlich zu sagen: Ich will eigentlich nicht forken. Da müssten wir uns schon alle einig sein dass das der Weg sein soll.

--Wüstenspitz (Diskussion) 15:23, 14. Dez. 2021 (NNZ)

Auf welcher Sprache ist die Buschtrommel geschrieben? Fühlt sich irgendwie wie Python an, obwohl ich weiß, dass es falsch ist Mondelieu (Diskussion) 19:55, 14. Dez. 2021 (NNZ)

Also der Link vom Formular lautet http://kamelopedia.net/extensions/Buschtrommel/trommel.php?action=add also würde ich mal stark von PHP ausgehen.

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

Nebenbei bemerkt habe ich jetzt während des "Hackens" der Kamelo herausgefunden, wie man das veraltete Youtube-Plugin modernisieren könnte - was ja vor vielen Jahren der Anlass war, mich schon einmal zu mokieren. Dolle Wurst, JETZT komm ich dahinter *grmpf* --Wüstenspitz (Diskussion) 20:28, 14. Dez. 2021 (NNZ)

@Charly: Ich revidiere meine frühere Aussage aus dem Chat: Nach eingehender Inspektion meines vorhandenen Webspace + Vertragssituation muss ich zugeben, dass ich mich etwa um den Faktor 50 vertan habe, was den Speicherplatz angeht. Wäre also mehr als genug Reserve vorhanden. Trotzdem hoffe ich, dass sich Sloyment kümmert und wir nicht forken müssen. Einen groben Handlungsrahmen hatte ich ja schon im August ganz am Ende dieser Seite skizziert, wovon ich gerade die Punkte 3 und 4 bearbeite. Das größte Problem das ich aktuell sehe ist, dass ohne Zugang zum jetzigen Server regelmäßige Backups nur über die API möglich sind. Dieses Vorgehen ist extrem aufwendig und zeitintensiv (jeweils 4 Stunden Arbeit und 24 Stunden Download). --Wüstenspitz (Diskussion) 17:07, 15. Dez. 2021 (NNZ)

Ist noch wenig relevant, weil auch ich hoffe, dass wenigstens eine seiner Sockenpuppen mal hier auftaucht und die LÄ und die Trommel verstehend liest.--Charly (Diskussion) 18:37, 15. Dez. 2021 (NNZ)

Das ist ja genau der Haken an der Sache: Sobald es relevant wird, z.B. weil jemand oder etwas diese steinalte Software hackt, ist der richtige Moment vorbei, etwas zu unternehmen. Ich könnt heulen.

Ich hab mir heute Abend mal angeschaut, wie man eine Extension für ein MediaWiki 1.37 schreibt. Was schon geht: Eine Spezialseite erzeugen, die Trommeloberfläche anzeigen, REST-Schnittstelle ansteuern, User-Klasse einbinden. Was noch fehlt: Die Datenbank ansprechen, Chatverlauf handlen sowie die Bot-KI (= "Kamel-Intelligenz")

Kurz gesagt: Ein Prototyp der Trommel für ein aktuelles MW sollte am Wochenende fertig sein. An Datentransfers von Artikel-Seiten denke ich im Moment noch nicht, weil nicht mal klar ist von wo nach wo kopiert werden wird.

Heutiger Zwischenstand: Neue Trommel-Extension für 1.37 kommt gut voran. Datenbankanbindung ist fertig, REST-API Grundgerüst auch, aktuell baue ich an der KI. --Wüstenspitz (Diskussion) 20:43, 16. Dez. 2021 (NNZ)

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

Auf dem Server gibt es ein Backup-Script. Hast du meine E-Mail von heute morgen bekommen? -- Sloyment (Diskussion) 17:48, 16. Dez. 2021 (NNZ)

Bekommen und geantwortet. Ich wollte nur nicht mehr zu späterer Stunde anrufen - siehe Mail. --Wüstenspitz (Diskussion) 20:43, 16. 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)