Alle Beiträge von theXME

Bash: History mit Zeitpunkten und unbegrenzter Größe & .bashrc vs. .bash_profile

Auch wenn es einige Alternativen zur gewöhnlichen Bash unter Linux gibt, zählt sie auch heute noch zu den beliebtesten Shells. Auch ich selbst nutze sie auf meinem Server noch rege. Die Z shell (zsh) sieht zwar ebenso vielversprechend aus, aber das ist ein Thema für ein anderes mal.

Unbegrenzte History
Kommen wir zurück zur Bash: etwas, dass ich lange vermisst habe, war die Größe der History so festzulegen, dass diese nicht begrenzt ist. Oftmals gibt es dann doch den einen Befehl, der nützlicherweise noch in der History schlummern könnte, wenn er nicht schon dem Größenlimit zum Opfer gefallen wäre. Festlegen lässt sich die Historygröße grundsätzlich über die beiden Variablen HISTSIZE sowie HISTFILESIZE. HISTSIZE legt dabei die maximale Anzahl von Befehlen bzw. Zeilen fest, die in der History im Hauptspeicher während einer Sitzung festgehalten bleiben. HISTFILESIZE legt dagegen die maximale Anzahl von Befehlen bzw. Zeilen in der Historydatei fest, die gespeichert bzw. beim Start der Bash geladen werden. Wichtig ist also, beide Werte entsprechend anzupassen. Bis zur Bash Version 4.3 gab es AFAIK keine Möglichkeit, beide Werte auf „unlimitiert“ zu setzen, sodass lediglich ein möglichst hoher Wert eine Alternative darstellte. Seit Version 4.3 führt ein Wert kleiner 0 zu einer unbegrenzten Größenfestlegung. Dazu sind folgende beiden Einträge in die Bashkonfiguration aufzunehmen:

HISTFILESIZE=-1
HISTSIZE=-1

History mit Zeitangaben
Doch auch wenn nun verwendete Befehle weit in der Vergangenheit nachgeschlagen werden können, bleibt manchmal die Frage offen, zu welchem Zeitpunkt ein Befehl ausgeführt wurde. Über HISTTIMEFORMAT lässt sich das Historyformat entsprechend anpassen, sodass die History künftig um eine Zeitangabe erweitert wird.  Ein mögliches Format kann beispielsweise so aussehen:

HISTTIMEFORMAT=“[%d.%m.%y] %T „

Dies resultiert in Historyeinträgen im folgenden Schema:
536 [12.02.18] 00:13:56 ls -lha

.bashrc vs .bash_profile
Bleibt noch die Frage offen, in welche der beiden Dateien die neuen Kofigurationszeilen aufzunehmen sind. Grundsätzlich lassen sich die Einträge in beide Dateien eintragen, sie werden allerdings zu unterschiedlichen Zeitpunkten Verwendung finden. Die .bashrc wird bei jedem Öffnen eines interaktiven Terminals automatisch geladen, während die .bash_profile beim Öffnen einer Login-Shell geladen wird. Um auf der sicheren Seite zu sein, müssten die Einträge also in beiden Dateien vorgenommen werden. Bei einem Server, der ohnehin grundsätzlich über SSH angesteuert wird, lässt sich die .bashrc aber auch automatisch mit der .bash_profile ausführen. Dazu ist lediglich folgendes kleine Snippet in die .bash_profile einzutragen:

if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi

 

 

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.