Archiv ‘Linux’

Samstag, 14. Juni 2025

Ein ZTE MF79U 4G USB-Modem unter Debian zum Laufen bringen

Ich habe mir kürzlich über Amazon ein ZTE MF79U 4G Mobilfunkmodem gekauft. Zusätzlich dazu noch eine Digitec IoT SIM mit 0.4 MBit/s (Anbieter: digital republic), welche im Jahr mit 44 CHF zu buche schlägt.

Einsatzzweck: Out-of-band (OOB) Lösung an einem WLAN-Travelrouter einer Bekannten. Der Router verbindet sich als WLAN-Client mit einem WLAN-Netzwerk eines Drittanbieters (analog zu einem Gäste-WiFi in einem Hotel), welches quartalsweise ein neues WLAN-Passwort erhält (ja, der Anbieter ist noch nicht auf die Idee gekommen, das WLAN zu öffnen und stattdessen mit Portal-Technologie zu arbeiten, welche einzelne Clients mit Benutzernamen und Passwort authentifziert).

Ich möchte damit künftig vermeiden, dass ich vor Ort das WiFi-Kennwort anpassen gehen muss, damit sich der WLAN-Travelrouter wieder mit dem WLAN-Netzwerk der Institution verbindet.

Der Plan ist, dass künftig auf dem Travelrouter basierend auf OpenWRT über das 4G-Interface ein Reverse SSH Tunnel zu einem meiner Server geöffnet wird, über welchen ich dann aus der Ferne auf den Router und das Web-Interface zugreifen kann (meines Wissens könnte ich das Kennwort vermutlich auch auf der Kommandozeile wechseln, aber soweit bin ich noch nicht).

Gestern habe ich den USB-Stick an einem Debian-Server in Betrieb genommen. Was ich dabei gelernt habe:

Das Teil findet man sofort nach Anschluss mittels lsusb:

# lsusb
...
Bus 001 Device 006: ID 19d2:1405 ZTE WCDMA Technologies MSM ZTE Mobile Boardband

Die Bedeutung der Produkt-ID 1405 ist hier dokumentiert: ZTE MF 823 (Megafon M100-3) 4G Modem

1405

A communication mode in which the device has a wikipedia:USB communications device class interface in addition to the card reader interface. Communications Device Class (CDC) should work in Linux. The cdc_ether kernel module is required. This mode will be the one usb_modeswitch will switch the device into.

Der Stick stellt auch ein Block-Device (Speicher) zur Verfügung; das ist nur unter Windows nützlich, weil sich auf dem Datenträger die Treiber für den Stick finden. Clever!

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sr0     11:0    1   6.8M  0 rom
# blkid
...
/dev/sr0: BLOCK_SIZE="2048" UUID="2022-06-21-14-31-58-00" LABEL="ZTEMODEM" TYPE="iso9660" PTTYPE="mac"

Der USB-Stick spannt ein eigenes WLAN-Netzwerk auf, sobald er Strom hat. IP-Adressbereich ist 192.168.0.1/24. Die SSID und das Kennwort findet man unter der Abdeckung des Sticks, welche einem Zugang zum physischen SIM-Slot erlaubt.

Der Stick hat eine Weboberfläche unter http://192.168.0.1/, mit welcher man alle möglichen Einstellungen vornehmen kann. Das admin-Kennwort ist ebenfalls unter der Abdeckung aufgedruckt.

Ich musste meines Wissens eine Runde in der Web-Oberfläche drehen und die (bereits aktivierte) SIM-Karte einschalten, sonst hätte sich der Stick nicht mit dem Internet verbunden.

Der Clou: Verbindet man Geräte mit dem WiFi des USB-Sticks, können alle Geräte über die Mobilfunkverbindung ins Internet. Gemäss Web-Oberfläche ist die Zahl der Clients auf 10 beschränkt, diese Zahl scheint aber anpassbar zu sein.

