Da mein bisheriges SVN-Repository abgeschalten wurde, musste ich mich darum kümmern selber eines aufzusetzen. Große Ansprüche habe ich da nicht, es sollte nur einfach und schnell eingerichtet und über eine IP/Domain erreichbar sein. Folgende Möglichkeiten hab ich gefunden:

Das blanke Verzeichnis als Repository

SVN hat eigentlich gar keinen Server, sondern nur eine Vorggegebene Verzeichnisstruktur und eine dazugehörige Datenbank, die zusammen ein Repository darstellen. Man kann als Datei direkt per svn [COMMAND] file:///my/repository/path darauf zugreifen. Da man hier aber nur lokal zugreifen kann, die Benutzerrechte entsprechend anpassen muss und ansonsten auch keinerlei Zugriffsschutz einrichten kann, fiel das schonmal flach.

Als Apache2-Modul

Ein Apache-Server in dem per WebDAV und SVN connector auf das Repository zugegriffen werden kann. Hier hab ich keine brauchbare Anleitung finden können, die mir schnell genug zum Ziel führte. Außerdem müsste dann immer ein Apache laufen, was mir ein wenig wie mit Kanonen auf Spatzen zu schießen erscheint. Also so auch nicht.

Der mitgelieferte svnserve-Deamon

Ein eigener Deamon der mit svn schon mitgeliefert wird und super simpel funktioniert. Er ist nicht sonderlich sicher, aber ich greife nur über ein VPN auf den Dienst zu, da ist die Sicherheit nicht ganz so wichtig. Hier war diese Anleitung ganz hilfreich, die mir hier auch als Grundlage diente.

Folgendes muss (als Root oder per Sudo) getan werden, um ein SVN-Repository incl. “Server” aufzusetzen:

Vorbereiten

apt-get install subversion

Alle benötigten SVN Module installieren

mkdir /home/svn;chown root:root /home/svn;chmod go-rwx /home/svn

Das Root-Verzeichniss anlegen, in dem alle SVN-Repositories untergebracht werden sollen, und die Rechte so setzen, dass nur root darin etwas machen kann

echo -e “[users]\nmyUser = myUnencryptedPwd” > /home/svn/.passwd

Legt die allgemeingültige “Benutzertabelle” für SVN an. Hier der Benutzer myUser mit dem Passwort myUnencryptedPwd. Neue Benutzer einfach in die Datei in eine neue Zeile eintragen. Aber ACHTUNG: die Passworter liegen im Klartext vor und das lässt sich in der Form auch nicht ändern. Also am besten eigene, nur für dieses SVN gedachte Passwörter benutzen.

echo -e “[general]\nanon-access = none\nauth-access = write\npassword-db = ../../.passwd” > /home/svn/svnserve.conf

Legt die SVNServe-Config an und zwar so, dass die eben angelegte Benutzertabelle verwendet wird und nur autorisierte Benutzer auf die Repositories zugreifen dürfen

chmod 600 /home/svn/.passwd;chmod 600 /home/svn/svnserve.conf

Die Rechte zur Sicherheit nochmal einschränken, schließlich stehen da Passwörter im Klartext drin

Die angelegte Benutzertabelle und die Server-Config sollen in allen Repositories gelten, weswegen sie hier im SVN-Root-Verzeichnis liegen. Man kann das auch für jedes einzelne Repository machen, aber das das brauche zumindest ich an dieser Stelle nicht.

Server einrichten und starten

Dieses Init-Script runterladen…

…und dann die Zeile
DAEMON_ARGS="-d -r /home/svn --listen-host 127.0.0.1"anpassen. IP und Port z.B. Das Script selber stammt aus der oben erwähnten Anleitung.

mv [INITDATEI] /etc/init.d/svnserve;chmod +x /etc/init.d/svnserve

Die Datei im Standart-Startordner des Systemes ablegen und die Rechte anpassen

update-rc.d svnserve defaults

Bewirkt, dass der Server beim Systemstart immer mitgestartet wird

/etc/init.d/svnserve start

Startet des SVN-Server

Ein Repository anlegen

Diesen Schritt kann man für jedes neue Repository ausführen

