Ein verschleißfreier Webserver zu Hause

Teil 7: Zusammenfassung


Mein 380Z liefert heute nicht nur meine Webseiten aus, sondern fungiert auch als Mail-, Druck- und NFS-Server. Er hat im Laufe der Zeit etliche Veränderungen mitgemacht, darunter auch manche Revision (Rückkehr zu einem früheren Zustand). Diese Seite teilt mit, welche Einstellungen sich bei mir bewährt haben.


Chronologie


Flash: billige und teure Technologie

Hersteller bieten USB-Stifte verschiedener Lebensdauer an. Der Hersteller Verbatim unterscheidet sie (zumindest in den Jahren 2006 und 2007) durch die Farbe: rote erlauben im Durchschnitt 10 000 Löschzyklen (MLC Technologie), blaue 1 000 000 (SLC Technologie). Ich besitze beide Typen, setze aber im 380Z bewußt einen roten Stift ein. Der erlaubt mir nämlich einen Blick in die Zukunft, indem sich Verschleiß bei ihm im Durchschnitt 100 Mal früher zeigt als beim blauen. Schon nach der bisherigen Lebenszeit meines roten Stiftes zu urteilen, würde ich einen blauen wohl nicht überleben. 1GB SLC Stifte waren im Jahre 2007 ab etwa 15 Euro erhältlich. Im Jahre 2010 erhielt man von Verbatim für das selbe Geld SLC-Stifte mit 8 GB. Auch diese Stifte haben blaue Farbe. Das bedeutet Verdopplung der Kapazität pro Jahr bei Erhaltung des Preises.


Flash: Lebensdauer

In webserver5.html hatte ich anhand der LED Aktivität meines USB Stiftes abzuschätzen versucht, wie lange auf ihn geschrieben oder von ihm gelesen wird. Über diese Dauer und die Übertragungsgeschwindigkeit meines USB-Busses erhielt ich ein Volumen pro Zeit, worüber ich die Lebensdauer meines USB-Stiftes berechnen wollte. Diese Methode ist nicht die einzig mögliche; hier ist eine andere: Das Debian Paket sysstat enthält ein Programm namens iostat. iostat mißt für alle angeschlossenen Blockgeräte das davon gelesene und darauf geschriebene Volumen. Es tut dieses sowohl für das Gesamtvolumen von der Zeit des letzten Bootens an als auch für das Differenzvolumen von einer Messung zur nächsten (was hier nicht vorgeführt wird).
tb@380z:~$ iostat -k
Linux 2.4.27_ext2 (380z)        09.12.2007

avg-cpu:  %user   %nice    %sys %iowait   %idle
           0,23    0,01    0,04    0,00   99,72

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
dev3-0            0,01         0,14         0,03     183397      40156
dev8-0            0,03         0,05         0,28      58457     354900

tb@380z:~$ uptime
 14:28:28 up 14 days, 16:20,  5 users,  load average: 0.22, 0.06, 0.02
Man sieht, daß auf den Stift (dev8-0) 354.900KB geschrieben und 58.457KB von ihm gelesen wurden. Das geschah über einen Zeitraum von knapp 15 Tagen. Daraus errechnet sich eine Schreibleistung von durchschnittlich 24MB und eine Leseleistung von durchschnittlich 4MB je Tag. Durch Vergleich von Schreib- und Lesevolumen des Stiftes mit den Werten der Festplatte, dev3-0, erkennt man, wieviel Arbeit ihr der Stift abnimmt.

Die früher geschätzte Schreibleistung des Stiftes von 1.35GB braucht nicht so falsch zu sein, wie die hier ermittelte Zahl nahelegt. Schließlich bedeutet etwa das Löschen einer Datei von 1KB auf dem Stift nicht nur ein Schreiben von 1KB, sondern von mehr, da Flashspeicher nicht dateiweise sondern blockweise (erase block sind 16 - 128KB groß) gelöscht wird.

Zum Betrieb von iostat ist die Installation des /proc Systems Voraussetzung. Dieses stellt die Werte zur Verfügung. Wie sonst auch sollte iostat Wissen über die Vergangenheit (nämlich bis zum letzten Booten) haben? Wenn man wüßte wo, könnte man sich iostat wahrscheinlich sparen.


Flash: Belastung der CPU

