Kubuntu 20.04 und Dropbox – Wenn die inotify-Handles ausgehen

KDE Plasma macht mit seinem Index-Dienst „baloo“ relativ ausgiebig Gebrauch von inotify. Wenn man dann noch zusätzliche Anwendungen oder Dienste nutzt, die ebenfalls auf inotify basieren, so kann die nicht sehr üppige Voreinstellung auf 8192 schnell zu knapp werden. Leider findet man nur weniges Anwendungen, die hier explizit einen Hinweis geben, z.B. VS Code. Sogar baloo meldet seine Probleme eher dezent im System-Log : „KDE Baloo File Indexer has reached the inotify folder watch limit.“

Einer der Dienste, die einfach stillschweigend nichts mehr tun, ist die Dropbox. In der Task-Leiste nimmt man zunächst nur noch ein dauerhaft drehendes Rädchen im Dropbox-Icon wahr, wenn man auf der Konsole Dropbox nach dem Status fragt, kommt immer nur ein „wird gestartet…“ – und dabei bleibt es auch. Auch Dropbox möchte inotify-Handles und bekommt keine, was man allerdings leider in keinem einzigen Log findet. 

Die Lösung ist dabei ganz einfach: Man muss die Anzahl der inotify-Handles pro User erhöhen. Das kann man temporär machen, in dem man manuell mit Root-Rechten einen höheren Wert setzt:

# echo 20000 > /proc/sys/fs/inotify/max_user_watches

Stellt man dann fest, dass dadurch das Problem behoben wird, so kann man dies auf permanent und bootfest setzen.

Dazu erzeugt man die Datei:

/etc/sysctl.d/40-max-user-watches.conf

mit folgendem Inhalt:

# change from original default of 8192
# https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers
fs.inotify.max_user_watches=524288

und bootet neu. Danach sollte die Dropbox wieder flüssig funktionieren.

(Aus: https://bbs.archlinux.org/viewtopic.php?id=235557)

Kubuntu 20.04: Probleme mit Handbrake und DVDs

Falls man nach einem Update oder Upgrade Probleme hat, Backups seiner eigenen, legal gekauften DVDs zu erstellen, so kann das an einer fehlenden oder fehlerhaften libdvdcss liegen. Die einfachste Möglichkeit, dies zu beheben, ist die Programme neu zu installieren und die libdvdcss neu zu erzeugen:

sudo apt remove       libdvd-pkg  handbrake-cli  vlc  handbrake
sudo apt install      libdvd-pkg  handbrake-cli  vlc  handbrake
sudo dpkg-reconfigure libdvd-pkg

Kubuntu 20.04: Einrichten von OpenVPN als User

Per Default wird eine frisch importierte OpenVPN-Verbindung für „alle Benutzer“ eingerichtet und fragt daher nach einem Admin-Passwort. Im Firmenumfeld möchte man aber eher Geräte herausgeben, auf denen die Nutzer keine Admin-Rechte haben. Daher muss man dafür sorgen, dass auch ein Normaluser eine VPN-Verbindung konfigurieren kann. Auch hier steht das Polkit im Weg.
 
Man erzeugt daher die Datei (freie Namenswahl, nur die Endung ist wichtig):
 
/var/lib/polkit-1/localauthority/50-local.d/nm-openvpn-connections.pkla
 
mit dem Inhalt:
 
[Setup and manage openvpn connections]
Identity=unix-group:users
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultActive=auth_self
 
Danach kann jeder User seinen eigenen VPN-Tunnel einrichten. Insbesondere sollte man unter Netzwerk -> [Verbindungs-Name]-> „Allgemeine Einstellungen“ den Schalter „Alle Benutzer dürfen sich mit diesem Netzwerk verbinden“ auf „Aus“ stellen.

Kubuntu 20.04: Eigenes Passwort ändern ohne Admin-Rechte

Unter Kubuntu 20.04 verhindert der PolicyKit1-KDE-Agent, dass man als Nicht-Admin-User sein eigenes Passwort ändern kann, indem er zu Verifikation nach einem Admin-Passwort fragt.
Dies kann man mit einer lokalen Policy leicht ändern:
Zunächst erzeugt man eine gemeinsame Gruppe für alle Normal-User, die ihr Passwort ändern können sollen (oder fügt sie zur lokal schon vorhandenen Gruppe „users“ hinzu). Dann legt man folgende Datei an (der Name ist egal, nur die Endung ist wichtig):
 
/var/lib/polkit-1/localauthority/50-local.d/change-own-passwd.pkla
 
mit dem Inhalt:
 
[Change own password]
Identity=unix-group:users
Action=org.freedesktop.accounts.change-own-password
ResultActive=auth_self
Danach kann jeder User sein eigenes Passwort ändern.
 
Siehe auch:

Konfigurationscheck für Varnish

Varnish ist eine tolle Sache. Wenn man aber komplexere Sachen in VCL schreibt und einen Fehler einbaut, riskiert man, dass der Daemon beim Reload der Konfiguration abschmiert. Was fehlt ist ein Syntax-Checker analog zu „apachectl configtest“.
Man kann sich ein solches Kommando aber leicht zusammen bauen, in dem man Varnish die Konfigurationsdatei temporär kompilieren lässt und sich das Ergebnis anschaut. Funktioniert es, dann gibt varnishd die gesamt Konfiguration aus, im Fehlerfall gibt es eine sinnvolle Fehlermeldung. Da man außerdem einen ordentlichen Return-Code bekommt, kann man sich daraus einen schicken Alias bauen:

$ alias varnish_test='varnishd -C -f /etc/varnish/default.vcl >/dev/null && echo "Syntax OK"'

Damit kann man seine Konfiguration jederzeit auf Fehler überprüfen, ohne den Daemon selbst durchzustarten.

Zimbra-Update von 8.0 nach 8.6 schlägt fehl

Wenn man versucht, ein Zimbra-System (GA) von 8.0.x auf 8.6.x zu aktualisieren, wird man danach mit einem nicht mehr startenden System da stehen. Die Fehlermeldungen sagen aus, dass sowohl der LDAP-Server als auch die MySQL-Datenbank nicht mehr starten.

Der Grund dafür ist, dass sich in dem zugegebenermaßen großen Upgrade-Sprung einige Pfade ändern und der Ldap-Index nicht korrekt aktualisiert wird und daher der Upgrade-Prozess mittendrin abbricht.

Bevor man jetzt jedoch wild Dateien löscht oder Backups zurück spielt: der Fix ist vergleichsweise einfach. Zunächst muss man den Ldap-Index von Hand reparieren. Dazu ruft man den Befehl

$ /opt/zimbra/openldap-2.4.39.2z/sbin/slapindex -F \ /opt/zimbra/data/ldap/config entryDN

auf. Danach kann man das Update-Skript einfach erneut starten und das System fährt sauber hoch.

(Siehe auch: http://brylov.info/2013/03/zimbra-8-0-2-8-0-3-update-failure)

OpenFire ist toll, aber die REST-API buggy

Wer das REST-API-Plugin benutzen möchte, der sollte zur Kommunikation auf jeden Fall XML nehmen. Ich persönlich würde zwar auch hier lieber auf JSON setzen (was offiziell auch unterstützt wird), aber hier macht OpenFire merkwürdige Vereinfachungen, die beim Type-Matching unweigerlich zu Problemen führen. Z.B. ist der XMPP-Roster definiert als „List of rosterItems“, in GO wäre das also „[]RosterItems“. Das funktioniert auch fast immer problemlos – außer, man hat genau einen Kontakt auf dem Roster. Dann vereinfacht openFire das eigenmächtig von einer List zu einem einzelnen Item, was sofort beim UnMarshal knallt. Mit XML macht er alles richtig.

Migration von Mac OS X Server mit iChat zu Openfire

Wer die Kontaktlisten (Roster) der Nutzer von Apples iChat-Server nach Openfire übertragen möchte, findet hier ein möglicherweise nützliches Programm. Achtung: Dieses Programm bitte nur dann benutzen, wenn eine externe Datenquelle für das Usermanagement genutzt wird (z.B. ein Active Directory) und User- und Group-Settings daher auf „read-only“ gesetzt sind! Ansonsten werden unter Umständen andere Userdaten wie z.B. das Passwort überschrieben.

Mac OS X Server bringt von Haus aus einen internen Chat-Dienst mit, der auf dem bekannten „jabberd“ beruht und das XMPP-Protokoll benutzt. Damit bietet er die Möglichkeit, mit einer relativ breiten Palette von Clients auf allen Betriebssystemen an diesem Chat teilzunehmen, nicht nur mit dem iChat-Client, bzw. in der neuesten Version dem Programm „Nachrichten“. Leider ist die Administration des Dienstes mit dem Server-Admin-Tool ziemlich rudimentär. Obwohl er sehr gut in die OpenDirectory-Umgebung eingebunden ist, so dass keine wirkliche Userverwaltung anfällt, gibt es nur wenig Möglichkeiten, das Chat-System selbst zu administrieren (Konferenzräume, Policies u.ä.).

„Migration von Mac OS X Server mit iChat zu Openfire“ weiterlesen

„Öffnen mit“-Kontextmenü im Finder bereinigen

Nach dem Update auf Mountain Lion hatte ich das Problem, dass ich im „Öffnen mit“-Menü viele doppelte EInträge hatte. Für die zu einem Dokument passenden Anwendungen führt Mac OS X einen index, den man im Terminal leicht neu erstellen und damit bereinigen kann:

$ cd /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/
$ ./lsregister -kill -domain local -domain system -domain user

Danach gegebenenfalls den Finder neu starten (Option-Rechtsklick auf das Finder-Symbol im Dock), und das Menü ist wieder aufgeräumt.

BoxCryptor unter Ubuntu

Leider gibt es für Linux nicht so einen hübschen kleinen Client, wie für Windows oder Mac OS X. Allerdings ist BoxCryptor intern kompatibel mit EncFS, so dassman auch unter Linux auf verschlüsselte Volumes zugreifen kann.

Unter Ubuntu muss man dazu die Pakete „EncFS“ und „CryptKeeper“ installieren. Um ersteres zu finden, muss man im Software-Center „technische Dateien einblenden“ auswählen. Installiert man das Applet „CryptKeeper“, so wird EncFS autmoatisch mit installiert.

Leider funktioniert CryptKeeper nicht so ohne weiteres mit Unity, weil dieses eine recht eingeschränkte Whitelist für Applets hat. Nicht wundern also, wenn man auf CryptKeeper klickt und nichts passiert. 🙂

Zur Behebung des Problems listet man zunächst die bisherig frei geschalteten Applets auf:

$ gsettings get com.canonical.Unity.Panel systray-whitelist
['JavaEmbeddedFrame', 'Wine', 'Update-notifier']

Diese Liste nimmt man nun, erweitert sie um CryptKeeper und setzt sie dann als neue Whitelist:

$ gsettings set com.canonical.Unity.Panel systray-whitelist\
 "['JavaEmbeddedFrame', 'Wine', 'Update-notifier',\
 'Cryptkeeper']"

Danach kann man CryptKeeper ganz normal starten und findet ihn oben in der Leiste wieder. Wer mag, kann noch ein Startobjekt dafür erzeugen.

(aus: http://www.datenteiler.de/sicher-in-die-wolke-mit-encfs/)