phoenitydawn

While at work I recognized an annoying problem with multipe screens: I often forget to change the focus of the windows to the screen I’m currently looking at. The result: In that cases I want to type in a window on screen A and all text go’s into a window on screen B. Very annoying.

But here is a possible solution: Because all screens have intregrated webcams, it would be possible to grab images from these webcams and use an eyetracking software to determinate at which screen I’m currently looking. With the help of the window manager the focused window could change accordingly and I would never type onto to wrong screen anymore.
But as usual, the problem is the missing implementation. I couldn’t find any eyetracking software for linux which is able to use v4l2-devices and I also don’t know if any window manager is capable of changing the focused window in that manner.

If you know a working solution for my problem or already implemented such eyetracking-stuff, just leave me a comment.

Ich war die Tage auf Arbeit ziemlich enttäuscht. Sowohl Webcam des Notebooks, als auch Webcam des externen Monitors funktionierten unter Linux, ohne dass ich auch nur einen Finger rühren musste. Wo bleibt denn da der Spaß? ;D

Vergangene Nacht wurde auf meinem Server Courier gegen Dovecot ausgetauscht. Abgesehen davon, dass ich erstmal leicht verwirrt vom Umfang der Konfigurationsdatei war lief auch alles sehr gut. Die eigentliche Umstellung dauert ~1 1/2 Stunden.
Etwas mehr Kopfzerbrechen bereitete mir, als ich Postfix dazu bewegen wollte sein SMTP AUTH über Dovecots SASL abzuhandeln. Tun wollte ich dies, da ich über Dovecot beispielsweise Passwörter mit SHA1 + Salt gehasht speichern kann was, wie schon vor einer Weile erwähnt, mit Postfix und PAM nicht funktioniert. Es gibt zwar ein wunderbar einfaches Howto wie man Postfix dazu bringt Dovecots SASL Authentifzierung zu verwenden, allerdings erhielt ich nach befolgen der Anleitung einfach nur folgende Fehlermeldung in meinem Errorlog:

Jun 1 03:54:16 localhost postfix/master[7882]: reload configuration /etc/postfix
Jun 1 03:54:42 localhost postfix/smtpd[11518]: warning: SASL: Connect to smtpd failed: No such file or directory
Jun 1 03:54:42 localhost postfix/smtpd[11518]: fatal: no SASL authentication mechanisms
Jun 1 03:54:43 localhost postfix/master[7882]: warning: process /usr/lib/postfix/smtpd pid 11518 exit status 1
Jun 1 03:54:43 localhost postfix/master[7882]: warning: /usr/lib/postfix/smtpd: bad command startup — throttling

Ich rätselte ein paar Stunden woran das liegen könnte und kam keinen Schritt weiter. Aber dann fand ich doch den Übeltäter. In diesem Fall die Datei /etc/default/saslauthd. Dort waren als OPTIONS für Postfix folgende gesetzt:

OPTIONS=”-c -m /var/spool/postfix/var/run/saslauthd -r”

Dies war ja aber nun obsolet geworden. Nach dem abändern der Zeile auf:

OPTIONS=”-c”

funktionierte dann das Ganze auch.
Grundlegend hab ich also nun alles wieder so funktionierend wie vorher, allerdings mit mehr Möglichkeiten was ich damit nun anstellen kann. Nun werden nach und nach die Passwörter auf salted-SHA1 umgestellt und auch einfach zu handhabende Anti-Spam-Maßnahmen für die Benutzer werden folgen, wenn ich mal die Zeit dafür habe.

Schon lange hatte ich vor meinen Desktoprechner komplett neu zu bespielen, dabei die komplette Festplatte zu verschlüsseln und auf 64Bit umzusteigen. Gestern nahm ich dies nun endlich mal in Angriff und ich muss sagen ich bin mal wieder entzückt von Linux. Insbesondere natürlich von Debian. Es sind noch keine 24 Stunden seit dem Beginn der Neuinstallation vergangen und von der Benutzung her merkt man dem System nichts an, was auf eine komplett neue Installation schließen lassen würde.
Wichtig dafür war natürlich, dass sämtliche persönlichen Daten und persönlichen Einstellungen erhalten bleiben. Glücklicherweise liegen die unter Linux alle zusammen schön im Nutzerverzeichnis des Benutzers, sodass ich einfach nur ein Backup dieses Verzeichnisses auf meinen Rechner zurückkopieren musste. Das ging wider Erwarten auch erstaunlich gut. Selbst fremdsprachige Zeichen in Dateinamen (französisch, russisch, …) blieben erhalten (ein plus für Unicode ).
Was anzupassen blieb waren ein paar systemweite Einstellungen. So wollte der Drucker neu konfiguriert werden und auch der Flashplugin erforderte eine andere Herangehensweise als unter 32Bit. Immerhin funktioniert Flash und das ohne großen Frickelaufwand!
Ich bin auf jeden Fall trotz einiger kleinerer Problemchen die bisher auftauchten (Rechner startete auf einmal nicht mehr weil’s mir die initial ramdisk zerhauen hatte, …) sehr zufrieden wie das alles so gelaufen ist.

