vlc als snap package = untauglich

VideoLanClient wird wie eine steigende Anzahl weiterer SW Pakete auf Ubuntu standardmäßig als snap package installiert.

Von Vorteil ist natürlich die laufenden SW Aktualisierungen, da das vlc snap package in sich geschlossen ist (self contained) und die typischen Abhängigkeiten mitbringt. Gerade im Video Playback Bereich kann dies, bedingt durch unzählige Codecs, von Vorteil sein.

Umso enttäuschender ist das Verhalten des snap packages, wenn man versucht ein Video aus einem NFS share zu starten, was VLC mit einer Fehlermeldung quittiert.

Der Grund dafür ist das Rechtemodell der snaps und das self contained Modell, das dazu führt, dass die Applikation wie in einer chroot Umgebung nicht das eigentliche root filesystem des Rechners sehen kann.

Zwar können sich snap packages via connections allerhand Zusatzrechte besorgen, z.B.

  • home – erlaubt Zugriff unterhalb von /home
  • removable-media – erlaubt Zugriff unterhalb von /media

..ein Zugriff auf /mnt oder /net oder gar wahlfreier Zugriff auf einen Order im eigentlich root filesystem ist nicht vorhergesehen.
Dies gilt für alle snaps, die nicht im sog. classic mode verfügbar sind.

Wichtig hierbei ist die Angabe des confinement Parameters des snap packages, was man mit folgendem Befehl untersuchen kann:

snap info vlc --verbose

Falls das confinement auf strict gesetzt ist, können nur die durch das package gesetzten connections benutzt werden.
Falls devmode auf true gesetzt wird – eine Operation die durch den Benutzer möglich ist – können zwar alle connections durch diesen gesetzt werden, was aber für den NFS Zugriff nichts bringt, da eine solche connection nicht vorgesehen ist.
Einzige Abhilfe ist ein snap package mit einem confinement, welches auf classic gesetzt wurde um die connections komplett zu umgehen und einen Zugriff analog der normalen (.deb) packages zu erlauben. Das snap package atom macht genau dies.

Hintergrundinformationen zu diesem Thema findet man auf:
https://tutorials.ubuntu.com/tutorial/advanced-snap-usage#3
https://snapcraft.io/docs/snap-confinement

lifetime von kerberos tickets

Manchmal könnte es passieren, das bspw. der NFSv4 Zugriff nicht mehr klappt, da das authorisierende kerberos ticket nicht mehr gültig ist. Mittels dem Kommando

klist

würde man dann eine Expiration erkennen.

Die grundsätzliche maximale Lebensdauer, sowie die maximale Zeit, in der der Client eine Erneuerung selbstständig durchführen kann, ist serverseitig in der Datei /etc/krb5kdc/kdc.conf festgelegt.

max_life = 1d
max_renewable_life = 14d 0h 0m 0s

wäre ein Beispiel, wobei der zweite Einträg extra die möglichen syntaktischen Möglichkeiten darstellt.

lifetime von kerberos tickets weiterlesen

unliebsame Überraschungen beim NFS Export

Wenn im heimischen LAN IPv4 und IPv6 zum Einsatz kommt, müssen Dienste auch beide Verbindungsarten unterstützen. Gerade bei einem NFS Server wird traditionell in der Datei

/etc/exports

gerne ein IPv4 Subnetz bei den erlaubten Hostzugriffen angegeben. Dies führt aber dazu, dass host-Anfragen mittels IPv6 Verbindungen dann abgelehnt werden, obwohl die IPv4 Adresse des anfragenden hosts für einen Zugriff freigeben wäre. Abhilfe schafft da die Angabe von domain-Namen. Dies wiederum bedingt aber einen funktionierenden DNS der sowohl IPv4 als auch IPv6 Adressen – auch reverse – auflösen kann. Im Falle einer kerberos Sicherung von NFSv4 muss dies aber eh der Fall sein.

rsync zu microSDXC card

Beim Kopieren von Mediendateien vom NAS zu einer microSDXC Karte für den Einsatz auf dem Mobiltelefon, gab es wieder exakt das gleiche Problem, wie ich schon vor über 8 Jahren auf folgendem Blogpost geschrieben hatte:

rsync Problem UTF8 (World vs. Apple)

Was mir aber bis vor kurzem nicht klar war, ist die Tatsache, dass die Normalisierungsprobleme auch auf einem Dateisystem mit UTF-16 Dateinamenkodierung auftritt.

Die microSDXC Karte ist nämlich mit dem moderneren Windows Dateisystem exFAT formatiert, das wiederum UTF-16 für die Kodierung von Filenamen benutzt. Daher auch hier der dringende Rat:

