Fedora 28 und das Upgradeaftermatch

„Hey, Fedora 27 ist Geschichte, freu Dich auf Fedora 28, User!“ Ich habe ihn nicht gehört, aber der MCP hat das bestimmt vorhin beim Upgrade gesagt oder gedacht. Leider hat es nicht funktioniert.

Keine Friends in Sicht…

Ja, heute war es soweit: das obligatorische Sechsmonatsupgrade auf Fedora 28 war dran. Auf dem Laptop läuft es seit letzter Woche, also sollte das ja jetzt kein Problem werden. Flugs den Desktop stoppen, in eine Root-Shell und DNF mit Arbeitsanweisung versorgen. Gesagt, getan. 15 Minuten später waren alle 3800 Pakete geladen und bereit. Zwei unwichtige Downgrades und 3 unwesentliche Altpaketentfernungen waren abgesegnet. Schritt 1/7550 kam in Sicht und …. hey… (nanü? Was ist mit der Absatzüberschrift los?)… ging 🙂

7550 Schritte später, wartet mein Cursor, meine Root-Shell und mein neues Fedora auf mich, also „reboot“ getippt, beide Daumen zerquetscht und gewartet. Bios .. Grub \o/ … die seit Jahren vertraute Meldung, daß die Kernel-Module vom Systemd nicht geladen werden konnten…( Anm.d.R „auch diesmal“ wieder nicht 🙁 ) .. Fedora Bootlogo… wird weiß… Login! … DESKTOP! … P.R.O.G.R.A.M.M.E !.! … was ist das denn?

„Wollen Sie die Default Ordner rename to die lokal gewählte Sprache…“

Was zum Geier… wie kommt Cinnamon darauf, daß ich bei einem Deutschen Desktop englische Verzeichnisnamen haben können wollte? Könnten die Spracheinstellungen defekt sein? Nachguck.. Nö. Deutsch/Deutsch. Sieht ok aus. „Da hat bestimmt Gnome beim Update was zerlegt.“ war der Gedanke, also ins Gnome gewechselt… was ein schwerer Fehler war, den GNOME ist nicht mehr .. DAS hat es tatsächlich beim Upgrade zerlegt, denn die Gnome-Shell kommt nicht an den Start. Die Programme schon, aber ohne Windowmanager nützt das nicht viel 😀 … Hmm.. Programme melden sich aber in Deutsch, das ja komisch.

Mit STRG+ALT+F3 ab in die Root-Shell, anmelden …. was ist das denn? „setlocale: Konnte LC_TIME nicht setzen“ (War natürlich auf english, aber zum besseren Verständnis wird es hier eingedeutscht). Wie kann das denn sein?

Kurz mal die Umgebungsvariablen checken:

# strings /proc/self/environ 
...
LANG=de_DE.UTF-8
...
_=/usr/bin/strings


# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Alles ok, Deutsch ist eingestellt. Übersetzungen gingen ja in den Programmen, aber tatsächlich war die Zeit in English mit 12H+AM/PM .. schauen wir doch mal mit strace auf welche Locale will das Programm eigentlich zugreifen: also „strace -f locale de_DE.UTF-8“ eingegeben und es würde gern diese Datei benutzen „/usr/lib/locale/de_DE.utf8/LC_TIME“ … ist ja merkwürdig, die ist gar nicht vorhanden…. hey! den ganzen Ordnerbaum gibt es gar nicht! HIER FEHLT DEUTSCH!

Und so behebt man das

Die Sachelage ist klar: Keine Deutsche Locale vorhanden, also nachinstallieren. Da wir den Pfad kennen, fragen wir dnf wer das bereitstellen könnte:

# dnf provides „/usr/lib/locale/de_DE.utf8/LC_TIME“

glibc-langpack-de-2.27-32.fc28.x86_64 : Locale data for de
….

also installieren wir das und rebooten kurz ( damit auch die Bootprozesse in Deutsch melden können, wenn Sie das wünschen):

# dnf install glibc-langpack-de

und da merkt man dann, daß das kein Witz war, weil der jetzt „j“ nicht mehr als „ja“ => „yes“ erkennt .. muß man also wirklich „y“ drücken 🙂