Endlich habe ich keinerlei unverschlüsselte Festplatte mehr in meinem Haushalt.

Seit heute gibt es einen befreiten La Fonera mehr. Und zwar meinen. Den hatte ich schon länger bei mir rumstehen und seit circa drei Monaten steht er nicht mehr nur in einer dunklen Ecke, sondern bei mir auf dem Balkon und wird seitdem auch fast täglich genutzt. Funktionierte auch alles perfekt. Also kein Grund irgendwas an der Software des La Foneras verändern zu wollen. Denn da kommt man nicht so ohne weiteres ran. Es gibt zwar ein Webinterface, aber dort kann man nur die allerwichtigsten Einstellungen vornehmen. Direkt an der Firmware rumzupfuschen versucht FON möglichst zu verhindern. Klappt natürlich nicht und so gibt es inzwischen Projekte die die Orginalfirmware des La Foneras ergänzen oder ersetzen, denn im Prinzip läuft auf dem Teil auch nur ein Linux. Heute stieß ich dann zufällig über FreeWLAN die sich zum Ziel gesetzt haben dem Nutzer die volle Kontrolle über seinen La Fonera zu geben ohne dabei die eigentliche Funktionalität einzubüßen. Also eine feine Sache. Ich hab mir den FreeWLAN-Mod dann auch prompt installiert und es läuft alles sehr gut. Gibt zwar hier und dort noch kleinere Problemchen, aber nichts was sich nicht beheben lassen sollte. Und es ist toll was man da nun alles für Einstellungen vornehmen kann. Und man kann sogar via SSH direkt auf den La Fonera drauf. Ich bin auf jeden Fall sehr zufrieden damit und kann das einspielen eines solchen Mods anderen La Fonera-Besitzern nur wärmstens empfehlen.

P.S.: Sorry für den anstrengenden Satzbau in diesem Artikel, mir war einfach mal danach. ;P

Entweder ich übersehe grade einen wichtigen Punkt oder pam-mysql und MySQL selbst bieten keinen sinnvollen Hashing-Algorithmus für Passwörter. Aber zum eigentlichen Thema:

Die Informationen zu den E-Mail-Adressen und FTP-Accounts auf diesem Server befinden sich in einer MySQL-Datenbank. Unter anderem auch die gehashten Passwörter. Auf diese Informationen wird beispielsweise via pam-mysql zugegriffen. pam-mysql in Debian bietet zum Hashing der Passwörter drei Möglichkeiten. crypt(), md5 und die MySQl password()-Funktion.
Doch alle drei haben schwerwiegende Nachteile: crypt() weil es nur die ersten acht Zeichen der zu hashenden Zeichenkette beachtet, md5 weil der Algorithmus inzwischen gebrochen wurde und zu password() steht im MySQL-Manual ausdrücklich: “The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications.“.

Also alles irgendwie keine sinnvollen Möglichkeiten. Die neuste Upstreamversion von libpam-mysql unterstützt auch sha1, wobei dieses ja auch mehr oder weniger gebrochen ist.
Ich persönlich würde mir eher sowas wie sha512 + salt wünschen. Aber das unterstützt MySQL nicht und somit auch nicht pam-mysql.

Kennt da jemand irgendeine tolle Möglichkeit dieses Problem zu umgehen oder muss man zwangsläufig damit leben?

Update: Ich sehe grade, dass MySQL6 das Erzeugen von Hashs der SHA2-Famile ermöglichen wird. Das ist ja immerhin schon mal etwas. Fehlt nur noch das Salt.