Anfang 2009 liefen folgende Prozesse auf dem Server, angeordnet nach ihrer CPU Belastung:
tb@380z:~$ uptime
 12:13:27 up 46 days,  2:06,  3 users,  load average: 0.00, 0.00, 0.00

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
--------------------------------------------------------------------------
  462 root       9   0     0    0    0 S  0.0  0.0   0:45.27 usb-storage-0
  874 tb         9   0  1400 1396 1112 S  0.0  1.5   0:19.83 fetchmail
10542 tb         9   0  3076 3076 1712 S  0.0  3.2   0:12.95 mutt
11376 root       9   0   800  800  708 S  0.0  0.8   0:05.84 syslogd
  752 mail       8   0  1668 1668 1424 S  0.0  1.7   0:03.97 exim3
    1 root       8   0   504  504  448 S  0.0  0.5   0:03.83 init
  834 root       9   0   612  608  520 S  0.0  0.6   0:03.13 noflushd
    3 root      19  19     0    0    0 S  0.0  0.0   0:01.71 ksoftirqd_CPU0
Es sind alle Prozesse aufgeführt, deren CPU-Zeit eine Minute überschritt. Tatsächlich nimmt die Verwaltung des Flashspeichers die CPU bei weitem am meisten in Anspruch. Fetchmail läuft bei mir dauernd im Hintergrund.


Flash: Auswirkung auf den Mailtransport

Durch die Auslagerung von /var und /home/tb in den Flashspeicher hat sich Zweierlei beim Mailtransport geändert. Zum Einen verursacht die Bearbeitung der Warteschlange keinen Plattenanlauf mehr, zum Anderen gilt das auch für den Eingang von Mail (z.B. beim Pollen des POP Servers). Daher lasse ich Beides (Bearbeitung der Warteschlange und Pollen des POP Servers) jetzt öfter vornehmen. In der Konfiguration sieht das folgendermaßen aus: Keine der beiden Frequenzen erhöhe ich, weil mir Einschränkungen im Umgang mit Mail aufgefallen wären, sondern tue es, weil es nichts kostet; es handelt sich um eine Luxuserscheinung. Bei der Pollfrequenz wirkte allerdings die Unart eines ISPs mit, die DSL Verbindung zu beenden, wenn 15 Minuten kein Verkehr stattgefunden hat. Dieser ISP heißt t-online.


Noflushd: Durchschnittliche Plattenlaufzeit

Nach jahrelanger Beobachtung des Webservers mit Flashspeicher zeigte sich, daß die Plattenlaufzeit durchschnittlich weniger als 4 Minuten je Tag beträgt. Das bedeutet: Auf meine Platte wird durchschnittlich weniger als 4 Mal täglich für je eine Minute zugegriffen. Der Wert ist abhängig von der Größe des RAM-Speichers, Anzahl der Mails, Druckjobs usw., also geräte-, personen- und zeitabhängig. Unter Schaltzeiten 2008, 2009, 2010 und 2011 findet man alle registrierten Plattenzugriffe in den genannten Jahren. Die höchste bisher gemessene Ruhezeit meiner Platte beträgt 12.76 Tage.


Noflushd: Dateisystem mit oder ohne Journaling?

