phoenitydawn

Ursprünglich mochte ich NetworkManager nicht. Grundsätzlich machte er mehr Probleme bei der Handhabung von Netzwerkverbindungen unter Linux, als er löste. Das ist allerdings schon einige Jahre her und spätestens seit der grandiosen Integration von WWAN-Hardware ist er ein richtig brauchbares Hilfsmittel geworden.

Eine Sache, die mir nun fehlte, war die Möglichkeit nach dem verbinden in ein WLAN eine Authentifizierung via Browser zu automatisieren. Nach einer kurzen Suche stellte sich heraus, dass es mit NetworkManager ein leichtes ist, auch das zu automatisieren. Dazu reicht es ein Shell-Skript in /etc/NetworkManager/dispatcher.d/ abzulegen, dass als ersten Parameter den Namen der betroffenen Verbindung und als zweiten Parameter die Statusänderung der Verbindung (up oder down) erwartet. Daraufhin war es ein leichtes, ein kleines Skript zu basteln, dass die Authentifizierung via HTTP übernimmt, nachdem eine bestimmte Verbindung aktiviert wurde:

#!/bin/sh

# network manager connection name
CONN_NAME="sample_wlan"

# check if this script is triggered for the wlan interface
if [ "$1" != "wlan0" ]; then
    exit 0;
fi

# check if the action is the enabling of the interface
if [ "$2" = "up" ]; then
    # check if the connection we want to automate, is active
    if [ "$(nmcli con status | grep -o $CONN_NAME)" = "$CONN_NAME" ]; then
        wget -q --post-data="username=john&password=123456&possible_other_post_parameters=xyz" https://fqdn-of-the-captive-portal.tld/login.html -O - > /dev/null
    fi
fi

There already exist great tutorials how to setup IPSec for IPv6 using racoon for Internet Key Exchange (IKE) like this one or this one.
But for the usage of IPSec inside one subnet, they miss one point: Inside an IPv6-subnet clients depend on the Neighbor Discovery Protocol (NDP) for receiving Link-Layer-addresses. If NDP isn’t working, clients won’t receive the Link-Layer-address of the target host und won’t therefore be able to send packets to it.
Long story short: If you want to use IPSec for IPv6 in the same subnet, you’ll have to add an exception to enable unencrypted ICMPv6-packets. That problem doesn’t occur with IPv4, because the Address Resolution Protocol (ARP), which is used there for the same purpose, doesn’t rely on IP in contrast to NDP.
I had to search a while to figure that out and finally found the solution there: http://www.oss.sgi.com/archives/netdev/2004-02/msg00684.html.

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.