Microsoft Office Update: Windows und Mac Version im Vergleich

Mit dem vor wenigen Tagen veröffentlichten Office Update für Mac werden nach 20 Jahren erstmals wieder alle Plattformen aus einer gemeinsamen Codebasis bedient. Dadurch lassen sich künftig Features, die zuerst in einer Plattform integriert werden, zeitnaher auf anderen Plattformen ausbreiten. Um dies zu bewerkstelligen, besitzt jede Plattform entsprechende Updatemechanismen. Diese unterscheiden sich sich grundsätzlich – so auch bei der Windows und Mac Variante.

Microsoft Office für Windows hält zwei verschiedene Wege für die Installation und Updates parat. Zum einen existiert der Weg über die MSI-basierte Installation. Diese stellte bis Office 2010 die gängige Methode zur Installation von Office dar. Auf diesem Weg werden die Office Updates über Windows Updates eingespielt – also ganz klassisch.
Seit Office 2013 gibt es mit Click-to-Run (Klick-und-Los) eine neue standardmäßige Variante. Hierbei wird die Office Installation auf den Computer gestreamt, sodass die Anwendungen bereits während der Installation genutzt werden können. Dabei wird die Office Installation über App-V virtualisiert und die einzelnen Office Anwendungen in verschiedene Module aufgeteilt. Die Office Updates werden hier über einen eigenen Mechanismus direkt aus Office heraus vorgenommen. Dadurch, dass nur veränderte Module einer Anwendung ausgetauscht werden müssen, ist ein Update in der Click-to-Run Variante deutlich schneller als über die MSI-basierte Installation via Windows Update.

Microsoft Office für Mac nutzt mit Microsoft AutoUpdate (MAU) einen eigenen Mechanismus für Updates. Die Updategröße richtet sich dabei nach dem Alter der zu aktualisierenden Office-Instanz. Liegt diese schon einige Versionen zurück, kommt ein Komplettupgrade zum Tragen, das vom Umfang einer Neuinstallation gleicht. Liegt die Office-Instanz eine oder mehrere, aber noch nicht deutlich mehr Versionen zurück, kann auf Delta-Updates zurückgegriffen werden. Diese enthalten nur die Änderungen für einige wenige zurückliegende Versionen. Sie fällt im Vergleich zum Komplettupgrade deutlich kleiner aus und spart etwa 77 Prozent der Größe ein. Mit der nächsten Microsoft AutoUpdate Version (MAU 4.0, noch nicht veröffentlicht) werden zudem Ultrathin Updates (Binary-based Updates) Einzug halten. Diese sparen nochmals deutlich an Umfang ein: der Unterschied zu einem Delta Update beträgt in einem Beispiel mehr als 90% – sie dürften aber vermutlich nur von der letzten Version aus möglich sein. Wer also öfter aktualisiert, profitiert von kleineren Updategrößen – bislang und auch künftig.

Bleibt festzustellen, dass trotz der gemeinsamen Codebasis weiterhin unterschiedliche Updatemechanismen zum Tragen kommen, die jeweilige Plattformeigenheiten berücksichtigen.

Winfsp & sshfs-win als Dokan & win-sshfs Ersatz

