Donnerstag, 19. Oktober 2006
MediaWiki Update Problem/Fehler
MediaWiki
Beim Update einer unserer MediaWiki-Installationen bin ich gerade auf ein Problem gestoßen. Mal abgesehen von der Art und Weise wie das Update vonstatten geht (Shell öffnen, irgendwelche PHP-Scripte von der Shell her ausführen und hoffen das dann alles noch geht), gibt es bei den heutigen PHP-basierten Applikationen doch schon komfortablere Updater, wo man lediglich ein paar Buttons in einem Browser drücken muss. Aber okay.
Nach dem Ausführen des Update-Scriptes php update.php folgte immer
” failed with error code “Specified key was too long; max key length is 1024 bytes (localhost)”
In einem anderen Blog fand ich die Lösung. Man muss einfach in der Datei maintenance/archives/patch-job.sql hinter ") TYPE=InnoDB" und vor dem ";" die Zeile "DEFAULT CHARACTER SET latin1 COLLATE latin1_general_ci" einfügen. Damit läuft das Script durch und die MediaWiki-Installation ist aktuell.
Donnerstag, 24. März 2005
Nero für Linux
Siehe da ... manche Firmen entdecken doch so nach und nach die Linux Welt für sich. So auch die Nero AG, die man sicherlich von der Brennsuite Nero her kennt. Wie ich heute las, bekommt man ab sofort eine kostenlose Nero Version namens NeroLINUX, wenn man sein Nero 6 Reloaded auf der Website registriert.
Die Screenshots sehen schonmal recht vielversprechend aus. Mal schauen, ob die Release Notes das halten, was sie versprechen. Ich werde NeroLINUX gleich mal ausprobieren.
Mittwoch, 23. März 2005
Gentoo und Updates

Gentoo Linux
Gentoo Linux ist meiner Meinung nach die beste Linux-Distribution, die es zur Zeit gibt. Dennoch gibt es ein paar Dinge, die noch nicht so funktionieren, wie sie sollten.
Ich betreue also ein Gentoo System, das als ~x86 (das kann man gut und gerne als Gentoo unstable bezeichnen) aufgesetzt wurde. Ich muss noch hinzufügen, dass dies ein Produktionssystem ist.
Was ist nun genau passiert: Da schon einige Zeit seit dem letzten Systemupdate vergangen war, wollte ich den gestrigen abend zum updaten einiger wichtiger Pakete nutzen. Nach einem
emerge sync folgte ein emerge -upvt system um zu sehen, was denn geupdated werden soll. Trotz einer Gentoo unstable Installation gibt es Möglichkeiten, bestimmte Pakete in den stable Tree zu holen. So tat ich es auch aus Vorsicht mit der glibc, ein Systempaket, auf das so ziemlich alles aufbaut. Ich sah also, dass ein Update der glibc anstand. Da sich dieses Paket im stable Tree befindet, habe ich mir nichts weiter dabei gedacht und das Update angestoßen. Als ich wieder in das Terminal schaute sah ich, dass der emerge Prozess mitten in der binutils Installation abgebrochen war. Leider befanden sich die binutils im unstable Tree. Ich konnte noch gerade sehen, dass vor den binutils die glibc erneuert wurde. Als ich dem Problem auf den Grund gehen wollte und ein ls -lsa eintippte, sah ich auch schon den Schlamassel: Auf dem Bilschirm erschien ein schlichtes und einfaches Segmentation Fault - so ziemlich das schlimmste, was bei einem Remote System passieren kann. Aus früheren Erlebnissen solcher Art wusste ich schon in etwa, was zu tun ist. Ein kurzer Besuch im Gentoo Forum und schon hatte ich mir zwei Rescue Binary Pakete der glibc und binutils besorgt. Um diese zu installieren, musste das ganze System natürlich mit einer Rettungs-CD o.ä. gebootet werden. Es war bereits kurz vor 23.00 Uhr. Überrascht war ich, als sich ein Mitarbeiter an der 1,86€ teuren Support Hotline des Providers meldete. Nach exakt 8 Minuten und 3 Sekunden und 14,94€ später, hatte er mir das System mit einem Knoppix gebootet. Dort konnte ich die beiden Pakete in einer Changeroot-Umgebung installieren. Gerade als ich die letzte stable Version der beiden Pakete mittels emerge installieren wollte, war auf einmal wieder das Netz von der Machine weg. Ein erneuter Anruf um 01:30 Uhr war leider erfolglos, da keiner mehr abnahm. Soviel zum Theme 24/7 Support.
Heute morgen erwachte ich also extra früh (08:15 Uhr), um das Problem zu lösen. Kurz nach 10.00 Uhr bekam ich endlich jemanden von dem Provider an den Höhrer. Meine Stimmung war schon deutlich in den Keller gerutscht. Der freundliche Herr auf der anderen Seite versprach mir, dass sie das Problem lösen werden. 13.00 Uhr war die Machine immer noch nicht erreichbar. Jetzt war ich schon ein bisschen sauer. Man zahlt schließlich ein Haufen Geld und nichts passiert. Ein erneuter Anruf war also fällig. Nachdem ich dem Herrn zum wiederholten Male erklärte, was er tun soll, war der Rechner nach einer halben Stunde in dem Knoppix erreichbar. Hier konnte ich keinen Fehler mehr feststellen und tippte ein
reboot in die Konsole, in der Hoffnung, dass nun alles wieder funktionieren würde. Nachdem der Rechner nach 10 Minuten noch nciht wieder Netz hatte, war mir bereits klar, was warscheinlich passiert war. Der Mitarbeiter, der das System mit der Knoppix-CD hochgefahren hat, muß im Bios als erstes Boot-Device das CD-ROM Laufwerk angegeben haben. Somit bootete die Maschine wiederum mit dem Knoppix und nicht mir dem eigentlichen Gentoo. Naja, noch ein Anruf war fällig. Auf meine Frage hin nach dem ersten Boot-Device sagte mir der Mann, dass er jetzt danach nicht geschaut hätte. Herr, schmeiß Hirn vom Himmel. Wenn man mal ein bisschen mitgedacht hätte, wäre das nicht passiert. Nun gut, eine Stunde später und siehe da, die grausame Zeit von 15 (!) Stunden ohne E-Mails war vorbei. Was lernen wir (ich) daraus? Noch mehr aufpassen beim Gentoo Update und dem Support Mitarbeiter ganz genau erklären, was er tun soll.
(Seite 1 von 1, insgesamt 3 Einträge)
Blog abonnieren
Favoriten
Verwaltung des Blogs
0 oder 1, das ist hier die Frage square design by David Cummins for Serendipity v.1.4.1

Kommentare