Angeregt durch einen Kommentar von Thorsten auf meinem etwas älteren Post über ein geteiltes Typo3-Setup auf einem virtuellen Server 3.0 von Hosteurope, habe ich über das Wochenende ein Update auf die neueste Version des vServers gemacht und dabei gleich auch das Typo3 auf den aktuellen Stand gebracht. Ein kurzer Abriss.
Hosteurope bietet für die 4. Generation der virtuellen Server leider kein SuSE Linux mehr an, weshalb ich mich für das Update auf ubuntu entschied.
Die Bereitstellung des Servers für das Update dauerte ca. 24 Stunden, nun hatte ich 7 Tage Zeit, den gesamten Content vom „alten“ 3.0. Server auf den „neuen“ 4’er zu verfrachten.
Hier also der Bericht über die „Stoplersteine“ beim Umzug und TYPO3-Upgrade.
Kein Problem stellte die Migration des gesamten Servercontents dar. Nach dem obligaten Softwareupdate (Plesk, OS) einfach den Migrations-Manager angeworfen, die Zugangsdaten des alten Server eingetippt und alles migrieren lassen.
Wäre schön, wenn das dann alles gewesen wäre.
Aber: Auf dem genannten vServer befindet sich eine zentrale TYPO3 Installation ausserhalb des Seitenbaumes einer jeden Präsenz. Also werden lediglich die Inhalte der jeweiligen Domain, die Datenbanken und die Maileinstellungen transferiert. Ist ja auch schon mal was…
Dumm und nicht ganz nachzuvollziehen: Warum müssen sich ständig bei Versionswechseln auch die Pfade im System ändern?
Will sich da jemand ein Denkmal setzen?
Konkret:Früher, unter vServer 3.0, lag die Webserver-Root unter /srv/www – Nun, unter 4.0 und ubuntu darf es also /var/www sein.
Okay, wenn’s denn sein muss.
Also bin ich auf der Shell in dieses Verzeichnis /var/www gewechselt und hab dann mittels wget die aktuellen TYPO3-Sourcen von der Downloadseite gezogen.Rasch entpackt und schon war das aktuelle TYPO3 im Verzeichnis /var/www/typo3_src-4.3.0 angelegt.
Ich erinnere daran: Der Server wird NUR von mir allein genutzt, daher verzichte ich auf etwas Sicherheits-Paranoia. Deswegen erlaube ich mir, das Typo3 Sourcen-Verzeichnis dem Webserver zu übereignen. Wer sich mehr Zeit nehmen möchte, sei auf Google verwiesen. FastCGI oder PHP als CGI sei noch als Stichwort genannt. Eine Kanne Baldrian-Tee sollte auch bereit stehen ;) Aber nun zurück zu meiner Baustelle:
Natürlich ist der Apache auf ubuntu auch nicht mehr wwwrun.
Wozu auch? www-data heisst der Häuptling heute, der selben Gruppe zugehörig.
Also:
- chown -R www-data.www-data /var/www/typo3_src-4.3.0
und Gut ist. Den selben Schritt auch für jedes httpdocs Verzeichnis, das später mit TYPO3 laufen soll, richtet es so, dass es tun sollte.
Tut’s aber nicht. Weil nun natürlich die Symlinks auf die TYPO3-Sourcen nicht mehr stimmen, wegen dem Denkmal.
—
Exkurs:
Wenn man mehr als eine TYPO3-getriebene Webseite auf einem Server hat, bietet sich eine zentrale Installation der TYPO3-Sourcen an.
Bei einem Update muss man dann nur noch diese Sourcen aktualisieren und hat mit einem Schlag alle Präsenzen auf dem neuesten Stand. Theoretisch.
Damit das klappt, muss man halt die wichtigen Verzeichnisse aus dem jeweiligen DocRoot auf die entsprechenden Verzeichnisse der TYPO3-Sourcen verlinken. Für ein späteres Update aktualisiert man nur die Links und fertig. Dazu habe ich folgende Struktur auf meinem vServer:
Typo3-Sourcen in
- /var/www/typo3_src-4.3.0 (oder aktuelle Versionsnummer halt).
Einen Symlink auf dieses Verzeichnis in
- /var/www : typo3act -> typo3_src-4.3.0/
Und dann innerhalb der httpdocs-Verzeichnisse jeweils:
- misc -> /var/www/typo3act/misc/
- t3lib -> /var/www/typo3act/t3lib/
- typo3 -> /var/www/typo3act/typo3/
Wenn ich nun den lediglich den einen Link „typo3act“ auf die neue Version ändere, aktualisiere ich automatisch alle virtuellen Hosts auf einen Schlag ;)
Dass man in der vhost.con ein paar Einstellungen gemacht haben sollte, erwähnte ich schon im vorhergehenden Artikel, aber der Vollständigkeit halber:
<Directory /srv/www/vhosts/DOMAINNAME/httpdocs>
Options +FollowSymLinks
php_admin_value open_basedir „/var/www/vhosts/DOMAINNAME/httpdocs:/tmp:/var/www“
php_admin_flag safe_mode off
</Directory>
—
Nun sollte theoretisch nach einem Webserver-Restart alles laufen. Ein frommer Wunsch, der natürlich nicht erhört wurde…
Der Migration-Manager von Plesk. Eine echte Hilfe. Aber auch ein *?#&&!-Teil!
Der Migration Manager hat bei mir alles Wort-Wörtlich mirgiert. Also auch alle Pfad-Anweisungen in den httpd.include Dateien. Folge: Der Webserver findet seine virtuellen Hosts nicht mehr und verabschiedet sich mit lakonischer Fehlermeldung.
In jeder httpd.include also nun alle Pfade anpassen? „Hey, Sysiphus, heute schon was vor?„…
Lassen wir Das... Linker Typ, der ich bin, hilft ein
- ln -s /srv/www /var/www
und Zack, stimmen die Pfade für den Webserver. Ätsch!
Aber die IP’s für den virtuellen Host… Die stehen auch falsch in der httpd.include. Nunja, die hab ich dann noch händisch geändert.
Einmal /etc/init.d/apache2 restart und ….. viola, es läuft.
Sogar die TYPO3-Webseiten sind da und laufen auf den ersten Blick perfekt.
Mal im Backend nachgesehen, die neue Version 4.3.0 ist da und meckert nicht. Jetzt noch den Update-Wizard im Install-Tool anwerfen und ein paar Abfragen „durchklicken“. Und da heisst es etwas aufpassen:
Bei mir verabschiedete sich nach dem Update die Erweiterung real_url ohne Fehlermeldung oder sonstiges. Die Links funktionierten einfach nicht mehr. Eieiei…. Böses Foul, was ist passiert?
- Der Update Wizard von TYPO3 4.3.0 schiebt einem, wenn man etwas vorschnell klickt, die Extension Simulate Static URLs [simulatestatic]
unter. Diese Extension „beisst“ sich mit real_url und führt dazu, dass real_url ohne Fehlermeldung nicht mehr läuft. Im Extension Manager kann man die wieder ausschalten und real_url kooperiert wieder. - Wenn Sie UTF-8 verwenden, kann es passieren, das Sie beim Schlussendlichen „Compare Database“ die Tabelle „tx_realurl_uniqalias“ nicht anlegen können. Grund hierfür ist eine Überschreitung einer maximalen Indexgrösse von 1000 Bytes in mysql. Abhilfe: Lassen Sie sich die SQL-Query anzeigen und verwenden Sie phpmyadmin aus Plesk um die Query manuell einzugeben. Ändern Sie vorher den Wert in der Query von „value_alias varchar(255)“ auf „value_alias varchar(220)„
Dann läuft auch real_url wieder. Oder warten Sie mit dem Update von TYPO3, bis nicht mehr die 4.3.0 aktuell ist – Ein Update auf eine Nuller-Version ist normal nur was für Neugierige :)
So, ich denke, auch hier wird es wieder die eine oder andere Meinung geben? Ich freue mich schon!
Bis bald.
Schreibe einen Kommentar