Es existieren verschiedene Möglichkeiten, externe Linux Netzwerklaufwerke unter Windows einzubinden. Zuhause im LAN hat sich Samba, das auf SMB/CIFS setzt, bewährt. Auch über LAN-Grenzen hinweg lässt sich Samba nutzen, allerdings möchte ich Samba ungerne auf einer dedizierten Maschine – die für andere Dienste genutzt wird – rein für diesen Zweck betreiben. Aus diesem Grund habe ich in der Vergangenheit nach passenden Tools gesucht, die eine Einbindung über das SSHFS erlauben. Neben einigen kostenpflichtigen Lösungen (Mountain Duck, ExpanDrive, NetDrive, u.a.) bin ich damals auch auf Dokan und win-sshfs gestoßen. Die Dokan Library stellt dabei den Unterbau bereit, der die Einbindung von virtuellen Dateisystemen unter Windows ermöglicht. Über win-sshfs lässt sich dann das SSHFS über eine GUI einbinden. Beide Tools sind Open Source und auf GitHub zuhause. Dokan wird sehr aktiv weiterentwickelt, dies trifft auf win-sshfs leider – trotz Forks – nicht mehr zu. Die aktuelle Version ist dabei leider nicht mehr mit Dokan kompatibel, auch ein Workaround aus dem Issue Tracker hat bei mir keine Abhilfe gebracht. Also ging die Tage die Suche erneut los. Neben einem Blick auf die kommerziellen Lösungen bin ich durch Zufall auch auf ein noch relativ neues Projekt gestoßen: Winfsp. Winfsp ist dabei quasi das Äquivalent zu Dokan, zur Einbindung des SSHFS existiert mit sshfs-win eine Zusatzlösung vom gleichen Autor. Auch diese beiden Tools sind Open Source. Die Einbindung eines SSHFS nach der Installation beider Tools geschiet direkt über die gewohnte „Netzwerklaufwerk verbinden“ Oberfläche im Windows Explorer. Lediglich der Pfad sieht etwas anders aus:

\\sshfs\<benutzer>@<server>!<port>\\<pfad>
z,B, \\sshfs\root@example.local!22\\/var/www

Momentan werden SSH Keys zur Authentifizierung noch nicht nativ unterstützt, über Umwege scheint dies aber möglich zu sein.
Genauere Erfahrungswerte zu Winfsp/sshfs-win kann ich abschließend ich noch nicht mitteilen, allerdings laufen erste Tests unter Windows 10 x64 1709 bislang vielversprechend.

 

theXME’s Podcast 2017

Spontan, spontaner, Zeit für einen neuen Podcast! 🙂 Nach 10 Jahren ist es heute doch tatsächlich geschehen: es ist noch einmal ein Podcast entstanden. Die Themenliste hat sich ebenso zufällig ergeben. Feedback zum Podcast und den Themen sowie mögliche Themenvorschläge für einen eventuellen nächsten Podcast (wenn es ihn denn geben sollte) sind erwünscht 🙂

Download: https://www.thexme.de/wp-content/uploads/2017/12/theXME_Podcast_2017.mp3

Inhalt:
– 00:09: Einleitung: erster Podcast nach 10 Jahren
– 01:35: Aktuelles zum theXME.de Theme
– 02:43: Gesehene Filme: La La Land & Emoji
– 04:58: Mein Spotify Musikjahr 2017
– 08:02: Alexa (die leider etwas leise ist, sorry!)
– 10:24: Let’s Encrypt
– 11:28: Ende des AOL Instant Messengers
– 13:35: Ausleitende Worte & ein Witz von Alexa

Ich füchsel weiterhin – auch mit Firefox Quantum

In der vergangenen Woche hat Mozilla mit Firefox 57 „Quantum“ die neuste Version seines Webbrowsers in die Welt entlassen. Häufige Versionswechsel sind wir mittlerweile gewohnt, doch mit dem neusten Ableger hat sich dann doch etwas mehr als sonst getan. Der neuste Fuchs präsentiert sich runderneuert und legt Altlasten wie das bisherige Addon-System vollständig ab. Das so ein großer Eingriff nicht ohne entsprechende Nutzerrückmeldungen über die Bühne gehen würde, war klar. Ich verstehe einerseits die Endnutzer, die teilweise auf langgenutzte Addons (vorläufig) verzichten müssen. Und ebenso Addon-Entwickler, die aufgrund von fehlenden WebExtension-API’s bisherige Erweiterungen nicht ohne weiteres portieren können – hoffentlich zeigt sich Mozilla in diesem Punkt auch in Zukunft offen und reagiert auf entsprechende Wünsche.
Auf der anderen Seite fühlt sich der neue Fuchs auch etwas moderner an. Natürlich lässt sich über das neue Design trefflich streiten. Unter dem Strich gefällt es mir aber sehr, insbesondere das dunkle Theme hat es mir angetan. Dabei  nutze ich dunkle Themes ansonsten eigentlich recht selten. Weitreichende Themes, die Auswirkungen auf den Firefox-Aufbau hatten, habe ich ohnehin seit Jahren nicht mehr eingesetzt, deshalb fällt mir der Wechsel auch relativ einfach. Personas haben mir hierfür in der Vergangenheit ausgereicht.
Auf den ersten Blick fühlt sich der neue Firefox schneller an, allerdings ist das nur ein subjektiver Eindruck . Die Zeit wird sicherlich einen genaueren Eindruck vermitteln.
Um nochmals auf den Punkt Addons zurückzukommen: auch ich musste einen Blick auf meine bislang eingesetzten Addons werfen, nicht alle sind im aktuellen Zustand in eine WebExtension portiert worden. Nach etwas Recherche bin ich dann (vorübergehend) auf folgende Alternativen gewechselt:

  • Flagfox (wird noch angepasst) => Country Flags & IP Whois
  • SixOrNot (wird laut Autor vermutlich nicht mehr angepasst) => IPvFoo
  • KeeFox => Kee (automatischer Wechsel, gleicher Autor)

