alles über das Betriebssystem der Zukunft
Dieser Artikel im heise newsticker spricht mir aus der Seele. An Apple einen Bugreport zu schicken, ist vergeudete Zeit. Selbst wichtige Probleme wie services oder gar sicherheitsrelevante Fehler werden lange ignoriert.
Da bleiben dann Feature Regressions wie das seit mehreren Releases kaputte CardDAV gleich ganz liegen. Der Bug Report 16938876 wird dann spätestens mit Abwicklung der Firma Apple geschlossen.
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:
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.
lsblk -no name,fstypeWenn mal wieder das MacBook zur Apple Reparatur muss – Butterfly Tastatur lässt grüßen – dann gibt man es einfach im Apple Store ab und zwar gleich mit dem Passwort eines admin Users!
Warum?
Weil Apple gerne ein Hilfprogramm installieren möchte und dazu einen admin Account benötigt!
Warum nicht per Startmedium?
Keine Antwort! Apple braucht den admin-account!
Noch übler ist es, dass sein einigen Jahren das macOS Verschlüsselungssytem FileVault2 nicht mehr per User, sondern die ganze Partition verschlüsselt. Daher nützt es nichts, einen dummy admin-account anzulegen, mit der Intention, dass dieser nicht an die verschlüsselten Dateien der anderen (ebenfalls admin user) herankommt.
Der einzige Workaround ist, alle user-bezogenen Daten zu löschen und mittels TimeMachine von einem externen Medium (Server) später wieder herzustellen.
Again: Apple Sucks!
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.
Seit Chrome 58 funktionieren einige https Verbindungen nicht mehr, da der Browser das Zertifikat als ungültig erklärt.
Hintergrund ist RFC2818, der die Namenserkennung des zu sichernden Servers nicht mehr im CN (Common Name) Feld, sondern via DNS Eintrag in Feld SAN (Subject Alternative Name).
Nach einigen Versuchen, hat sich gezeigt, dass das Zertifikatsrequest noch nicht unbedingt die Requested Extension x509v3 Subject Alternative Name haben muss.
Spätestens aber beim Signieren muss es aber in das Zertifikat (public key) eingetragen werden. Dazu schaut man in der OpenSSL Steuerungsdatei
/etc/ssl/openssl.cnf
wohin die Variable
x509_extensions
zeigt. Dabei handelt es sich um eine Sektion die weiter unten mit [ ] eingeschlossen ist. Dort trägt man folgende Zeile ein.
subjectAltName=${ENV::SAN}
Dies erlaubt eine dynamische Zuweisung des DNS Eintrags als Umgebungsvariable, die man bspw. vor der Signierung auf der Kommandozeile setzt.
export SAN=DNS:www.testserver.org
Die Umgebungsvariable ist aber mit der o.g. Konfiguration auch notwendig, da sonst openssl ein extension Fehler wirft.
Abgeleitet wurde diese Konfiguration von dieser Webseite – danke dafür.
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):
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.
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.
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
Zwei Schritte vor – einen zurück. Das beschreibt ungefähr die NFS Unterstützung in macOS.
mit der abermals hier beschriebenen Option:
nfs.client.mount.options = nfc
erzwingt man auf macOS Ebene die Kodierung der Dateinamen als UTF-8 Form C zu interpretieren (machen alle außer Apple so).
Prinzipiell funktioniert das auch, aber der Teufel steckt wie immer im Apfel.
1. Öffnet man eine Form-C relevante Datei, bpsw. mit German-Umlaut „Angebot Sonderwünsche.pdf“ so kann man die Datei auf dem NFS Share auf einem macOS Sierra Client mit Preview öffnen.
2. Leider legt dann Apple Preview (auf deutsch: Vorschau genannt) ein verstecktes File an, in diesem Fall wäre dann eine Datei names „._Angebot Sonderwünsche.pdf“.
3. Sobald diese Datei existiert, kann das eigentliche pdf nicht mehr geöffnet werden, selbst mit Adobe Reader lässt sich die Datei nicht mehr öffnen, obwohl dieser das hidden File gar nicht angelegt hätte.
Die Fehlermeldung selber trägt auch nicht zur Aufklärung bei.
Leider scheint es unter macOS Sierra auch keine Möglichkeit zu geben, das Anlegen solcher Files auf NFS (oder allg. Network Shares) zu verhindern. Apple ist via Bugreport 32837974 informiert – ob’s was bringt?
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