Linux

Früher habe ich Ubuntu gerne Leuten empfohlen, die einfach nur einen funktionierenden Computer ohne Windows haben wollten. Nachdem ich über die Jahre gesehen habe, was für überflüssige Probleme Ubuntu im Alltag für ebensolche Leute generiert und welche Politik Canonical fährt (zum Beispiel ein bisschen arg viel Not-invented-here-Syndrom), kann ich Ubuntu nicht mehr ruhigen Gewissens weiterempfehlen.

Ich selbst bin und bleibe sowieso treuer Debian-Nutzer, insofern ist für mich Ubuntu nur begrenzt interessant. Aber es gibt eben einen Bereich, in dem ich viel mit Ubuntu zu tun habe und dieser Bereich heißt Arbeit. Dort habe ich mir heute mal Ubuntu 16.04 LTS auf einen neuen Rechner installiert es gibt zwei Punkte, die ich diesbezüglich an dieser Stelle ansprechen möchte:

1. Secure Boot per Default aktiviert

Ubuntu 16.04 LTS funktioniert out-of-the-box mit Secure Boot inklusive tatsächlichem prüfen von Signaturen, sofern man keine proprietären oder lokal kompilierten Treiber braucht, da diese nicht von Canonical signiert sind.

2. “Ruhezustand” ist nicht standardmäßig aktiviert

Um “Ruhezustand” nutzen zu können, muss man eine extra Konfiguration für Polkit anlegen. War mir so auch neu und ist wenig hilfreich für Leute, die einfach nur ihren Computer benutzen wollen.

Neben diesen beiden für mich herausragenden Punkten war die Installation absolut problemlos, sämtliche Hardware funktionierte sofort und die Startzeit war, vielleicht dank systemd, überaus flott. systemd ist dann auch das Feature über das ich mich, insbesondere im Serverbereich, am meisten freue. Ich muss mir noch im Detail anschauen, ob das in Ubuntu genauso halbherzig wie upstart eingeführt wurde, freue mich aber, insbesondere im Serverbereich, dadurch einige hässliche Init-Skripte loswerden zu können.

0

Ich habe mich gerade beim übertragen von Daten mittels rsync im lokalen Netzwerk gewundert, dass die Übertragungsrate lediglich 20MB/s betrug und dabei die CPU der Flaschenhals war. Stellt sich heraus: SSHs Komprimierung ist schuld. Mit

rsync -e "ssh -o Compression=no" -av quelle ziel

sind es nun über 100MB/s und nur deshalb nicht mehr, weil Gigabit-Ethernet und die Festplatten jetzt der Flaschenhals sind. Diesen Unterschied müsste SSHs Komprimierung erst mal wett machen, was in diesem Fall sowieso vollkommen illusorisch ist, da die Daten bereits gut komprimiert sind. 😉

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

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

0

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.

2

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

0

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

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

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