Im Geiste der Vorweihnachtszeit schreiben auch wir unseren Wunschzettel. Adresse ist jedoch nicht der Nordpol sondern so ziemlich jeder Webhoster auf dem Globus.
Der Grund für den Wunschzettel: Es gibt Probleme, die tauchen mit schöner Regelmäßigkeit auf. Nicht alle diese Probleme liegen im Einflussbereich eines Script-Entwicklers, sondern lassen sich dem Webspace-Provider in die Schuhe schieben. ;-)
Würden Webhoster die folgenden Punkte beherzigen, senkte sich nicht nur der Support-Aufwand für die Script-Anbieter, sondern auch für die Hoster.
1. Cron Jobs
Das Optimum wären Web-basierte und möglichst fein einstellbare Cron Jobs, gespickt mit einer verständlichen Anleitung. Web-basiert bekommt man ja noch in den meisten Fällen, aber mit fein einstellbar hapert es aber oft.
So erlaubt zum Beispiel Domainfactory selbst auf einem Managed Server keine kleinere Einstellung als alle 30 Minuten. Das verwundert, kann man doch bis zu 50.000 Datenbanken einrichten. Wer als Webhoster in der Lage ist, eine solche Masse an Datenbanken zu verwalten, sollte auch in der Lage sein, vernünftige Cron Jobs anzubieten. Feiner als alle halbe Stunde sollte möglich sein, ohne Probleme auf dem Server zu verursachen. Möglichkeiten gäbe es da sicherlich genug.
2. Aktuelle Software-Versionen
Als die c't vor einer Weile die Software von Webhostern auf Aktualität überprüfte, wurde deutlich, dass man als Webhosting-Kunde fast durchweg nur alte Software bekommt. Und das obwohl aktuelle Versionen schon seit längerem verfügbar waren.
Insbesondere bei Script-Sprachen scheinen Webhoster zu befürchten, dass Updates nur Chaos verbreiten. Wer allerdings Updates nicht installert, aus Angst vor plötzlich nicht mehr funktionierenden Kunden-Scripten, löst das Problem nicht, sondern schiebt es nur vor sich her. Mal davon abgesehen, dass ein kompetenter Server-Betreiber in der Lage sein sollte, Dinge dieser Art auf die Reihe zu bekommen. Ist schließlich sein Job. Dafür bezahlen ihn seine Kunden.
3. Versteckspiel mit Datenbank-Zugangsdaten
Für die Installation von Scripte mit Datenbankunterstützung benötigt der Script-Nutzer folgende Informationen:
- Version der Datenbank-Software
- Host-Name
- Datenbank-Name
- Datenbank-Benutzer
- Datenbank-Passwort
Nur selten lassen sich diese Details übersichtlich auf einer Seite finden. Stattdessen sind sie über mehrere Seiten verstreut. Damit hat man noch Glück. Denn meistens fehlt der Host-Name ganz oder das Passwort lässt sich nicht anzeigen. Komfortabel geht anders.
4. Zugrif auf externe Resourcen
Warum es Webspace-Provider wie den US-Hoster Godaddy gibt, die Scripten den Zugriff auf einen externen Mail-Account (zum Beispiel Google Mail) verweigern, ist unklar. Leider merkt der Kunde solche Sachen erst, wenn es zu spät ist – also die Hosting-Gebühren für die nächsten 12 Monate bereits abgebucht wurden.
5. Datenbank-Backups
Datenbank-Backups sollten auch ohne phpMyAdmin oder ähnliche Anwendungen möglich sein. Als Kunde kann man bei den meisten Hostern Datenbanken und Datenbank-Benutzer nach Belieben erstellen und löschen. Da sollte es doch auch möglich sein, auf Knopfdruck Backups der Datenbanken erstellen oder bestehende Backups wieder importieren zu können. phpMyAdmin ist für viele Leute zu kompliziert und unterliegt zudem (wie auch andere Scripte) der Laufzeitbeschränkung.
6. Schreibrechte für Dateien und Verzeichnisse
Die vermeintlichen Probleme von standardmäßig schreibbaren Dateien und Verzeichnisse, ohne zuvor chmod auszuführen, sind bekannt. Wieso jedoch schaffen es große Webspace-Provider dies trotzdem zu ermöglichen, ohne dass ihre Kunden die Server reihenweise zu Grunde richten und Hackern Tür und Tor öffnen?
7. Vollständige Installation von Scriptsprachen.
Nicht das zum Beispiel bei PHP wichtige Erweiterungen wie IMAP, GD Library oder Freetype fehlen.
8. PHP: Error Reporting und Error Log
Wenn schon das Error Reporting abgeschaltet ist, dann sollte doch wenigstens automatisch eine PHP Error Log erstellt werden. Oder besser noch, warum nicht standardmäßig immer eine PHP Error Log erstellen. Die Apache Error Log ist auch Standard. Gleiches Recht also für alle.
Ob die PHP Error Log an einem zentralen Ort oder direkt im Scriptverzeichnis erstellt wird, ist dann fast auch egal.
9. Log-Dateien
Bei manchem Webspace-Provider kommt man nur über Umwege an die Log-Dateien (Access, Error, PHP Error), und zwar nur über die Web-Oberfläche des Betreibers. Welchen Sinn das haben soll, weiß nur der Webhoster. Wenn überhaupt. Log-Dateien sollten bequem per FTP erreichbar sein.
10. Schwarzer Peter
Ja, manchmal hat der Kunde Schuld an einem Problem. Ja, manchmal hat das Script einen Fehler. Ja, manchmal liegt das Problem beim Script-Entwickler. Aber deshalb bei Problemen mit Scripten die Verantwortung automatisch abzuschieben ist nicht die feine englische Art. Denn ebenso oft liegt das Problem auf Seiten des Webspace-Providers.
Die Pear-Klasse QuickForm ist so ein nichtsahnender Kandidat. Bevor QuickForm POST-Daten zurück in die Formularfelder schreibt, überprüft die Klasse, ob magic_quotes_gpc aktiviert ist. Ist dies der Fall, werden eventuell vorhandene Backslashes vorher entfernt, andernfalls werden die Daten unverändert übernommen. In einer Situation, in der magic_quotes_gpc abgeschaltet ist und wir $_POST nachträglich mit Backslashes versehen haben, tauchen diese Backslashes in den Formularfeldern auf.
