Debian

0

Seit neuneinhalb Jahren nutze ich Debian und war immer ausgesprochen zufrieden damit. Als technisch versierterer Benutzer kann man ja dank testing und unstable ausreichend frische Softwareversionen nutzen. Der neueste Schrei ist nun der Ersatz von SysVinit durch systemd als Init-System. Da es bei meinem Setup noch kleinere Haken mit systemd gibt und mir systemd nach wie vor etwas ungeheuer ist, hatte ich vor so lange wie möglich bei SysVinit zu bleiben.

Die letzten Wochen mehrten sich dann aber mehrere Probleme:

  • Mein Notebook zeigte nach dem starten kein Bild mehr an, wenn beim starten der Splash von Plymouth aktiv war.
  • Auf sämtlichen Rechnern wird das tun-Modul für openvpn nicht mehr automatisch geladen, sondern muss per Hand geladen werden.
  • Suspend-to-RAM und Suspend-to-Disk waren im “Verlassen”-Bildschirm von KDE nicht mehr zu finden und das schließen des Notebookdeckels legte ihn auch nicht mehr schlafen.

Insbesondere der letzte Punkt nervte mich und ich machte mich auf die Suche nach der Ursache. Die fand ich auch recht schnell in Form eines Debian Bugreports: #752413 kde-workspace-bin: upower-1.0 transition. Spannend dabei die Aussage im letzten Kommentar:

It does mean as a consequence, that kde will depend on systemd/logind
for suspend/hibernate support.

Kurz entschlossen habe ich mein Notebook mal mit systemd neu gestartet und siehe da: Alle oben genannten Probleme waren mit einem Mal verschwunden. Das ärgert mich, denn es zeigt, dass SysVinit in Zukunft wohl kaum mehr vernünftig als Init-System für Desktoprechner verwendet werden können wird, wenn sogar jetzt schon ohne systemd Probleme auftreten, die mit ihm nicht auftreten.

0

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.

0

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

0

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.

2

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

0

Abhängigkeitsbaum von infon-viewerSeit 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)