Unter Debian wird der Stick problemlos auch als USB-basiertes Ethernet-Interface erkannt (Treiber: cdc_ether:

# lsmod | grep -i ether
cdc_ether              24576  0
usbnet                 57344  1 cdc_ether
usbcore               348160  8 ehci_pci,usbnet,usb_storage,uvcvideo,ehci_hcd,cdc_ether,uas,uhci_hcd
# ip a
...
5: enx344b50000000:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 34:4b:50:00:00:00 brd ff:ff:ff:ff:ff:ff

Damit man den Laptop über dieses Interface mit dem Internet verbinden kann, muss folgendes geschehen:

  • Interface hochbringen: ip link set enx344b50000000 up
  • IP-Adresse beziehen: dhclient enx344b50000000 -v
# dhclient enx344b50000000 -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   Socket/fallback
DHCPDISCOVER on enx344b50000000 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.0.169 from 192.168.0.1
DHCPREQUEST for 192.168.0.169 on enx344b50000000 to 255.255.255.255 port 67
DHCPACK of 192.168.0.169 from 192.168.0.1
bound to 192.168.0.169 -- renewal in 38135 seconds.

Sobald der Server eine IP in der 192.168.0.1/24-Range besitzt, sollte man über dieses Interface ins Internet rauspingen können:

# ping -I enx344b50000000 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.0.169 enx344b50000000: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=177 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=18.2 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 18.203/97.527/176.851/79.324 ms

Die Frage ist nun, ob diese Schritte an einem OpenWRT-Router automatisiert werden kann.

Nachteil: Der Stick selber macht NAT, und somit kann man in Double-NAT-Situationen landen. Einige Sticks scheinen einen Bridge-Mode zu besitzen, doch diese Option habe ich bei meinem Stick nicht gefunden.

Nachtrag

Ich habe unter Linux beim rumpröbeln einige Pakete installiert, weiss aber nicht, ob das nötig gewesen wäre:

  • usb-modeswitch
  • ppp
  • libnss-myhostname
  • libnss-resolve
  • modemmanager

Tags: , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 25. März 2025

systemctl befindet sich bei unterschiedlichen Debian-Versionen an verschiedenen Orten

Kürzlich habe ich auf einem meiner Linux-Server einen Service nachgerüstet, welchen ich mit monit überwache, und gegebenenfalls neu starte.

Beim ersten Absturz des Services erhielt ich von monit folgende Fehlermeldung:

Execution failed Service homebridge 

	Date:        Mon, 24 Mar 2025 22:49:48
	Action:      alert
	Host:        SERVER
	Description: failed to start (exit status -1) -- Program /usr/bin/systemctl failed: File '/usr/bin/systemctl' does not exist

Your faithful employee,
Monit

Die Konfiguration hatte ich von einem anderen Linux-System kopiert, unter welchem Neustarts problemlos funktionierten.

Was ich nach etwas debuggen herausgefunden habe:

  • Unter Debian 11 (Kernel 5.10) befindet sich systemctl unter /bin/systemctl
  • Unter Debian 12 (Kernel 6.1.115-1) befindet sich systemctl unter /usr/bin/systemctl

Nachdem ich in der monit-Konfiguration den Pfad angepasst habe, funktioniert das Neustarten des Services nun problemlos.

Tags: , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Wo ist der GRUB Bootloader alles installiert?

Vor einigen Wochen spukte eine SSD in einem meiner physischen Servern. Ich entschied mich, eine neue SSD zu kaufen, den kompletten Inhalt der alten SSD auf die neue SSD zu klonen, und dann die neue SSD als neue Festplatte in den Server einzubauen (die alte SSD wanderte ins Archiv).

Als ich gestern das Debian GNU/Linux auf diesem Server aktualisierte, bemerkte Debian, dass es auf einer neuen SSD lief, und fragte mich, wo ich den GRUB Bootloader überall installieren wollte (/dev/sda, das heisst auf der Festplatte selber, plus /dev/sda1, auf der ersten (Boot-)Partition).

GRUB war natürlich bereits installiert, sonst hätte der Server nach dem SSD-Wechsel nicht gebootet — aber vermutlich war in der GRUB-Konfiguration noch die Referenz auf die alte SSD enthalten und nicht auf die neue.

Überfordert entschied ich mich wie im Dialog angeregt, den Bootloader sowohl auf /dev/sda als auch /dev/sda1 zu installieren. Das sei die sicherste Methode.

Später dann fand ich nach einer mehrminütigen Internetsuche heraus, wie ich bei einem „baugleichen“ Server hätte nachschauen können, wo der Bootloader alles installiert ist:

# debconf-show grub-pc
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline_default: quiet
  grub-pc/timeout: 5
* grub2/linux_cmdline:
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline_default: quiet
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/install_devices_failed_upgrade: true
  grub2/force_efi_extra_removable: false
  grub-pc/disk_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/kopt_extracted: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/update_nvram: true
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_empty: false
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/hidden_timeout: false

Sprich: Nur auf /dev/sda.

Auf dem Server mit der ausgewechselten SSD schaut es nun halt leider so aus:

# debconf-show grub-pc
* grub-pc/install_devices: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/install_devices_empty: false
  grub2/force_efi_extra_removable: false
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
* grub2/linux_cmdline:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/mixed_legacy_and_grub2: true
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/timeout: 5
  grub2/kfreebsd_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub2/update_nvram: true
  grub-pc/disk_description:
  grub-pc/hidden_timeout: false
  grub-pc/kopt_extracted: false
* grub2/linux_cmdline_default: consoleblank=60
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:

Sprich: Man sieht, dass der Bootloader sowohl auf die Festplatte, als auch die erste Partition („part1“) installiert wird.

Tags: , , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 6. September 2023

Postfix: Wartende ausgehende Emails löschen

Gestern habe ich auf einem Linux-System durch einen dummen Programmierfehler einen endlosen For Loop generiert, welcher tausende Emails mit dem selben Inhalt an meine persönliche Email-Adresse absetzte.

Zum Glück habe ich den lokalen Postfix so konfiguriert, dass er die Emails in für meinen Hoster in homöopatischen Dosen rauslässt (main.cf):

...
# Rate Limiting / Throttling
# default_destination_rate_delay = seconds between two emails
initial_destination_concurrency = 1
default_destination_concurrency_limit = 1
default_destination_rate_delay = 20
default_destination_recipient_limit = 2
default_process_limit = 1

Während also alle paar Sekunden die Unfall-Mails in der INBOX aufpoppten, entschied ich mich, auf den Heimserver einzuloggen und kurzerhand die ganze Postfix-Queue zu löschen.

Das ist ganz einfach:

# postsuper -d ALL

Quelle: How to Flush the Mail Queue in Postfix

Bei der Aktion wurden über 4000 auf den Versand wartende Emails gelöscht …

Tags: , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 19. Juni 2023

Apaches gehärtetes mod_rewrite strauchelt über Leerzeichen (%20)

Seit einem kürzlichen Update Apaches findet sich in den Apache Error Logs vieler Web-Applikationen folgende Fehlermeldung:

[Sat Jun 17 20:23:52.123046 2023] [rewrite:error] [pid 553164] [client 1.2.3.4:49928] AH10411: Rewritten query string contains control characters or spaces

Scripts funktionieren nicht mehr, und Browser zeigen Fehlermeldungen an, wenn man bestimmte URLs aufruft.

Des Rätsels Lösung: Ist mod_rewrite aktiviert, und enthält die umzuschreibende URL ein HTML-enkodiertes Leerzeichen (%20), erachtet das „gehärtete“ Apache dies als Sicherheitsrisiko und blockiert den Request.

Der Workaround: Das mod_rewrite-Flag [B] (Dokumentation) muss in die .htaccess gepfriemelt werden, wie in AH10411 error: Managing spaces and %20 in apache mod_rewrite empfohlen:

RewriteRule ^ajax/(.*) /ajax.php?q=$1 [B]

Als Person, die in der Informationssicherheit arbeitet, bin ich mir aber nicht ganz sicher, ob die Apache-Jungs diese „Sicherheitsverbesserung“ wirklich bis zum Ende durchdacht haben. Ich habe das Gefühl, dass man mit diesem Flag viele Installationen unsicherer macht …

Tags: , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 18. Juni 2023

Unter macOS GNU-Tools statt FreeBSD-Tools verwenden

macOS ist seit 2005 das Betriebssystem meiner Wahl.

Ich arbeite viel auch auf der Kommandozeile und schreibe hin und wieder Scripts, um Prozesse zu automatisieren. Dabei laufe ich immer wieder in das Problem hinein, dass macOS mit FreeBSD Kommandozeilen-Tools daherkommt, und viele Anleitungen im Internet GNU Tools referenzieren.

Oftmals verhalten sich diese Tools glücklicherweise identisch — aber eben nicht immer.

Da hilft es, wenn man MacPorts installiert hat: In vielen Fällen reicht es, dem eigentlichen Namen des Tools „g“ voranzustellen, um die von MacPorts installierte GNU-Version anstelle Apples FreeBSD-Version laufen zu lassen.

Soeben war das ganz nützlich, als ich einen Szene isch Züri Telegram-Kanal-Video-Extraktor programmiert habe:

  • gdate --date="7 days ago" +%Y-%m-%d
  • gtouch /tmp/2023-06-11 -d 2023-06-11

Tags: , , , ,
Labels: Apple, IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Ein Base64-enkodiertes Zertifikat im Klartext ausgeben

Wer ein Zertifikat im folgenden Format angezeigt erhält …

-----BEGIN CERTIFICATE-----
MIIFsDCCBJigAwIBAgISBMA6IcCIbuwMyJ+i4d6Wv7mOMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MTcwNzQ3MjZaFw0yMTEyMTYwNzQ3MjVaMCAxHj...

… macht es folgendermassen lesbar (certificate-b64.crt mit dem Pfad zum zwischengespeicherten Zertifikat ersetzen):

$ openssl x509 -in certificate-b64.crt -text -noout

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. September 2021

Wie man unter Debian „E: Broken packages“ am einfachsten löst

Release-Upgrades von Debian GNU/Linux-Kisten sind immer so eine Sache. Bei der Migration von Stretch auf Bullseye stand ich vor folgendem Problem:

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  apt apt-utils cpp gcc libmariadb-dev
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
# apt upgrade apt
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apt : Depends: libapt-pkg6.0 (>= 2.2.4) but it is not going to be installed
       Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
 apt-utils : Depends: apt (= 1.8.2.3) but 2.2.4 is to be installed
E: Broken packages

Wie ich endlich, nach all den Jahren herausgefunden habe, löst man solche Probleme am einfachsten mit dem Downgrade eines oder mehrerer Pakete. Dies, indem man apt-get install %paketname%=%versionsnummer% ausführt.

Welches Paket man im obigen Fall downgraden muss? Gar nicht so einfach. Irgendeinmal hatte ich es dann doch herausgefunden:

# apt-get install gcc-10-base=10.2.1-6

Danach flutschte apt-get upgrade durch.

Nachtrag 1

Gerade wieder ein solches Problem:

# apt-get dist-upgrade
...
The following packages have been kept back:
  locales
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Manueller Versuch:

# apt-get upgrade locales
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc-bin : Depends: libc6 (> 2.32) but 2.31-13+deb11u2 is to be installed
E: Broken packages

Von welcher Version sprechen wir?

# dpkg --list | grep -i locales
...
ii  locales                        2.31-17                        all          GNU C Library: National Language (locale) data [support]
...

Welche Version ist stable für meine aktuelle Distribution?

# cat /etc/debian_version 
11.1

Debian 11 ist Bullseye, also gehen wir rüber zu packages.debian.org und sehen, dass die aktuelle stabile Version Package: locales (2.31-13+deb11u2) ist. Somit:

# apt-get install locales=2.31-13+deb11u2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be DOWNGRADED:
  locales
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 1 not upgraded.
Need to get 4,082 kB of archives.
After this operation, 2,048 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 locales all 2.31-13+deb11u2 [4,082 kB]
Fetched 4,082 kB in 0s (11.1 MB/s)
Preconfiguring packages ...
dpkg: warning: downgrading locales from 2.31-17 to 2.31-13+deb11u2
(Reading database ... 139926 files and directories currently installed.)
Preparing to unpack .../locales_2.31-13+deb11u2_all.deb ...
Unpacking locales (2.31-13+deb11u2) over (2.31-17) ...
Setting up locales (2.31-13+deb11u2) ...
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
Processing triggers for man-db (2.9.4-2) ...

Und Feierabend.

Nachtrag 2

Kürzlich ist das Problem wieder einmal aufgetreten:

# apt-get upgrade libfido2-1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libfido2-1 : Depends: libc6 (>= 2.33) but 2.31-13+deb11u2 is to be installed
E: Broken packages
# dpkg --list | grep libfido2-1
ii  libfido2-1:amd64               1.9.0-1                        amd64        library for generating and verifying FIDO 2.0 objects

Nun, da schauen wir mal, welche Version dieses Pakets aktuell ist: packages.debian.org meldet für Debian Bullseye (11) Version 1.6.0-2 als aktuell. Somit downgrade initiieren:

# apt-get install libfido2-1=1.6.0-2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libcbor0.8
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  libcbor0
The following NEW packages will be installed:
  libcbor0
The following packages will be DOWNGRADED:
  libfido2-1
0 upgraded, 1 newly installed, 1 downgraded, 0 to remove and 1 not upgraded.
Need to get 77.3 kB of archives.
After this operation, 37.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 libcbor0 amd64 0.5.0+dfsg-2 [24.0 kB]
Get:2 https://debian.ethz.ch/debian bullseye/main amd64 libfido2-1 amd64 1.6.0-2 [53.3 kB]
Fetched 77.3 kB in 0s (436 kB/s)      
Selecting previously unselected package libcbor0:amd64.
(Reading database ... 145105 files and directories currently installed.)
Preparing to unpack .../libcbor0_0.5.0+dfsg-2_amd64.deb ...
Unpacking libcbor0:amd64 (0.5.0+dfsg-2) ...
dpkg: warning: downgrading libfido2-1:amd64 from 1.9.0-1 to 1.6.0-2
Preparing to unpack .../libfido2-1_1.6.0-2_amd64.deb ...
Unpacking libfido2-1:amd64 (1.6.0-2) over (1.9.0-1) ...
Setting up libcbor0:amd64 (0.5.0+dfsg-2) ...
Setting up libfido2-1:amd64 (1.6.0-2) ...
Processing triggers for libc-bin (2.31-17) ...
[ Rootkit Hunter version 1.4.6 ]
File updated: searched for 180 files, found 147

libc-bin war auf demselben System auch störrisch:

# apt-get upgrade libc-bin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc-bin : Depends: libc6 (> 2.33) but 2.31-13+deb11u2 is to be installed
E: Broken packages
# dpkg --list | grep libc-bin
ii  libc-bin                       2.31-17                        amd64        GNU C Library: Binaries

packages.debian.org meldet als aktuelle Version 2.31-13+deb11u2, somit auch hier ein Downgrade:

# apt-get upgrade libc-bin=2.31-13+deb11u2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be DOWNGRADED:
  libc-bin
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 817 kB of archives.
After this operation, 1,024 B disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 libc-bin amd64 2.31-13+deb11u2 [817 kB]
Fetched 817 kB in 0s (3,055 kB/s)
dpkg: warning: downgrading libc-bin from 2.31-17 to 2.31-13+deb11u2
(Reading database ... 145105 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.31-13+deb11u2_amd64.deb ...
Unpacking libc-bin (2.31-13+deb11u2) over (2.31-17) ...
Setting up libc-bin (2.31-13+deb11u2) ...
Processing triggers for man-db (2.9.4-2) ...
[ Rootkit Hunter version 1.4.6 ]
File updated: searched for 180 files, found 147

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 19. September 2021

Von Stretch nach Bullseye mit gravierenden Problemen

Gestern lüpfte ich einen zweiten OpenVPN-Server von Debian Stretch auf Bullseye.

Das erfolgte leider nicht kurz- und schmerzlos. Ich kämpfte mit und debuggte während 16 Stunden (abzüglich 7 Stunden Schlaf) an folgenden Problemen:

Konsolen-, SSH- und Telnet-Logins dauern 1min30sec

D.h. nach Eingabe des Passwortes scheint das System zu hängen. Wer sich in Geduld übt, landet nach eineinhalb Minuten in der gewohnten Shell.

Bei mir bildeten sich in diesen ersten 90 Sekunden bereits viele Schweissperlen, denn wie flickt man ein Debian GNU/Linux, wenn man sich nicht mehr einloggen kann? Mittels grub in den Single User/Recovery Mode zu booten wäre ein noch grösserer Alptraum geworden …

Meldungen in syslog:

...
Sep 18 22:40:43 OPENVPN2 systemd[1]: Starting User Manager for UID 1000...
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Main process exited, code=exited, status=1/FAILURE
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89451 (gpgconf) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89452 (awk) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89457 (dirmngr) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89452 (awk) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89457 (dirmngr) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Failed with result 'exit-code'.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Unit process 89452 (awk) remains running after unit stopped.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Unit process 89457 (dirmngr) remains running after unit stopped.
Sep 18 22:42:13 OPENVPN17 systemd[1]: Failed to start User Manager for UID 1000.
...

Die Lösung:

# apt-get remove gpgconf
...
The following packages will be REMOVED:
  dirmngr duplicity gnupg gnupg-agent gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libgmime-2.6-0 libgpgme11
  libnotmuch4 mutt python3-gpg samba-dsdb-modules scdaemon

Die vielen zu deinstallierenden Pakete liessen mich kurz zweifeln, aber das System lief nach deren Deinstallation problemlos weiter.

Quelle: WireGuard Bounce Server Setup

Wobei, wenn ich die Kommentare so lese: Eventuell war gpgconf gar nicht das Problem, sondern der Nameserver, der nicht reagierte (siehe unten).

Netzwerkprobleme

Probleme mit named und localhost

BIND 9 ist zwar an localhost (127.0.0.1) gebunden und lauscht auf dem Interface …

# lsof -i :53
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
named   653 bind   23u  IPv4  15673      0t0  UDP localhost:domain 
named   653 bind   24u  IPv4  15679      0t0  UDP localhost:domain 
named   653 bind   25u  IPv4  15680      0t0  TCP localhost:domain (LISTEN)
named   653 bind   27u  IPv4  15681      0t0  TCP localhost:domain (LISTEN)
named   653 bind   29u  IPv4  15682      0t0  UDP 10.1.2.3:domain 
named   653 bind   30u  IPv4  15683      0t0  UDP 10.1.2.3:domain 
named   653 bind   31u  IPv4  15684      0t0  TCP 10.1.2.3:domain (LISTEN)
named   653 bind   32u  IPv4  15685      0t0  TCP 10.1.2.3:domain (LISTEN)

… aber die Namensauflösung funktioniert nicht. Wenn man mit telnet 127.0.0.1 53 eine Session aufbauen will, hängt die Verbindung.

Mittels strace analysierte ich dann was im Hintergrund genau vor sich ging, und verglich die Ausgabe mit einem strace auf einem Server, bei dem die Namensauflösung funktionierte:

Defekter Server:

# strace ping -c 1 emeidi.com
...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1631995746, tv_nsec=794103764}) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "{\311\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 0 (Timeout)
clock_gettime(CLOCK_REALTIME, {tv_sec=1631995747, tv_nsec=795739261}) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "{\311\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 0 (Timeout)
close(5)                                = 0
...

