instruyete – Seite 4 – man lernt nie aus

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.

Google weiß es besser

Vor kurzem stieg in in Deutschland in einen TGV und loggte mich mit dem Laptop in das Zug-WLAN ein.

Kaum öffnete ich den Mail-Client schon haute mir Google die Warnmeldungen entgegen.

Was war passiert? Trotz deaktiviertem Standortverlauf in meinem Google-Account wurde der aktuelle Standort meines Handys verwendet um ein Login – angeblich aus Paris – zu verhindern.

Es war natürlich der Zug der französischen SNCF, dessen Routing wohl über ein IP-Knoten in Paris führt, woher wusste aber Google, dass ich mich zu der Zeit in Süddeutschland befand? Offensichtlich wird die Standortbestimmung des Mobiltelefones auch dazu benutzt um auf einem Laptop ein Zugriff eines „falsches Standortes“ zu unterbinden.

Obwohl ich bei den sofort ankommenden Warn-EMails angegeben habe, dass ich diesen Zugriff unternommen hatte, konnte ich mit dem o.g. Mail-Client keine Verbindung mehr mit dem Google-IMAP Server herstellen. Zudem ärgert mich diese Standortverwendung! Google erweckt mit seinen zahllosen Einstellmöglichkeiten, dass man Herr seiner Daten ist, aber wenn man nicht völlig ohne Standortbestimmung beim Handy operieren will, muss man implizit allen möglichen Google-Standortdiensten zustimmen.

Auch denjeniegen, die besser über einen Bescheid wissen als man selber. HAL 9000 lässt grüßen.

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.

IPv6 ULA Adressen auf Dual-Boot Rechnern

Der Verbrauch aller verfügbaren IPv4 Adressen zwingt allmählich die ISPs (Internet Service Provider) den Kunden nicht mehr exklusiv eine IPv4 Adresse – weder dauerhaft noch temporär – zur Verfügung zu stellen. Stattdessen wird der begrenzte IPv4 Adressraum mit NAT (Network Adress Translation) auf ISP-Level erweitert – das sog. Carrier Grade NAT.
Für den Kunden bedeutet dies, dass er nicht mehr über eine stabile IPv4 Adresse verfügt, sondern nur noch über eine stabile – wenn auch sich temporär ändernde – IPv6 Adresse. Der Zugriff auf IPv4-only Webdienste erfolgt üblicherweise mit DS-Lite Tunnels in denen IPv4 Adressen in IPv6 Tunnel bis zum Provider gelangen, der dann mittels Carrier Grade NAT dem Paket eine momentan verfügbare öffentliche IPv4 Adresse zuweist und eine Zuordnungstabelle führt, um den Response dem ursprünglichen Anfrager zurückzuleiten.

Auf Kundenseite impliziert dieses Verfahren den Einsatz von IPv6 – mindestens auf Router-Level. Wobei durch Router-Propagation auch jeder Client hinter dem Router eine öffentliche IPv6 Adresse erhalten kann und performante IPv6 Verbindungen – ohne NAT und Zuordnungstabellen – aufbauen kann.
Die Entscheidung, ob der Zugriff auf eine URL mit IPv4 oder IPv6 erfolgt, trifft das Betriebssystem, vorausgesetzt der hostname lässt sich durch den verantwortlichen Nameserver in eine IPv4 und IPv6 Adresse auflösen. Da dies aber immer häufiger der Fall ist, steigen auch die IPv6 Anfragen durch alle Netzwerke….

…was der Grund für mich war auch im privaten Netzwerk durch den lokalen Nameserver alle hosts auf IPv6 aufzulösen. Da die GUA (Global Unicast Address) sich aber täglich ändert und ich zudem im privaten Netzwerk auch nur private (also nicht geroutete) Adressen verwenden will, trage ich dort die stabilen ULAs (Unique Local Address) ein, die eben nicht über eine Gateway Grenze geroutet werden.
Diese Adressen bestehen aus einem standardisierten 8bit Prefix (fd00::/8), gefolgt von einer Global+Subnet ID, die im Normalfall im Router eingestellt wird und durch diesen propagiert (Router Advertisement) wird. Die folgende Grafik zeigt den Aufbau der GLAs und ULAs

Die niederwertigen 64bits werden lokal durch EUI-64 (Extended Unique Identifier) eingestellt – auch bekannt als Interface ID. Dies passiert überlicherweise mittels SLAAC (Stateless Address Autoconfiguration). Die EUI-64 besteht in der einfachsten Form aus einer MAC-Adresse (48bit) erweitert durch ein mittiges Einsetzen von 0xfffe. Dadurch entstehen permanente IPv6 Adressen – im Falle der ULA sogar dauerhaft permanent, da sich der Prefix – bestehend aus Global ID + Subnet ID – nicht ändert. Flankiert werden diese permanenten Adressen durch die Privacy Extensions for Stateless Address Autoconfiguration in IPv6 gemäß RFC4941. Diese erzeugen einen zufälligen Adressbestandteil auf der Interface ID und die damit gewonnen zusätzlichen temporären IPv6 Adressen können für ausgehende Verbindungen genutzt werden um eine vergrößerte Privatsphäre zu erhalten.

Bis zu diesem Punkt ist aus Administrationssicht alles in Ordnung. Schwierig wurde es mit der Einführung des RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). Dieser sieht vor, die stabilen IPv6 Adressen im Bereich der EUI-64 Interface ID nicht mehr aufgrund der MAC ID zu generieren. An sich wäre das nicht schlimm, da die Adressen ja immer noch stabil sind und daher in eine DNS Konfiguration eingetragen werden können. Schwierig wird es aber wenn eine IPv6 Adresse eines Client-Netzwerkports auf einem Dual-Boot Rechner plötzlich anders lautet, da bspw. Linux und macOS den RFC7217 anwenden und auf unterschiedliche IPv6 Adressen kommen. Das lässt sich in einer DNS Konfiguration nicht mehr abbilden, es sei denn man vergibt auf dem Dual-Boot Rechner unterschiedliche Hostnamen (und IPv4 Adressen), wobei dann auf OSI-Level 2 eine ARP Adresse auf unterschiedliche IPv6 Adressen verzweigt, was ev. bei einem Switch zu Problemen führt.

