Das Problem

In der Stadt gab es 8 Netze in Reichweite. Da lief es immer gut. Hier sind es sage und schreibe 13 und da mein Sender 2 Stockwerke unter mir liegt, ist die Signalstärke aller Netze deutlich höher als das von meinem.

Als Resultat gibt es ständig Verzögerungen und manchmal kann ich mich gar nicht verbinden. Ich hab mir einen LAN-Stick geholt, der eine bessere Antenne abgibt, aber das hilft nur ein wenig. Am nervigsten sind aber die Unterbrechungen ohne Verbindungsabbruch. Es passiert einfach gar nichts mehr und nach 5 bis 10 Sekunden gehts dann wieder. Allerdings auch nur ein paar Sekunden und dann gibts gleich wieder ‘ne Zwangspause.

Die Erkentnis

Mit dem Linux-Tool iwlist (aus dem Ubuntu-Packet wireless-tools) hab ich mir mal alle Netzwerke in Reichweite auflisten lassen mit allen Parametern, die die Dinger so geschätzig von sich geben.

Das es viele sind, war mir ja bekannt. Auffällig war aber, dass sich viele auf sehr wenigen Kanälen häufen. Die sind anscheinend alle via “auto-Kanal” eingestellt, denn wer welchen Kanal benutzt wechselt recht oft, aber Kanal 1, 6 und 10 sind immer seeehr beliebt.

Kanal 3 kam nur bei einem Netz genau ein mal vor, Kanal 12 nie. Etliche Treiber sind laut Ubuntu-Beschreibung zum WLAN auf den US-Standard eingestellt und können Kanal 12 und 13 nicht verwenden. Aus dem Grund, vermute ich, meiden auch viele Sender den Bereich.

Ansonsten laufen 11 Netzwerke in der Betriebsart “n” (54MBit) und 2 mit “g” (48MBit). D.h. viele haben neue Sender und ich behaupte einfach mal, die benutzen immer den höchstmöglichen Standard. Wenn man keine Probleme damit hat, sollte das ja auch so sein. Meine Netzanbindung ist ganze 1,5MBit “dick”. Wozu also muss ich mit 54MBit mit meinem WLAN verbinden? Selbst “g” mit 48MBit ist sinnfrei. Ein uralt “b” mit 11MBit reicht vollkommen,

Die Lösung

Den Kanal 12 und 13 sind frei, also benutz ich fix die 12. Das half schon ein wenig, denn jetzt ist die Verbindung deutlich stabiler. Allerdings sind die Zwangspausen noch immer da.

Der Wechsel der Betriebsart von “mixed g+n” auf “n” brachte nur eher subjektiv etwas. Bei “g” waren die Pausen schon seltener. Bei “n” gibt es gar keine mehr. Den WLAN-Stick hab ich auch gleich wieder eingemottet, denn jetzt gehts auch ohne einwandfrei.

Fazit

Langsamer ist oft auch Störunanfälliger. Das das allerdings so gut funktioniert, hätte ich nicht gedacht.

Was mich etwas wundert ist die Tatsache, dass die Betriebsarten “n” und “g” eigentlich selbst abgestufte, langsamere Varianten haben, auf die zurückgegriffen wird, wenn es Verbindungsprobleme gibt. Das funktioniert ja, wie ich sehen kann, so überhaupt nicht gut. Vermutlich sind meine Zwangspausen die Zeiten, in denen die neue Geschwindigkeit ausgehandelt wird, mit der die Verbindung wieder ok ist. Aber bei den Verzögerungen ist das irgendwie nicht sinnvoll.

Egal. Jetzt gehts und gut iss.

Aber warum sich das Leben schwer machen: ich hab deswegen heut mal intensiver nach einem Updateclienten gesucht und ddclient gefunden. Das wird auf der DynDns-Seite sogar direkt genannt und ist super simpel via apt-get installierbar. Der Installationsprozess hat sogar eine grafische Shell-Oberfläche, in der bequem alle Konfig-Eintragungen abgefragt werden. Sehr praktisch!

Einzige Änderung die man vornehmen sollte: das Update der IP-Adresse wird ja einfach via HTTP an DynDns.org gesendet und Username und Passwort gehen somit als Klartext übers Netz. Das kann man zumindest via SSL erledigen lassen, was durch den Konfigeintrag ssl=yes in der Datei /etc/ddclient.conf zu erledigen ist (siehe Anleitung bei DynDns.org). Zur Sicherheit hab ich an gleicher Stelle noch die Option retry=yes gesetzt, damit jetzt die Updates auch wirklich gemacht werden. Sollte das immer noch Probleme machen, setze ich noch das force! *grrr*

Ich hoffe, dass das jetzt mal endlich läuft, denn demnächst hab ich andere Sorgen als ein Server der nicht am Netz bleiben will.

