OSS

Jansens Pott hat in seinem Blog eine Idee aus dem englischsprachigen Raum übernommen, in der Blogger ein paar Fragen zu ihren Blogs und ihrer Bloggerkarriere beantworten. Ich finde es interessant, auch mal etwas Persönliches über meine Blogger-Kolleginnen und -Kollegen zu lesen und möchte gern selbst etwas zu dieser Idee beitragen. Auf geht’s.

Um externe Links automatisch mit CSS zu kennzeichnen müssen zuerst mit einem passenden CSS-Selektor alle externen Links ausgewählt werden. Anschließend können Darstellungseigenschaften für die ausgewählten Links festgelegt werden. Mit folgendem Code werden z.B. hier im Blog alle ausgehenden Links mit einer kleinen Grafik versehen.

article a[href^="http://"]:not([href*="blog.tausys.de"]):not([href*="localhost"]):after,
article a[href^="https://"]:not([href*="blog.tausys.de"]):after {
  content: " " url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAVklEQVR4Xn3PgQkAMQhDUXfqTu7kTtkpd5RA8AInfArtQ2iRXFWT2QedAfttj2FsPIOE1eCOlEuoWWjgzYaB/IkeGOrxXhqB+uA9Bfcm0lAZuh+YIeAD+cAqSz4kCMUAAAAASUVORK5CYII=);
  position: relative;
  top: -.3em;
}

Alle Artikel hier im Blog stehen innerhalb von <article> ... </article>. In diesen Artikeln werden alle Links (a) selektiert, welche mit http:// beginnen und nicht auf die Blog-Webseite (blog.tausys.de) zeigen. Der Link darf auch nicht auf localhost zeigen, da ich Artikel-Entwürfe mit hugo darüber anzeigen lasse.

Seit langer Zeit habe ich hier keinen neuen Beitrag mehr veröffentlicht. Was im Gegensatz zur Veröffentlichungsfrequenz neuer Artikel jedoch enorm gestiegen ist, sind die Anmeldeversuche an der hiesigen WordPress-Instanz. WordPress und die wenigen installierten Addons aktualisieren sich zwar automatisch, aber es bleibt immer das ungute Gefühl, irgendwann doch von einer Lücke im PHP-Code oder gar im PHP-Interpreter betroffen zu sein und sich dann zumindest Arbeit und evtl. auch Ärger einzuhandeln.

Eine sehr nützliche Funktion der Bash ist es, Kommandos in einer Historie zu speichern, um sie wiederholt ausführen zu können. So z.B. können die zuletzt ausgeführte Kommando durch Drücken der Cursor-Hoch-Taste wieder in die Eingebezeile geholt, evtl. editiert und erneut ausgeführt werden.

Wenn nun durch wiederholtes Ausführen immer des gleichen Kommandos ausgeführt wird, z.B. um sich ändernden Plattenplatz bei einer Sicherung zu beobachten oder den Verzeichnisinhalt zu überwachen, der durch ein laufendes Programm geändert wird, schreibt die Bash auch immer wieder das gleiche Kommando in die Historie. Das ist sehr unpraktisch, wenn man evtl. ein weiter zurückliegendes Kommando wieder aus der Historie hervorholen will.

In der Monitoring-Software Zabbix gibt es die Möglichkeit, aufzuzeichnende Werte über Shell-Komandos zu ermitteln, die über SSH von einem enfernten Host gesammelt werden. Dazu muss sich der auf dem jeweiligen Host für die Datensammelei installierte Zabbix-Agent per SSH mit dem entfernten Rechner verbinden können. Passwortlos funktioniert das am besten mit dem in SSH integrierten Public-Key-Verfahren: dazu erstellt man zuerst für den Benutzer, unter dem der Zabbix-Agent läuft einen SSH-Key mit ssh-keygen, schickt dann den generierten öffentlichen Schlüssel an den entfernten Rechner und trägt diesen beim Benutzer in der Datei ~/.ssh/authorized_keys ein. Die letzten zwei Schritte kann man auch halbautomatisch mit dem Befehl ssh-copy-id erledigen.

Immer wieder sind falsche Informationen zu Cookies zu lesen, selbst in Fachzeitschriften. Auch heute las ich wieder solch eine irreführende Aussage, dass Cookies beim Surfen angeblich Daten auf meiner Festplatte speichern. Das ist Humbug. Genausowenig speichert eine Webseite beim Surfen irgendwas auf meinem Computer. Vielmehr weist mein zum Surfen verwendeter Browser das Betriebssystem des Computers an, etwas zu speichern. Das können Inhalte aus einer Webseite oder eben auch ein mit der Webseite empfangenes Cookie sein. Aber von vorn.

Kürzlich ergab sich das Problem, Syslog-Nachrichten an einen Remote-Host verschicken zu müssen, der sonst dazu verwendete Befehl logger auf dem System aber noch kein Verschicken an Remote-Systeme unterstützte. Leider gab es für das betreffende Gerät auch keine neuere Software, es handelte sich um eine externe Netzwerk-Festplatte von WD, ein My Book Live.

Wenn sonst keine entsprechenden Werkzeuge zur Verfügung stehen, ist es oft ein unterschätztes Feature, dass bash direkt an Netzwerkadressen senden oder von diesen empfangen kann. Glücklicherweise unterstützt die auf den Geräten installierte bash-Version das Lesen und Schreiben an Netzwerkadressen per TCP oder UDP. Das ursprüngliche Syslog-Nachrichtenformat, beschrieben in RFC3164, ist reiner Text. Gesagt getan, ein Skript muss her:

Für den Betrieb des dezentrale Netzwerk Friendica, müssen periodisch Nachrichten verschickt und notwendige andere Aufgaben abgearbeitet werden. Früher konnte dazu ein Cron-Job eingerichtet oder alternativ ein Addon installiert werden, welche diese Aufgaben periodisch ausführte. Mittlerweile hat Friendica dafür einen eigenen Daemon bekommen, dessen Einbindung in ein Debian-System mit systemd hier kurz vorgestellt wird.

Der Update-Daemon erzeugt ein PID-File, dessen Name und Pfad in der Konfigurationsdatei “config/local.config.php” eingestellt wird:

'system' => [
  'pidfile' => '/run/friendica/daemon.pid',
 ],

Beim Systemstart existiert obiges Verzeichnis noch nicht. Debian verwaltet flüchtige Dateien und Verzeichnisse mit systemd-tmpfiles. Damit dieses Verzeichnis beim Systemstart automatisch angelegt wird, kann in die Datei “/etc/tmpfiles.d/friendica.conf” Folgendes eingetragen werden:

Achtung für alle, die WordPress mit dem Plugin Crayon zum Darstellen von Quelltexten einsetzen und auf Debian 10 (Buster) updaten wollen. Mit Buster kommt PHP 7.3 mit, welches ein paar Anpassungen im leider seit langem nicht mehr gepflegte Crayon erfordert.

Die Anpassungen können manuell durchgeführt werden. Alternativ kann auch ein komplett angepasstes Plugin von Github heruntergeladen werden.

Nach dem Update von Stretch auf Buster braucht OpenSSH, speziell auf VMs, schon mal gerne mehrere Minuten zum Starten. Grund dafür ist, dass systemd alle Dienste ziemlich parallel startet und für OpenSSH-Verschlüsselungsroutinen einfach noch nicht genug Entropie vorhanden ist. OpenSSH wartet deshalb erst einmal ab und lässt noch keine Verbindungen von außen zu. Erst wenn im Kernel-Log die Meldung “random: crng init done” auftaucht, ist die Initialisierung abgeschlossen und OpenSSH startet komplett.