Mandriva ist nun endgültig am Ende

Jahrelang habe ich als Distribution Mandrake und dann Mandriva als Distribution eingesetzt. Für mich war die Distribution immer die “out of the box” Distribution, die es technisch locker mit Ubuntu aufnehmen hätte können. Leider hat sie immer nur ein Nischendasein gefristet. In den Jahren in denen ich mit Mandrake bzw. Mandriva unterwegs war, hatte das dahinter stehende Unternehmen schon einige Male finanzielle Probleme, konnte sich aber immer wieder aufraffen. Jetzt hat es das Unternehmen wohl endgültig erwischt.

Laut http://lwn.net/Articles/645862/ ist eine Liquidation erfolgt. Die offizielle Seite ist ebenfalls nicht mehr erreichbar. Auch wenn Mandriva (das Unternehmen) in der Vergangenheit meiner Meinung nach einiges falsch gemacht hat, verdanke ich ihm doch mit der Distribtion Mandrake bzw. Mandriva meinen ersten richtigen Einstieg in Linux. Von daher schade darum. Hoffentlich kommen die Anstellten bei anderen Unternehmen unter.

KDE Plasma und Claws-Mail stürzen beim Herunterfahren oder bei einem Neustart ab

Ausgangssituation ist folgende. Auf einem Rechner läuft Arch Linux mit KDE Plasma. Updates sind zum aktuellen Stand komplett eingespielt. Egal ob der Rechner herunter gefahren oder neu gestartet wird, es stürzt die Plasmashell sowie das durchgehend laufende Programm Claws-Mail mit einem Signal 11 ab. Nachdem man einige Fenster mit den Absturzmeldungen weg geklickt hat, startet der Rechner dann aber wie beabsichtigt neu oder fährt komplett herunter. Besonders wohl ist mir dabei aber nicht wegen Claws-Mail.

Nach einigem hin und her habe ich gestern die Lösung gefunden. Der verdammte Layer 8 war mal wieder das Problem… Vor einiger Zeit gab es eine Änderung mit der der Microcode eines Intel-Prozessors nicht mehr automatisch aktualisiert wird und somit ein Eingreifen des Nutzers nötig ist. Vor einigen Wochen hatte ich mir die Datei /boot/syslinux/syslinux.conf verbastelt, so dass ich die vorhandene gelöscht und eine neue erstellt habe. Dabei habe ich natürlich nicht den Eintrag für das Update des Microcodes eingebaut… Nachdem ich das jetzt nachgeholt habe, funktioniert alles wieder wie es soll. Warum das ganze aber erst nach Wochen Probleme gemacht hat, kann ich nicht wirklich sagen. Scheinbar gab es ein Update, dass mit einer alten Version Probleme hat.

EXT4-fs (mmcblk0p2): couldn’t mount as ext3 due to feature incompatibilities

In der Logdatei meines Raspberry Pi tauchen nach jedem Start die Fehlermeldungen “EXT4-fs (mmcblk0p2): couldn’t mount as ext3 due to feature incompatibilities” und “EXT4-fs (mmcblk0p2): couldn’t mount as ext2 due to feature incompatibilities” auf. Es funktioniert zwar alles aber es nervt. Vor allem weil mmcblk0p2 in dem Fall ext4 und nicht ext3 oder ext2 nutzt. Aber die Lösung ist recht einfach.

Einfach die Datei /boot/cmdline.txt öffnen und rootfstype=ext4 hinzufügen und abspeichern. Nach einem Neustart ist die Fehlermeldung verschwunden. Nebenwirkungen konnte ich auch noch keine feststellen.

Alias für Services unter systemd

Manche Services unter systemd haben ziemlich umständliche Bezeichnungen. Systemd-networkd.service oder openvpn@vpn.service zum Beispiel. Um es sich beim Aktivieren, Deaktivieren oder Neustarten etwas einfacher zu machen, kann man hier zu einem Alias greifen. Nehmen wir mal openvpn@vpn.service als Beispiel.

Hier öffnet man einfach die Datei openvpn@vpn.service welche unter /etc/systemd/systemd/multi-user.target.wants/ liegt. Diese sollte wie folgt aussehen.

[Unit]
Description=OpenVPN connection to %i

[Service]
Type=forking
ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config /etc/openvpn/%i.conf --da$
PIDFile=/run/openvpn@%i.pid

[Install]
WantedBy=multi-user.target

Soll der Service auf den Alias vpn1 reagieren, muss man einfach unter [Install] Alias=vpn1.service hinzufügen. Wichtig ist hier, dass der Alias die gleiche Endung hat wie das Original. Also in dem Fall .service. Hier kann man auch mehrere Aliase angeben, welche man in die gleiche Zeile mit einem Lehrschritt getrennt eingibt.

Hat man die Datei nun entsprechend geändert und abgespeichert aktiviert man den Service mittels systemctl enable openvpn@vpn.service. Hiermit wird nun ein Symlink vpn1.service angelegt, welcher auf openvpn@vpn.service verweist. Von nun an kann dieser “Service” anstelle des Originals genutzt werden. Also beispielsweise systemctl status vpn1.service.

SSH-Verbindungen leicht gemacht

Ich nutze regelmäßig SSH-Verbindungen zu diversen Rechnern. Im LAN z. B. zu meinem Receiver oder zu meinem Quake-3-Arena-Server. Da letzterer im Internet erreichbar ist, läuft SSH nicht auf dem Standardport sondern auf einen anderen um Scriptkiddies zu blocken und somit die Logdateien sauber zu halten. Somit muss ich jedes mal, wenn ich mich mit dem Rechner verbinden will ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben. Oder den Befehl aus der Historie von ZSH herausfischen. Das muss doch auch besser funktionieren, oder? Ja tut es.

Hierzu legt man, falls nicht schon vorhanden, als erstes die Datei ~/.ssh/config auf dem Rechner mit dem man sich mit dem Server verbinden will an. Nun erstellt man in dieser folgenden Eintrag.

Host quake
Hostname 192.168.1.220
Port 1234
User quake
IdentityFile /home/$Benutzer/.ssh/quake

In der ersten Zeile geben wir den Namen der Verbindung an. Hier kann man frei wählen. Als nächstes geben wir die IP des Rechners an zu dem wir uns verbinden möchten. Der Port muss angegeben werden, wenn wir einen, vom Standard abweichenden, Port eingestellt haben. In der nächsten Zeile wird der Benutzer angegeben mit dem wir uns auf dem Rechner einloggen möchten. Sollte man anstelle von Passwörtern SSH-Keys nutzen und hat man mehrere unter ~/.ssh liegen gibt man am besten mit IdentityFile auch noch die richtige Schlüsseldatei an.

Nachdem man die Datei abgespeichert hat, braucht man nun nicht mehr ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben sondern es reicht ganz bequem ssh quake.