Nach dem Reboot war es dann in Ordnung. Warum der den Language-pack nicht installiert hat, werden wir nicht erfahren. Um GNOME werde ich mich wohl mit „rm -rf .config/gnome-session“ kümmern müssen.

Update Tag 2:

Die WetterApp geht nicht. Libmozjs crasht beim Start extrem hart, incl. Coredump. Autsch. Mal sehen was von den HinterbänklerApps noch so nicht geht.

Linux – Jitsi Probleme mit Sipgate beheben

Seit SIPGate vor einigen Monaten an Ihrer Infrastruktur unangekündigt Veränderungen vorgenommen hat, verliert die Linuxversion von Jitsi im UDP Modus häufig die Verbindung zum Server. Dabei ist es egal, welche Version und welches Java man verwendet.

Die Abhilfe ist aber sehr leicht zu schaffen, man schaltet das automatische Proxy ab und ersetzt es mit :

Proxy:  tcpproxy.sipgate.de
Port: 5060
Bevorzugter Transport: TCP <-! Wichtig

Seit der Anpassung, funktioniert Jitsi wieder stabil mit SIPGATE.

Gnomefehler bei Libinputupdate beheben

Da kommt aus heiterem Himmel ein Update für Cinnamon und Gnome kann plötzlich nicht mehr richtig mit der Maus scrollen. Und jetzt ?

In dem Beitrag über die Anpassungen zu den Mausgeschwindigkeiten, die bei Gnome set einiger Zeit nicht mehr sauber funktionieren, wird gezeigt, wie man sein Eingabegerät ermittelt:

~]$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ImPS/2 BYD TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ UVC Camera (046d:081b) id=8 [slave keyboard (3)]
↳ Eee PC WMI hotkeys id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]

Meins ist die ID 11, was an einem bekannten Kernelbug zur Erkennung von Touchpads liegt.

Seit dem besagten Update scrollte meine Maus mit dem Scrollrad falsch rum, was unter Cinnamon komischerweise korrekt funktionierte.  Dank der Liste verfügbarer Eigenschaften des „Touchpads“ :

~]$ xinput list-props 11
Device 'ImPS/2 BYD TouchPad':
    Device Enabled (151):    1
    Coordinate Transformation Matrix (153):    1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    libinput Accel Speed (289):    -0.500000
    libinput Accel Speed Default (290):    0.000000
    libinput Accel Profiles Available (291):    1, 1
    libinput Accel Profile Enabled (292):    1, 0
    libinput Accel Profile Enabled Default (293):    1, 0
    libinput Natural Scrolling Enabled (294):    1
    libinput Natural Scrolling Enabled Default (295):    0
    libinput Send Events Modes Available (273):    1, 0
    libinput Send Events Mode Enabled (274):    0, 0
    libinput Send Events Mode Enabled Default (275):    0, 0
    libinput Left Handed Enabled (296):    0
    libinput Left Handed Enabled Default (297):    0
    libinput Scroll Methods Available (298):    0, 0, 1
    libinput Scroll Method Enabled (299):    0, 0, 0
    libinput Scroll Method Enabled Default (300):    0, 0, 0
    libinput Button Scrolling Button (301):    2
    libinput Button Scrolling Button Default (302):    274
    libinput Middle Emulation Enabled (303):    0
    libinput Middle Emulation Enabled Default (304):    0
    Device Node (276):    "/dev/input/event3"
    Device Product ID (277):    2, 5
    libinput Drag Lock Buttons (305):    <no items>
    libinput Horizonal Scroll Enabled (278):

konnte ich mit einem Einzeiler die Scrollrichtung wieder umdrehen:

xinput set-prop 11 289 -0.5 2>/dev/null           # Mausgeschwindigkeit mit LibInput
xinput set-prop 11 294 0 2>/dev/null                # Scrollradrichtung

Komisch, das sowas im Testlauf nicht gefunden wird…

Update: 13.12.2016

Der neue Kernel 4.8.13 behebt das Problem, weil die PS/2 Mäuse jetzt als Maus erkannt werden un dnicht mehr als Touchpads.

Pydio 5.2.5 Sharefunktion fixen

