HAPPYTEC.at :: Blog

Debian Wheezy ist völlig veraltet und erhält keinerlei Sicherheitsaktualisierungen mehr, Debian Jessie ebenso. Trotzdem kommt es selten vor, dass ich eine temporäre VM für Testzwecke mit Debian Wheezy hochziehen muss. Meistens hole ich dann mittels APT-Pinning einige Pakete aus z.B. Debian Jessie dazu.

Das Problem: APT will mir dann sofort Systemd nachinstallieren und, das ist richtig kurios, bei einem "apt-get autoremove" gleich wieder entfernen. Jedes Mal ärgere ich mich über dieses Problem und ignoriere es einfach, weil es bei einer Test-VM keine Relevanz hat. Doch für alles gibt es eine Ursache bzw. einen Workaround!

Die Lösung findet man in der Upgrade-Dokumentation von Debian Jessie...

Auf einigen Systemen liegen bestimmte Munin-Plugins bzw. relevante Dateien in Home-Verzeichnissen von Benutzern. Das ist nicht ideal, aber leider nicht ohne Weiteres zu ändern. Und jedes Mal stolpere ich über dieses Problem, dass ich mir nirgends notiert habe, wie man das löst...

Verantwortlich dafür ist (z.B. bei Debian) Systemd bzw. die Option ProtectHome im jeweiligen Unitfile. Es handelt sich dabei um eine äußerst sinnvolle Änderung! Trotzdem kann man das Verhalten bei Bedarf anpassen...

Nach einem Upgrade von Debian Stretch auf Buster und direkt weiter auf Debian Bullseye, sah ich mich am Wochenende mit einem völlig neuen Problem konfrontiert: Das (Neu-) Starten des Munin-Nodes dauerte ewig und lief sogar in ein Timeout. Systemd versuchte danach quasi im Minutentakt, den Dienst hoch zu bringen, was immer wieder scheiterte. Grafiken dieses Nodes wurden dementsprechend keine mehr generiert.

Die grundlegende Ursache: Ich verwende auf diesem Host sehr viele snmp_* Plugins, von denen aber einige Hosts nicht 24/7 laufen. Beim Starten von munin-node werden alle Plugins einmal mit "config" initialisiert. Das dauert so schon relativ lange, aber noch länger, wenn bei allen Hosts, die offline sind, jeweils auf ein Timeout gewartet werden muss. Wenn das insgesamt länger dauert, als Systemd bereit ist zu warten, bekommt man ein Problem. Durch den andauernden Neustart des Dienstes kann dieser die Initialisierung niemals vollenden und steht nicht zur Verfügung...

Eines der letzten Chromium Updates machte mich wahnsinnig: Durch das automatische Ausblenden von Protokoll und Teilen der Subdomain (Stichwort www), sprang der Inhalt der Adressleiste relativ grauslich hin und her, sobald man etwas darin bearbeiten wollte. Besonders nervend war es, wenn man einen Doppelklick auf einzelne Wörter oder Parameter ausführte. Eine schnelle und gezielte Änderung der URL war für mich nicht mehr möglich, ohne Kopfschmerzen zu bekommen und massiv ausgebremst zu werden!

Die Lösung ist zum Glück relativ simpel: Öffnen der chrome://flags und deaktivieren folgender Optionen...

Ausgangslage: Der SMTP-Versand einer Webapplikation soll am Entwicklungsserver getestet werden. Selbstverständlich sollen die E-Mails dabei nicht an die wirklichen Empfänger verschickt werden! Es reicht, wenn sie der Administrator bzw. Entwickler direkt in sein eigenes E-Mail Postfach bekommt. Dadurch können auch Datensätze mit Fantasiemailadressen benutzt werden. Da am Entwicklungsserver bereits ein vollständiger Postfix für andere Zwecke läuft, wird dieser kurzerhand umkonfiguriert...

In der master.cf wird ein zusätzlicher lokaler SMTP-Port aktiviert...