svnadmin create /home/svn/myFirstRepo

Legt das Repository an, also die SVN Datenbank und die Grundlegenden Verzeichnisse. In dem Fall mit dem Namen myFirstRepo

cd /home/svn/myFirstRepo/conf;rm *;ln -s ../../svnserve.conf;

Entfernt die Config und Benutzertabelle für das Repository und verwendet die oben angelegten, globalen Dateien

/etc/init.d/svnserve restart

Startet des SVN-Server neu, damit er die Änderungen auch mitbekommt

Jetzt kann man per svn info svn://127.0.0.1/myFirstRepo, nur eben mit der passenden IP, prüfen ob alles geht. Der Login sollte abgefragt und ein paar grundlegende Daten über das Repository angezeigt werden.

Dem neuen Repository fehlen aber noch ein paar Dinge, die die meisten SVN-Clienten einfach voraussetzen. Z.B. dass man Branches im /branches Verzeichnis ablegt und dass der Trunk unter /trunk liegt u.v.m. Deshalb ist es sinnvoll, gleich die empfohlene Verzeichnisstruktur anzulegen. Hierzu muss man als normaler Benutzer folgendes tun:

mkdir tmp
mkdir tmp/trunk
mkdir tmp/trunk/myFirstProject
mkdir tmp/branches
mkdir tmp/branches/myFirstProject
mkdir tmp/tags
mkdir tmp/tags/branches
mkdir tmp/tags/branches/myFirstProject
svn import tmp svn://127.0.0.1/myFirstRepo -m "svn-Verzeichnisstruktur erstellt"

Weiteres Projekt einem repository hinzufügen

Damit werden die grundlegenden Verzeichnisse im Repository abgelegt. Die myFirstProjekt-Verzeichnisse sind die Verzeichnisse für ein einzelnes Projekt. Will man eines weiteres hinzufügen, muss man folgendes, wieder als normaler Benutzer, tun:

svn co svn://127.0.0.1/myFirstRepo
mkdir myFirstRepo/trunk/mySecondProject
mkdir myFirstRepo/branches/mySecondProject
mkdir myFirstRepo/tags/branches/mySecondProject
svn ci myFirstRepo -m"Weiteres Projekt angelegt

Alles in allem gar nicht viel Arbeit, aber die Tatsache, dass es ziemlich unsicher ist, hinterlässt schon einen starken Nachgeschmack. Aber in meinem VPN laufen noch ganz andere, extrem unsichere Dienste, so dass das hier den Kohl auch nicht fett macht.

Wenn man schon so ‘nen Schicken EEE-PC 901 geschenkt bekommt, will man den ja auch richtig einrichten. In dem Ding ist z.B. eine SSD verbaut und da sich die Schreibzyklen stark auf die Lebensdauer auswirken, dachte ich mir, kann man da doch bestimmt was machen.

Geplant war, die Teile der Platte, die häufige Schreiboperationen erdulden müssen, irgendwie zu schützen und die Änderungen gesammelt auf die Platte zu schreiben. Genau nach diesem Prinzip funktioniert unionfs. Man kann beliebig viele Quellen der Reihe nach übereinander legen und die oberste Quelle mit Schreibrechten wird eben zum Schreiben aller Änderungen benutzt, die darunter liegenden Schichten nur zum Lesen. Im vorliegenden Fall habe ich also die Teile der Platte, die geschützt werden sollten, als unterste Schicht mit Schreibschutz verwendet und oben drüber eine RAM-Disk gelegt.

Orte mit vielen Schreiboperationen

Folgende Verzeichnisse konnte ich bei Ubuntu ausmachen, die oft geschrieben werden:

/tmp

Das allgemeine, temporäre Verzeichnis. Viele Scripte legen da ihren Kram ab, aber viel Platz verbraucht es nie.

/var/tmp

Noch ein temporäres Verzeichnis. Keine Ahnung, wer da so alles rein schreibt. Ebenfalls recht klein vom Platzbedarf.

/var/log

Alle Logdateien (eigentlich) aller Prozesse. Hier wird städig rein geschrieben und gerade Desktopanwender brauchen die Infos nie

/media

