Typo3 - Wartung: Unterschied zwischen den Versionen
| Zeile 3: | Zeile 3: | ||
== Wartungsaufgaben == | == Wartungsaufgaben == | ||
| + | === Checkliste === | ||
| + | Von http://jweiland.net/index.php?id=typo3-wartung Datum des Zugriffs: 18.7.2007 | ||
| + | |||
| + | ==== Wartungsarbeiten für TYPO3 Projekte ==== | ||
| + | |||
| + | TYPO3 installieren und dann vergessen? Nein, so einfach ist das nicht. Wie ein Auto sollte man auch eine TYPO3 Installation einer regelmäßigen Inspektion unterziehen. Diese Seite erklärt, worauf es ankommt. | ||
| + | |||
| + | '''1. Wachsender Bedarf an Speicherplatz | ||
| + | ''' | ||
| + | Jede TYPO3 Installation verfügt über einen begrenzten Speicherplatz, ganz gleich ob es sich um Webspace oder einen eigenen Server handelt. Im Kundenmenü des Providers befindet sich in der Regel eine Abrufmöglichkeit für den bereits belegten bzw. freien Speicherplatz. | ||
| + | |||
| + | Der Bedarf an Speicherplatz wächst aber nicht nur mit dem Einstellen neuer Inhalte auf der Webseite (insbesondere Bilder und Multimedia-Inhalte) sondern auch durch Logdateien. | ||
| + | |||
| + | Da sind einerseits die vom Webserver erstellten Logfiles: je nach Konfiguration werden diese nach ein paar Wochen gelöscht oder aber auch für einen unbegrenzten Zeitraum gespeichert. | ||
| + | |||
| + | Generell sollten Logdateien vor einer Löschung archiviert werden (z.B. auf ein externes Medium), damit man bei Bedarf wieder auf die Daten zugreifen kann. | ||
| + | |||
| + | Auch TYPO3 selbst bietet die Möglichkeit, z.B. für die Erstellung von Statistiken mit AWSTATS, Logdateien zu erstellen. | ||
| + | |||
| + | Im Gegensatz den den Logdateien des Servers wird hier allerdings nur eine Zeile je Seitenzugriff gespeichert (der Server speichert Zugriffe auf alle Dateien). Aber die Logdatei von TYPO3 kann im Laufe der Zeit eine beträchtliche Größe erreichen. Allerdings liegt hier die maximale Dateigröße auf den meisten Systemen bei 2 GB, danach werden keine weiteren Daten mehr protokolliert. | ||
| + | |||
| + | Sinnvoll wäre hier z.B. zu Jahresbeginn die Einträge des Vorjahres in eine separate Datei auszulagern und wieder frisch anzufangen. Auf der Unix-Shell könnte das Anfang 2007 z.B. so aussehen: | ||
| + | |||
| + | # Extrahieren und Packen der Daten von 2007: | ||
| + | egrep "/2007:" logfile.log > 2007.log | gzip | ||
| + | |||
| + | # Extrahieren der Daten vom Beginn des Jahres 2008: | ||
| + | egrep "/2008:" logile.log > 2008.log | ||
| + | |||
| + | # Kopieren von 2008.log in die 'neue' Datei logfile.log: | ||
| + | cp 2008.log logfile.log | ||
| + | |||
| + | '''2. Datenbanken, die aus allen Nähten platzen''' | ||
| + | |||
| + | So eine MySQL Datenbank kann schon beachtlich groß werden. Die größte TYPO3 Datenbank die ich im Einsatz gesehen habe, hatte über 50 GB Umfang. So eine Größe geht natürlich auch zu Lasten der Performance. | ||
| + | |||
| + | In der Datenbank neben den eigentlichen Inhalten auch viele Cache-Tabellen und temporäre Daten verwaltet. Oft stellt man fest, dass gerade die "cache...." Tabellen am meisten Platz benötigen. | ||
| + | |||
| + | Zusätzlich gibt es Extensions wie sys_stat oder vts (Visitor Tracking System), die jeden Seitenaufruf protokollieren. Nach einer Millionen Seitenaufrufe haben diese Tabellen entsprechend viele Einträge. | ||
| + | |||
| + | Die Einträge aus der Tabelle sys_stat dienen z.B. zur Anzeige der Zugriffe in den letzten 30 Tagen unter Web->Info->Zugriffstatistik. Dadurch macht es relative wenig Sinn, in dieser Tabelle die Daten mehrerer Jahre zu speichern. Über einen cronjob könnte man z.B. regelmäßig alle Datensätze entfernen (oder in einer Datei auslagern), die älter als 30 Tage sind. | ||
| + | |||
| + | Auch für Extensions wie vts muß man sich überlegen, ob eine Erfassung aller Zugriffsdaten sinnvoll ist. Nützlicher wäre in vielen Fällen die Datensammlung über einen Zeitraum von einer Woche und das 1-2 Mal pro Jahr. | ||
| + | |||
| + | '''3. Backups''' | ||
| + | |||
| + | Ein Administrator sollte in regelmäßigen Abständen prüfen, ob die Backups der Dateien und Datenbanken korrekt angelegt werden. Ideal ist eine gelegentliche Prüfung, ob sich die Daten aus den Backups auch wiederherstellen lassen. | ||
| + | |||
| + | Bei unseren TYPO3 Hosting Paketen werden z.B. doppelte Backups angefertigt: einerseits auf dem Webspace selbst (kostet zwar Speicherplatz, aber der Kunde hat selbst Zugriff auf die Dateien), andererseits auf externe Systeme. | ||
| + | |||
| + | Beim Prüfen der Datensicherung auch darauf achten, ob z.B. neu angelegte TPYO3 Projekte und Datenbanken auch mit in das Backup aufgenommen werden. | ||
| + | |||
| + | Sehr sinnvoll ist es auch, z.B. einmal im Monat ein Backup zusätzlich auf CD/DVD zu speichern. | ||
| + | |||
| + | '''4. Aktuelle Versionen und Security Updates''' | ||
| + | |||
| + | TYPO3 und auch die Extensions werden ständig weiterentwickelt. Das sollte schon Grund genug sein, ein System immer auf dem Laufenden zu halten und Updates zu installieren. | ||
| + | |||
| + | Ganz wichtig ist die zeitnahe Installation von Updates, die nach Entdeckung einer Sicherheitslücke verfügbar gemacht werden: hier beginnt bei Bekanntgabe der Lücke nämlich ein Wettlauf zwischen Hackern, die diese Lücke ausnutzen wollen und den Betreibern von Webseiten, die ihre Systeme wieder absichern möchten. | ||
| + | |||
| + | Security Updates gibt es übrigens meist nur für die jeweils aktuelle TYPO3 Version, das ist ein weiterer Grund um sein System immer auf dem aktuellen Stand zu halten. | ||
| + | |||
| + | '''5. Verdächtiges aufspüren''' | ||
| + | |||
| + | In regelmäßigen Abständen sollte ein Administrator die Liste der TYPO3 Backend-Benutzer kontrollieren. Wurden hier z.B. über SQL-Injection vielleicht neue User angelegt, die dort nichts zu suchen haben? Oder sind hier noch Redakteure gelistet, die schon lange nicht mehr in der Firma arbeiten? | ||
| + | |||
| + | Auch ein Blick in das Systemlog von TYPO3 (Tools->Log) offenbart fehlgeschlagene Loginversuche in das TYPO3 Backend. | ||
| + | |||
| + | Beim Einloggen in das TYPO3 Backend sollte ein Admin-User auch immer auf die gelben Warnhinweise achten, die bei Fehlkonfigurationen angezeigt werden. Nicht umsonst erscheinen sie im knalligen Gelb mit Warndreieck... | ||
| + | 6. Wenn einer eine Reise tut... | ||
| + | |||
| + | Manchmal passieren irgendwelche Dinge, wenn man sie am wenigsten brauchen kann (Murphy's Law). Kaum ist man am Urlaubsort angekommen, stellt sich heraus, dass irgendetwas mit der Webseite nicht stimmt. | ||
| + | |||
| + | So manches kann man ja Dank eines Content Management Systems auch vom nächsten Internetcafe unterwegs erledigen, aber dafür ist es erforderlich, die wichtigsten Daten zur Hand zu haben. | ||
| + | |||
| + | Hier eine Checkliste: | ||
| + | |||
| + | * Zugangsdaten (URL, User, Passwort) für TYPO3 Backend und Kundenmenü | ||
| + | * Telefonnummer des Providers (möglichst keine 0800-Nummer, da diese aus dem Ausland meist nicht erreichbar ist) | ||
| + | * Kundennummer und Passwort beim Provider | ||
| + | |||
| + | '''Fazit''' | ||
| + | |||
| + | Wenn die Hinweise auf dieser Seite beachtet werden, dann steht einem jahrelangen, problemlosen Betrieb von TYPO3 und auch einem längeren Urlaub nichts im Wege. | ||
| + | |||
=== Temporäre Dateien === | === Temporäre Dateien === | ||
Im Install Tool | Im Install Tool | ||
Version vom 18. Juli 2007, 12:59 Uhr
Eine laufende Typo3 Installation muß ab und zu gewartet werden. Das betrifft vor allem die temporären Dateien. Das meiste kann man auch mittels Cron Job automatisieren.
Wartungsaufgaben
Checkliste
Von http://jweiland.net/index.php?id=typo3-wartung Datum des Zugriffs: 18.7.2007
Wartungsarbeiten für TYPO3 Projekte
TYPO3 installieren und dann vergessen? Nein, so einfach ist das nicht. Wie ein Auto sollte man auch eine TYPO3 Installation einer regelmäßigen Inspektion unterziehen. Diese Seite erklärt, worauf es ankommt.
1. Wachsender Bedarf an Speicherplatz Jede TYPO3 Installation verfügt über einen begrenzten Speicherplatz, ganz gleich ob es sich um Webspace oder einen eigenen Server handelt. Im Kundenmenü des Providers befindet sich in der Regel eine Abrufmöglichkeit für den bereits belegten bzw. freien Speicherplatz.
Der Bedarf an Speicherplatz wächst aber nicht nur mit dem Einstellen neuer Inhalte auf der Webseite (insbesondere Bilder und Multimedia-Inhalte) sondern auch durch Logdateien.
Da sind einerseits die vom Webserver erstellten Logfiles: je nach Konfiguration werden diese nach ein paar Wochen gelöscht oder aber auch für einen unbegrenzten Zeitraum gespeichert.
Generell sollten Logdateien vor einer Löschung archiviert werden (z.B. auf ein externes Medium), damit man bei Bedarf wieder auf die Daten zugreifen kann.
Auch TYPO3 selbst bietet die Möglichkeit, z.B. für die Erstellung von Statistiken mit AWSTATS, Logdateien zu erstellen.
Im Gegensatz den den Logdateien des Servers wird hier allerdings nur eine Zeile je Seitenzugriff gespeichert (der Server speichert Zugriffe auf alle Dateien). Aber die Logdatei von TYPO3 kann im Laufe der Zeit eine beträchtliche Größe erreichen. Allerdings liegt hier die maximale Dateigröße auf den meisten Systemen bei 2 GB, danach werden keine weiteren Daten mehr protokolliert.
Sinnvoll wäre hier z.B. zu Jahresbeginn die Einträge des Vorjahres in eine separate Datei auszulagern und wieder frisch anzufangen. Auf der Unix-Shell könnte das Anfang 2007 z.B. so aussehen:
# Extrahieren und Packen der Daten von 2007: egrep "/2007:" logfile.log > 2007.log | gzip
# Extrahieren der Daten vom Beginn des Jahres 2008: egrep "/2008:" logile.log > 2008.log
# Kopieren von 2008.log in die 'neue' Datei logfile.log: cp 2008.log logfile.log
2. Datenbanken, die aus allen Nähten platzen
So eine MySQL Datenbank kann schon beachtlich groß werden. Die größte TYPO3 Datenbank die ich im Einsatz gesehen habe, hatte über 50 GB Umfang. So eine Größe geht natürlich auch zu Lasten der Performance.
In der Datenbank neben den eigentlichen Inhalten auch viele Cache-Tabellen und temporäre Daten verwaltet. Oft stellt man fest, dass gerade die "cache...." Tabellen am meisten Platz benötigen.
Zusätzlich gibt es Extensions wie sys_stat oder vts (Visitor Tracking System), die jeden Seitenaufruf protokollieren. Nach einer Millionen Seitenaufrufe haben diese Tabellen entsprechend viele Einträge.
Die Einträge aus der Tabelle sys_stat dienen z.B. zur Anzeige der Zugriffe in den letzten 30 Tagen unter Web->Info->Zugriffstatistik. Dadurch macht es relative wenig Sinn, in dieser Tabelle die Daten mehrerer Jahre zu speichern. Über einen cronjob könnte man z.B. regelmäßig alle Datensätze entfernen (oder in einer Datei auslagern), die älter als 30 Tage sind.
Auch für Extensions wie vts muß man sich überlegen, ob eine Erfassung aller Zugriffsdaten sinnvoll ist. Nützlicher wäre in vielen Fällen die Datensammlung über einen Zeitraum von einer Woche und das 1-2 Mal pro Jahr.
3. Backups
Ein Administrator sollte in regelmäßigen Abständen prüfen, ob die Backups der Dateien und Datenbanken korrekt angelegt werden. Ideal ist eine gelegentliche Prüfung, ob sich die Daten aus den Backups auch wiederherstellen lassen.
Bei unseren TYPO3 Hosting Paketen werden z.B. doppelte Backups angefertigt: einerseits auf dem Webspace selbst (kostet zwar Speicherplatz, aber der Kunde hat selbst Zugriff auf die Dateien), andererseits auf externe Systeme.
Beim Prüfen der Datensicherung auch darauf achten, ob z.B. neu angelegte TPYO3 Projekte und Datenbanken auch mit in das Backup aufgenommen werden.
Sehr sinnvoll ist es auch, z.B. einmal im Monat ein Backup zusätzlich auf CD/DVD zu speichern.
4. Aktuelle Versionen und Security Updates
TYPO3 und auch die Extensions werden ständig weiterentwickelt. Das sollte schon Grund genug sein, ein System immer auf dem Laufenden zu halten und Updates zu installieren.
Ganz wichtig ist die zeitnahe Installation von Updates, die nach Entdeckung einer Sicherheitslücke verfügbar gemacht werden: hier beginnt bei Bekanntgabe der Lücke nämlich ein Wettlauf zwischen Hackern, die diese Lücke ausnutzen wollen und den Betreibern von Webseiten, die ihre Systeme wieder absichern möchten.
Security Updates gibt es übrigens meist nur für die jeweils aktuelle TYPO3 Version, das ist ein weiterer Grund um sein System immer auf dem aktuellen Stand zu halten.
5. Verdächtiges aufspüren
In regelmäßigen Abständen sollte ein Administrator die Liste der TYPO3 Backend-Benutzer kontrollieren. Wurden hier z.B. über SQL-Injection vielleicht neue User angelegt, die dort nichts zu suchen haben? Oder sind hier noch Redakteure gelistet, die schon lange nicht mehr in der Firma arbeiten?
Auch ein Blick in das Systemlog von TYPO3 (Tools->Log) offenbart fehlgeschlagene Loginversuche in das TYPO3 Backend.
Beim Einloggen in das TYPO3 Backend sollte ein Admin-User auch immer auf die gelben Warnhinweise achten, die bei Fehlkonfigurationen angezeigt werden. Nicht umsonst erscheinen sie im knalligen Gelb mit Warndreieck... 6. Wenn einer eine Reise tut...
Manchmal passieren irgendwelche Dinge, wenn man sie am wenigsten brauchen kann (Murphy's Law). Kaum ist man am Urlaubsort angekommen, stellt sich heraus, dass irgendetwas mit der Webseite nicht stimmt.
So manches kann man ja Dank eines Content Management Systems auch vom nächsten Internetcafe unterwegs erledigen, aber dafür ist es erforderlich, die wichtigsten Daten zur Hand zu haben.
Hier eine Checkliste:
* Zugangsdaten (URL, User, Passwort) für TYPO3 Backend und Kundenmenü * Telefonnummer des Providers (möglichst keine 0800-Nummer, da diese aus dem Ausland meist nicht erreichbar ist) * Kundennummer und Passwort beim Provider
Fazit
Wenn die Hinweise auf dieser Seite beachtet werden, dann steht einem jahrelangen, problemlosen Betrieb von TYPO3 und auch einem längeren Urlaub nichts im Wege.
Temporäre Dateien
Im Install Tool typo3temp/
Datenbank
Im Install-Tool Database Analyser (Wenn Statistik, Log oder ähnliches gelöscht werden soll) CleanUp Database Gecachte Daten bzw. deren Referenzen