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

SSH VPN mit den iproute2 Tools

Vor einiger Zeit habe ich gezeigt, wie man ein SSH VPN erstellt. Heute gibt es nun die verbesserte Version, die auch iproute2 Tools benutzt, die ifconfig & Co. abgelöst haben.

Es gelten die gleichen Regeln wie für den alten Beitrag. Als kleine Abweichung nutzen wir diesmal das tun0 Interface, aber das ist reine Kosmetik.

Vorbereitungen

Auf dem VPN Server muß der SSH Tunnel erlaubt sein. Dazu tragen wir „PermitTunnel yes“ in /etc/ssh/sshd_config ein und starten den sshd neu.

Auf dem Clienten

Als erstes öffnen wir den Tunnelverbinder und wie man an den neuen Optionen sehen kann, brauchen wir kein Sleep mehr, denn das macht SSH jetzt für uns von ganz alleine :

ssh -NTCf -w 0:0 root@2te.vpn.server.ip

auf dem VPN Server

 ip link set tun0 up;
 ip addr add 10.0.1.1/32 peer 10.0.1.2 dev tun0;
 echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;

Da der SSH Befehl im Hintergrund anbleibt, können wir auf das Sleep verzichten und direkt zum Clienten wechseln.

Auf dem Clienten

ip link set tun0 up;
ip addr add 10.0.1.2/32 peer 10.0.1.1 dev tun0;
route add 2te.vpn.server.ip gw alte.gw.ip;
route del default gw alte.gw.ip;
route add default gw 10.0.1.1 dev tun0;

Das wars schon wieder, sofern Ihr keine Fehlermeldung bekommen habt. Wichtig ist die Reihenfolge der Aktionen, also daß SSH zuerst gestartet wird, damit das Tunnelinterface auf der Serverseite vorbereitet werden kann. Wenn man nach SSH z.b. „ip link delete tun0“ eingibt, war alles umsonst und es wird nicht funktionieren.

Update:

Falls ihr ein „Cannot find device „tun0““ bekommt, dann führt mal mit Rootrechten “ tunctl -t tun0 -n “ aus.

 

Jabbermeldungen von der Konsole schicken

Normalerweise geht man davon aus, daß Jabber/XMPP-Clienten von Menschen bedient werden. IM macht ja nur sinn, wenn jemand anderen was schicken will. Dieser Andere muß aber nicht notwendigerweise ein Mensch sein, ein Server tut es natürlich auch.

„SendXMPP“ heißt der Befehl. Das in Perl geschriebene Script ist nicht ganz fehlerfrei, aber dafür kommt es mit TLS Unterstützung, was es sympathisch macht, da so die Verbindung zum eigentlichen Jabberserver brav verschlüsselt wird.

echo "Das sieht aus, wie eine normale Nachricht auch aussieht." | sendxmpp -n -t  -u "Shell.Bot" -j xmpp.server.de -p 02332dfs09329324jfd  Ziel@xmpp.server.de

Da die Eingaben von STDIN angenommen werden oder von einer Datei stammen dürfen, kann man das Script praktisch an so alles ranstöpseln, was Statusinformationen loswerden will. Das geht soweit, daß man es über Webseiten z.b. zum Senden von Kundennachrichten an den Support benutzen kann.

Jetzt fehlt eigentlich nur noch eine Shelllösung zum Abchecken, ob das Ziel überhaupt online ist. Damit könnte man dann den Livechat auf der Webseite ausgrauen, wenn niemand erreichbar ist. Da Jabberclienten i.d.R. beliebig viele JabberAccounts verwalten können, hat man natürlich richtig viele gute Möglichkeiten hierarchisch strukturiert Kundensupport zu leisten und auch verschiedene Quellen bei Personen zusammen zu führen.

Anmerkung: Die Config von sendxmpp liest die „derzeit“ aktuelle Version leider nicht sauber ein, deswegen die Parameter. Im Prinzip kann man die aber an einen Linux-Useraccount binden und muß die dann nicht mehr eingeben.

Fehlermeldungen:

„Use of uninitialized value in string eq at /usr/bin/sendxmpp line 515
Error ‚AuthSend‘: [?]“

Wer die findet, sollte die Parameter für Usernamen/Server/Passwort in die Kommandozeile verlagern.