Ein leeres Verzeichnis, in dem beim mounten von z.B. USB-Sticks Verzeichnisse als Einhängpunkte erstellt und später wieder entfernt werden.

/home/*/

Das Benutzerverzeichnis des aktuell angemeldeten Benutzers wird bei laufender X-Oberfläche ständig beschrieben. Da ist, neben /var/log, so ziemlich am meisten los.

/etc/mtab

In dieser Datei wird jegliches Ein- und Aushängen von Datenträgern dokumentiert.

Bei so vielen zu schützenden Verzeichnissen bedeutet das am Ende aber, dass man viele RAM-Disks anlegen muss. Ich bin mir nicht sicher, aber die Dinger wachsen dynamisch mit bis zur angegebenen Obergrenze, wenn man Daten hinein legt. Entfernt man aber Daten, glaube ich nicht, dass der Speicher wieder freigegeben wird. Zumindest nicht alles und auch nicht sofort. Also sollte es, um dieser Frage einfach aus dem Weg zu gehen, nur eine RAM-Disk geben. Außerdem ist dann die Verwaltung des verbrauchten Platzes einfacher und die Überwachung, wie viel noch frei ist, ebenfalls.

SSD-FS als Init-Script

Um die Aufgabe möglichst einfach zu erledigen, hab ich dieses ssdfs-Script erstellt, dass zur Boot-Zeit direkt nach dem mounten aller normalen Laufwerke aus /etc/mtab eine RAM-Disk erstellt und an die entsprechenden Verzeichnisse per mount –bind hängt. Auch /etc/mtab wurde per –bind an eine Datei auf der RAM-Disk gebunden. Die Verzeichnisse, deren Daten erhalten bleiben sollen, wurden per unionfs und weiteren Teilen der RAM-Disk schreibgeschützt. Die Installationsanleitung sowie ein paar Kommentare zum Verhalten und ein paar Schalter zum Debuggen etc. sind im Script selbst ganz oben enthalten. Das Script würde ich aber als Entwicklerversion ansehen und keinesfalls für den Normalbetrieb benutzen. (siehe weiter unten)

Erfolge

Insgesamt konnte ich das Dateisystem damit so schützen, dass vom Einschalten des Rechners bis zum Ausschalten nur 45 Schreiboperationen ausgeführt wurden. Und die alle in /etc/mtab (mehr dazu gleich, unter “Probleme”). Alle Änderungen an den Daten werden beim Runterfahren am Stück geschrieben und so unnötiges Schreiben verhindert.

(Schwere) Probleme

Folgende Probleme sind mir beim Entwickeln aufgefallen, die leider so gravierend sind, dass ich das Projekt erst mal verworfen habe:

Unionfs kann kein Merge

Mit unionfs kann man auf simple Weise die ursprünglichen Daten und Änderungen trennen. Das wird z.B. bei Live-CDs benutzt, um das System normal zu benutzen ohne auf die CD-ROM schreiben zu können. Aber es wurde nur GENAU DAFÜR gemacht. D.h. man kann nicht sagen “führe die Änderungen jetzt mal auf die ursprünglichen Daten aus”. Im Script habe ich einen Trick benutzt, das selber zu machen: es wird per rdiff einfach eine Daten mit allen Änderungen zwischen den ursprünglichen Daten und dem kompletten Unionfs durchgeführt. Das dauert zwar etwas länger, da alle Daten ein mal gelesen werden müssen, funktioniert aber zuverlässig.

Unionfs ist zickig

Wenn man unterhalb eines Unionfs per –bind Verzeichnisse eingehangen hat, bleibt ein umount des Unionfs einfach stehen. Man kann dann nur noch hart ausschalten und alle Daten, die noch nicht auf die Platte gesynct wurden, sind verloren. Auch kann man Unionfs-Quellen nur aushängen, nicht den Status ändern oder sie gar wieder einhängen. Das führt ebenfalls zum Absturz des Unionfs und eben wieder zum Datenverlust. Daraus ergibt sich, dass man ein Sync der Daten auf die Platte nur genau ein mal machen kann. Ein regelmäßiges Syncen, um Datenverluste zu vermeiden durch ausgehen des Rechners z.B. durch zu wenig Akkuleistung, ist nicht möglich.

/etc/mtab wird uneinheitlich verwendet

Hier waren, nach dem alles andere recht gut lief, die letzten 45 Schreiboperationen zu finden. In dem Init-Script der mtab ist extra angegeben, wenn die Datei ein Link ist, dass dieser dann korrekt behandelt wird. Das funktioniert aber gar nicht, da andere Prozesse diese Ausnahme nicht kennen und das System schon beim Starten korrumpieren. D.h. die unionfs-Laufwerke werden zwar erstellt, können aber nicht mehr gesynct werden und es gehen somit wieder Daten verloren. Per mount –bind kann man auch einzelne Dateien binden, aber auch das funktioniert hier nicht. Der df-Befehl z.B. erkennt dann überhaupt kein Laufwerk mehr, und unionfs lässt nicht schon wieder nicht unmounten… und wieder mal Datenverlust.

Umount von per –bind eingebundenen Laufwerken ist zickig

Wegen der Zickigkeit von Unionfs habe ich mehrere Laufwerke übereinander legen müssen, um z.B. das Unionfs beim Syncen mit einem Schreibschutz versehen zu können, da Unionfs bei dieser Aktion direkt abstürzt und wenn beim Syncen gleichzeitg Änderungen in der Quelle gemacht werden, bestimmt viel Datenmüll raus kommt. Bei so verschachtelten –bind Anweisungen scheint es umount irgendwann aus der Bahn zu werfen. Sporadisch wurde ein Umount verweigert, was wieder zu Datenverlust führte.

Fazit

Dieser Weg funktioniert ziemlich gut, ist aber extrem Instabil und führt zu gravierenden Datenverlusten. Zum basteln und lernen ist das gut geeignet, zu mehr aber auch nicht. Zum Vergleich: Ich habe während der Entwicklung das System ca. 200 mal neu starten müssen und ~90% der Zeit die Daten der Sitzung komplett verloren.

Ich für meinen Teil habe viel über Unionfs, die mtab und das System an sich gelernt. Das Script selber werde ich aber erst dann wieder anfassen, wenn Unionfs “etwas” stabiler geworden ist. Ansonsten richte ich mir die Umgebung gerade so ein, dass die Daten, die oft geschrieben werden, auf einer SD-Karte liegen und nicht auf der SSD, um bei Ausfällen für 10 € einfach eine neue SD-Karte zu kaufen statt einer teuren SDD. Aber dazu später mehr

PS:

Ich hab den Blog schon gute 3 Monate komplett vernachlässigt, was aber meinem Garten zuzuschreiben ist, denn im Frühling ist da einfach sehr viel zu tun. Jetzt, wo ich quasi nur auf’s Ernten warte, werd ich auch wieder mehr schreiben.

Um meinen Server mal ein wenig im Blick zu haben, und auch um ein wenig PHP-Erfahrung zu sammeln, hab ich das Script zur Anzeige des Server-Status eines Bekannten ein wenig erweitert. Dabei herausgekommen ist eine einfache Seite auf der die, zumindest für mich, wichtigsten Daten angezeigt werden wie z.B. die Uptime, eingeloggte Benutzer, RAM-Verbrauch, Partitions-Belegung incl. INodes, Festplatten-APM-Status, ein paar Temperaturen und die Prozessliste.

Das Ganze sieht so aus, wobei das Beispiel nur eine statische Ausgabe ist da die Informationen eventuell für Angriffe relevant sein könnten. Das Script dieses Servers ist per .htaccess geschützt.

Den Quelltext des Scriptes, der hier zu finden ist, hab ich versucht halbwegs sauber zu halten. Der PHP-Teil ist ein Objekt und die Ausgabe erfolgt über einen Datenhash, so dass man leicht Änderungen und Erweiterungen vornehmen kann. Allerdings sind viele Dinge vermutlich unnötig umständlich gelöst da ich PHP quasi direkt beim Schreiben lernen musste. Ansonsten muss das Script nur irgendwo im Webserver-Pfad abgelegt und dann einfach im Browser aufgerufen werden. Es gibt aber ein paar Dinge, die eingerichtet werden müssen, damit sie angezeigt werden.

Die Temperaturen werden per lm-sensors gemessen. Hier ist eine Beschreibung dazu, wie man es installiert und einrichtet. Da die Seite oft nicht erreichbar ist, hier eine kurze Zusammenfassung:

sudo apt-get install lm-sensors

Installieren der benötigten Programme

sudo sensors-detect

Richtet die Treiber ein. Hier muss man eigentlich nur alles mit Ja beantworten. Bei mir blieb es an einer Stelle hängen, so dass ich nach dem abbrechen und neu durchgehen diese Stelle dann mit Nein übergangen habe. Ansonsten ist es ziemlich simpel

sensors

Liefert die Messergebnisse.

Die Messwerte sind nicht immer korrekt und müssen teilweise interpretiert werden. Bei mir mit dem VIA C3 ist die System-Temperatur eigentlich die CPU-Temperatur und der als CPU-Temperatur angegebene Wert ist mit dauerhaft über 140°C unbrauchbar. Die North-Bridge-Temperaur scheint allerdings glaubwürdig. Da die Daten, die geliefert werden, sehr unterschiedlich sein können, muss das Statusscript hier mit hoher warscheinlichkeit bei jedem System ein wenig angepasst werden.

Der APM-Status der Festplatten beruht auf dem selbst erstellten APM-Script. Man könnte die Daten auch per hdparm auslesen, was bei mir aber das Aufwachen der Platten bewirkt. Außerdem braucht hdparm root-Rechte, und die werde ich sicher keinem PHP-Script verpassen.

Ansonsten ist noch zu erwähnen, dass die Daten mit den Überschriften der Shellausgabe als Schlüssel verwendet werden. Mein System ist in englischer Sprache und die Schlüssel werden entsprechend so verwendet. Bei anderen Sprachversionen ist auch hier an etlichen Stellen eine Anpassung nötig.

Ich habe ja schon erwähnt, dass dieser Blog jetzt auf meinem Mini-Server läuft. Der Aufbau des selbigen war nicht immer ganz einfach, weshalb ich das hier mal festhalten will.

Vorgeschichte
Wegen Problemen mit dem WebHoster war ich genötigt mir Alternativen zu suchen diesen Blog unterzubringen. Da ich wenig Geld ausgeben und trotzdem gerne einen kompletten Server haben wollte um mehr Freiheiten und Möglichkeiten zu haben, fiel mir die häusliche 16 MBit ADSL Leitung ein, die ständig mit dem Netz verbunden und quasi ungenutzt ist. Ein Test mit einer lokalen Wordpress-Anwendung zeigte, dass mit dieser Upload-Leitung problemlos 2,5 (nicht gzip’pte) Seitenabrufe pro Sekunde drin waren, was für meine Ansprüche völlig genügt. Mit gzip sind es dann ca. 8 Seiten pro Sekunde.

Vorbereitung
Da der Server ständig vor meiner Nase steht, muss er klein und geräuschlos sein. Und wegen der Kosten preisgünstig in der Anschaffung und stromsparend. Ein gebrauchter Laptop war zu teuer und zu unflexibel, da die Hardware nicht groß angepasst werden kann und ein “normaler” Rechner braucht viel Strom und Platz. Also ging ich auf die Suche nach ThinClient-PCs.

Die meisten davon haben nur eine DiskOnChip-”Platte” (Flash), die absolut nicht ausreichen für einen Server, da sie meist unter 128MB groß sind. IDE und SATA Anschlüsse sind auch nicht überall dabei aber ein flotter USB-Anschluss mit externer Festplatte geht ja auch. Aber bei Nachfragen stellte sich heraus, dass die DiskOnChip-Teile oft auf einem IDE-Anschluss stecken und die Angabe bei der Beschreibung schlicht und einfach fehlte. Ich entschied mich für IDE und gegen USB weil es mit simpler erschien.

Die RAM-Ausstattung sieht bei gebrauchten ThinClients eher dürftig aus und hat in einigen dieser PCs Sonderformen, wie z.B. spezielle Laptop-RAM-Riegel. Die maximal verwaltbare RAM-Größe ist oft nicht wirklich hoch, aber auch sowas erfährt man erst nach gezielter Nachfrage. Meine Mindestanforderung lag bei 1GB RAM, was sich noch gerade so einrichten ließ.

Bei Festplatten hatte ich, durch Versuche am eigenen Rechner, herausgefunden, dass 3,5 Zoll Festplatten knapp 15 Watt verbrauchen und eben auch deutlich hörbar sind. Zumindest meine. Also hab ich gleich nach 2,5 Zoll Platten gesucht, die in so ein kleines Gehäuse auch viel besser rein passen.

Anschaffung
Den Rechner (CA 800 ThinClient, VIA) gabs gebraucht bei eBay für 60 Euro und 1 GB (SD)RAM, (2×512 Riegel) für 20 Euro. 2 x 30GB IDE Festplatten für je 20 Euro und 2 x 3,5-zu-2,5-Zoll IDE-Adaptern à 7 Euro mussten es dann auch noch sein, denn der IDE-Anschluss ist der normale für 3,5 Zoll Platten. Leider gibt es größere 2,5 Zoll IDE-Patten scheinbar nirgends mehr neu zu kaufen, was mich auf diese maximal 2 x 30GB festnagelte.

Ergibt also gesamt 134 Euro für alles.

Schön ist das Teil nicht besonders, aber das war ja eh keine Voraussetzung.

Ausstattung
Folgendes hatte ich damit am Start:

• Gehäuse mit 29 cm Breite, 23 cm Tiefe und 5,5 cm Höhe
• externes Netzteil
• 800 MHz VIA C3 Nehemiah Prozessor, 1 Kern
• 1 GB SD RAM (2 x 512 MB Riegel) .. das Limit dieses Rechners
• 100 MBit LAN
• 1 PCI + 1 ISA Steckplatz
• 1 IDE Anschluss für 2 Geräte
• 2 x 30 GB IDE Festplatten
• 2 x USB v1.0 Anschlüsse für externe Geräte. 100kb/s langsam
• Onboard-Sound
• Onboard Intel-Grafik mit VGA-Ausgang
• PS2 Anschlüsse für Maus und Tastatur
• Diverse Uralt-Schnittstellen wie Serielle Ports.

Die externen Schnittstellen des Servers:

Einbau der Festplatten

Im Gehäuse ist es sehr eng und trotzdem musste ich dort die 2 Platten verbauen. Da das vom Hersteller nicht vorgesehen war musste improvisiert werden.

Eine einfache und billige Lösung dafür ist, die Festplatten mit Abstandshaltern auf die Hauptplatine zu “legen” und dann mit dem Gehäusedeckel zu fixieren, so dass nichts verrutschen kann. Dazu braucht man nur ein Lineal, eine Schere und einen Schnellhefter aus relativ festem Plastik. Man schneidet ein Viereck aus dem Schnellhefter von der Größe der Grundfläche der Festplatte und lässt dabei rechts und links knapp 1cm Rand überstehen. Diese Ränder knickt man dann nicht ganz rechtwinklig nach unten ab und stellt dieses umgedrehte “U” dann auf die Ränder.

Die Ränder der Halterung sollten jeweils an der Außenseite von z.B. aufgelöteten Schnittstellen oder Jumper blockiert werden, so dass beim Druck von oben auf die Halterung die Konstruktion nicht einfach zusammenklappt, wegknickt oder verrutscht. Andere Bauteile, vor allem SMD-Teilchen, sollten nicht belastet werden, denn wenn die im Betrieb mal warm und dann durch die Halterung zur Seite gedrückt werden, lösen sie sich im schlimmsten Fall von der Platine und das Board ist im Eimer.

Auf dieses U kam bei mir dann die erste Festplatte welche dort mit Isolierklebeband einfach draufgeklebt wurde. Da drauf kam eine weitere Lage Plastik vom Schnellhefter, wobei das Lüftungsloch der Platte ausgespart wurde. Das wurde wiederim mit Isolierklebeband auf Platte 1 fixiert. Da drauf liegt dann ein IDE-Kabel und da drauf Festplatte 2, wiederum mit Isolierklebeband mit all dem verbunden.

Das Ganze ist jetzt schon relativ stabil, bleibt es aber nur so lange, wie man leicht von oben drauf drückt. Deswegen liegt das restliche IDE-Kabel, die Stromkapel der Platten und noch ein wenig als “S” gebogene Schnellhefter-Reste lose obendrauf und zwar so, dass beim Schließen des Gehäuses das ganze Konstrukt leicht auf die Hauptplatine gedrückt wird. Ich könnte das Ding jetzt sogar schütteln und es würde sich nichts bewegen.

Wärmeentwicklung
Da nach dieser Umbauaktion der Platz fas völlig ausgenutzt ist, ist Wärmestau natürlich ein Thema. Da das Ding aber so wenig Energie verbraucht, ist es doch erstaunlich kühl. Der Server läuft schon seit Monaten durch und die Festplatten-Temperatursensoren liefern mir 41°C und 37°C als Werte (gemessem mit hdparm -H /dev/sda). Wenn der Prozessor unter Vollast eine Weile läuft, schafft er 67°C, unter normalen Bedingungen sind es um die 40°C.

Ein Problem besteht allerdings bei der Gehäuseunterseite. Wenn ich den Server auf einen Holzuntergrund stelle erhöhen sich die genannten Temperaturen um gute 5°C. Deswegen liegt er jetzt plan auf dem Metallgehäuse meines “normalen” Rechners, so dass die Unterseite vollflächig aufliegt und nach unten ein bisschen Wärme abgegeben werden kann.

System einrichten
Bei der Installation des Betriebssystemes (Ubuntu) hab ich darauf Wert gelegt, dass das System wenig Resourcen verbraucht und einfach Wart- und Erweiterbar ist. Somit läuft auf der Kiste ein Ubuntu Desktop in der Minimalinstallation von rund 700MB Größe und knapp 120MB Ramverbrauch. Zum Vergleich: die Server-Version von Ubuntu braucht nur 80MB RAM als Minimalinstallation, aber leider läuft der Kernel nicht auf diesem System.

System optimieren
Der Server soll ja in 99% seiner Zeit nur Mails verwalten und Webseiten ausliefern. Alles keine Dinge wobei eine Festplatte wirklich gebraucht werden würde. Da eben diese ja somit unnötig Strom verbrauchen und genau so unnötig verschleißen, sollten sie in eben 99% der Zeit kompett abgeschalten sein. Das ist derzeit so gelöst, dass alle relevanten Daten für den Web-Server und alle anderen Dienste im RAM abgelegt sind. Die Daten werden täglich per rsync auf die Platte gesichert. Ansonsten war noch, wegen des miesen APM bei meinen Hitachi-Platten, ein eigenes APM nötig. Beides läuft schon seit einiger Zeit stabil und problemlos, wobei es Zwischenzeitlich bei MySQL sogar gravierende Probleme gab, die sich aber jetzt erledigt haben.

Natürlich gabs dann noch die unvermeidlichen Angriffe aus dem Netz, die sich allerdings mit einigen Firewall-Einstellungen gut eindämmen lassen.

Messdaten
In der Praxis ist ja immer alles ein wenig anders, deswegen mal ein paar gemessene Daten.

Prozessorleistung

16,8 Sekunden (Kleiner ist besser). Gemessen mit folgender Befehlszeile, die zwar nicht wirklich repräsentativ, aber einfach nachvollziehbar ist: time perl -e 'foreach(1..10_000_000) { my $a = ($_ % 2) }' Als Grundlage gilt die “user” Angabe.

Festplattendurchsatz

21.95 MB/sec. Gemessen per hdparm -t /dev/sda

Stromverbrauch

24 Watt im Leerlauf, 34 Watt unter Vollast. Wobei die Messung mit einem 08/15 Leistungsmesser für die Steckdose erfolgte. Ich vermute, wenn man die Blindleistung und Messfehler noch abzieht, liegt das Teil bei knapp 10 Watt im Leerlauf.

Netzwerkleistung

80 KB/s download, 250 KB/s upload. Er hängt halt an einer 16MBit-ADSL Leitung.

Blog-Geschwindigkeit (Wordpress)

~8 Seiten pro Sekunde, allerdings nur mit (Hyper)Cache-Plugin. Dieser Blog läuft ja aktuell auf dem Mini-Server, es ist durchaus brauchbar.

RAM-Verbrauch

~180 MB, wobei 60MB für die RAM-Disk drauf gehen

Verbrauchter Plattenplatz

Mit allen Tools und weiterem Schnickschnack derzeit 1,2 GB

Zum Vergleich der Prozessorleistung ein paar Daten von Rechnern freiwilliger Testpersonen. Allesamt schneller als der Mini Die Prozessorangaben wurden per cat /proc/cpuinfo|grep "model name" ermitelt.

Intel(R) Xeon(R) CPU E5430 @ 2.66GHz / 8 Cores [ vserver / Gentoo ]

1,67s

Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz / 2 Cores[ Tobi ws / Ubuntu ]

1,78s

Intel(R) Core(TM)2 Duo 2.4 GHz / 2 Cores [ Jo / Mac ]

1,88s

Intel 2,16GHz 2,38 / 2 Cores [ Ben / Mac ]

2,30s

Intel(R) Pentium(R) D CPU 2.80GHz / 2 Cores [ Tobi old-ws / Ubuntu ]

2,52s

Intel(R) Pentium(R) 4 CPU 3.00GHz / 2 Cores [ Alex / Gentoo ]

2,88s

AMD Athlon(tm) 64 3500+ 2,2GHz / 1 Core [ Alex server / Gentoo ]

3,02s

AMD Athlon(tm) 64 Processor 3700+ / 1 Core [ Ben home / gentoo ]

3,39s

AMD Athlon(tm) 64 Processor 3000+ [ Tobi home / Ubuntu ]

4,23s

Intel(R) Atom(TM) CPU 230 @ 1.60GHz / 1 Core [ Jo server / Debian ]

6,29s

AMD Athlon XP 1200+ / 1 Core [ Alex home / Gentoo ]

6,36s

Fazit
Ich bin sehr zufrieden mit dem Mini-Server. Die Einrichtung war, aufgrund fehlenden Wissens und einiger technischer Stolpersteine schwer, aber lehrreich. Die Leistung übertrifft meine Erwartungen und es sind noch genügend Kapazitäten frei, um da noch einiges hinzuzufügen. Ich bereue nichts

Anwendungen einrichten und weiteres…
Eingerichtet ist, wie schon gesagt, derzeit dieser Wordpress-Blog mit ein paar Anpassungen, dann noch ein FTP-Client, SSH und ein StreamingServer. Aber das ist eine andere Geschichte und die wird ein anderes mal erzählt.

Bei der Erstellung des Scripts zum Spiegeln von /var in eine RAM-Disk habe ich, aus Mangel an Wissen und Erfahrung, das HUP-Signal benutzt um alle Prozesse, die unterhalb von /var ein offenes Filehandle haben, neu zu starten, damit die Überlagerung keinen Datenmüll ergibt. Bei ein paar, z.B. den klogd, hat das von vornherein nicht funktioniert, weswegen die explizit über ihr Init-Script neu gestartet werden.

Bei MySQL hat es nur scheinbar funktioniert, denn der Grund für den Crash von MySQL war genau das nicht neustarten. Der MySQL-Server hatte noch offene Filehandles auf dem Festplatten-Verzeichnis, dann hat die RAM-Disk das Verzeichnis überlagert und alle dann geöffneten Filehandles zeigten auf die RAM-Disk. Das Resultat war, wie zu erwarten war, Datenmüll.

Bei dem Script für die RAM-Disk ist MySQL jetzt auch explizit per Init-Script neu gestartet und das Ganze wurde von mir ausgiebig getestet: seit dieser Änderung bestehen keine Probleme mehr.

Jetzt muss ich mir nur noch überlegen, wie ich alle laufenden Prozesse mit Filehandles in /var dazu bringen kann, sich komplett neu zu starten. Derzeit fällt mir, außer Signalen, nichts ein, denn automatisch auslesen kann ich nur die PID und die Namen der Prozesse.