Linux

Syncthing – Cloud-Synchronisation ohne Cloud

by

Ich würde meine wichtigen Daten nie in der Cloud speichern, also verzeiht bitte den Titel, der vielleicht irreführend ist.

Vor kurzem bin ich auf dieses Tool gestoßen. Ich hatte schon vor einiger Zeit davon gehört, aber heute habe ich beschlossen, es auszuprobieren. Zuvor habe ich Tools wie bsync, unison und andere verwendet. Ich war mit keinem von ihnen wirklich zufrieden und kehrte oft zu rsync zurück. Mit Syncthing habe ich nun jedoch ein Tool gefunden, das ich in meiner gesamten Infrastruktur einsetzen möchte.

Das Tool ist für Linux, Windows und offenbar auch für macOS verfügbar. Die beiden letztgenannten Betriebssysteme konnte ich nicht testen, aber ich glaube, dass es auf ihnen genauso gut funktioniert.

Ich verwende es, um Daten zwischen verschiedenen Systemen zu synchronisieren. Und was soll ich sagen, es funktioniert wunderbar und sehr schnell.

Bei meiner Einrichtung war es wichtig, dass keine externen Relay-Server verwendet werden. Auf diese Weise kann ich sicherstellen, dass die Synchronisierung autonom erfolgt, was meiner Meinung nach auch die Sicherheit etwas erhöht.

Ebenso wichtig sind die Ausschlüsse, die gesetzt werden sollten, wenn bestimmte Dateitypen nicht synchronisiert werden sollen. In meinem Fall sind dies Ausgabedateien von verschiedenen Compilern wie gcc und g++, die in der Regel eine Menge Objektdateien (*.o) erzeugen.

Schnelle Übertragungen mit dd und loop-devices

by

Bei der Verwendung von dd stelle ich oft verschiedene Festplattenparameter ein. Auch wenn die Einstellmöglichkeiten nicht sehr auffällig sind, hängt die Übertragungsgeschwindigkeit letztlich vor allem von der verwendeten Hardware ab.

Die folgenden Parameter haben sich für mich bei der Arbeit mit Loopback-Geräten bewährt:

dd if=/dev/sdf2 of=/dev/loop0p2 status=progress bs=64K oflag=direct oflag=direct

Emacs: Signatur archive-contents.sig konnte nicht verifiziert werden

by

Heute erhielt ich die Nachricht

Failed to verify signature archive-contents.sig

von meinem Emacs nach der Eingabe von package-list-packages. Der vollständige Fehler ist unten aufgeführt:

Failed to verify signature archive-contents.sig:
No public key for 645357D2883A0966 created at 2024-04-22T11:05:03+0200 using EDDSA
Command output:
gpg: Signature made Mon Apr 22 11:05:03 2024 CEST
gpg: using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
gpg: Can't check signature: No public key

Es scheint, dass ich elpa-Pakete nicht mehr installieren kann.

Nach einiger Recherche bekam ich den Tipp, gnu-elpa-keyring-update mit dem Emacs-Paketmanager zu installieren, um dieses Problem zu lösen.

Das hört sich einfach an, aber vor der Installation eines Pakets musste ich vorübergehend die folgende Variable setzen, um den Keyring-Check zu deaktivieren:

(setq package-check-signature nil)

Danach rufe ich wieder package-list-packages auf und installiere
gnu-elpa-keyring-update.

Um auf Nummer sicher zu gehen, habe ich Emacs neu gestartet und der Fehler war weg.

Einrichten einer statischen Route in Debian-Linux

by

Einfache Netzwerkrouten können unter Linux mit dem Befehl route gesetzt werden. Hier ist ein einfaches Beispiel:

route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.0.1

Damit diese Änderung auch nach einem Neustart aktiv ist, muss die Datei /etc/network/interfaces geändert werden.

iface ens192 inet static
   address 192.168.0.156/24
   up /bin/ip route add 10.25.20.0/24 via 192.168.0.1

Wie kann man die Umgebung eines laufenden (übergeordneten) Prozesses unter Linux ändern?

by

Dies ist eigentlich nicht beabsichtigt, und es gibt keine saubere Möglichkeit, dies zu tun.

Es ist jedoch möglich, eine Umgebungsvariable eines bestehenden Prozesses mithilfe eines Debuggers zu ändern.

Konkret geht es hier um den Debugger namens gdb. Dieser kann sich an bestehende Prozesse anhängen und verschiedene Operationen durchführen. Unter anderem auch das Ändern von Umgebungsvariablen.

Um sich mit einem laufenden Prozess zu verbinden, müssen Sie gdb installiert haben und die entsprechende Prozess-ID (PID) kennen. Im folgenden Beispiel ist die ID 2811:

gdb --pid=2811

Der Debugger meldet sich dann mit dem GDB-Prompt:

(gdb) call putenv ("MYVAR=1234")

Im oberen Beispiel finden Sie auch den Befehl, mit dem die Umgebungsvariable des Prozesses gefunden werden kann. In diesem Fall wird die Variable MYVAR auf den Wert 1234 gesetzt.

Bitte beachten Sie, dass der entsprechende Prozess angehalten wird, sobald gdb mit dem Parameter --pid gestartet wird. Sobald die Variable gesetzt ist, kann der Debugger mit den Tasten q und Enter wieder beendet werden – der Prozess läuft dann weiter.

Das Ganze ist aber nur ein schmutziger Hack und sollte nicht in einer produktiven Umgebung eingesetzt werden.

apt-file – Programme in APT/Debian-Repositories finden

by

Kürzlich stellte ich auf einem frisch installierten Server fest, dass es keinen Befehl namens nslookup gab. Glücklicherweise verfügen Debian-ähnliche Distributionen über das Werkzeug apt-file.