Eine Synchronisierung der Dateien von einem macOS Betriebssystem ist nicht empfehlenswert, schon gar nicht in heterogenen Umgebungen.

Wenn man übrigens nicht sicher ist, welches Filesystem auf einer Karte verwendet wird, dann empfiehlt sich folgendes Kommando:
lsblk -no name,fstype

Google Earth Pro unter Linux mit falschen Ortsanflug

Die meisten deutschsprachigen Benutzer von Google Earth (Pro), welche das Programm unter Linux betreiben, dürften diesen Fehler kennen, da er auch schon seit vielen Jahren bekannt ist.

Man gibt im Suchfeld eine Adresse an und der Anflug an diese landet irgendwo anders. Da Google kein Interesse hat den Fehler zu beseitigen, muss mal wieder ein Workaround her. Dieser besteht darin, gewisse Regionaleinstellungen nicht auf DE einzustellen, sondern auf US. (frei nach H. Simpson: „USA USA USA„)

LC_NUMERIC=en_US.UTF-8

bringt die Abhilfe. Allerdings ist ein globales Setzen dieser Variable nicht empfehlenswert, da man sich sonst Probleme einhandelt wenn gleichzeitig die restlichen Regionaleinstellungen (LC_xxxx) auf DE verbleiben.

Diese Einstellung soll nur für dieses Programm gelten und am elegantesten (aus Anwendersicht) löst man dies in dem man die .desktop Datei manipuliert. Diese befindet sich beispielsweise auf meinem Ubuntu 16.04 System unter:

/usr/share/applications/google-earth-pro.desktop

und vollzieht dort folgende Änderung:

Exec=env LC_NUMERIC=en_US.UTF8 /opt/google/earth/pro/google-earth-pro %f

Nachteil dieser Lösung ist, dass bei jedem Paketupdate von Google Earth diese Änderung erneut durchgeführt werden muss. Dennoch meines Erachtens eine bessere Lösung als manipulierte Startskripte, die man eventuell beim Starten nach längerer Nichtbenutzung gar nicht mehr anwendet.

Das Ubuntu Wiki schreibt auch zu diesem Thema unter Orte werden falsch angeflogen.

CardDAV – 6 Jahre später

Auch am Beispiel CardDAV sieht man, dass der Lifecycle von vielen Produkten – auch Software – eher zu- als abnimmt. Die mittlerweile erreichte Komplexität lässt schnelle Lebenszyklen eher nicht mehr zu, schon gar nicht, wenn es sich um kollaborative Werkzeuge handelt die nur auf einem Standard basieren und dementsprechend mannigfaltig implementiert werden.

Heute wird der aktuelle CardDAV Stand anhand von 3 Tools beleuchtet, die einige Überraschungen bieten.

Seit meinem Umstieg von iOS auf Android bei den mobilen Plattformen suchte ich dort nach einer guten CalDAV/CardDAV Implementation, da es auf Android (und übrigens auch nicht auf Samsung Adaptionen) keine Referenzimplementation gibt.

Fündig – und mittlerweile auch glücklich – wurde ich mit DavDroid von Bitfire , das nur eine DAV Datenschnittstelle bereitstellt, die beliebige Kalender oder Kontakttools bedient.

Mittlerweile glücklich, da das Tool anfänglich bei mir auch nicht fehlerfrei arbeitete. Die Synchronisierung hing sich teilweise auf, was aber schon lange her ist. Zudem wurde ein Feature eingebaut, welches die Synchronisation auf ein bestimmtes Netzwerk (WLAN SSID) beschränkt. Dann gab es lange einen Fehler mit doppelten Einträgen, was allerdings spätestens mit Version 1.9.1 gelöst wurde. Der derzeitige Stand ist 1.10 und in all den Versionen seit 1.0 floßen eine Menge Bugfixes und Verbesserungen in akzeptabler Zeit ein.

Auf den Linux Plattformen kommt benötigt Thunderbird ein Plugin für CardDAV – was bisher der sog. SOGO-Connector darstellte.  Prinzipiell funktionierte er ordentlich, konnte aber während einer laufenden Thunderbird Instanz nicht resynchronisieren. Außerdem ist in dieser Konstellation auch das native Thunderbird Adressbuch, welches durch den Connector beliefert wird nicht ideal, da es mit dem CardDAV Standard RFC6352 nicht unbedingt harmoniert.

Glücklicherweise kommt mit dem CardBook Plugin für Thunderbird eine tolle neue Alternative ins Spiel, die parallel zum nativen Adressbuch ein zweites Adressbuch – voll auf CardDAV Basis – anbietet. Dieses Plugin lässt kaum Wünsche offen und läuft sehr stabil…

..so stabil, dass nun Thunderbird mit dem CardBook Plugin auch auf macOS zum bevorzugten Setup wird, denn das Apple-eigene Adressbuch (Contacts) ist schlechter als je zuvor.

Apple hat es tatsächlich geschafft die CardDAV Funktionalität seines Adressbuchs völlig zu ruinieren. Es ist seit Version 10.10 nicht mehr möglich mehr als ein Adressbuch von einem Server abzurufen. Desweiteren ist die eigenen Benennung fehlerhaft implementiert und die Synchronisation bricht immer wieder ab ohne einen konkreten Fehler zu bennenen. Das hinterlässt ein unvollständiges Adressbuch mit fehlenden Einträgen – an eine Synchronisation in Serverrichtung ist daher gar nicht mehr zu denken, zumal obendrein das Programm seit 10.12 auch gerne mal abstürzt.

Wer dennoch einen Blick in das schwarze Loch werfen will, dem sei folgende Links als Einstieg angeraten (es gibt viel viel mehr davon):

  • https://discussions.apple.com/thread/6815546
  • https://userforum.mailbox.org/topic/kontakte-sync-mit-carddav-und-el-capitan-macos
  • https://www.mactechnews.de/forum/discussion/carddav-sync-voellig-kaputt-nach-macOS-upgrade-330937.html

Fazit: Es geht – wenn auch langsam – voran. CardDAV hat sich zu einer festen Größe entwickelt, die man auch abseits von Google oder anderen Cloud-Anbietern benutzen kann.

Kerberos KDC replication mit systemd units

Um eine automatische Replikation des primären Kerberos KDC mit dem sekundären zu erzielen, müssen auf beiden Rechner systemd service units eingerichtet werden. Zumindest unter Ubuntu 16.04 LTS sind diese in keinster Weise vorhanden, weswegen hier auf die Einrichtung eingangen wird.

Service Unit auf dem sekundären (slave) KDC

Auf dem slave KDC muss eigentlich lediglich der kpropd service als stand-alone Instanz gestartet werden. Ursprünglich war der kpropd service auf den (x)inetd master-daemon ausgelegt. Da dieser mittlerweile fast obsolet wurde benutzen wir den stand-alone service, der ab Version 1.11 des kpropd automatisch erkannt wird.
Für das automatische Starten während des Boot-Vorgangs benötigt man mittlerweile ein systemd service unit file, das in unserem Fall folgendermaßen aussieht.


[Unit]
Description=Krb5-KDC replication service
Requires=krb5-kdc.service
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/sbin/kpropd
Type=forking
ReadOnlyDirectories=/
ReadWriteDirectories=/var/tmp /tmp /var/lib/krb5kdc /var/run /run /var/log


[Install]
WantedBy=multi-user.target

Ein Verifikation mit dem systemd hauseigenen Tool sollte keine syntaktischen Fehler ergeben.

systemd-analyze verify kpropd.service

Auf dem Weg zu der hier abgebildeten service unit, gab es zwei große Stolpersteine, welche syntaktisch aber einwandfrei waren, weswegen das verificiation Tool hierbei keine Hilfestellung leisten konnte.
Der erste war die Direktive
Type=forking
Nur damit kann der systemd erkennen, dass es ein typischer geforkter UNIX daemon ist, der nicht sofort als dead (vom Startprozess her) markiert wird. Die Alternative wäre das Setzen des -d (debug) flags, der den Startprozess permanent als ein foreground Prozess behält.
Der zweite, noch größere Stolperstein, kommt von den unterschiedlichen After/Wants Direktiven. In den meisten Tutorials über systemd wird immer auf
After=network.target
verwiesen, was in diesem Fall zu einem gescheiterten Start von kpropd führt, beispielhaft ausgeführt an folgendem syslog Eintrag.


Mar 18 21:57:30 aurora systemd[1]: Started Light Display Manager.
Mar 18 21:57:30 aurora systemd[1]: Started Raise network interfaces.
Mar 18 21:57:30 aurora systemd[1]: Reached target Network.
Mar 18 21:57:30 aurora systemd[1]: Started Unattended Upgrades Shutdown.
Mar 18 21:57:30 aurora systemd[1]: Started Krb5-KDC replication service.
Mar 18 21:57:30 aurora systemd[1]: Started BIND Domain Name Server.
Mar 18 21:57:30 aurora kpropd[1073]: ready
Mar 18 21:57:30 aurora systemd[1]: Reached target Host and Network Name Lookups.
Mar 18 21:57:30 aurora kpropd[1073]: getaddrinfo: Der Name oder der Dienst ist nicht bekannt
Mar 18 21:57:30 aurora systemd[1]: Starting OpenBSD Secure Shell server...
Mar 18 21:57:30 aurora systemd[1]: kpropd.service: Main process exited, code=exited, status=1/FAILURE
Mar 18 21:57:30 aurora systemd[1]: kpropd.service: Unit entered failed state.
Mar 18 21:57:30 aurora systemd[1]: kpropd.service: Failed with result 'exit-code'.

Das Netzwerk ist „irgendwie“ schon vorhanden, aber es scheint der resolver Mechanismus (getaddrinfo) noch nicht richtig zu Arbeiten.
Die Lösung hält dieser systemd Eintrag von freedesktop.org bereit. Entscheidend ist die Änderung in:
After=network-online.target
Pikanterweise gab es unter Ubuntu aber auch hier wohl einige Zeit eine Unstimmigkeit, bzgl. des resolver Mechanismus unter diesem (passiven) Target, wie man hier nachlesen kann.
Erwähnenswert ist noch, dass man den Dienst theoretisch auch ohne root-Rechte starten könnte, wenn man das Capability Feature von Linux nutzt. Dazu setzt man im [Service] Block des unit files folgende Direktive – in diesem Fall handelt es sich im das Portbinding, welches beim kpropd übrigens auf TCP-Port 754 stattfindet.

CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Service Unit auf dem primären (master) KDC

Auf dem primary KDC muss kontinuierlich ein aktueller Dump dem secondary geschickt werden. Das erzeugen des dumps sowie der transmit Befehl sind in folgenden script (kprop.sh) verpackt:

#!/bin/bash

# starts the krb5kdc propagation to the secondary KDC
# location of dumpfile and secondary KDC are taken from the
# following variables

dumpfile=/var/lib/krb5kdc/kdb_repldata
kdcslave=aurora

kdb5_util dump $dumpfile
if [ $? == 0 ]; then
kprop -f $dumpfile $kdcslave
fi


exit $?

Um diese Aktion frequentiert aufzurufen, kann man natürlich die globale crontab bemühen. Es geht aber auch mit kleinen Vorteilen im systemd Ökosystem. Dazu braucht man allerdings dann 2 files.
Wieder ein systemd service file (kprop.service)

[Unit]
Description=kprop KDC propagation


[Service]
Type=simple
ExecStart=/root/bin/kprop.sh

und ein systemd timer file (kprop.timer)…

[Unit]
Description=Run kprop daily

[Timer]
OnCalendar=4:50
Persistent=true


[Install]
WantedBy=timers.target

..welches in unserem File täglich um 04:50 aufgerufen wird.
Beide files landen in /etc/systemd/system. Aber nur das timer file wird via
sudo systemctl enable kprop.timer
aktiviert.
Vorteil dieser Lösung ist, dass man einerseits mit systemctl auch manuell die Synchronisation anstoßen kann, aber auch schnell eine übersichtliche Darstellung der Logeinträge bekommt, welches man mit
journalctl -u kprop
auf dem primary KDC, bzw.
journalctl -u kpropd
auf dem secondary KDC abfrägt.

Key table entry not found while getting initial credentials

Wenn die Kerberos Replizierung mit kprop unter Linux (Ubuntu) folgendes Problem aufwirft

kprop: Key table entry not found while getting initial credentials

dann lohnt es sich ein Blick in die /etc/hosts Datei zu werfen. Falls dort der aktuelle hostname – welcher auch im service principal host/<HOSTNAME>@REALM der/etc/krb5.keytab verwendet wird – eingetragen ist und dort auch noch über localhost aufgelöst wird, dann tritt o.g. Fehler auf. In diesem Fall in der /etc/hosts den Eintrag mit dem hostname entfernen.

Das o.g. Problem ist übrigens nicht gleichzusetzen mit einer fehlenden /etc/krb5.keytab Datei. In diesem Fall würde folgender Fehler erscheinen:
kprop: Client not found in Kerberos database while getting initial credentials

Ubuntu 16.04 workspace switching via shortcuts funktioniert nicht mehr

Von einem auf den anderen Tag funktionierten die Shortcuts

STRG + ALT + Pfeiltasten

zum Umschalten der Workspaces auf Ubuntu 16.04 nicht mehr. Der Grund ist mir nicht klar – beim Guest-Account funktionierte es auch weiterhin.
Abhilfe schafft ein Workaround:

sudo apt install compizconfig-settings-manager

installiert den Compiz Config Settings Manager. Diesen ruft man nach der Installation mit dem Kommando

ccsm

auf und aktiviert in der GUI die Option Desktop Wall in der Sektion Schreibtisch.

Die Quelle dieses Tipps kommt wie so oft von askubuntu

There is also (at least) this Ubuntu Launchpad Bug report
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1627472