Leider mußte ich mal wieder den Sharecenter von Pydio fixen, weil es für einen offensichtlichen Bug keinen Patch gibt, wir kennen das ja schon. Mal sehen ob Charles wieder den Aufstand macht, wenn ich ihm den DIFF schicke, statt den Patch auf GitHub hochzuladen 🙂 Leider kann man nicht auf Version 6 Updaten, weil dann Pydio nicht mehr funktioniert.  Wie man dafür 1300 € im Jahr verlangen kann, ist mir ein Rätsel, leider ist es das beste Tool für die Sache, trotz der Fehler.

Zwei Bugs müssen behoben werden:

  1. class.AJXP_Utils.php    error l.1744    message=mcrypt_create_iv(): Cannot open source device
  2. class.ajxp_confAccessDriver.php(2250) : eval()’d code   error l.2       message=mcrypt_decrypt(): Key of size 6 not supported by this algorithm. Only keys of sizes 16, 24 or 32 supported

Fangen wir mal mit Bug #2 an , der ist einfacher :

In der Defaulteinstellung von Pydio steht ein Hashwert der Länge 6. Das ist aber seit einigen PHP Versionen zu kurz, deswegen die MCrypt Meldung.

Bitte hier auf 16 umstellen :

pydiobug1

Bug #1 ist da schon viel anspruchsvoller 🙂 In der Datei „core/classes/class.AJXP_Utils.php“ Zeile 1746 muß ein Wert geändert werden, weil Charles beim Programmieren offensichtlich ein altes Windows PHP benutzt hat, denn da ist „MCRYPT_DEV_URANDOM“ wohl Pflicht.

public static function pbkdf2_create_hash($password)
    {
        // format: algorithm:iterations:salt:hash
        $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTE_SIZE, MCRYPT_DEV_URANDOM));
        return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" .
        base64_encode(self::pbkdf2_apply(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTE_SIZE,
            true
        ));
    }

ersetzen durch :

public static function pbkdf2_create_hash($password)
    {
        // format: algorithm:iterations:salt:hash
        $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTE_SIZE, MCRYPT_RAND));
        return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" .
        base64_encode(self::pbkdf2_apply(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTE_SIZE,
            true
        ));
    }

Nach dieser kleinen Anpassung „funktioniert“ der Sharecenter wieder, was aber nicht heißt, daß man den Share in dem Sharecenter angezeigt bekommt 🙂

Den muß man dann aus dem Repository extrahieren :

pydiobug2

Munin unter Fedora 21 zum Laufen bringen

Munin hat speziell mich die letzten zwei Wochen auf Trab gehalten, seitdem unsere Testserver für die neuen Softwarekomponenten auf Fedora 21 umgestellt wurden. Jeden Tag haben wir hunderte Emails von Munin bekommen, daß alles auf dem Server ok wäre. Eine Konsultation mit den Entwicklern von Munin brachte nur ein „Kann ich nicht reproduzieren“ hervor, ja.. also.. kann passieren 😉

Da mir das nun langsam auf die Nerven gegangen ist, habe ich mich dann selbst an Munin versucht.

Das Problem

Das DiskFree Modul und die DiskFree-Inodes Modul von Munin ( kurz df und df_inode) gehen die Liste von Filesystemen eines Servers durch und prüfen, ob diese voll oder fast voll sind. Dabei wird scheinbar alles geprüft, was irgendwie ein Filesystem ist, selbst romfs, ramfs  und debugfs, die ja nun keine echten Filesysteme mit möglichen Belegungsproblemen sind. Komischerweise schickte uns Munin immer nur OK Meldungen, aber keine Warnmeldungen zu df und df_inode zu. Die Filesysteme auf den Servern hatten zudem auch gar keine Belegungsprobleme, trotzdem haben wir alle 15 bis 30 Minuten so eine Email bekommen.

testdomain.de :: testdomain.de :: Inode usage in percent OKs: /run/user/0 is 0.00, /sys/fs/cgroup is 0.01, /opt/root/dev/shm is 0.00, /run is 0.88, / is 3.78, /run/user/496 is 0.00, /dev/shm is 0.00, /dev is 0.24.

Die Analyse

Munin bietet zwar von Haus aus Debugfunktionen an, aber keine führte zum Ziel. Damit man Munin debuggen kann, muß man zunächst zum Munin User werden, der „normalerweise“ keine Shell hat, damit man sich nicht einloggen kann:
# su munin -s /bin/bash

