Redio Blog

Aus aktuellem Anlass ein Überblick über das, was hier bei Redio an (personenbezogenen) Daten anfällt.

Der Webserver führt ausschließlich ein Logbuch für Fehler, es werden also nicht alle Zugriffe protokolliert, sondern nur solche, die einen Status ungleich 200 zurücklieferten. Eine typische Zeile sieht so aus und enthält die Zeit, IP-Adresse, Datei, Referer und, je nach Fehlertyp, noch andere Informationen:
[Fri Oct 16 22:29:38 2009] [error] [client *] File does not exist: /home/www-data/htdocs/e/example/www/example.php, referer: http://www.example.com
Speicherdauer: 14 Tage.

Auch jeder Versand von Mails wird protokolliert. Gespeichert werden hier Skriptpfad plus Zeile des mail()-Aufrufs und alle E-Mail-Header:
mail() on [/home/www-data/htdocs/e/example/www/emailer.php:212]: To: ...
Speicherdauer: 14 Tage.

Der FTP-Server (das betrifft die wenigsten) speichert alle Verbindungsversuche und alle Aktionen mit Zeit, IP-Adresse und Benutzername:
Thu Oct 15 17:20:21 2009 [pid *] CONNECT: Client "*"
Thu Oct 15 17:20:23 2009 [pid *] [anonymous] FAIL LOGIN: Client "*"
Speicherdauer: 30 Tage.

Das HVS protokolliert diverse “wichtige” Aktionen wie zum Beispiel “Account erstellt”, “Account gelöscht”, “Neues Passwort angefordert”, diverse von Administratoren ausführbare Aktionen, sowie Meldungen von Verwaltungsskripten. Was genau gespeichert wird hängt recht stark vom Meldungstyp ab (Benutzername/-ID, E-Mail-Adresse, Datum des letzten Login, “Onetime-ID”, …), Zeit und Benutzername (falls angemeldet) werden aber immer gespeichert, nicht jedoch die IP-Adresse.
Speicherdauer: Zurzeit unbegrenzt. Es ist aber geplant die Daten nach etwas mehr als einem Monat zu löschen.

Außerdem wird nachts ein Backup der Redio-Datenbank (nicht der Benutzerdatenbanken!) erstellt. Darin befinden sich natürlich alle Daten, die das HVS erhebt (Nutzerdaten wie E-Mail-Adresse und Accountname, aber auch Domains und Datenbanknamen/-passwörter).
Speicherdauer: 14 Tage.

Nach dem kleinen Schock von gestern habe ich nochmal ein wenig genauer nachgesehen:

Es gibt im Moment 1980+2347 = 4327 Benutzer (jeweils lexu + azure). 522+430 = 952 (22,0%) davon haben 0(!) Bytes auf ihrem Webspace (der Webspace ist also leer). 567+499 = 1066 (24,6%) sind mit < 1KB dabei, 568+890 = 1458 (33,6%) haben weniger als 1 MB, 1382+1572 = 2954 (68,2%) weniger als 10 MB und 1947+2300 = 4247 (98,1%) weniger als 100 MB auf ihrem Webspace gepeichert. Datenbanken sind hier aber nicht eingerechnet.

Das heißt im Klartext: Jeder vierte im Moment existierende Account ist “unbenutzt”, wenn man unbenutzt als “weniger als 1 KB belegt” definiert.

…wäre ich fast vom Stuhl gefallen. Der Grund:

400(!) Nutzer weniger. Das ist an sich kein Fehler, denn es waren alles Nutzer, die sich — selbst nach Aufforderung per E-Mail — vor mehr als 6 Monaten eingeloggt hatten und damit als “inaktiv” markiert wurden. Aber ein bisschen viel ist es schon…

Der Umbau ist komplett. Beide Server, azure gestern und lexu heute morgen, sind auf ein leicht modifiziertes mod_fcgid umgestellt worden. Modifiziert in der Hinsicht, dass die PHP-Authentifizierung wieder funktioniert und dass nicht für jeden vHost neue Worker gespawnt werden. Alles natürlich in der Hoffnung, dass die Umstellung die Probleme der Vergangenheit löst — so ganz sicher ist man sich da vorher aber nie…

Seit einiger Zeit beobachte ich dieses Phänomen nun schon: Plötzlich — wie aus dem Nichts — werden von FastCGI/PHP keine Anfragen mehr bearbeitet. Es gibt nur noch einen Timeout und den damit verbundenen “Internen Serverfehler”. So auch heute wieder zwischen 12:20 und 13:00 Uhr.

Typische Log-Einträge sind dann:

[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first read) idle timeout (30 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

oder auch

[error] (4)Interrupted system call: FastCGI: comm with server "/usr/local/fcgi-bin/fcgi-php-user" aborted: select() failed
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

Letztere Meldung lässt sich angeblich durch ein Update von mod_fastcgi beheben. Das wird wohl auch für Redio mal fällig.

Update: Ich sehe gerade, dass die Apache Foundation die Rechte an mod_fcgid übernommen hat und das Modul aktiv weiterentwickelt. Das wäre sicherlich die bessere Alternative, als weiterhin auf mod_fastcgi zu setzen, das schon mehr als eine Jahr kein Update mehr erfahren hat.

Seit acht Tagen gibt es nun PHP 5.2.11, inklusive “Security Enhancements”. Installiert ist es aber noch nicht? — Doch, schon.

Es gibt nur ein Problem: Diese Version ist wesentlich instabiler als 5.2.10. Ein Vergleich: In den letzten 24 Stunden gab es mit 5.2.10 ganze Null(!) Segfaults (also Fehler beim Zugriff auf den Speicher, die zum Absturz des Programms führen). PHP 5.2.11 hingegen häuft (morgens) in drei Stunden 23 Stück davon an. Hochgerechnet auf einen Tag dürften es also 200 und mehr werden. Das heißt aber auch 200 Zugriffe, bei denen ein Benutzer nur einen “500er” Serverfehler zu sehen bekommt. Das hört sich, bei einigen hunderttausend Hits pro Tag, nicht viel an, aber es ist — im Vergleich zur vorherigen Version — zu viel und einfach nicht akzeptabel.