Linux Archive - TauSys

Bash-Kommandohistorie: Doppelte Einträge verhindern

Jens Tautenhahn4. April 20224. April 2022

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.

Syslog-Meldungen mit Bash verschicken

Jens Tautenhahn25. August 202025. August 2020

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"

Friendica: Update-Daemon und systemd 3

Jens Tautenhahn19. August 202023. Februar 20213 Kommentare

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

Kommentar: Yacy? Eher nicht. 20

Jens Tautenhahn10. Juli 201720 Kommentare

Immer mal wieder geht die verteilte Suchmaschine Yacy durch die Medien, Blogs und Chats. Offenbar haben viele Internetnutzer das Bedürfnis, sich ob der vielen Datenschutzbedenken von den großen etablierten Suchmaschinen zu lösen, was erfreulich ist. Für Experimentierfreudige ist Yacy ein Projekt, um einmal in den Aufbau einer verteilten Suchmaschine und deren Funktionsweise reinzuschnuppern. Ich habe dieses Experiment gewagt und möchte nach ca. dreimonatiger Anwendung über meine Erfahrungen berichten. ...weiterlesen "Kommentar: Yacy? Eher nicht."

Neues Bintec-Tracetool verfügbar

Jens Tautenhahn5. Juli 201730. August 2019

Router der Bintec-Reihe haben neben der per Browser zugänglichen Verwaltungsoberfläche und der per SSH oder Telnet erreichbaren SNMP-Shell noch eine Tracemöglichkeit eingebaut, mit der sich der Traffic auf einer Schnittstelle auslesen lässt.

Nach langer Wartezeit, die vorherige Version 2.43 ist schon mehr als zehn Jahre alt, wurde die Version 2.53 des Tracetools auch für Linux veröffentlicht. Diese kann nun endlich auch mit den seit langer Zeit nicht mehr nur vierstelligen Interface-Nummern der Bintec-Firmware umgehen.

```
$ bricktrace
```
```
 
```

Bintec/Funkwerk remote interface tracer ($Revision: 2.53 $)

```
 
```
```
Usage:
```

  bricktrace [opts] <routerip> [<channel> <unit> <slot> or <ifindex>]

        -h      hexadecimal output (-! for full length)

```
        -2      layer 2 output
```
```
        -3      layer 3 output
```

        -a      asynchronous HDLC (B-Channel only)

        -e      ETS300075 (EuroFileTransfer) output (B-channel only)

```
        -F      FAX (B-Channel only)
```

        -A      FAX + AT Commands (B-Channel only)

```
        -D      delta time
```
```
        -p      PPP (B-Channel only)
```

        -f      Frame Relay (B-Channel only)

```
        -i      IP output
```
```
        -N      Novell(c) IPX output
```

        -t      ascii text output (B-Channel only)

```
        -x      raw dump mode
```

        -X      asynchronous PPP over X.75

        -T <tei>        set tei filter (D-Channel only)

        -c <cref>       set callref filter (D-Channel only)

        -r <cnt>        capture only cnt bytes per paket

        -v      increase debug verbose level

        -V 1..3 trace protocol version (default: 3)

        -P<port>        specify trace tcp port (default: 7000)

        -I ipsrc:ipdst:proto:srcport:dstport      IPsession filter

        -B ip1:ip2:proto:port1:port2     bidirect IPsession filter

```
        -o      OR for LAN filter
```

        --src=<addr>    LAN filter for source MAC address

        --dst=<addr>    LAN filter for destination MAC address

        --llc           LAN filter for LLC packets

        --help          extended help (environ vars & filter)

        --vpi=<vci>     VPI for ADSL connections

        --vci=<vpi>     VCI for ADSL connections

        --ethereal      start ethereal (implies --pcap-pipe)

        --pcap-pipe     write data in pcap-format into named pipe

        --pcap-file     write data in pcap-format into file

        --ofile=<fname> out filename (pipe/file)

        --pwd=<passwd>  remote admin-password

```
 
```

        <routerip>      trace host (router's name or IP-address)

        <channel>       0 = D-Channel or no ISDN, 1..31 = Bx-Channel

```
        <unit>          0..15
```
```
        <slot>          0..9
```

        <ifindex>       interface index (instead of chan/unit/slot)

        if no chan/unit/slot or ifindex given: list all interfaces

```
 
```
```
Examples:
```

    bricktrace router                   : list all interfaces

    bricktrace router 0 1 2             : D-Channel(0) of ISDN Slot 2, Unit 1

    bricktrace router 1000              : LAN Interface 1000 (Slot 1)

    bricktrace router 100001            : virtual IPsec interface 100001

    bricktrace --ethereal router 1000   : write PCAP & start ethereal

    bricktrace --pcap-file router 1000  : write PCAP file

    bricktrace --ethereal --pcap-linktype=9 router 3000 : tracing PPPoA with VC-mux encaps in ethereal

Damit ist nun endlich auch wieder eine Analyse bei Netzwerkproblemen mit Bintec-Routern möglich.