Heute will ich mal ein bisschen lästern. Aber alle potenziellen Leser können beruhigt sein, denn ich habe nicht vor über konkrete Personen zu lästern. Genauergesagt will ich über gewisse Linuxdistributionen lästern. Und zwar über die aus der Red Hat-Ecke. Als Beispiel nehme ich Fedora und CentOS, da ich beide vor kurzem benutzt habe, aber bei Redhat Enterprise Linux (RHEL) ist die Problematik natürlich die gleiche. Und zwar will ich über das Paketmanagement lästern. Es kann durchaus auch sein, dass ich einfach nur aus Unwissen lästere, aber ich bin froh über jeden Wissenszuwachs. Wer also Ergänzungen zu meinen Ausführungen hat, den bitte ich diese doch in den Kommentaren niederzuschreiben.
Also, Thema Paketmanagement: Ich bin ja nun eher der Debianer. Und unter Debian ist alles ganz toll. Das Paketmanagement dpkg ist sehr ausgereift und es gibt sehr komfortable Tools zur Installation und zum Management von Software. Natürlich gibt es grafische Tools, doch ich ziehe ein Kommandozeilentool wie aptitude vor, da ich es durch die Keyboardnavigation bedeutend komfortabler als irgendwelche grafischen Tools finde. Aber das ist Geschmackssache. Bis auf den Fall wenn man ohne grafische Oberfläche dasitzt. Beispielsweise bei Servern oder weil, aus welchem Grund auch immer, keine grafische Oberfläche mehr starten will.
Im Rahmen meines Hiwi-Jobs arbeitete ich bisher mit Fedora 7. Dort konnte ich kein auch nur ansatzweise komfortables Kommandozeilentool finden, was vor allem dann unpraktisch ist wenn ein Sicherheitsupdate das grafische Tool names pirut unbrauchbar macht, wie mir vor kurzem passiert ist (glücklicherweise behob ein weiteres Update ein paar Tage später das Problem wieder). Da bleibt dann nur sowas unkomfortables wie yum übrig. Heute dann der nächste Knaller. Mein Rechner hing grade nicht am Internet und ich wollte pirut starten. Ging nicht, da kein Internet verfügbar. Das einzige was ich machen konnte war pirut gewaltsam zu beenden.
Was mich an pirut auch ziemlich stört ist das man Abhängigkeiten von Paketen nicht vernünftig angezeigt bekommt. Erst nachdem man Pakete zur Installation ausgewählt hat und auf “weiter” klickt ist pirut der Meinung einem mitteilen zu müssen dass es gerne noch dieses und jenes Paket installieren wolle.
Was soll so ein Schrott? Und wie administriert man vernünftig einen Server der mit einer RPM-basierten Linuxdistribution läuft? Hab ich da vielleicht irgendein Tool übersehen?
Wie dem auch sei. Ich finde es einfach nur peinlich was da an Paketmanagement-Werkzeugen mitgeliefert wird. Als Konsequenz wird morgen auf meinem neuen Arbeitsrechner (den ich heute gekriegt habe), erstmal Debian installiert. \o/

Yesterday I tried kvm on my macbook, because I recognized that the cpu does support hardware based virtualization. I wanted to run a virtual machine with the actual kde4 release candidate. First I tried the Suse based KDE4Live, but kvm crashed immediately with “exception 13″. I dunno why that happened, but I didn’t get it working. Then I tried the debian based KDE4-LiveCD which is unfortunately only based on KDE4 beta4. But that cd worked.
I was just wondering if kvm is quite faster than qemu with kqemu, because it didn’t felt faster. I know that kvm does have a few advantages compared with kqemu, like smp and hardware visualization support, but I asked myself how much faster (or actually slower) would it be compared to kqemu.
So I set up a minimal Debian/testing installation in a qemu image. After that I tried in snapshot mode how long it would last to compile a new standard debian kernel once with kvm and once with kqemu.
But enough words are spoken. Let’s see the facts:
Test system:
1,83 Ghz Core Duo MacBook as host with kernel 2.6.22-1-686.
The VM got:
- 256 MB RAM
- 2.5GB HDD space

startup time:
kvm: 30 sec
kqemu: 42 sec

kernel compile time:
kvm: 1h 27min 57sec
kqemu: 2h 13min 17sec

All right. kvm is a lot faster than kqemu, so the reason that it feels not faster on my macbook seems to be the small amount of ram. So I need more ram for my macbook.

