Springe zum Inhalt

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.

Genau für diese Funktion hat die Bash eine Einstellung, welche aus der Umgebungsvariable HISTCONTROL gelesen wird. Wird dort ignoredups eingestellt, werden keine direkt aufanderfolgenden gleichen Kommandos in die Historie geschrieben. Eine zweite Einstellung ignorespaces legt fest, dass keine Kommandos in die Historie geschrieben werden, die mit einem Leerzeichen beginnen, was z.B. für Kommandos nützlich ist, bei denen man ein Kennwort direkt in der Kommandozeile angegeben hat. Da beide Einstellungen sehr nützlich sind, können sie mit ignoreboth gleichzeitig eingeschaltet werden.

In der ~/.bashrc fügt man dazu folgende Zeile ein:

HISTCONTROL=ignoreboth

Nach einem erneuten Login oder nach dem "sourcen" der Datei mit . ~/.bashrc ist die Option sofort aktiv.

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.

Danach sollte sich der Zabbix-Agent-Benutzer mit "ssh <Remote-Host>" ohne Passworteingabe auf dem Remote-Host anmelden können. Anschließend können die zu überwachenden Werte in Zabbix konfiguriert werden.

Groß ist die Verwunderung, wenn Zabbix im Status des jeweiligen Wertes "Public key authentification failed" anzeigt, obwohl der manuelle Verbindungsaufbau problemlos funktioniert hat.

Ursache ist, dass ssh-key-gen jetzt standardmäßig Keys im OpenSSH-Format und nicht mehr im alten RSA-Format erstellt. Zu erkennen ist das neue Format in der Datei ~/.ssh/id_rsa. Für OpenSSH steht dort "-----BEGIN OPENSSH PRIVATE KEY-----" und für RSA "-----BEGIN RSA PRIVATE KEY-----" in der ersten Zeile. Zumindest meine Zabbix-Version (4.0) kann noch nicht mit dem OpenSSH-Format umgehen und verwendet den entsprechenden Schlüssel dann einfach nicht. Resultat: Public key authentification failed.

Abhilfe schafft das Kommando "ssh-keygen -m PEM", welches einen neuen Schlüssel im alten Format erzeugt, das auch ältere Zabbix-Version verstehen.

1

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.

Ein Cookie ist nichts anderes als eine Textinformation, die beim Abrufen einer Webseite mittels Browser vom Server in der Antwort mitgeschickt wird, quasi in den Metadaten des eigentlich erwarteten Inhalts, der Webseite.

Das verhält sich in etwa so, wie wenn ich beim Bäcker fünf Brötchen haben möchte, die freundliche Verkäuferin mir als Antwort noch ein paar nebensächliche Fakten zu den gewünschten Brötchen mitteilt (die Meta-Daten) und mir nebenbei noch eine Kundenkarte (Cookie) in die Hand drückt. Da ich ihr keine alte Kundenkarte direkt bei der Bestellung vorgezeigt habe, überreicht sie mir eine neue Kundenkarte. Diese kann ich ablehnen oder einstecken (speichern). Auf der Kundenkarte kann die Verkäuferin verschiedene Dinge festhalten, wie z.B. die Anzahl der gekauften Waren.

Andere Sachen als das Speichern von Informationen können mit der Kundenkarte nicht ausgeführt werden. Sie öffnet nicht automatisch meine Geldbörse oder stellt irgendetwas anderes in ihrer Umgebung an. Genausowenig kann ein auf dem Computer gespeichertes Cookie irgendwelche Funktionen auf dem Computer aufrufen. Die einzige Besonderheit ist, dass ich die Kundenkarte evtl. einstecke und bei jedem Besuch dieses Bäckereigeschäfts wieder vorzeige.

Genau so verhält es sich mit den Cookies im Browser. Sie werden beim Sufen mitgeliefert und werden je nach Browsereinstellung akzeptiert oder verworfen. Sie bestehen aus Textschnipseln, die jedoch meistens für Menschen nicht auswertbar sind, sondern Informationen für Computer enthalten, die wiederrum mit diesen Informationen Besucher der jweiligen Webseite eindeutig identifizieren können. Und da liegt die Crux und um es mit dem Beispiel des Bäckers zu beschreiben: sollte die Kundenkarte irgendwann akzeptiert, also gespeichert worden sein, wird sie vom Browser jedesmal beim Besuch der Bäckerei bzw. der Webseite automatisch vorgezeigt. Die Verkäuferin weiß also immer, wie viel wir schon gekauft haben.

Kleines Problem