Die restlichen Erweiterungen waren entweder bereits kompatibel oder ich habe diese direkt beim Aufräumen entsorgt. Auch wenn nicht alle Erweiterungen bereits den gleichen Umfang wie die alten Addons aufweisen, so lässt es sich mit der neuen Sammlung vorerst leben.
Der „harte“ Wechsel ist also ohne größere Probleme geschafft. Einen Grund für einen Umstieg auf Chrome sehe ich weiterhin nicht, ich mag meinen Fuchs! 🙂 Und etwas Konkurrenz tut dem Web auch sicherlich künftig gut. Denn Vielfalt bereichert bekanntlich das Leben. In diesem Sinne: gutes Browsing! 😀

Hopp, FC Winti!

Mit dem letzten Trip zu meiner Schwester in die Schweiz – besser gesagt nach Winterthur – hat es dann auch mal mit dem Stadionbesuch des dortigen FC Winterthur geklappt. Der hiesige Club spielt in der zweiten Liga und ist tabellarisch leider nicht ganz vorne mit dabei. Dennoch hat dies der Stimmung im Schützenwiese Stadion keinen Abbruch getan, denn diese war wirklich ausgesprochen toll!
Am Ende des Spiels, das leider kurz vor Schluss noch mit 0:2 verloren wurde, klang „You’ll never walk alone“ durch die Lautsprecher – könnte ein Fußballabend schöner enden? 🙂
Dem FC Winterthur wünsche ich an dieser Stelle für die Restsaison viel Erfolg! Mal schauen, vielleicht ergibt sich in der nächsten Zeit die Möglichkeit eines weiteren Stadionbesuchs. 🙂

FC Winti (1)
FC Winti (2)
FC Winti (3)
FC Winti (4)

JMAP – das nächste IMAP?

JMAP – Java..? Auch wenn es mit jmap ein gleichnamiges Java-Werkzeug gibt, handelt es sich bei JMAP trotz Namensgleichheit (aber anderer Schreibweise) um eine neue Protokollspezifikation: der JSON Meta Application Protocol Specification (JMAP).
Bis vor wenigen Tagen hätten sich über meinem Kopf auch noch viele Fragezeichen hervorgetan, wäre mir da nicht ein Roundcube Issue Eintrag auf GitHub  über den Weg gelaufen.
Das Konzept von JMAP hört sich interessant an: die Ablösung von IMAP und SMTP (auf Clientseite, Mailserver <-> Mailserver bleibt unberührt) mit dem Ziel, Schwachstellen von IMAP zu optimieren und die Erweiterbarkeit (z.B. durch die Möglichkeit der Synchronisation von Kontakten und Kalendern) sicherzustellen.
Die Entwicklung wurde von FastMail angestoßen und wird mittlerweile in der IETF offen fortgesetzt. Noch stehen einige Punkte auf der Milestone-Liste – bis das Protokoll also in der praktischen Anwendung anzutreffen ist, dürfte noch etwas Zeit vergehen. Dennoch ist die Entwicklung eines derartigen Alternativprotokolls zu einem gefühlt jahrhundertaltem etablierten Protokoll spannend.