Abhilfe schafft hier, auf Betriebssystemebene die Anwendung der RFC7217 zu verhindern, was bei genauerer Betrachtung die Privatsphäre nicht wesentlich beinträchtigt, da die temporären Adressen gemäß RFC4941 immer noch existieren und darüber hinaus der Footprint eines Anwenders durch viele andere Erkennungsmerkmale gewonnen werden kann (oder bspw. durch uBlock Origin verhindert werden kann).
Dies Abschaltung der RFC7217 Implementationen wird mit folgenden Kommandos erreicht (Quelle: https://www.fz-juelich.de/SharedDocs/Downloads/IAS/JSC/DE/tki/tki-0412.pdf?__blob=publicationFile)

auf Linux (ohne Network Manager, bspw. Ubuntu 14.04)
in /etc/sysctl.conf folgendes eintragen (falls eth0 tatsächlich das richtige interface ist)
net.ipv6.conf.eth0.use_tempaddr = 0
auf Linux (mit Network Manager, bspw. Ubuntu 16.04)
user@host> nmcli conn show
(zeigt die verfügbaren Netzwerknamen an – hier den richtigen heraussuchen, bspw. ‚Wired connection 1‘)
user@host> nmcli conn edit 'Wired connection 1' nmcli> save nmcli> set ipv6.addr-gen-mode eui64 nmcli> set ipv6.ip6-privacy 0 nmcli> save nmcli> quit
auf macOS:
$ echo net.inet6.send.opmode=0 >> /etc/sysctl.conf $ reboot

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

hidden files (macOS Finder related) on NFS shares

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?

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

NFS auf macOS – typisch Apple

Die Firma Apple ist schlicht und einfach arrogant. Objektiver kann man es nicht ausdrücken.

Jede paar Monate werden Schnittstellen, GUIs und Konfigurationseinstellungen geändert. Alles ohne direkten Nutzen für den Benutzer. Es passt halt ins Konzept der Apple Sekte und wer nicht mindestens die Hälfte seiner privaten Zeit für die phantastischen Neuigkeiten des Apple Universums investiert ist deren nicht würdig.

Eines von unzähligen Beispielen ist der Support für das NFS Protokoll. Damit NFS Client-seitig auf macOS Sierra überhaupt nutzbar ist, müssen Mount Optionen gesetzt werden, was früher mit der GUI NFS mounts in der Applikation Disk Utility möglich war.

Da Apple sein OS allerdings alle paar Monate komplett umkrempelt um in der Design Abteilung keine Langeweile aufkommen zu lassen, gibt es diese Funktionalität nicht mehr. Auf GUI Ebene wählt man nun die GUI Mit Server verbinden in der Applikation Finder an. Ganz easy, ohne lästige Optionen und damit…

…ohne brauchbare Funktionalität. Denn schon seit Jahren ist bekannt, dass Verzeichnisse und Dateien eines NFS mounts im Finder nur dann performant angezeigt werden, wenn die Mount-Option locallocks gesetzt ist.
Um dies auf macOS Sierra zu erreichen, empfielt sich folgendes Vorgehen:

1. in /etc/auto_master den Eintrag /net in der 3.Spalte mit der Option nolocks zu versehen, bspw.
/net -hosts -nosuid,nolocks,locallocks
ACHTUNG: Die Optionen hidefromfinder und nobrowse dürfen nicht gesetzt sein.
2. in /etc/autofs.conf den Eintrag AUTOMOUNTD_MNTOPTS ebenso mit den Optionen nolocks,locallocks versehen.
3. Im Finder erscheint dann unter dem linksseitigen Hostnamen nun auch der Folder net, der allerdings bis dato leer sein dürfte.
4. Dann muss man im Terminal den NFS Share explizit einmal anwählen, bspw. mit
cd /net//
5. Danach erscheint der NFS Share auch im Finder unter net. Diese Gelegenheit benützt man um den Folder auf die linksseitige Favoritenleiste zu legen.

Und das war’s dann….noch nicht ganz. Um die Kompatibilität zu einem Linux-basierendem NFS Server zu gewährleisten (siehe hier und hier) sollte weiterhin Clientseitig auf macOS die mount_nfs Option nfc gesetzt sein, zusammen mit intr um eine Abbruchsignal bei hängendem NFS Server wirksam werden zu lassen, die Datei /etc/nfs.conf würde also folgendermaßen aussehen:
# # nfs.conf: the NFS configuration file # nfs.client.mount.options = intr,nfc

Falls man sich im laufenden Betrieb nicht mehr sicher ist, welche NFS Mount Optionen eigentlich gesetzt sind, befragt man den Client am besten mit
nfsstat -m
Dann sollte dem NFS Client Glück nichts mehr im Wege stehen, oder etwa doch…?

Das bessere Produkt aus dem Duden-Verlag

Deutsch Sprach – schwer Sprach… und weil das auch für mich gilt, hätte ich doch gerne die Unterstützung von den heimischen Erzeugnissen des Duden Verlags.

Jahrelang setzte ich dabei auf die SW Duden-Bibliothek in der Version 5.x – Wer sie kennt, kennt auch deren Macken und leider auch die Behäbigkeit mit der diese beseitigt oder auch gerne ignoriert wurden.
Wobei das mit der Ignoranz dann am Ende damit gelöst wurde, indem man die SW Version 5.x als obsolet deklarierte und die Version 6.x als (besseren) Nachfolger etablierte.

WarumDenn.net würde man denken – aber die vom Duden Verlag engagierte SW Truppe schickt einen vom Regen in die Traufe. Das kleinere Übel – man war es nie anders gewohnt – war und ist, dass man die SW auf Linux (zumindest Ubuntu 16.04. 64bit) nicht ordnungsgemäß zum Laufen bringt. Zuerst klappt der Start nicht, da eine gstreamer Komponente fehlt, die allerdings bei der Packetinstallation hätte automatisch installiert werden müssen, sofern die Paketabhängigkeiten gestimmt hätten. Nach Überspringen dieser Hürde startet das Programm endlich, nur um sofort mit einer Fehlermeldung zu terminieren, dass „wichtige Komponenten fehlen„. Welche das sind bleibt das Geheimnis der Softwerker – man kann nicht sagen dass die SW nicht sicher sei – sie ist ziemlich sicher: vor Benutzung.
Wie auch immer, was fehlt war das Vorhandsein des privaten Konfigurationsordners ~/.dudenbibliothek6 mit samt der Datei dudenbib.nbof. Geholfen hat mir dabei der Support – immerhin…. wenn auch mit teilweise hanebüchenen Aussagen.

Dieses Vorgeplänkel tritt aber sofort in den Schatten, wenn man zum ersten Mal startet und die bisherigen „Bücher“ der alten Version importieren möchte, denn nicht nur das Oxford Dictionary aus einem Fremdverlag wird nicht mehr akzeptiert (darauf war ich vorbereitet), sondern auch alle Produkte aus dem Duden Verlag vor 2007. Damit war jeglicher Content entwertet – geplante Obsoleszenz also. Die Frage an dieser Stelle wäre – kann man denn überhaupt mit einem Synonymwörterbuch, welches 10 Jahre alt ist, noch leben? Antwort: VERDAMMT, JA!
An dieser Stelle möchte ich der vollständigkeit halber erwähnen, dass man auch mit der alten Version 5.x weiterleben kann (war in diesem Artikel die Quintessenz), wenn man nicht gerade unter Linux arbeitet und/oder mit den Unzulänglichkeiten dieser Version noch Leben kann.

Trotzdem prozessierte mein Gehirn noch den Gedankengang zu Ende, die neue SW mit neuen (fast gleichem) Duden Büchern wieder zu füllen, kam aber in der Ergebnisauswertung zum Schluß, dass der Homer-Simpsons-Faktor zur groß wäre. Denn um sich auszumalen, dass der Content bei der nächsten Major Revision wieder entwertet wird und die SW sowieso kompletter Crap ist und ziemlich sicher bei der nächstes OS-Update Runde nicht mehr (ordnungsgemäß) funktioniert ist seeeeehr groß.

Und……es gibt eine Alternative: Das Duden Universalwörterbuch (aggregiert zumindest teilweise mehrere Duden Einzelbände) gibt es als pdf Datei. Und wer ein mächtiges PDF Tool besitzt (z.B. PDFStudio, MasterPDFEditor…) hat dann eine Kombination auf sehr gutem Inhalt (Duden) und sehr guter SW.
In all den Jahren hat der Duden Verlag immer nur auf seinen Inhalt geschaut, der konstant gute Qualität bietet, bei seiner SW allerdings fast nur Schrott produziert oder produzieren lassen. Ein weiteres Beispiel wäre die Duden Rechtschreibkorrektur. Wie nötig wäre ein solches Programm für Libre-/OpenOffice und wie gut war der Inhalt der alten Versionen. Es wurde aber aufgegeben – aus gutem Grund, sie SW war und passte sich auch nie der laufenden Entwicklung der Programme an (stand wohl nicht im Work-Package drin).
Schade Duden. Inhaltlich Top – SW Flop! Ob das auf Dauer gut geht bezweifle ich stark.

Kein Speicherplatz mehr bei Ubuntu 12.04 / 14.04 LTS

Die Long Term Support Varianten von Ubuntu sind angetreten den alljährlichen Distributions-Upgrade Wahnsinn zu beenden – bringen sich selber aber durch einen Bug in Bedrängnis.

Durch Security Updates kommen aber regelmäßig neue Kernel-Builds auf das System. Dabei geht es nicht nur um das Kernel-image Paket, sondern auch um das image-extra Paket welche die Kernelmodule beinhaltet und oftmals auch um die header Pakete, die dann richtig viel Platz benötigen.

Eigentlich sollten Kernel Pakete die durch ein Update obsolet wurden automatisch vom System mit
apt-get autoremove
deinstalliert werden. Durch einen Bug in Ubuntu System vor 15.10 (siehe auch diesen Artikel auf den Thomas Krenn Seiten) funktioniert das nicht, da die betreffenden Pakete fälschlicherweise als manuell installiert gekennzeichnet sind anstatt als automatisch installiert.

Wenigsten hat Ubuntu in Ihrem (deutschsprachigem) Wiki einen Eintrag über das Problem und ein recht einfachen Workaround. Dabei listet ein kryptisch anmutendes sed Kommando alle Kernel Pakete auf, die dann einer Löschung zugeführt wurde.
Zu beachten ist, dass die eine sog. One-Shot Lösung ist. Das Problem geht weiter, solange man noch nicht auf bspw. Ubuntu 16.04 LTS upgedatet hat.