Beim Bäcker meines Vertrauens ist das alles kein Problem. Er liefert ja hervorragende Brötchen. Durch die Kundenkarte erhalte ich evtl. irgendwann einen Vorteil. Problematisch ist nur, dass versucht wird, jedem Besucher eine Kundenkarte zuzustecken, auch wenn gar nichts gekauft wurde. Bei wiederkehrenden Besuchern kann so festgestellt werden, dass z.B. schon mehrfach vorbeigeschaut, aber immernoch nichts gekauft wurde.

Großes Problem

Ein viel größeres Problem ist, wenn sich mein Bäcker entschließt, eine Kooperation mit einem Rabattprovider oder Punktesammelverein einzugehen. Beim Besuch der Bäckerei erhält dann jeder zwei Kundenkarten. Technisch gesehen müsste beim Bäcker noch ein Vertreter des Punktesammelvereins sitzen, dem die Kundenkarte bei einem wiederholten Besuch automatisch überreicht wird. Der Browser liefert Cookies beim Surfen nur an diejenige Webseite zurück, von der er sie erhalten hat. Und hier liegt das Problem: der Vertreter beim Bäcker weiß ja, wo er sich befindet. Er weiß also bei Besuchern genau, wie oft diese schon da waren. Durch die Kooperation mit dem Bäcker erfährt er über andere Wege zusätzlich, wie viel gekauft wurde. Dabei ist es auch vollkommen egal, ob wir Kunde des jeweiligen Punktesammelvereins sind. Durch die automatisch zugesteckte Kundenkarte kann er uns immer wieder erkennen.

Nun stelle man sich vor, in jedem Geschäft sitzt solche ein Vertreter eines Punktesammelunternehmens. Und nein, nicht nur in Geschäften, auch in jedem einzelnen Zeitungsartikel den wir lesen, jedem Lied welches wir hören, jedem Film den wir schauen, in jeder Sache, die wir wahrnehmen. Und wir überreichen allen schön brav automatisch unsere Kundenkarte.

Unser Bäcker wollte uns nichts Böses. Er versprach sich von der Kooperation eine finanzielle Unterstützung. Die Kunden hofften auf Prämien durch die gesammelten Punkte. Der Punktesammelverein weiß jedoch umfassend, was wir wann wo getan haben, wenn wir seine automatisch zugesteckte Kundenkarte akzeptiert haben.

Fiasko

Und nun wird es noch einmal ganz übel: auf Webseiten sind viele dieser Punktesammelvereine, dort heißen sie Werbenetzwerke, eingebunden, die fleißig aufzeichnen, was wir im Netz denn so tun.

Genauso fleißig sammeln die eingebundenen sozialen Netzwerke Daten über uns. Und es wird noch schlimmer, denn durch die automatisch zugesteckten Kundenkarten bzw. Cookies können uns diese Datensammler überall wiedererkennen. Um einmal Zahlen zu nenen: Facebook weiß bei drei Viertel aller deutschen Nachrichtenseiten, wer wann was gelesen hat (Quelle).

So ganz ungefährlich sind diese kleinen Textschnipsel also nicht.

Schutz

Es stellt sich die Frage, wie man sich vor derlei automatischer Ausspioniererei schützen kann, denn nichts anderes ist diese umfassende Sammelwut. Da der Browser die Cookies verwaltet, gilt es zum Surfen zuerst einmal einen Browser auszuwählen, bei dem sich die Behandlung von Cookies überhaupt steuern lässt. Evtl. kann diese Behandlung dem Browser auch durch die Installation von Addons hinzugefügt werden.

Beispiele sind der Browser Chrome der sich mit dem Addon uBlock-Origin erweitern lässt. Der Browser Firefox wurde von den Entwicklern mit einem Modus zum Schutz vor Aktivitätsverfolgung ausgestattet und kann zusätzlich mit dem Addon uBlock-Origin erweitert werden. Im Bäckerei-Beispiel würde das Addon uBlock-Origin so arbeiten, dass erst gar nicht mit dem Vertreter des Punktesammelvereins gesprochen wird, er wird einfach ignoriert.

Eine weitere Methode ist das regelmäßige Löschen von Cookies oder den Browser anzuweisen, Cookies nur so lange zu speichern, bis der Browser wieder komplett geschlossen wurde. Allerdings ist das nicht immer praktisch, da in Cookies auch Zugangscodes zu bestimmten Webseiten gespeichert sein können. Löscht man diese Cookies, muss man sich neu bei der jeweiligen Seite anmelden.

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:

