[TYPO3-german] Domainwechsel

[Stephan Schuler]

Hallo Jochen.


Ich vermute, dass dein Kunde keinen Domainwechsel sondern eher einen Providerwechsel haben möchte -- und dorthin seine bisherige Domain mitnehmen. Bei Preisen um die 10€/Jahr sollte sich niemand mit dem Gedanken tragen, eine bestehende Domain (unter die mich vermutlich einige Kunden kennen) löschen zu lassen.

Du musst vorher klären, was eigentlich genau passieren soll. Ein bestehndes TYPO3 von einem Hoster zu einem anderen Hoster zu übertragen ist etwas anderes als eine vollständig neue Präsenz aufzubauen. Insbesondere was den Zeitraum des Umstiegs und ggf. anfallende Benutzereingaben (sowohl durch Redakteure im Backend als auch durch Kunden im Frontend) betrift muss hier unterschiedlich viel Aufwand betrieben werden.

Eine neue Webpräsenz bei einem neuen Hoster frisch aufzuziehen ist recht einfach: Ich installiere sie dort, lasse mir dafür so viel Zeit wie ich will und brauche und drehe anschließend den Domaineintrag meiner bestehenden Domain sodass der nicht mehr zum alten sonern zum neuen Provier zeigt.

Eine bestehende Webpräsenz zu einem anderen Provider zu ziehen ist deutlich aufwändiger weil ein Umzug nich von jetzt auf gleich passiert sondern einen gewissen Zeitraum beansprucht. Wie man den möglichst gering hält dazu später mehr.
Ein solcher Umzug ist eine Kopie. Nachdem der Umzug durchgeführt ist existiert meine Seite doppelt. Die Domain ist nur einfach vorhanden, aber einige Kunden kennnen ggf. noch die alte IP. Ich muss deshalb dafür sorgen, dass ab dem Beginn des Umzugs keine Eingaben im Altsystem mehr erfolgen.
Ich muss natürlich zunächst allen Redakteuren mitteilen, dass sie für die Dauer des Umstiegs keine Eingaben durchführen können. Dafür setze ich einen Stichtag (mit Uhrzeit) und sperre zu diesem Zeitpunkt das TYPO3-Backend. Die Datei imi typo3conf-Verzeichnis heißt "LOCK_BACKEND", sobald die existiert kann niemand (auch kein Administrator) mehr ins Backend bevor die Datei nicht wieder gelöscht ist. Das kann ich meinen Redakteuren ankündigen. Bei größeren Firmen sollte es genügen, den zuständigen IT-Ansprechpartner darüber zu informieren, der wird das seinen Kollegen schon weiterleiten.
Außerdem habe ich ggf. Frontendeingaben die ich nicht verlieren kann und möchte. Wenn ich mir eine Downtime meiner Webseite leisten kann, oder jedenfalls des Bereichs der durch Benutzer bearbeitet werden kann, dann sollte ich das ausnutzen. Ein Forum oder ein Gästebuch würde ich für die Dauer des Umsteigs sperren, diesen Prozess kann man den ggf. aktiven Nutzern (im Falle eines Forums) vorher mitteilen. Andere Eingaben, wie z.B. Anmeldungen zu Newslettern (in TYPO3 also das Erzeugen von tt_address-Records über das Frontend) würde ich ggf. von Hand synchronisieren. Sollte (auch wenn das unwahrscheinlich ist) sich in den fünf Minuten des Umzugs jemand am alten System anmelden obwohl ih die Kopie der Datenbank schon im neuen System habe muss ich diesen einen Datensatz eben manuell anlegen.

Kommen wir zur Frage, wie Downtimes und der Zeitraum möglicher gleichzeitiger Verfügbarkeit von Alt- und Neusystem möglichst gering gehalten werden. Ich würde lange vorher (sagen wir 48h vorher) den TTL-Wert einer Domain auf eine bis fünf Minuten reduzieren. Dadurch wird jeder Rechner der die Domain kennt angewiesen, sich die Zuordnung zwischen Domain und IP nur ein bis fünf Minuten (eben so lange wie ich das konfiguriert habe) zu merken. Wenn ich das nicht mache, merken sich die Browser meiner Kunden die IP der Domain ggf. 24h und fragen so auch einen Tag nach dem Umzug noch den alten statt den neuen Server. Solange beide Server die gleichen Informationen liefern ist das kein großes Problem, wenn es aber darum geht auf welchem Server neue Newsletteranmeldungen landen ist das eben schon ein recht großes.

Das bedeutet zwangsläufig, dass ich für den Umzug mit entsprechend kompetenten Partnern zusammenarbeiten muss. Zu einem Hoster zu wechseln der mir diese Domain-Spielchen (48h vor dem Umzug TTL auf eine Minute reduzieren, 48h nach dem Umzug wieder auf 24h erhöhen) nicht erlaubt erschwert mir das Leben. Entweder ich habe selbst Zugriff auf das Domain-Tool meines Hosters oder ich brauche kompetenten Supprt der mir diese Konfigurationen durchführt.

Ich hatte auch schon mal einen Umzug (eines Intranet-Servers) bei dem ich die TTL der Intranet-Domain nur mit viel bürokratischem Aufwand hätte veranlassen können. Ich habe dann einen Reverse-Proxy konfiguriert der drei Tage vorher die Inhalte des alten Servers ausgeliefert hat, zeitlgiech habe ich die Domain (TTL 24h) auf den Reverse-Proxy gestellt. Zwei Tage später (als ich mir sicher sein konnte dass jeder Rechner im Unternehmen das Intranet auf den Reverse-Proxy auflöst anstatt auf den alten Server) habe ich dann den Reverse-Proxy auf den neuen Server umgeleitet und die Domain auf den neuen Server umgestellt. Weitere zwei Tage später durfte der Reverse-Proxy wieder sterben. Das war für mich ein Aufwand von 45 Minuten (den ich dem Unternehmen natürlich in Rechnung gestellt habe), den Übergangsserver hat mir die IT dieses Unternehmens zur Verfügung gestellt. Trotzdem war das für die deutsche Standort-IT dieses Unternehmens der deutlich geringere Aufwand als zu begründen, warum man für einen von mehreren tausend internen Rechnernamen eines Unternehmens einen zu allen anderen abweichenden TTL-Eintrag haben möchte.

Der weitere Vorteil des Reverse-Proxys bei Intranetserern ist, dass mich Unternehmen die mir einen VPN-Zugang in ihr Intranet und den SSH-Zugang auf en Intranetserver geben nur ganz selten an ihrem Intranet-DNS spielen lassen. Durch diesen Reverse-Proxy kann ich die Umstellung dann durchführen wann ich es für sinnvoll halte und muss mich nicht an die Geschäftszeiten des für das DNS zuständigen Mitarbeiters richten.

Wo wir auch gleich beim nächsten Punkt wären: Eine Umstellung würde ich grundsätzlich dann durchführen, wenn die geringste Last im System zu erwarten ist. Bei deutschen Firmenwebseiten ist das häufig nachts und noch häufiger am Wochenende. Je nach Auftragsvolumen setze ich mich dann schon mal in der Nacht von Samstag auf Sonntag hin und führe den Umzug durch. Nachdem aber Umzüge manchmal auch Probleme mit sich bringen die es dann zu korrigieren gibt, ist das natürlich nicht bei jeder Auftragsgröße machbar. Was aber auch keine große Rolle spielt, es ist schließlich auch nicht bei jedem Kundenauftrag notwendig.

Was die Frage nach den Fähigkeiten des Systems bzw. den passenden Mitteln für eine bestimmte Aufgabe betrifft so gibt es nur eine Antwort: Es kommt drauf an. Ich kann natürlich alles in TYPO3 realisieren. Aber ich will nicht. Und TYPO3 will nicht.
Wenn ein Forum gewünscht ist geht das in TYPO3, und für einige Ansprüche ist das mm_forum auch durchaus passabel. Aber ein fertiges WBB (die Lizenzen müsste man sich mal ansehen, ggf. ist die einmalige 50€-Lizenz notwendig) ist um Längen einfacher konfiguriert und gewartet. Wenn die Frage nach einem Forum gestellt wird und es keine 100%ige Integration in die Webseite geben muss würde ich das allem anderen vorziehen.