Kurztipp: mit Munin SSL Zertifikate im Auge behalten

Mit dem Monitoring-Tool Munin und dem ssl_ Plugin lassen sich Restlaufzeiten von SSL Zertifikaten auf einfache Weise überwachen. Insbesondere bei Zertifikaten mit kurzen Laufzeiten (u.a. Lets Encrypt) kann das ganz nützlich sein. Nach dem Download des Plugins muss nur eine Verknüpfung für die zu überwachende Domain angelegt werden, z.B.:

ln -s /usr/share/munin/plugins/ssl_ /etc/munin/plugins/ssl_<domain>

Wenn man nun in der munin.conf wie folgt noch die gewünschten Werte für Warnung und Critical hinterlegt, lässt sich damit im Handumdrehen eine simple E-Mail Benachrichtigung einrichten, die bei einem anstehenden Ablauf des Zertifikats aktiv wird (in diesem Beispiel, sobald 20 (Warning) bzw. 10 Tage (Critical) Restlaufzeit erreicht werden).

ssl_<domain>.expire.warning 20:
ssl_<domain>.expire.critical 10:

Munin ssl_
Munin ssl_

 

MySQL und MariaDB – eine Nachbetrachtung

Heute möchte ich nochmals meine Gedanken aus dem Beitrag Die Zukunft von MySQL ist eine spannende Angelegenheit aus dem Jahre 2013 aufgreifen. Sind die Befürchtungen wahr geworden, gibt es mittlerweile neue Gesichtspunkte?

Oracle hat sich in der Vergangenheit bei Open Source Projekten nicht gerade beliebt gemacht, insofern bestanden auch bei MySQL ernsthafte Bedenken, was die künftige Marschrichtung und Zukunft anbelangte. Entgegen aller Unkenrufe scheint es Oracle mit MySQL aber ernster zu meinen als mit anderen „Randprodukten“, die vermutlich aus Oracle-Sicht nicht ganz ins Portfolio passten. Das zeigt sich an der Entwicklung von MySQL in den letzten Jahren: mit MySQL 5.7 haben viele sinnvolle Dinge Einzug gehalten, an der nächsten Version 8.0 wird zudem aktiv gearbeitet und diese wird auch alte Zöpfe abschneiden.
Ein großer Kritikpunkt der weiterhin besteht ist allerdings der Umgang mit Bugtracker-Einträgen. Nicht alle sind öffentlich zugänglich, manche stehen nur Oracle-intern zur Verfügung. Ganz offen zeigt sich hier Oracle also weiterhin nicht. Auch das MySQL Updates in der Regel an festen Oracle Patchdays erscheinen, stößt so manchem Bitter auf. Hier kann MariaDB natürlich definitiv punkten und zeigt sich offener.

Apropos MariaDB. Auch hier hat sich im Laufe der Jahre einiges getan und erst kürzlich wurde die stabile Version 10.2 veröffentlicht. Linux Distributionen setzen nun mehrheitlich auf MariaDB, mit Debian Stretch ist vor etwas mehr als einem Monat eine weitere große dazugekommen. Dabei zeigt sich immer mehr, dass MariaDB nicht mehr nur ein Fork darstellt, sondern mit der Zeit viel mehr zu einem eigenständigen Produkt wird. Noch dürften die jeweiligen Eigenheiten von MySQL und MariaDB normale Webanwendungen nicht großartig tangieren, aber ob dies auf langfristige Sicht so bleiben wird bleibt fraglich. Solange wir uns damit aber noch nicht herumschlagen müssen, darf die Wahl nach Gusto erfolgen. Insofern ist es immer schön eine offene Alternative wie MariaDB in der Hinterhand zu haben.

Ich selbst bin persönlich noch bei MySQL geblieben, allerdings benötigen meine Webanwendungen bislang keine der speziellen Funktionen von MySQL oder MariaDB – ein späterer Wechsel wäre also noch relativ problemlos durchführbar. Insofern verfolge ich entspannt beide Entwicklungslinien, MySQL und MariaDB dürfen sich durchaus beidseitig inspirieren 🙂