Funktionierender Server:

# strace ping -c 1 emeidi.com
...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "UK\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [463])               = 0
recvfrom(5, "UK\201\200\0\1\0\1\0\r\0\r\6emeidi\3com\0\0\1\0\1\300\f\0\1"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [28->16]) = 463
poll([{fd=5, events=POLLOUT}], 1, 999)  = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "W}\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\34\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 998)   = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [278])               = 0
recvfrom(5, "W}\201\200\0\1\0\0\0\0\0\r\6emeidi\3com\0\0\34\0\1\1a\fr"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [28->16]) = 278
close(5)                                = 0
...

Macht man dasselbe mit der internen IP des Servers (bspw. 10.1.2.3) kann eine Session aufgebaut werden. Die Namensauflösung konnte ich nicht durchführen, weil mir der oder die Befehle nicht geläufig waren — im Nachhinein aber las ich dann, dass es sich bei DNS-Abfragen nicht um Klartextkommandos handelt.

Nun gut, dies bewog mich zu einem Workaround, ohne das eigentliche Problem zu beseitigen. Ich passte kurzerhand meine /etc/resolv.conf an:

#nameserver 127.0.0.1
nameserver 10.1.2.3

options timeout:1
options single-request

Ich vermutete zuerst Probleme in systemd-resolved. Installieren resp. entfernen tut man das Paket mit:

# apt-get install libnss-resolve
# apt-get remove libnss-resolve

Ist das Paket installiert, hat man neben /etc/resolv.conf auch noch Konfigurationen in /etc/systemd/resolved.conf und /run/systemd/resolve/resolve.conf. Typischer systemd-Wahnsinn. (siehe dazu Ubuntu – 18.04 Unable to connect to server due to “Temporary failure in name resolution” sowie Ubuntu 18.04 DNS resolution fails after a while)

Als ich systemd-resolved mit meinen Pröbelein zerschossen hatte, tauchten in /var/log/syslog noch folgende Fehlermeldungen auf:

Sep 18 20:35:04 localhost dbus-daemon[329]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.15' (uid=0 pid=2015 comm="resolvectl ")
Sep 18 20:35:04 localhost dbus-daemon[329]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.

Siehe auch Activation via systemd failed for unit ‚dbus-org.freedesktop.resolve1.service‘: Unit dbus-org.freedesktop.resolve1.service not found

Site-to-site OpenVPN erlaubt Pings in nur eine Richtung

Die Sache wurde immer mysteriöser: Aus dem entfernten Subnetz, in welchem der hier Probleme verursachende Server steht, konnte ich problemlos zur anderen Site pingen. Sowohl den VPN-Endpunkt, als auch alle anderen IPs im Subnetz hier. Das funktionierte auch von anderen Geräten im entfernten Subnetz aus.