Die Anforderung, Dateien auf dem Webserver zu verwalten hatte ich bisher übrigens noch nie. Jedenfalls noch nie über ein PHP-Tool. Für solche Fälle würde ich einen FTP-Zugang konfigurieren. Insbesondere wenn auf einem Webspace ein TYPO3 läuft will ich z.B. überhaupt nicht, dass sich der Kunde in anderen Verzeichnissen als dem fileadmin bewegt. Ich konfiguriere dazu einen FTP-User der genau dieses Verzeichnis sehen darf, damit sind alle Parteien zufriedengestellt.

Du suchst einen Hoster der was taugt? Es wurden einige genannt. Ich kann dir von keinem eigene Erfahrungen nennen weil wir ausschließlich eigene Server stehen haben. Was auch einer der wesentlichen Aspekte für effitiente Umzüge ist: Ich kenne meine Umgebung auswendig. Natürlich beauftragen auch Kunden Umsetzungen die anschließend bei anderen Hostern laufen sollen. Nur brauche ich da eben entsprechend länger um viele Kleinigkeiten zu konfigurieren. Es fängt damit an dass ich YaST anders verwenden muss und es nach anderen Paketnamen fragen als das bei aptitude der Fall ist und hört mit den unterschiedlichen sinnvollen Parametern unterschiedlicher Image- oder GraficMagic-Versionen auf.

Da fällt mir übrigens ein weiterer wichtiger Punkt ein: Fertige TYPO3-Pakete.
Hat der Zielhoster ein eigens TYPO3-Paket? Dann nimm das. Die gefühlten 1'000 Parameter des Install-Tools die sich von Server zu Server unterscheiden (Outputkomprimierung, Grafikparameter, Programmpfade, CURL-Konfiguration, etc) nötigen dich schon fast dazu.
Hast du ein Standardpaket? Dann nimm das. Nichts ist nerviger als im Verlauf einer Installation alle acht Minuten festzustellen dass schon wieder Typoscript anders aussieht als die hundert Installationen davor und dass schon wieder Extensions nicht installiert sind.
Natürlich kannst du nicht gleichzeitig das TYPO3 des Hosters verwenden und dein eigenes. Aber man muss sich eben darauf einstellen, dass egal welche Wahl man trifft es jeweils die falsche war :).

Meine liebsten Deployments: In meiner eigenen Infrastruktur.
Meine zweitliebsten Deployments: Komplette ESX-Images die aus meiner Infrastruktur zum Kunden ziehen. Gerne auch mal auf DVD via Kurier.

Ich hoffe man sieht: Es spricht hier nicht nur einiges an Erfahrung sondern auch an Herzblut.


Grüße,


Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Website: media.netlogix.de


--
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Internet: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



________________________________________
Von: typo3-german-bounces at lists.typo3.org [typo3-german-bounces at lists.typo3.org]" im Auftrag von "Guido Palacios [guido.palacios at web.de]
Gesendet: Mittwoch, 17. August 2011 19:53
Bis: German TYPO3 Userlist
Betreff: Re: [TYPO3-german] Domainwechsel

Hey Phillip,

Ein bot Text hätte die frage mit sicherheit verständlicher formuliert ;-)

@Jochen: was meinst du mit "wie macht ihr das"? Einen Domainumzug
selber? Oder die auswahl der Extensions die dein kunde auf dem alten
System hatte? Wir sollten alle denke ich erst einmal wissen, was genau
du wissen willst bzw. was dein IST zustand ist und was der SOLL zustand
sein soll. Für uns ist leider unklar, was "machbar" sein soll.

Grundsätzlich kann TYPO3 aber alles (bis auf Schwäbisch - zu schade=) -
das kannst deinem Kunden auch so weiter geben =)

Wegen Anbieter, Strato kann ich auch nicht empfehlen. Ich selber bin
inzwischen seit +4 Jahren und das sehr Zufrieden bei 1und1 (3 Jahre
root, seit 1nem Jahr ein vserver). Es soll aber auch Leute geben die mit
Herrn Davis nichts anfangen können =)

Gruß
guido

Am 17.08.2011 18:42, schrieb Philipp Gampe:
> Philip Hahn wrote:
>
>> Sorry, soll das da unten Deutsch sein? Wenn ja, dann muss ich mir mal
>> einen aktuellen Duden holen. Wenn nein, dann übersetze das Ganze doch
>> bitte einmal, schließlich sind wir in der deutschen Userlist.
> Ich Tippe eher auf einen Bot Text.
>
> Grüße
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german