Startseite | Impressum | Kontakt | Sitemap

Warum überhaupt updaten?

Letztlich ist die Entwicklung jedes internetfähigen Tools ein Spiel mit den Hackern. Man sieht es an den ständigen Updates von aktuellen Browsern. Ständig werden neue Sicherheitslücken entdeckt und geschlossen. Ohne diese Updates sind auch CMS-Systeme sehr anfällig für Angriffen von außen.

Die neuste Angriffswelle geht - wenn man den Sicherheitsverlautbarungen von typo3 Glauben schenkt - vom sogenannten Cross-Site Scripting (XSS) aus. Alle möglichen Extensions, aber auch typo3 in älteren Versionen, sind dafür anfällig. Hier gilt wie bei allen anderen Dingen auch: der beste Schutz ist, das CMS auf dem neusten Stand zu halten. Denn bei den aktuellen Versionen sind die Angriffsflächen soweit wie möglich dezimiert. Wer also derzeit nicht unfreiwillig zu einer Java-Script-Schleuder werden will, sollte sich um regelmäßige Updates kümmern.

Nötige Vorarbeit: Backup

Auf ins Abenteuer. Natürlich zuerst ein Backup. Falls irgendetwas schiefgeht. Für Backups gibt es im Repository mittlerweile mehrere Extensions. Ich nutze w4x_backup. Ist zwar auch eine Beta-Version, erlaubt aber laut eigener Aussage ein vollständiges Backup - was mir sehr gelegen kommt. Außerdem scheint mir die Extension relativ gut dokumentiert zu sein.

Die Installation klappt bei mir problemlos; nach einem Neuladen der Seite erscheint die Extension links unter Tools - dort, wo sie hingehört. Also los: Ich gebe an, dass ich gern auch das ganze typo3conf-Verzeichnis mitnehmen würde. Sieht w4x aber anders. Fehlermeldung. Ca. 500 Dateien würden Probleme bereiten. Und ohnehin gäbe es einen mysqldump- und einen tar-error. Als ich die Option "Proceed without permissions check" anklicke, ist die Extension zwar zunächst ein wenig irritiert (Sicherheitsabfrage: Wollen Sie wirklich?), zeigt dann aber nach einem beherzten Klick auf "Backup jetzt erstellen" stolz an: "Backup Created".

Wenn ich mir jetzt das Backup ansehe, fehlen die ganzen Dateien aus dem typo3conf-Ordner, die Dateien aus dem fileadmin und den uploads, von denen mir die Extension ja schon vorher gesagt hatte, es würde Probleme mit ihnen geben. Ist aber wohl nicht so dramatisch, da ich an diesem Ordner ohnehin nichts verändern will.

Nun aber wirklich: Update via ftp

Im source-package, dass ich mir bei SourceForge.net ziehe, sind lediglich die Ordner misc, t3lib und typo3 und eine neue index.php (sowie einige dokumentierende txt-Dateien) enthalten. Jene Ordner, die meine selbst erstellten bzw. hochgeladenen Dateien enthalten, sind von dem Update also gar nicht betroffen. Das vereinfacht die Sache.

Da der Upload dieser Ordner bzw. Datei via ftp aber eine Ewigkeit dauert (mittels UMTS habe ich es geschafft, die Prozedur auf eine dreiviertel Stunde zu zerdehnen), macht es Sinn, den gesamten typo3_src-Ordner mit Versionsendung zunächst hochzuladen. Erst im zweiten Schritt bekommt mein alter typo3_src-Ordner die alte Versionsnummer, während ich die Nummer vom neuen Ordner lösche. Das hat den Vorteil, dass die Seite während des uploads erreichbar bleibt - und ich schlimmstenfalls wieder zur alten Version zurückwechseln kann, wenn irgendetwas wieder Erwarten nicht funktioniert.

Falls auf dem Server kein typo3_src-Ordner existiert und die Ordner misc, t3lib und typo3 auf der obersten Ebene herumliegen, hilft ein anderer Trick beim Upload. Ich habe bei einer Installation genau dieses Problem gehabt. Deswegen habe ich, nachdem ich den typo3_src-Ordner der neuen Version auf der Festplatte entpackt hatte, die drei Ordner umbenannt. Sie hießen nun misc_new, t3lib_new und typo3_new. Ebenso habe ich die index.php in index_new.php umbenannt. So konnte ich sie problemlos hochladen, ohne dass es zu einer Kollision mit den alten Dateien kam. Als alles auf dem Server war, benannte ich die alten Ordner (und die index.php) mit der Endung _old um und entfernte die Endungen _new von den neu hochgeladenen Dateien.

Was folgt, ist der obligate Gang ins Installationstool, um über den Database-Analyser zu schauen, welche Tabellen für das neue typo3 erweitert oder verändert werden müssen. Beim Sprung von 4.1.5 zu 4.2.5 sind das eine ganze Menge. Zum Glück läuft das relativ selbstständig über den Button am Ende der Seite.

Dann rein in den Update-Wizzard. (Punkt 3 im Install-Tool)

Nun will ich natürlich wissen, ob die Page keinen Schaden genommen hat. Ich gehe also ins Frontend. Im Großen und Ganzen sieht die Seite aus wie immer. Nur: scheinbar gab es bei mir beim Hochladen Datenmurks im Rechner-Cache. So hatte ich am Ende der Index-Seite plötzlich einen Code-Schnipsel stehen, der da nun wirklich nicht hingehörte, und den ich erst einmal wieder aus der index-php entfernen musste. Also gut, hier noch einmal gegenzuprüfen. FTP-Programme mit einer brauchbaren Synchronistation sind hier klar im Vorteil. Nachdem ich drei Tage lang mit einem Update gekämpft habe, ohne es wirklich fehlerfrei zum Laufen zu bringen, habe ich es schließlich geschafft, in dem ich das ftp-Programm gewechselt habe. Mit ws_ftp95 LE dauerte der Upload zwar etwas länger - dafür brauchte ich bei diesem vom Design her sehr simpel anmutenden Programm auch nicht mehr mit Datenmüll in den Dateien zu kämpfen. - In den einschlägigen Foren stellt sich immer wieder raus, dass die meisten Fehler, die beim Update passieren, auf Datenmüll in den Dateien beruhen: überflüssige Leerzeilen, falsch gesetzte Leerzeichen oder gar - wie einmal bei mir - Skriptteile von anderen Dateien und doppelter Skriptcode - alles beim Upload von einem übereifrigen ftp-Programm gesetzt. Wer also das Update nicht zum Laufen bringt, sollte zumindest einen Programmwechsel in Erwägung ziehen. Damit lässt sich viel Stress sparen.