Es gibt ständig die Meldung, dass ein Fehler bei der Autentifizierung bei dyndns.org aufgetreten ist. Nach einem Neustart des ganzen Teils geht es aber wieder. Und dann komt es auch vor, dass bei einem wechsel der IP das Ding laut Log behauptet, die IP ist noch immer gleich und DynDns muss nicht benachrichtigt werden. Kurzum: unbrauchbar und der totale Schrott.

Viel zu Aufwendig und außerdem immer noch Fehleranfällig. Dieses Script hat auch behauptet, dass die IP nochh gleich ist, obwohl sie sich schon geändert hatte. ich hab was anderes probiert. Mal sehen ob’s jetzt geht.

Immerhin gibts leiche Abhilfe unter Ubuntu mit dem Perl-Scriptchen dyndns welches über apt-get einfach installiert werden kann. Es nimmt einem die Arbeit ab die IP alle 5 Minuten zu kontrollieren und bei einer Änderung DynDns zu benachrichtigen. Auch wird beachtet, dass man mindestens alle 30 Tage eine Meldung schicken muss, da DynDns sonst den Account sperrt. Allerdings ist die Doku für die Katz, da die Textbeschreibung vorne und hinten unvollständig ist. So wird der Parameter –file als Optional angesehen, obwohl man ihn braucht und Standardmäßigg wird die aktuelle IP durch ifconfig ermittellt, was ja nich stimmt, da diese ja nur die interne IP ist.

Folgendes funktioniert aber einwandfrei:
dyndns --debug --login USERNAME --password PASSWORT --host HOSTNAME-BEI-DYNDNS --urlping-dyndns --file /var/log/dyndns.log -D 5 & Damit prüft er die eigene, aktuelle IP über ein Script auf DynDns, schreibt den aktuellen Stand in die Log und trägt die aktuelle IP bei DynDns ein, wenn sich seit dem letzten IP-Eintrag in der Datei was geändert hat.

Wichtig! Wenn man den Prozess startet, nicht vergessen, per disown das Ding auch frei zu geben. Ansonsten läuft der nur so lange, wie die eigene Shell. Ist mir gestern passiert, weswegen der Server SCHON WIEDER einen ganzen Tag nicht erreichbar war.

Damit man sich nicht mehr drum kümmern muss, ist folgendes Startscript hilfreich: #!/bin/sh -e
echo "dyndns $1 ..."
case $1 in
start)
dyndns --debug --login USERNME --password PASSWORD --host HOSTNAME-BEI-DYNDNS --urlping-dyndns --file /var/log/dyndns.log -D 5 &
disown
echo "started"
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported"
exit 3
;;
stop)
killall dyndns
echo "stopped"
;;
*)
echo "Usage: /etc/init.d/dyndns {start|stop}"
exit 3
;;
esac
exit 0
Damit es beim Syastemstart gleich mit gestartet wird, muss es nur unter /etc/init.d/dyndns abgelegt und mit sudo chmod +x /etc/init.d/dyndns und zusätzlich sudo update-rc.d dyndns defaults 98 aktiviert werden.

Das funktioniert jetzt jedenfalls erst mal wieder alles korrekt. Ich hoffe nur, dass mir jetzt nicht noch ein Teil ärger macht und der Server endlich mal problemlos am Netz bleibt

Das Problem

Nachdem ich Ubuntu neu Installiert hatte, bzw auch bei den Live-CDs, frohr das System nach einiger Zeit ein. Und zwar sehr genau immer an der gleichen Stelle im Bootprozess ohne allerdings irgend einen Logeintrag oder eine Fehlermeldung zu hinterlassen. Und das System frohr wirklich komplett ein, da rührte sich gar nichts mehr.

Ich habe so ziemlich alles durchprobiert: Ubuntu 8.04, 8.10, 9.04, 9.10, 10.04 und 10.10 jeweils als Desktop, Server oder Alternativ-Variante. Das Interessante: ich hatte da 8.04 bereits mal am laufen. Auch das aktuelle Debian ging nicht. Allerdings funktionierte Knoppix und DamnSmallLinux. Die Hardware hatte also keinen Schaden.

Nach endlosen Stunden und immerhin einem guten halben Jahr Downtime bin ich durch Zufall über einen Foreneintrag gestolpert, worin die Probleme ziemlich genau beschrieben wurden.

Die Ursache

Schuld ist das Startscript /etc/init.d/ondemand welches folgende Zeile ausführt echo -n ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor.

Die Lösung

Die Lösung ist simpel. aber nicht immer leicht zu machen. Eine Installation per Live-CD ist nicht möglich, da das Script schon dort beim Booten verwendet wird. Und die Live-CD auspacken, die Daten suchen und verändern, darauf hatte ich keine Lust. Während der Installation geht es folgendermaßen:

Mit der Alternativ-CD bzw. ich habe es mit der Server-CD gemacht, wird das beim Booten der CD nicht aufgerufen. Man kann die Installation komplett durchlaufen, muss dann aber am Ende der Installation via STRG + ALT + F2 in eine der anderen Konsolen wechseln, und per vi /target/etc/init.d/ondemand und dort unterhalb der ersten Zeile exit 1 einfügen. Alternativ kann man auch einfach sudo update-rc.d -f ondemand remove benutzen und das Script wird dann nicht mehr aufgerufen. Dann einfach die Installation beenden und den Rechner neu starten und alles funktioniert.

Für den Fall, das es nach einem Dist-Upgrade passiert, hilft nur noch der Start mit einer Rettungs-Distribution und dann das Script eben auf der Systemplatte entsprechend per vi wie oben beschrieben deaktivieren.

Hintergrund

Mit dem Script bzw. dem oben erwähnten Echo-Befehl, wird ein Verwaler für die Prozessor-Taktung (SpeedStepping) aktiviert. Standardmäßig läuft der Prozessor auf voller Geschwindigkeit, aber um Strom zu sparen und ihn kühl zu halten kann er langsamer laufen.

Seit der Ubuntu-Version 8.04 gibt es im Kernel einen Fehler, der sich bei Via-Prozessoren auswirkt. Wird irgend ein anderer als der volle Prozessor-Takt verwendet, hält das System einfach an. Das passiert nicht nur, wenn der Wert auf ondemand gesetzt wird, sondern auch jede andere Option hat diese Wirkung. Außer das standardmäßige performance, das funktioniert.

Mit der oben beschriebenen Lösung bleibt der Prozessor also immer auf voller Taktung und verbraucht dadurch ggf. mehr Strom. In meinem Fall, einem VIA C3 Nehemia mit 800 MHz, macht das irgendwas unter 3 Watt Mehrverbrauch aus. Genau kann ich das aber nicht sagen. Ein bisschen Wärmer ist er dadurch auf alle Fälle. Derzeit sind es ca 56°C, vorher waren es im Schnitt um die 50°C.

Die Gemeinheit daran

…war, dass das Ganze mit einer Verzögerung von 60 Sekunden ab aufruf des Scriptes gemacht wird. Dadurch ergibt sich diese charakteristische, immer gleiche Zeitspanne bis zum Systemtot. Außerdem erklärt das auch die nicht im Zusammenhang mit dem Einfrieren stehenden Logeinträge des Bootvorganges, denn er brach immer beim USB-Host-Init ab, weswegen ich an der Stelle ewig rumgesucht hab .. natürlich ohne Erfolg.

Und da Ubuntu8.04 ja mal lief trieb mich das richtig in den Wahnsinn. Das wurde alllerdings per DistUpgrade gemacht und hat anscheinend irgend etwas bei diesem Dienst noch auf dem alten Stand gelassen. Anders kann ich es mir nicht erklären.

Ich war so kurz davor aufzugeben und mir wieder einen Hoster zu suchen :/

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.

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.

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.

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 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.

Kaum auf dem eigenen Server und schon gravierende Probleme. Die MySQL-Datenbank ist Gestern irgendwann im Laufe des Tages komplett drauf gegangen. Warscheinlich wegen apparmor und meinen Spielereien mit “mount -bind” und einer RAM-Disk.

Resultat war, dass die Datenbank irgend einen Zwischenstand erreichte, der komplett inkonsistent war. Die Post-Tabelle war auf dem Stand von vorige Woche und die Tabelle “wp_options” enthielt plötzlich Kommentardaten. Also ist ganz unten auf der Ebene des Dateisystemes was gewaltig in die Hose gegangen.

Ich habe die bisherigen Daten des Blogs nur retten können, da ich ein Backup von letzte Woche hatte und die fehlenden Posts einfach aus dem Browsercache per grep (und per Hand! *schwitz*) wieder raus gefriemelt habe.

Da ich die Idee, alle Daten die sich oft ändern in einer RAM-Disk zu halten, nicht aufgeben will und die Schuld nicht bei MySQL sondern bei Apparmor suche, habe ich das erst mal so gelassen. Aber ich habe das MySQL-Profil aus der apparmor-Konfig genommen. Mal sehen, was das bringt, ich werde weiter darüber berichten.

Ich mach jetzt jedenfalls öfter Backup der Datenbank und muss mein Auto-Backup-Vorhaben mal endlich in die Tat umsetzen.

Erste Erkentnis: es könnte daran liegen, dass das disk2ram-Script den MySQL-Server und Apparmor nur per HUP-Signal neustartet. Ich habe jetzt Apparmor wieder aktiviert und beim disk2ram die beiden Prozesse explizit neu gestartet. Mal sehen…