Zur Entlastung der Festplatte von 4GB (nicht zur Vergrößerung des Volumens) setze ich einen Flashspeicher von 1GB Größe ein. mount zeigt Folgendes an:
tb@380z:~$ mount
/dev/hda1 on / type ext2 (rw,noatime,errors=remount-ro)
proc on /proc type proc (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var type ext2 (rw,noatime,errors=remount-ro)
Der Flash ist also mit ext2 formatiert und als /dev/sda1 auf den Ordner /var gemountet. In diesen Ordner ist außerdem mein gesamtes Heimatverzeichnis gelinkt:
tb@380z:~$ ls -l /home/tb
lrwxrwxrwx  1 root staff 11 2007-08-12 10:29 /home/tb -> /var/tb-var 
Der Flashspeicher ist mit etwa 190MB gefüllt. Mount zeigt weiter, daß auch mein Wurzelverzeichnis auf der IDE-Platte mit ext2 formatiert ist. Bis November 2007 las man an dieser Stelle ext3. Der Wechsel hängt mit noflushd zusammen:

Mehr als ein Jahr lang setzte ich noflushd auf einem ext3-Dateisystem ein. Dabei beobachtete ich, daß noflushd nicht in das Journaling des ext3 eingreift, d.h. trotz noflushd findet nach der Commit-Zeit ein Plattenzugriff statt, und damit ein Anlauf der Platte, falls sie vorher ruhte. Als Default hat ext3 eine Commit-Zeit von 5 Sekunden eingestellt. Diese erhöhte ich auf 20 000, 30 000, 60 000 und schließlich 1 000 000 Sekunden (11.5 Tage). Die 1 Million Sekunden verwendete ich in Ermangelung einer Einstellung Unendlich. Ich wollte Zugriffe auf die Platte nur noch zulassen, wenn angeforderte Dateien nicht im Cache vorhanden sind, also Zugriffe nur aus Gründen der Sicherheit (Journaling) ausschließen. Kurz: ich wollte das Journaling zugunsten selteneren Plattenanlaufes abschalten.

Das legte einen Wechsel von ext3 zu ext2 nahe. Ich ersparte mir ein Neuformatieren der Platte und mountete die vorhandene ext3-Partition als ext2-Partition. Das ist möglich, denn ext3 ist ein ext2 Dateisystem mit Journaling. Der Wechsel des Dateisystems legte dann einen Wechsel des Kerns nahe. Während der bisher genutzte Vanilla Kern (Universal-Kern, Version 2.4.27) der inzwischen alten Debian Sarge Distribution rund 800KB aufweist und eine initiale RAMDisk benötigt, ist mein eigenes Compilat (ohne ext3, dvfs, Sound, ..) nur 560KB groß und kommt ohne RAMDisk aus.

Die Abwägung zwischen Sicherheit der Daten und Verschleißfreiheit der Platte ist bei meinem Webserver folgendermaßen getroffen: Der Sicherheit wird nur dadurch entsprochen, daß ich den Rechner


sshd: durch den Bootmechanismus oder durch init starten?

Damit auf einen Rechner von fern zugegriffen werden kann, verwendet der zugreifende Rechner (Client) ssh und der Rechner, auf den zugegriffen wird (Server), sshd. sshd wird standardmäßig (in der SystemV-Initialisierung) durch den Bootmechanismus gestartet; genauer: der erste Unix Prozeß init startet das Skript /etc/init.d/rcS. rcS startet das Skript /etc/init.d/ssh, was dann /usr/sbin/sshd startet. Wenn nach dieser Initialisierung sshd stirbt, bekümmert das den Server nicht.

Alternative: init startet den sshd, und zwar mit dem Parameter respawn. Dann fühlt sich init für sshds Existenz verantwortlich und startet sshd erneut, falls es gestorben ist. Im Falle des Falles (wenn Sie nicht neben dem Server sitzen) ist der Client für diese Vorsorge dankbar. Beschrieben wird die Konfiguration in webserver3.html.


Vorteile eines heimischen Webservers


Upgrade der Linux-Version?

Der Webserver wurde Ende 2005 eingerichtet. Damals war Sarge als stabile Debian Version aktuell. Heute gibt es Sarge nur noch auf sog. Archivservern, z.B. archive.debian.org/debian/. Von dort holen Sie die Sarge-Pakete mittels apt-get, aptitude oder deselect, nachdem Sie in Ihre /etc/apt/sources.list eingetragen haben
deb http://archive.debian.org/debian/ sarge main contrib
Allerdings gilt laut Debian: "As time goes on we will expire the binary packages for old releases. Currently we have binaries for etch, sarge, woody, potato, slink, hamm and bo available, and only source code for the other releases." Daher mag der Wunsch entstehen, die Sarge-Pakete zu Hause auf eigenen Speichermedium aufzubewahren. Den Wunsch erfüllen Sie sich durch den Besuch von   Debian Sarge. Dort finden Sie Images von CDs. Damit können Sie 14 CDs brennen und haben ein vollständiges Sarge (hoffe ich zumindest!). An benachbarter Stelle auf dem Server finden Sie auch Images für DVDs und sind mit 2 DVDs bedient.

Die Zeit ist weitergegangen. An der angegebenen Stelle finden Sie die bisherigen ISOs nicht mehr. Sie sind nicht verschwunden, sondern werden auf eine neue Art geholt. Diese Art heißt jigdo. jigdo-fähig werden Sie durch das Paket jigdo-file (ab Lenny erhältlich). Das Paket ist kleiner als 1MB. Starten Sie daraus das Programm jigdo-lite als User in einem User-Verzeichnis. Tun Sie das ohne Parameter, erfragt jigdo-lite, was es braucht, nämlich eine sog. .jigdo-Datei und einen Debian-Server. jigdo-lite wandelt .deb-Dateien (das sind Debian-Pakete) in die gewünschte .iso-Datei, verfährt daher so wie das Programm mkisofs. Die .jigdo-Datei ist eine Steuerdatei, die jigdo-lite sagt, wie die Umwandlung erfolgt. Diese Datei erhalten Sie für die erste Image CD von Sarge als   http://cdimage.debian.org/cdimage/archive/3.1_r8/i386/jigdo-cd/ debian-31r8-i386-binary-1.jigdo. Der zweite Parameter, der Debian-Server, ist (bei Linux) meist voreingetragen und braucht nur übernommen zu werden. Bei mir z.B. findet sich da   ftp://ftp.uni-koeln.de/debian/. Nach diesen Eingaben können Sie sich schlafen legen. Hinter einem 2 MBit-DSL Anschluß brauchte ich für das erste Image ziemlich genau 1 Stunde. jigdo entlastet die Server, von denen bislang die ISOs geholt wurden, indem diese anstelle der .iso-Dateien nur eine kleine .jigdo-Datei (zusammen mit einer ebenfalls kleinen .template-Datei) anbieten müssen. Genauer: Während eine .iso-Datei für eine CD meist 600 - 700 MB groß ist, haben die beiden kleinen Dateien für die erste Sarge-CD folgende Größen:

debian-31r8-i386-binary-1.jigdo        13-Apr-2008 18:37   34K  
debian-31r8-i386-binary-1.template     13-Apr-2008 18:37   13M  

Über die Verwendung alter Software gibt es im Internet viele Meinungsäußerungen. Üblicherweise wird davon aus Gründen der Sicherheit abgeraten. Meine Erfahrungen mit meinem Webserver und Sarge sind positiv.


Besuche von Google

Der erfaßte Zeitraum reicht von November 2009 bis März 2011. Von meinen Seiten ist diejenige über Zitate im SPIEGEL des Jahrgangs 2009 mit fast 100kB sehr groß geworden und erfährt häufig Änderungen. Google besuchte diese Seite in den Monaten Januar und Februar 2011 durchschnittlich alle drei Tage: zitate-2009

An 6 Tagen im gesamten Zeitraum kontrollierte Google die Seite mit den Zitaten zweimal; dreimal mit dem HTTP-Return-Code 304 (unmodified: Datei ist unverändert) und dreimal mit dem Return-Code 200 (die Datei hat sich möglicherweise geändert).

Eine Datei, die ich entfernt hatte, suchte Google 30 Tage lang und erhielt dabei 12 Mal den Return-Code 404 (not found). Man kann das eine Engelsgeduld nennen: autoren

Nach nur 4 Fehlläufen und nur 10 Tagen verschmerzte Google den Verlust einer anderen Datei, für die ich in der .htaccess Datei einen Redirect Befehl (Return-Code 301: Datei wurde umbenannt oder ist umgezogen) gegeben hatte: redirect

Meine Daten lassen nicht erkennen, daß Google sich bei der Häufigkeit seiner Kontrollen einer Seite von der Zahl der Zugriffe von Anwendern auf diese Seite leiten ließe. Die Seite, die bei mir über einen Zeitraum von Jahren laut meinem Apache Log das größte Interesse findet (gerlich.html) und daher vermutlich auch bei Google am häufigsten nachgefragt wird, kontrolliert Google weit seltener als die Seite mit den SPIEGEL-Zitaten: In den Monaten Januar und Februar 2011 besuchte Google gerlich.html 6 Mal, die Zitate-Seite 19 Mal. (Die Beschränkung auf den Zeitraum Januar, Februar 2011 erfolgte, weil die Seite mit den Zitaten viel jünger und Google nicht so lange bekannt ist wie gerlich.html.) Allerdings hat sich gerlich.html nur wenig geändert, d.h. Google fand meist den Return-Code 304 (unmodified) vor; gemessen an der Dateigröße hat es von November 2009 bis März 2011 höchstens 3 Änderungen von gerlich.html gegeben: möglicherweise von ? auf 26868 Byte, von 26868 auf 26771 Byte und von 26771 auf 26777 Byte (der Return-Code 200 bedeutet nicht zwingend eine Änderung): gerlich



eene.mine.nu/webserver7.html   Menü
Letzte Änderung: 15.01.2013