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.

 

 

Probleme bei Linuxumzug vermeiden

Vor ein paar Tagen habe ich mein Linux von 32 auf 64 Bit umgestellt. Dabei mußte ich natürlich das neue System erst installieren und konnte dann meine alte Home Partition kopieren.

Dabei gibt es einige Sachen zu beachten. Zunächst einmal müssen wir das neue 64 Bit System komplett aufsetzen und alle Programme neu installieren, welche Sie auch schon auf dem alten System hatten. Dazu benutzen Sie am besten Yum und RPM.

Auf dem alten Computer exportieren wir zunächst einmal alle installierten Pakete:

rpm -qa >/tmp/rpms

Dazu kopieren wir zunächst die zusätzlichen YUM Repositories auf das neue System:

cp ...altedaten/etc/yum.repos.d/rpmfusion* /etc/yum.repos.d/
cp ...altedaten/etc/pki/rpm-gpg/*rpmfusion* /etc/pki/rpm-gpg/
yum make cache

Damit sind die Voraussetzungen geschaffen, daß alles reibungslos funktionieren könnte. Natürlich müssen Sie hier alle zusätzlichen Repos kopieren, nicht nur RPMFusion.

Auf dem neuen Computer müssen wir dann die Paketliste mit SED ein bisschen bearbeiten und Referenzen auf die alte 32 Bit Paketbezeichnung entfernen:

sed -e "s/-[0-9-\.]*\.fc20\.i686//"

Im Beispiel habe ich mal Fedora20 benutzt, das müssen Sie natürlich an Ihre Gegebenheiten anpassen. Danach importieren wir die Paketliste in Yum:

yum -y install $(cat /tmp/neuerpmliste)

Danach folgt meist eine größere Orgie an Installationen für mehrere hundert alte Pakete. Bei mir waren es satte 998 Installationen.

Wenn Sie Glück haben sind die meisten davon bereits durch die Neuinstallation wieder vorhanden. Allerdings gibt es viele Pakete, die von Hand nachinstalliert werden müssen, da Sie nicht in einem Repository vorkommen. Darunter fällt zum Beispiel das beliebte OpenOffice, vermutlich auch Ihr Lieblingsdruckertreiber und diverse Erweiterungen zum Abspielen von Videos und Audiodateien.

Der einfachste Weg hier eine Übersicht zu bekommen, was Sie von Hand nach installieren müssen, ist den Installationsvorgang von Yum einfach in eine Datei zu pipen und dort mit einem grep nach „Paket nicht gefunden“ zu filtern.

Nun kommt die Königsdisziplin, der vermeintlich einfachste Teil : der Umzug des home directories.

Was einfach gedacht ist, ist es in der Realität meist nicht. Die Masse an Funktionalitäten wird klappen, wenn Sie einige Punkte beachten.

Wenn Sie auf die tollkühne Idee kommen sollten, Ihr Homeverzeichnis als Ihr eigener Benutzer von der Festplatte Ihres alten Computers zu kopieren, werden Sie leider feststellen müssen, dass Ihre Einstellungen nicht übernommen werden, weil in dem Augenblick wo Sie sich ausloggen, diese einfach mit den aktuellen Einstellungen von Gnome überschrieben werden. Daher müssen Sie Ihr Homeverzeichnis als root User kopieren, als eingeloggter root User versteht sich.

Andernfalls werden Sie beim Kopieren der Inhalte feststellen, daß Teile Ihres Desktop plötzlich anfangen zu reagieren, weil Sie zum Beispiel Ihren Onlinekalender gefunden haben, Ihr E-Mail Programm plötzlich seine Postfächer findet und diverse andere Sachen passieren können. Wenn es dumm läuft, überschreiben Sie sich damit in einer Teil Ihrer Konfigurationen mit halbgaren Inhalten, weil andere Teile noch nicht vorhanden waren.

Daher nochmals der Rat, tun Sie es nur als in die Oberfläche eingeloggter root User und nicht als ihr bereits angelegter normaler Benutzer.

64 Bit Programme, beziehungsweise eine 64 Bit Umgebung, hat natürlich noch ganz andere Probleme zu bieten, als einfach nur 64 Bit zu sein. Ohne 32 Bit Komponenten kommt man auch dort überhaupt nicht aus. Wenn Sie beispielsweise eine Wine Umgebung haben, war diese auf Ihrem alten Computer in 32 Bit und hat auch nur einen 32 Bit Computer simuliert. In einer 64 Bit Umgebung fehlen viele Treiber, die Sie vorher benötigt haben, um zum Beispiel Ihre Spiele zu spielen. Diese waren auf die 32 Bit Treiber von Linux ausgelegt, die nun nicht mehr vorhanden sind, was z.b. bei Nvidia der Fall ist. Sie werden nun also viele Komponenten auf 32 Bit Basis nachinstallieren müssen. Zum Glück ist diese einfach möglich, da Linux als Betriebssystem Libraries zwischen 32 und 64 bit unterscheidet, selbst wenn sie denselben Namen haben, da Sie in anderen Pfaden liegen.

Wine selber liegt nun in einer 64 Bit Version vor. D.b. Sie müssen alle Pakete von Wine auch in der 32 Bit Version installieren. Sie können Yum benutzen um herauszufinden, welche Pakete von Wine installiert sind:

yum list wine*

Sollten Sie nun glauben, daß 64 Bit Programme auf Anhieb funktioniert werden, muss ich Sie leider enttäuschen. Denn Sie haben Ihre 32 bit Version von Wine kopiert. In dieser Umgebung können Sie keine 64 Bit Programme ausführen. Sie benötigen eine neue vollständige 64 bit Umgebung.

Dies ist allerdings recht einfach zu bewerkstelligen. Installieren Sie einfach mit Hilfe von Wine64 das von Ihnen präferierte 64 Bit Programm. Wine erstellt eine neue 64 Bit Umgebung, wenn Sie die entsprechende Wine Umgebungsvariable mit eingeben.

ENV WINEPREFIX=/home/username/.wine64 wine64 64bitprogramm.exe

Sie müssen bedenken, daß in den Menüs und anderen aufrufbaren Dateien, immer davon ausgegangen wird, daß Sie die 32 bit Version von Wine benutzen möchten. Sie haben dies ja schliesslich in Ihrem Standartwineverzeichnis so installiert. Wenn Sie also auf Ihre 64 Bit Programme zugreifen wollen, müssen Sie diese Umgebungsvariable jedem wine Befehl mitgeben:

Dank Verscriptung ist dies kein großes Problem. Es ist aber trotzdem zu überlegen, alle 32 Bit Programme in Wine auf 64 Bit umzustellen und 32 Bit zur Ausnahme zu machen.