Tobi's Blog

Mit dem hier beschriebenen Update-Script der DynDns-IP gab es leider auch massive Probleme, weswegen ich ein weiteres mal einen Tag offline war *grummel*. Diesmal ging es sogar so weit, dass unter dieser Domain ein anderer Webserver zu erreichen war. Immerhin nur eine personalisierte “It works” Seite, aber das ist schon SEHR ungünstig.

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.

Ich habe ein altes Browser-Spiel wiederentdeckt, was ein netter Zeitvertreib und definitiv ungewöhnlich ist: Paraplüsch.

Das Spielchen ist schon etwas älter und so um 2005 herum hatte ich es schon mal gespielt. Es geht darum, dass man in einer Psychatrie als Arzt gestörte Plüschtiere therapieren muss. Eigentlich ist es recht linear, da man in der richtigen Reihenfolge die richtige Therapie wählen muss, aber es macht Spaß die Wirkungen zu sehen.

Oder wer kann von sich behaupten, ein Plüschkrokodil in die Drogenabängigkeit oder eine Plüschschildkröte in tiefe Depression bis zur Reaktionsunfähigkeit getrieben zu haben? Zu meiner Verteidigung muss ich aber sagen, dass ich alle Patienten heilen konnte. Interessant ist, dass das Teil nicht wirklich harmlos und trotzdem extrem goldig ist.

Seit ich das damals gespielt habe, hat sich auch ein bisschen was geändert, denn es gibt jetzt 5 Patienten stattt wie damals nur 3. Und ein “Doktor” ist noch in Arbeit, lässt sich aber noch nicht benutzen. Die Pinnwandeinträge sind aber noch immer von 2004, was nichts gutes für Neuerungen bedeutet.

Nur so als Tipp: wenn der Patient gar nicht mehr reagiert, hilft nur noch die Schocktherapie und das Teil liegt unter dem Patientenbett versteckt.

Und schon wieder war der Server vom Netz aus nicht erreichbar. Grund diesmal: DynDns hatte nicht mehr die aktuelle IP meines Servers. Ich habe eine DSL-EasyBox 802 mit der aktuellsten Firmware (Version:20.02.223) und die Option “Dyndns” funktioniert dort gar nicht.

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

Da mein Server, ein CA 800 ThinClient von Neoware, nur eine USB-1.0 Schnittstelle hat und ich ihn via WLAN ans Netz bringen wollte, musste eine Erweiterung her. Da der Server einen PCI-Steckplatz hat, hab ich mir einfach eine USB-2.0 PCI Karte geholt und eingebaut. Als kleines Schmenkerl ist auf der Karte noch ein IDE- und ein Sata-Anschluss drauf.

Ab dann fingen die Probleme an. Als erstes erkennt das Bios die Schnittstelle nicht an und ein Booten von dort angeschlossenen Geräten geht also gar nicht. Und wenn ich Geräte benutzen wollte, gab mir das System noch ein paar Sekunden zeit und dann bleibt es stehen.

Ich habe nicht herausfinden können, was es ist, aber ich vermute einen IRQ-Konflikt. Weder auf der Karte noch im Bios kann ich da eingreifen und ich denke, der PCI-Steckplatz ist nur für eine Grafikkarte gedacht und irgendwie fix auf einen IRQ gesetzt. Auffällig ist auch z.B. das der USB-1.0 Host bei eingesteckter karte beim Booten einen “can’t Init host controller” meldet.

Die besondere Gemeinheit and dem Fehler war noch, dass ich sowieso ein einfrierendes System hatte. Also gleich zwei Probleme, die den Rechner hart zum anhalten brachten. Meine Vermutungen lagen deshalb auch eine ganze Weile dabei, dass die Hardware defekt sei. Erst hab ich eine andere PCI-Karte probiert, die dann aber immerhin zurückgeben können. Dann hab ichh mir sogar für ganze 15 EUR nochmal so einen ThinClient geholt. Naja, immerhin hab ich jetzt genügend Ersatzteile.

Mein Server hatte ja eine gewisse Downtime und die hatte einen ziemlich unangenehmen Hintergrund.

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 :/