Pydio 7 & Pydio – Sync 4 Linux

Für einen Kunden suche ich grade nach einer Synclösung, die man auf dem Server des Kunde btreiben kann und die zuverläßig Daten zwischen Server und X Clienten verteilt. Angefangen hatte ich mit Pydio 7  und dem Pydio Sync.

Jetzt sollte man annehmen, daß Produkte aus dem gleichen Haus zusammen funktionieren. Leider ist das hier nicht der Fall.  Die Serverkomponente Pydio 7.0.4  lies sich noch widerstandsfrei installieren und auch schnell setupen. Sie funktioniert meiner Meinung nach Browser erstmal zuverlässig.

Der Client Pydio Sync in der Linuxversion tut genau das aber nicht. Den ersten Sync bekomme ich erst zustande als ich HTTPS aus der URL nehme, was schon ein K.O. Kriterium ist. Während der Einrichtung der Syncronisation erweist sich Pydio Sync als widerspenstiges kleines Tool, denn erst der dritte Versuch kommt überhaupt soweit, daß er „abgeschlossen“ ist.

Immer wieder muß ich in der Bash ein Passwort für den Keystore eingeben, ohne das es Hinweise dazu in der UI gibt. Auch, daß er sich ein völlig eigenes Verzeichnis zaubert, nachdem man den Syncordner ausgewählt hat, ist nicht grade vertrauenerweckend. Hat man es irgendwie im Xten Anlauf geschafft, Sync das Synctool wie es ihm beliebt. Eingestellt ist der Abgleich zwischen Server und Clienten, also in beide Richtungen syncen. Er synct aber nur vom Clienten zum Server. Vom Server zum Clienten schafft er in keiner Einstellung.

Auch wenn man auf dem Server alles Löscht, löscht er es nicht auch dem Desktop, sondern schiebt es einfach wieder hoch, ganz so, als wenn es Tag 1 der Aktion wäre.

Mit diesem Verhalten ist das Tool in Version 1.2.8 eine Katastrophe und kann nicht empfohlen werden.

Die Serverkomponente dagegen, läuft wie ein schnurrendes Kätzchen 🙂

JackD – Der Störenfried

Völlig überraschend kam heute für mich ein Ausfall des Hauptaudiodevices im Pulseaudio, nämlich das Interne Audio Device vom Mainboard. Das Mainboard ging aber noch und ansonsten gab es auch kaum interessantes zu melden, außer, daß die Programme die Audio benutzen wollten alle im Mixer festhingen.

Was konnte also die Ursache sein ?

In solchen Fällen wird es hilfreich sein,  also-info.sh zu starten und mal einen Blick in die Ausgabe zu werfen. Gedacht, getan:

!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes

Jack:
      Installed - Yes (/usr/bin/jackd)
      Running - Yes

Was zum Geier ist Jack ?

Der Gedanke kam mir zwar nicht, aber wer es nicht weiß, unter Linux Audiosystemen gibt es die großen drei Alsa, Jack und Pulseaudio. Auf Fedorasystemen ist die Kombination aus Alsa und Pulseaudio im Desktopbereich normal. Jack führt eher so ein Nischendasein, was aber einige Tools nicht davon abhält auf Jackkomponenten zuzugreifen z.B. Calf , weswegen es auf einem Desktop durchaus vorhanden ist.

Ok, es war da, aber was hat das mit dem Ausfall zu tun ?

Wie wir oben sehen können, liefen zwei SoundServer und das kann nicht klappen, wenn man nicht jedem der Server sagt, für welches Device er zuständig sein soll. Könnte ja sein, daß man eine SpezialSoundkarte im Einsatz hat mit der man professionell Musik machen will, da könnte das schon Sinn machen, diese von Jack verwalten zu lassen, besonders da Calf auf Jack aufbaut.

Durch ein ungünstiges Zusammenwirken vom „Dicken-Finger-Syndrom“, „Hast“, „Tippfehler“ und „Cinnamon“ wurde versehenlich Calf gestartet, was ich noch nie gesehen hatte und auch nie wieder sehen will, denn es hat einen lausigen ersten Eindruck gemacht 😉 Der Start von Calf führte zum Start von Jack und da Jack dumm wie Stroh zu sein scheint, griff sich der Soundserver die Interne Soundkarte von Mainboard und mein Sound war weg.

Abhilfe schafft …

einfach mit „killall jackd“ als Root töten und danach Calf und Flowblade deinstallieren. Problem solved 😉

Apache – Alles umleiten außer einem Pfad

Wer schon einmal eine Domain komplett z.b. auf https://domain.name umgeleitet hat, der kennt so einen Vhost Eintrag:

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    Redirect 301 / https://domain.name
</VirtualHost>

Was aber wenn man einen Pfad nicht umleiten kann/darf/will, weil das zu Problemen führen würde z.b. mit Lets Encrypt ?

Im Falle von Let’s Encrypt ist die Lösung ein negativer Pfadausschluß :

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    RedirectMatch 301 ^/((?!.well-known/acme-challenge).*)$ https://domain.name
</VirtualHost>

Damit wird alles, nur nicht der Pfad „/.well-kown/acme-challenge“ umgeleitet. Es ist für Lets Encrypt jetzt wieder möglich, die Challenges abzufragen.