Dann gibt mal als erstes mal munin-limits ein, um sich einen Überblick zuverschaffen.

# /usr/share/munin/munin-limits --debug

pre>2014/12/22 15:41:19 [DEBUG] processing critical: _dev_xvda1 ->  : 98
2014/12/22 15:41:19 [DEBUG] processing warning: _dev_xvda1 ->  : 92
2014/12/22 15:41:19 [DEBUG] processing unknown_limit: _dev_xvda1 -> 3
2014/12/22 15:41:19 [DEBUG] processing field: localhost::localhost::df::_dev_xvda1
2014/12/22 15:41:19 [DEBUG] field: $VAR1 = {
‚#%#name‘ => ‚_dev_xvda1‘,
‚critical‘ => ’98‘,
‚graph_data_size‘ => ’normal‘,
‚label‘ => ‚/‘,
‚update_rate‘ => ‚300‘,
‚warning‘ => ’92‘
};
2014/12/22 15:41:19 [DEBUG] value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
2014/12/22 15:41:19 [DEBUG] generating service message: localhost::localhost::df
2014/12/22 15:41:19 [DEBUG] Contact list for localhost::localhost::df:
2014/12/22 15:41:19 [DEBUG] processing service: fw_conntrack
2014/12/22 15:41:19 [DEBUG] state_file: /var/lib/munin/state-localhost-localhost.storable

Das obige Beispiel ist natürlich nur ein Ausschnitt, im Normalfall kommen dort Dutzende verschiedene Werte zur Ausgabe. Interessant ist diese Zeile:
value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
Der Wert des Feldes „df“ war 22.62 % für /dev/xvda1 ( unsere Rootpartition ). Eine Warnung gibt es bei  92 % Belegung und einen Critical ab 98%.  In diesem Beispielfall kommt also keine Email zustande, weil alles im Toleranzbereich ist.
Munin schickt laut Sourcecode nur dann noch Emails, wenn sich der Zustand geändert hat, also z.b. vorher Critical war und dann bei nächsten Check wieder OK ist. Genauso in die andere Richtung ( ok -> fail ).
d.h., wenn Munin keinen anderen tieferen Bug hat, muß es so einen Wechsel festgestellt haben und da die Platte als Quelle ausschied, weil dich dort nicht geändert hat, mußte die Warnung für ein anderes Filesystem gekommen sein, auch wenn man das nicht gesehen hat. Allzuviele kommen da nicht in Frage:
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/xvda1       78G     17G   58G   23% /
devtmpfs        490M       0  490M    0% /dev
tmpfs           500M       0  500M    0% /dev/shm
tmpfs           500M    3,1M  497M    1% /run
tmpfs           500M       0  500M    0% /sys/fs/cgroup
tmpfs           500M    4,0K  500M    1% /opt/root/dev/shm
tmpfs           100M       0  100M    0% /run/user/0
Scheinbar hatten sich die Ausgaben für tempfs und devtempfs von Fedora 20 zu Fedora 21 verändert,
was Munin verwirrt hat.

Die Lösung

Nach einigen Tests gelang es mir dann, Munin zur Aufgabe zu bewegen.

Dazu muß man in der plugin-conf für df das devtempfs und das tempfs excluden. Es macht sowieso kaum Sinn ein Ramlaufwerk zu checken, da Ramlaufwerke i.d.R. immer zu 100% voll sind, außer man hat ein fixed Ram-Drive gewählt.

# cat /etc/munin/plugin-conf.d/df
[df*]
env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs binfmt_misc rpc_pipefs fuse.gvfs-fuse-daemon tmpfs devtmpfs

Das alleine half aber nur bei dem Wert für df, df_inode sendete fleißig weiter OK Meldungen. Wie sich dann herausstellte, kann man auch für das df_inode eine eigene Configdatei ablegen. Dazu braucht man nur die df Datei zu kopieren „cp df df_inode“ und dann das System neustarten : systemctl restart munin-node . Den letzten Schritt sollte man nicht vergessen, denn auch wenn Munin alle 5 Minuten vom Cron gestartet wird, heißt das nicht, daß die Limits dann eingelesen werden, da die Node als eigener Prozess läuft.