Das vergangene Wochenende war eine schöne Erfahrung. Und zwar war es seit sehr langer Zeit das erste Wochenende, an dem ich kein Internet verfügbar hatte und auch sonst nichts besonderes los war. Ich hätte zwar in der Uni ins Internet gekonnt, aber so dringend war’s dann nun auch wieder nicht.
Was mir an diesem Wochenende ohne Internet auffiel: Dadurch, dass das Internet, zumindest in meinem Leben, eine sehr wichtige Rolle bei der Kommunikation mit Freunden und Bekannten spielt ist man ohne erstmal relativ isoliert. Und man hat auf einmal eine Menge freie Zeit mit der man nichts anzufangen weiß, bzw. wo man erstmal überlegen muss was man damit anfängt.
Bei mir führte dies dazu, dass ich endlich mal die komplette LAN-Verkabelung in der Wohnung neu machen konnte, eine sehr umfangreiche Putzaktion durchgeführt habe und etliche Sachen sortiert & organisiert habe. Ebenfalls führte es dazu das ich überdurchschnittlich viele Filme guckte. Ist mir zwar auf Dauer auch nichts, aber für ein Wochenende schon mal in Ordnung. Am Computer war neben aufräumen dank fehlendem Internet nicht allzuviel sinnvolles zu machen, sodass ich die Linux-Demo von Enemy Territory: Quake Wars sehr ausführlich testen konnte. Wobei es mir weniger um den Inhalt ging, denn solche Multiplayer-Tatic-Shooter sind nicht so mein Ding, sondern um die technische Realisierung unter Linux. Und ich muss sagen ich bin begeistert. Quake Wars basiert angeblich auf einer verbesserten Doom3-Engine, welche unter Linux sowieso schon gut lief. Allerdings war die Einrichtung von Doom3 und Quake4 immer noch etwas hakelig. Nicht so bei Quake Wars. Die Installation funktionierte ohne root-Rechte und es funktionierte einfach alles auf Anhieb. Sehr tolle Sache. Jetzt müssten bloß noch mehr Firmen mal erkennen, dass es sich vielleicht auch lohnt linux-kompatibel zu entwickeln.
Ja, soviel zum Wochenende. Heute zwischen 8:00 und 14:00 Uhr sollte nun der Techniker der Telekom kommen um den neuen DSL-Anschluß zu schalten. Allein der Termin, bis 6 Stunden durchgehend verfügbar zu sein, ist ja wohl eine Zumutung. Glücklicherweise tauchte der Techniker dann schon kurz nach 9:00 Uhr auf. Wobei er für mich eher wie ein Azubi wirkte. Also wirklich älter als ich war der garantiert nicht. Immerhin konnte er alles schnell und kompetent einrichten und wies mich auch gleich noch darauf hin, dass ich hier wohl mehr als 16Mbit/s kriegen würde da die nächste Vermittlungsstelle sehr nah ist.
Also hab ich inzwischen schön schnelles DSL. Wobei mir gleich erstmal negativ auffiel das der Upstream ja nur 1Mbit/s ist. Und das als ich 1,1GB auf meinen Server laden wollte. Na ja, dann lädt das halt mal ein paar Stunden. Nachteil dabei ist natürlich, dass dies auch den Downstream beeinträchtigt da ja die ACK-Pakete irgendwie durchkommen müssen. Es ist aber schon bedeutend spürbar schneller als die 2Mbit/s Downstream vorher.
Soviel zum Thema. Über Kommentare zum Thema Abhängigkeit in der heutigen Gesellschaft vom Internet freue ich mich natürlich wie immer.

Seit kurzem gibt es ein extrem cooles Tool für Debian. Sein Name ist debtree und es dient dazu Abhängigkeiten von Paketen im Debian-Repository grafisch darzustellen.
Ich hab es mir mal vorgenommen und ein paar nette Graphen generiert. Der hier zu sehende Graph ist der Graph von infon-viewer und es ist doch schon erstaunlich was da alles mit dranhängt. Für alle die infon noch nicht kennen: Hier ist die offizielle Homepage.
Als besonders hartnäckiger Graph stellte sich der Graph zum Metapaket “kde” heraus. Wie man schon vermuten kann, hängen an diesem Metapaket unzählig viele Programme. Dementsprechend ist auch die Größe des Graphen. Mir gelang es nicht diesen Graphen als PNG- oder JPG-Datei zu erzeugen, wobei die Dateigröße bei diesen Grafikformaten wohl auch explodiert wäre. Ich hab den Graphen mal als SVG-Grafik an diesen Artikel gehängt. Anschauen aber nur auf eigene Gefahr und möglichst nur mit einem halbwegs aktuellen Rechner.

SVG-Grafik für infon-viewer (115KB)
SVG-Grafik für kde (2,8MB)