Unter dem Strich lässt sich festhalten, dass auch MySQL noch lange nicht tot ist. Auch wenn sich so mancher Kritikpunkt weiterhin nennen lässt, hat Oracle MySQL zumindest nicht fallen lassen.

Upgrade auf Debian Stretch 9.0 geglückt

Im zweiten Anlauf ist mir in der vergangenen Nacht das Upgrade des Servers auf Debian Stretch geglückt. Damit ist etwas mehr als eine Woche nach dem Release von Debian Stretch die Hauptarbeit bereits abgeschlossen. Grundsätzlich habe ich direkte Upgrades auf die Nachfolgeversion von Debian bislang gemieden und stets auf eine (meistens deutlich spätere) Neuinstallation gesetzt. Auch diesmal stand dieser Weg bei mir ganz oben auf der Liste, allerdings habe ich mich dann doch relativ schnell für das Upgrade umentschieden – auch nachdem erste Berichte von einem grundsätzlich relativ reibungslosen Prozess berichteten. Bei vergangenen Debian Upgrades sah das zum Teil noch anders aus.
Das eigentliche Systemupgrade lief bei mir am problemlosesten, großartige Auseinandersetzungen mit Abhängigkeiten traten nicht zu Tage. Konfigurationsdateien diverser genutzter Pakete habe ich vorerst beibehalten und werde diese ggf. zu einem späteren Zeitpunkt gegenüber neuen Versionen vergleichen. Kritische Änderungen, die eine sofortige Aktion erfordern würden, gab es bei diesen nicht. Dies betraf vor allem Postfix und Dovecot, sodass der Mailserver auch weiterhin gewohnt seinen Dienst ohne direkten Eingriff verrichtet.
Apache und PHP kompiliere ich auf dem Server stets selbst, der Neueinstieg von OpenSSL 1.1 in Debian Stretch hat mir hier vor allem bei Apache das erste Problem beschert. Die kürzlich erschienene Apache Version 2.4.26 ist die erste, die OpenSSL 1.1 offiziell unterstützt – alles darunter führt zwangsläufig zu Frustrationen. Wichtig ist also, gleich die neuste Version zu wählen. Die aktuelle PHP Version 7.1.6 ist ebenfalls OpenSSL 1.1 kompatibel, auch wenn bei der Kompilierung noch einige Warnungen ausgespuckt werden. Die PHP Erweiterung curl erfordert zudem noch das Paket libcurl4-openssl-dev. Hier benötigt es dann noch einen Symlink, damit der Konfigurationsvorgang ohne Fehler durchläuft.
Das reguläre Upgrade auf Stretch betrifft vor allem bisherige Nutzer von MySQL, sofern die entsprechenden Debianpakete genutzt werden. Während des Upgrades findet dann ein automatischer Umstieg auf MariaDB statt. Mich hat dies nicht betroffen, da ich MySQL separat installiert habe. Die zugehörige MariaDB Library scheint zudem größtenteils MySQL-kompatibel zu sein, sodass sich auch Dovecot und Postfix daran nicht aufhängen. PHP nutzt über mysqlnd sowieso seine eigene MySQL-Library.
Der größte sichtbare Benefit mit dem Umstieg auf Debian Stretch war für mich die Möglichkeit, das HTTP/2 Modul des Apache Webservers zu aktivieren. Unter Debian Jessie war dies ohne Fallstricke nicht möglich, da die dortige OpenSSL Version und nötige libnghttp2 Bibliothek zu alt waren. Beides hat sich nun gelöst, sodass nach der Nachinstallation des libnghttp2-dev Pakets und anschließenden Kompilierung HTTP/2 final aktiviert werden konnte. Damit ist auch dieser letzte große Punkt auf der ToDo Liste verschwunden 🙂
Im Großen und Ganzen ist das Upgrade unter dem Strich also sehr weich verlaufen. Eine Neuinstallation hätte da weitaus mehr Zeit und Planung beansprucht. Auch wenn noch kleinere Nacharbeiten anstehen: der größte Teil ist geschafft und der Server damit für die nächste Zeit wieder auf dem aktuellsten Stand. Danke, liebes Debian Team!

Sometimes it seems to be my destination