#!/bin/bash
 
SEVERITY=${1:-7}
MESSAGE=$2
LOGHOST=Hostname oder IP-Adresse des Remote-Syslog-Hosts
 
declare -A SEVERTIES=([emergency]=0 [alert]=1 [critical]=2 [error]=3 [warning]=4 [notice]=5 [informational]=6 [debug]=7)
re='^[0-9]+$'
if ! [[ $SEVERITY =~ $re ]]; then
        SEVERITY=${SEVERTIES[$SEVERITY]}
        if [ -z "$SEVERITY" ]; then
                echo Severity not found &gt;&amp;2
                exit 1
        fi
fi
read -d $'\0' PROCNAME ARGS </proc/$PPID/cmdline
echo "<13$SEVERITY>$PROCNAME[$PPID]: $MESSAGE" >/dev/udp/$LOGHOST/514

Das Skript hat zwei Parameter, der erste gibt den Schweregrad an, welcher als numerischer Wert oder in seiner Textdarstellung übergeben werden kann. Der zweite Parameter ist die Nachricht selbst. Vor dem ersten Aufruf muss noch der Inhalt der Variablen LOGHOST angepasst werden.

Wenn das Skript nun z.B. unter dem Namen rlog.sh abgespeichert wird, kann es aus anderen Skripten wie folgt aufgerufen werden (vorher nicht vergessen, das Skript auch ausführbar zu machen):

rlog.sh debug "Ich bin eine Testnachricht"

Natürlich muss auf der Empfängerseite auch ein syslog-Daemon auf dem Port 514 lauschen. In der Debian-Standardinstallation tut der dortige rsyslogd das nicht. Dazu muss die Datei /etc/rsyslogd.conf angepasst bzw. die Kommentarzeichen vor folgenden Zeilen entfernt werden:

module(load="imudp")
input(type="imudp" port="514")

Möchte man nun die von Remote eintreffenden Nachrichten auf dem Syslog-Host in eigene Logdateien schreiben, können unter /etc/rsyslog.d/ entsprechende Konfigurationdateien erstellt werden.

if $fromhost-ip == [ '192.168.0.191', '192.168.0.192', '192.168.0.193' ] then /var/log/nas.log
& stop

In diesem Beispiel werden Syslog-Meldungen, welche von den angegebenen IP-Adressen empfangen werden, in das Logfile /var/log/nas.log geschrieben.

Von jetzt an können auch die hier vorhandenen WD My Book Live Syslog-Nachrichten schreiben:

rlog.sh debug "Ich bin eine Nachricht von $HOSTNAME"

3

Für den Betrieb des dezentrale Netzwerk Friendica, welches auch hier auf einer eigenen Instanz läuft, 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:

d /run/friendica 0755 www-data www-data -

Das Verzeichnis wird mit den angegebenen Berechtigungen und Eigentümer angelegt. Damit das Verzeichnis sofort zur Verfügung steht, wird folgender Befehl verwendet:

systemd-tmpfiles --create --prefix /run/friendica

Anschließend wird das Unit-File für systemd unter "/etc/systemd/system/friendica-daemon.service" mit folgendem Inhalt angelegt:

[Unit]
Description=Friendica daemon
After=network.target mysqld.service
Requires=network.target remote-fs.target nss-lookup.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/srv/friends
Type=simple
StandardOutput=null
StandardError=syslog
ExecStart=/usr/bin/php ./bin/daemon.php start
ExecStop=/usr/bin/php ./bin/daemon.php stop
PIDFile=friendica/daemon.pid
PrivateTmp=true
InaccessibleDirectories=/home /root /boot /opt /mnt /media
ReadOnlyDirectories=/etc /usr
Restart=always

[Install]
WantedBy=multi-user.target

Der Pfad bei WorkingDirectory muss auf den Pfad der lokalen Friendica-Installation angepasst werden. Anschießend werden die Unit-Files von systemd neu geladen:

systemctl daemon-reload

Jetzt kann der Update-Daemon mit systemd gestartet werden:

systemctl start friendica-daemon.service

Nach dem erfolgreichen Start schreibt der Update-Daemon seine PID in die oben angegebene Datei "/run/friendica/daemon.pid". Die gleiche PID sollte in der Ausgabe des folgenden Befehls angezeigt werden:

systemctl status friendica-daemon.service

Sollte bis hier hin alles korrekt verlaufen sein, kann der Update-Daemon für den automatischen Start beim Systemstart aktiviert werden:

systemctl enable friendica-daemon.service