Doch im Umkehrschluss funktionierte das nicht; d.h. von meinem Heimnetzwerk konnte ich nur den OpenVPN-Endpunkt pingen, aber nichts im entfernten Subnetz. Die ICMP-Pakete kamen zwar beim Zielgerät an (bspw. dem Internet-Router), dieser antwortete, aber das Antwortpaket wurde dann von auf dem entfernten OpenVPN-Endpunkt nicht von eth0 auf tun0 weitergeleitet.

Immerhin lernte ich für das Debugging nützliche tcpdump-Befehle kennen:

# tcpdump -n icmp and host 10.1.2.1
# tcpdump -i tun0 -n icmp and host 10.1.2.1
# tcpdump -i eth0 -n icmp and host 10.1.2.1

Die Ausgabe ist auch deshalb hilfreich, weil derselbe ping-Prozess immer dieselbe id trägt. Und die Sequenznummern sieht man auch gleich angezeigt. So konnte man isolieren, wo genau die ICMP-Pakete „verloren“ gingen respektive noch durchkamen.

Ausserdem kann man iptables so konfigurieren, dass sie verarbeitete Pakete ins syslog loggen (eine Regel iptables -I FORWARD -i eth0 -o tun0 -j ACCEPT existiert dabei schon und ist aktiv):

# iptables -I FORWARD -i eth0 -o tun0 -j LOG --log-prefix "OUTGOING "
# iptables -I FORWARD -i tun0 -o eth0 -j LOG --log-prefix "INCOMING "

Das Logging wird deaktiviert, indem man die Regel wieder entfernt:

# iptables -D FORWARD -i eth0 -o tun0 -j LOG --log-prefix "OUTGOING "
# iptables -D FORWARD -i tun17 -o eth0 -j LOG --log-prefix "INCOMING "

In dmesg entdeckte ich dann auch noch folgende Fehlermeldungen, was mich bewog, den Kernel zu aktualisieren:

...
cgroup2: unknown option "nsdelegate,memory_recursiveprot"
...

Die finale Lösung: Aktualisiere von Kernel-Version 4.9.0-16 auf 5.10.46-4, und Neustart.

# apt-get install linux-image-amd64

Tags: , , , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 14. September 2021

„Welcome to Raspberry Pi“ Installationshelfer nicht mehr anzeigen

Hierzu löscht man folgende Datei: /etc/xdg/autostart/piwiz.desktop

Quelle: Disable „Welcome to Raspberry Pi“ setup wizard at system start

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen