Archiv September 2021

Mittwoch, 29. September 2021

UniFi Network App wird unter iOS 15 mit Spotlight nicht (mehr) gefunden

Scheint ein iOS 15-Problem zu sein: Wenn ich UniFi in der Spotlight-Suche eingebe, erscheinen massenhaft Einträge. Nur nicht die App selber.

Ich bin mit dem Problem nicht allein, und es ist auch schon anderen Leuten aufgefallen. Wenn ich doch nur wüsste, auf welchem Screen sich die App befindet …

Tags: ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Elgato Key Light Air wird von Control App unter iOS und macOS nicht mehr erkannt

Gestern fand die Elgato Control App unter iOS mein Elgato Key Light Air plötzlich nicht mehr im Netzwerk. Auch die nachträglich installierte Control App unter macOS Big Sur meldete kein Licht zur Steuerung.

Ich setzte das Licht mehrere Male zurück, und verband es mit Müh und Not wieder mit dem WLAN. Das alles half nichts.

Mysteriös: Mein DHCP-Server erteilte dem Licht eine statische IP, und ich konnte die Lampe von allen Geräten aus auch pingen. Doch die Control App sah die Lampe nicht; ich vermute, dass es ein Problem mit Apples Bonjour gab.

Einige Ansätze: UniFi AP-AC-PRO Not Crossing mDNS/Multicast/Broadcast between 2.4GHz and 5GHz Networks?, iTunes Remote Multicast / Bonjour 2.4/5GHz Radio Issue).

Das Schlimmste am Ganzen: Das Licht verfügt einzig über einen Ein- und Ausschalter. Das Licht selber kann man aber nur über die App steuern (Helligkeit, und Lichttemperatur).

Auch der Trick mit der manuellen Anpassung von Settings.xml (auch: Elgato Control Center Settings.xml) funktionierte nicht, weil sich unter macOS keine solche Datei findet. Immerhin fand ich das Einstellungsverzeichnis (~/Application Support/com.corsair.ControlCenter), und (jetzt erst beim Schreiben des Blog-Artikels) die Einstellungsdatei (~/Preferences/com.corsair.ControlCenter.plist)

Was genau das Problem verursacht hat, kann ich nicht mit Sicherheit sagen. Aber allenfalls hat ein mehrmaliger Reboot meiner UniFi-Access Points während der Debugging-Übung das Problem unbeabsichtigt gelöst.

Doch zu dem Zeitpunkt hatte ich mir auf Basis von Automating Elgato Key Lights From macOS Touch Bar bereits selbst geholfen. Folgende zwei Scripts lassen einen die Lampe einschalten und eigene Lichtwerte einstellen, sowie die Lampe ausschalten:

on.sh

#!/bin/bash

IP="1.2.3.4"

BRIGHTNESS="100" #max
TEMPERATURE="256" #max

if [ $# -gt 0 ]
then
    BRIGHTNESS="$1"
fi

if [ $# -gt 1 ]
then
    TEMPERATURE="$2"
fi

DATARAW="{\"lights\":[{\"brightness\":$BRIGHTNESS,\"temperature\":$TEMPERATURE,\"on\":1}],\"numberOfLights\":1}"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw "$DATARAW"
echo ""

exit 0

off.sh

#!/bin/bash

IP="1.2.3.4"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw '{"lights":[{"on":0}],"numberOfLights":1}'
echo ""

exit 0

Als nächstes würde es mich reizen, für den Geschäftslaptop diese Funktionalität auch gleich noch auf die Touchbar zu legen, wie im Artikel weiter unten beschrieben

Mittlerweile „sendet“ die Lampe (wieder) unter Bonjour. Discovery.app zeigt folgenden Eintrag an:

_elg._tcp. - 1 item
Elgato
elgato.local.
1.2.3.4:9123
[fe80::]:9123
mf=Elgato
dt=200
id=3C:6A:9D:00:00:00
md=Elgato Key Light Air 123456789
pv=1.0

Unter Linux mit installierten avahi-utils kann man vermutlich mit folgendem Befehl dieselbe Information extrahieren:

$ avahi-browse -a

Tags: , , , , , , , ,
Labels: Home Automation, IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Danfoss-Ventil wieder an den Radiator anbringen

Der Umzugstermin naht in Riesenschritten. Zeit, die smarte Netatmo-Radiatorsteuerung rückzubauen.

Die Netatmo-Ventile kriegt man relativ einfach vom Radiator weg. Doch dann gibt es Probleme, die auf dem Estrich zwischengelagerten Danfoss-Ventile wieder anzubringen. Irgendwie wollen sie sich einfach nicht über das runde Metallelement schieben lassen. Ein im Ventil drinnen herausstehendes Metallstück verhindert dies.

Die Zeit tickt, ich höre, wie sich der Radiator mit Warmwasser füllt.

Nach viel Kopfzerbrechen und Tüfteln dann die Lösung: Man greift mit je einer Hand die beiden Enden des Ventils, und dreht sie voneinander weg (als ob man ein nasses Frotteetuch ausdrehen möchte). Der Metallstift verschwindet, und das Ventil lässt sich problemlos anbringen.

Man beachte jetzt nur noch, dass die Einkerbungen auf dem Metallstück des Radiators mit den Ausbuchtungen auf dem Ventil übereinstimmen.

Geschafft!

Tags: , ,
Labels: Home Automation

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

Mittwoch, 29. September 2021

New York: Ungeimpfte Pfleger weg, National Guard übernimmt

… währenddessen uns in der Schweiz eingetrichtert wird, dass man Pflegepersonal (insbesondere IPS-Personal) nicht aus dem Boden stampfen könne und dies der limitierende Faktor für die Erhöhung der Intensivbetten sei.

Eine Seite lügt, aber welche?

Dann schauen wir mal, wie sich der Staat New York mit Reservisten am Krankenbett so schlägt.

Und wer weiss, vielleicht kommen auf diesem Weg ja sogar entlassene Pfleger über die Hintertür wieder rein.

Nachtrag

(unverifiziert) Es wird immer kurioser: Eine Twitter-Benutzerin behauptet, dass die National Guard des Staates New York bis Juni 2022 von der Impfpflicht befreit ist:

Dies wird durch den Artikel COVID News: US military branches set vaccination deadlines von ABC bestätigt. Aber: Hochul won’t let unvaccinated National Guard members fill nursing gap despite deadline.

Tags: , , , , ,
Labels: Gesundheit, USA

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. September 2021

Apple produziert Dinge, die (vorerst) niemand will

“What makes the iPhone and perhaps Apple special is that it seems to deliver things that nobody asks for but then everybody wants while eschewing overshooting a performance dimension that a few demand but most won’t use.”

Quelle: The Most Important iPhone Ever

Tags: , , , , ,
Labels: Arbeit

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

Freitag, 17. September 2021

Kein Witz: Tigris holt Ex-Geliebte von Alain „Tigrillo“ Berset ab

Halt! Gemäss Ringier-Sprech darf es natürlich nicht „Ex-Geliebte“ heissen, sondern „Bekannte“:

Eine Bekannte des Innenministers Alain Berset (49) ist rechtskräftig verurteilt worden, weil sie erfolglos versucht hatte, 100’000 Franken vom SP-Bundesrat zu erpressen.

Quelle: Bundesanwaltschaft will Sonderermittler einsetzen

Zurück zum Thema: Alain Berset verwendet(e?) gemäss Weltwoche-Artikel den Email-Alias alaintigrillo für seine Schürzenjagden. Tigrillo ist ein anderer Name für das zentralamerikanische Tier Oncilla (Leopardus tigrinus).

Und jetzt der Hammer: Die Ex-Geliebte Bekannte wurde nach dem Erpressungsversuch von der Einsatzgruppe Tigris abgeholt. Denn:

Die Einsatzgruppe wird beigezogen, wenn im Einzelfall mit einem erhöhten Risiko von Gewaltanwendung gerechnet werden muss.

Mein Fazit: Irgendwie enthält die Story einfach zu viele Tiger, als dass es reiner Zufall sein könnte. Das ist alles ein abgekartetes Spiel. Ergo: #tiggergate

Tags: , , , , , , , , , , , ,
Labels: Politik, Schweiz

1 Kommentar | neuen Kommentar verfassen

Freitag, 17. September 2021

„Sturm“ auf’s Bundeshaus folgt dem Sturm auf’s Capitol

Nach der Lektüre Reto Nauses Tweet (a propos: Ich kaufe noch ein „s“) erwartete ich das schlimmste, in etwa so:

… und insbesondere das:

Quelle: Capitol rioter in horned hat gloats as feds work to identify suspects

Was ich stattdessen zu sehen bekam:

Da haben uns Reto Nause und die Polizei Bern noch einmal aber wirklich haarscharf vor dem Armageddon, dem Super-GAU, bewahrt.

PS: Der folgende Kommentar liess mich Schmunzeln:

Nachtrag

Mit am Zaun rütteln und 1. August-Feuerwerk abfeuern wurde EINE ROTE LINIE überschritten, so Sandro Broz:

Passend dazu:

Tags: , , , , , , , , , , ,
Labels: Politik, Schweiz

Keine Kommentare | neuen Kommentar verfassen