Archiv März 2024

Donnerstag, 28. März 2024

Debian Bookworm: scp meldet „Connection closed“

Link zu diesem Artikel

Ich plane, hier einige Blog-Artikel zum Upgrade meiner Debian Bullseye-Server auf Bookworm und dabei aufgetretenen Problemen zu veröffentlichen.

Erstes Problem: Ein Cron Job, der jede Stunde ein bash-Script aufruft, lief nach dem Upgrade nicht mehr durch.

Die Fehlermeldung:

...
/usr/bin/scp: Connection closed

Auf dem Server (dem Zielsystem) wurde folgendes geloggt:

Mar 26 01:00:15 SERVER sshd[1090765]: Connection from 10.10.10.19 port 33968 on 10.10.10.102 port 22 rdomain ""
Mar 26 01:00:15 SERVER sshd[1090765]: Accepted key RSA SHA256:X found at /home/cronbackup/.ssh/authorized_keys:1
Mar 26 01:00:15 SERVER sshd[1090765]: Postponed publickey for cronbackup from 10.10.10.19 port 33968 ssh2 [preauth]
Mar 26 01:00:16 SERVER sshd[1090765]: Accepted key RSA SHA256:X found at /home/cronbackup/.ssh/authorized_keys:1
Mar 26 01:00:16 SERVER sshd[1090765]: Accepted publickey for cronbackup from 10.10.10.19 port 33968 ssh2: RSA SHA256:X
Mar 26 01:00:16 SERVER sshd[1090765]: pam_unix(sshd:session): session opened for user cronbackup(uid=1001) by (uid=0)
Mar 26 01:00:16 SERVER systemd-logind[630]: New session 1240768 of user cronbackup.
Mar 26 01:00:16 SERVER systemd: pam_unix(systemd-user:session): session opened for user cronbackup(uid=1001) by (uid=0)
Mar 26 01:00:16 SERVER sshd[1090765]: pam_tty_audit(sshd:session): changed status from 0 to 1
Mar 26 01:00:16 SERVER sshd[1090765]: User child is on pid 1090789
Mar 26 01:00:16 SERVER sshd[1090789]: Starting session: subsystem 'sftp' for cronbackup from 10.10.10.19 port 33968 id 0
Mar 26 01:00:16 SERVER sshd[1090789]: Close session: user cronbackup from 10.10.10.19 port 33968 id 0
Mar 26 01:00:16 SERVER sshd[1090789]: Received disconnect from 10.10.10.19 port 33968:11: disconnected by user
Mar 26 01:00:16 SERVER sshd[1090789]: Disconnected from user cronbackup 10.10.10.19 port 33968
Mar 26 01:00:16 SERVER sshd[1090765]: pam_unix(sshd:session): session closed for user cronbackup
Mar 26 01:00:16 SERVER sshd[1090765]: pam_tty_audit(sshd:session): restored status to 0
Mar 26 01:00:16 SERVER systemd-logind[630]: Session 1240768 logged out. Waiting for processes to exit.
Mar 26 01:00:16 SERVER systemd-logind[630]: Removed session 1240768.

Nach etwas Googlen dann die Lösung:

Note: Since OpenSSH 8.8 the scp utility uses the SFTP protocol by default. The -O option must be used to use the legacy SCP protocol.

Quelle: ssh working on all devices but scp from some devices gives „Connection closed“ error

Seit ich im bash-Script das Argument -O ergänzt habe, läuft der Cron Job wieder durch.

Tags: , , , , ,
Labels: Uncategorized

2 Kommentare | neuen Kommentar verfassen

Mittwoch, 27. März 2024

Headless Chrome verrät sich über seinen User Agent

Link zu diesem Artikel

Headless Chrome eignet sich wunderbar, wenn man Web-Seiten mittels über Cron Jobs aufgerufenen bash-Scripts automatisiert abrufen möchte.

In meinem Anwendungsfall sende ich mir an Werktagen um 9:00 Uhr jeweils das Mittagsmenu des örtlichen Metzgers per Email zu.

Dies tat ich bis vor einigen Wochen mittels wget, doch serverseitig hat irgendwas geändert, und das CMS und/oder der Serverbetreiber haben nun eine Landeseite vorgeschaltet, die überprüft, ob ein „realer“ Benutzer oder ein Bot auf die Seite zugreift.

Anstelle des gewünschten Seiteninhalts bekam ich so seither nur noch eine HTML-Seite mit viel komprimiertem JavaScript-Code zu sehen, welcher höchstwahrscheinlich für die Erkennung und Weiterleitung verantwortlich ist.

Headless Chrome half hier:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

Die Option --virtual-time-budget=5000 ist super, denn sie gaukelt vor, dass nach dem Laden 5 Sekunden vergangen sind. Genug, um die Landeseite aufzurufen, die Checks durchlaufen zu lassen, und dann den tatsächlichen gewünschten Inhalt anzuzeigen.