Damit ist es möglich, nach Anwendungen zu suchen, die noch nicht installiert, aber im Prinzip im APT-Repository verfügbar sind. Der Befehl

apt-file search nslookup

brachte schnell Klarheit in die Angelegenheit und lieferte das folgende Ergebnis:

bash-completion: /usr/share/bash-completion/completions/nslookup
bind9-doc: /usr/share/doc/bind9-doc/arm/man.nslookup.html
dnsutils: /usr/bin/nslookup
dnsutils: /usr/share/man/man1/nslookup.1.gz
exim4-doc-html: /usr/share/doc/exim4-doc-html/spec_html/ch-the_dnslookup_router.html
fpc-source-3.0.4: /usr/share/fpcsrc/3.0.4/packages/fcl-net/examples/cnslookup.pp
libnet-nslookup-perl: /usr/share/doc/libnet-nslookup-perl/changelog.Debian.gz
libnet-nslookup-perl: /usr/share/doc/libnet-nslookup-perl/copyright
libnet-nslookup-perl: /usr/share/lintian/overrides/libnet-nslookup-perl
libxpa-dev: /usr/share/man/man3/xpanslookup.3.gz

Es war also klar, dass das dnsutils-Paket nachträglich installiert werden musste
danach. Aufruf von

apt-get install dnsutils

reichte aus, und das nslookup-Tool war bereits auf meinem Server vorhanden.

Wenn apt-file selbst noch nicht installiert ist, kann man es vorher installieren mit

apt-get install apt-file

Es ist wichtig, dass der Cache unmittelbar danach eingerichtet wird. Dies geschieht mit

apt-file update

Übertragen von Dateien mit Netcat/nc

by

Einzelne Dateien können auch mit netcat übertragen werden. Dazu müssen die
Dazu müssen auf dem Sender und dem Empfänger die folgenden Anweisungen befolgt werden:

Auf dem Empfänger:

nc -l -p 8888 -w 5 > dest < /dev/null

Beim Absender:

nc servername 8888 < source

Erläuterung: Der Empfänger startet einen Serverdienst, der auf den ersten Teilen basiert,
der auf Anfragen am TCP-Port 8888 reagiert. Mit der Anweisung > dest wird der Inhalt der empfangenen Daten in eine Datei mit dem Namen dest geschrieben.

Der Dateitransfer wird auf dem Sender durch die Eingabe der zweiten
Anweisung gestartet. Hierbei wird eine Verbindung mit dem Server servername über Port 8888 initiiert und die Datei source übertragen.

Die Datei wird unverschlüsselt und unkomprimiert übertragen. Mit Werkzeugen wie gzip und openssl könnte dies transparent umgesetzt werden.

Erzeugen von Spektrogrammen mit arecord, sox und ffmpeg/avconv

by

Erstellen eines Spektrogramms (Bild)

Der folgende Befehl zeichnet eine WAV-Datei mit ALSA (Device 2.0) auf.
In diesem Beispiel wird Sox in den Prozess eingefügt – was in diesem Fall eigentlich unnötig ist – aber dennoch verwendet werden könnte, um verschiedene Filter auf die resultierende test.wav-Datei anzuwenden:

arecord -D hw:2,0 -r 32000 -f S16_LE -c 1 -t wav | sox -t wav -c 1 -L -b 16 -r 32000 - test.wav

Mit der neu erstellten Datei test.wav kann nun ein Spektrogramm erstellt werden:

sox test.wav -n spectrogram -o image.png

Der folgende Befehl erstellt eine WAV-Datei mit Alsa (Device 2.0). In diesem
Fall wird zusätzlich Sox über die Pipeline geleitet, was hier völlig unnötig ist,
Allerdings könnte Sox der resultierenden test.wav noch verschiedene Filter hinzufügen
ändern:

arecord -D hw:2,0 -r 32000 -f S16_LE -c 1 -t wav | sox -t wav -c 1 -L -b 16 -r 32000 - test.wav

Mit der soeben erstellten Datei test.wav wird nun ein Spektrogramm erzeugt:

sox test.wav -n spectrogram -o image.png

Ein ähnliches Spektrogrammbild kann mit avconv direkt aus einer Videodatei erstellt werden:

avconv -i test.avi -lavfi showspectrumpic=s=hd480:legend=0,format=yuv420p out.png

Erstellen eines Spektrogramms (Video)

Die folgende Anweisung erstellt ein Spektrogramm aus einem Video test.avi. Dieses wird als Video unter dem Namen out.avi gespeichert.

Anstelle von avconv hätte auch ffmpeg verwendet werden können. Die Debian-Version unterstützt hier derzeit nicht alle Parameter.

Alternativen mit MPlayer und Sox

Sie können auch ein Spektrogramm aus einem Video mit mplayer oder einer Kombination aus mplayer und sox erzeugen.

Extrahieren Sie zunächst eine WAV-Datei mit mplayer:

mplayer test.mp4 -ao pcm:file=/dev/stdout -vo null > test.wav

Erstellen Sie dann das Spektrogramm:

sox test.wav -n spectrogram -o test.png

Vergleich von Spektrogrammen:

Auf diese Weise erstellte Spektrogramme können direkt verglichen werden.
Doch selbst bei scheinbar identischen WAV-Dateien kann dieser Vergleich schwierig sein.

Um Unterschiede besser sichtbar zu machen, empfiehlt es sich, ein Spektrogramm diff zu erstellen.

Erstellen Sie zunächst eine Diff-WAV-Datei:

sox -m -v 1 source1.wav -v -1 source2.wav diff.wav

Dann erzeugen Sie das Spektrogramm diff:

sox diff.wav -n spectrogram -o diff.png