Als ich von der Stadt aufs Land gezogen bin dachte ich, dass ich ggf. mit meinem Netzanschluss ein Problem kriege (was der Fall ist:), aber dass WLAN-Empfang schwierig wird, ahnte ich nicht.

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.

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.

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

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

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.