Das funktionierte wunderschön bis vor einigen Tagen, als kein Menu mehr via Email eintraf. Irgendwie kam auch Headless Chrome nicht mehr über die Landeseite hinaus. Doch wieso?

Bald einmal kam ich darauf: Wird Headless Chrome wie oben aufgerufen, identifiziert sich der Browser als Headless laufender Chrome (!):

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/96.0.4664.110 Safari/537.36

Kein Wunder entdeckte und blockierte die Bot-Abwehr den Zugriff.

Zum Glück war die Lösung des Problems ganz einfach:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

… und seither funktioniert das Script wieder wie gewünscht. Das Argument --user-agent="" war alles, was es dazu brauchte.

Selenium headless: How to bypass Cloudflare detection using Selenium half mir dabei auf die Sprünge.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Etwas ist sehr faul im Staate Boeing

Link zu diesem Artikel

Sehr gute Folge von Last Week Tonight with John Oliver, welche einem einen Überblick über die gewaltigen Probleme gibt, mit welchen Boeing jetzt und vermutlich für die nächste Dekade oder so kämpfen wird:

Tags: , , , ,
Labels: Wirtschaft

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Flug MH370: Alle bis heute bekannten Fakten

Link zu diesem Artikel

Dieses Jahr jährte sich das Verschwinden von Flug MH370 zum zehnten Mal.

Im Gegensatz zum Teleportationshype, der vor einigen Monaten auf Twitter und YouTube um sich gegriffen hatte, bemüht sich Mentour Pilot, Fakten zu liefern und stellt kaum irgendwelche Mutmassungen an. Bravo, sehr informatives Video:

Tags: , , , , , ,
Labels: Geschichte

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Wo ist der GRUB Bootloader alles installiert?

Link zu diesem Artikel

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

Sonntag, 10. März 2024

Bereit für den Höllensommer 2024?

Link zu diesem Artikel

Dann schauen wir doch mal, was dieser Sommer so bringt …

Beim Referenten handelt es sich um Mark Benecke, einen Kriminalbiologen. Der Vortrag fand am 5. März 2024 an der Hochschule für Finanzwirtschaft und Management in Bonn statt.

Hier das gesamte Video:

Tags: , , , , ,
Labels: Umwelt

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. März 2024

Deutschlands Energiewende, einmal aus Sicht des FOCUS, einmal aus Sicht von Forbes

Link zu diesem Artikel

Zwei Artikel, die man direkt nacheinander lesen sollte. Und man sich dann fragt, ob die Autoren auf einem anderen Planeten leben — und welcher der beiden Autoren in der Realität, und welcher im La La Land lebt:

Und heute (5. März 2024) noch dieser Artikel:

Tags: , , , , , , ,
Labels: Wirtschaft

Keine Kommentare | neuen Kommentar verfassen

Samstag, 2. März 2024

Gebrauchten Tado Wireless Smart Thermostat einbinden

Link zu diesem Artikel

Vor einigen Wochen habe ich über Tutti.ch vier gebrauchte Tado Wireless Smart Thermostate gekauft, um die restlichen Räume unserer Wohnung komplett auf diese Technologie umzurüsten. Heute endlich fand ich die Zeit, mit einem Bekannten die Feller Thermostate mit den Tado Thermostaten zu ersetzen.

Doch bereits beim ersten Thermostaten ein vorerst unlösbares Problem: Ich konnte den Thermostat nicht in den Pairing-Modus versetzen. Ich starte dazu über die App den „Add device“ modus, scannte den QR-Code auf dem Rücken des Thermostaten, und die App startete dann den Pairing-Prozess über die lokale Bridge. Jedes Mal, als ich die Thermostat-Taste für 3 Sekunden gedrückt hielt, erschien das Symbol, dass der Thermostat bereits gekoppelt sei.

Ich kontaktierte den Verkäufer, doch er sagte mir, dass er die Thermostate ordnungsgemäss aus der App entfernt hatte (offizielle Anleitung). Das erklärt meiner Meinung nach, wieso der Prozess nicht bereits beim Scannen des QR-Codes fehlschlug.

Auf Grund eines identischen Problems mit einem anderen Käufer sandte er mir aber eine Empfehlung des Tado Supports. Von mir überarbeitete Anleitung:

Pairing Reset am Thermostaten selber vornehmen: Die Taste 3 Sekunden lang gedrückt halten, bis das Paired Symbol erscheint. Taste loslassen, etwas warten, Taste noch einmal 3 Sekunden lang gedrückt halten. Auf dem Display erscheint ein Werksmenu, durch welches man mit den Auf- und Ab-Tasten scrollen kann. Dort das Symbol auswählen, welches das Paired Symbol zusammen mit einem Recycling-Pfeil zeigt. Dieses Symbol mit einem kurzen Druck auf die Taste betätigen. Danach kann der Thermostat wie ein Neugerät mit der Bridge gekoppelt werden.

Tags: , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen