Raspi - Erfahrungen mit einem Raspberry Pi 4 B

Raspi - Erfahrungen mit einem Raspberry Pi 4 B

Die ersten Erfahrungen mit einem Raspi durfte ich dank einem Geschenk machen.

Am 15. Januar 2024 habe ich einen neuen Raspi 4 B erhalten inklusive dem empfohlenen offiziellen Netzteil:
- Raspberry Pi 4GB Model B
- Official Raspberry Pi 4 Power Adapter USB-C Weiss
Unten beschreibe ich die bisherigen Erfahrungen damit; Probleme und deren Lösungen inklusive.

Installation

Der neue Raspi 4B hat 4GB RAM und zum Glück lag noch eine neue SD-Karte mit 32GB Speicher herum. Unter Windows lud ich von der Webseite https://www.raspberrypi.com/software/operating-systems/ das Raspberry Pi OS (64-bit) [Raspbian Debian 12 bookworm] herunter.
Mit dem erhaltenen 'Raspberry Pi Imager' wurde die SD-Karte beschrieben. Achtung: Beim 'Imager' sollten alle 'Reiter' angeklickt werden, da man dort z.B. wählen kann, ob SSH installiert und aktiviert werden soll und die Passwörter (Benutzer und WLAN) setzen kann!
Die SD-Karte kann dann auf der Unterseite der Platine eingeschoben werden und nachdem die Stromzufuhr eingeschaltet wurde, schaute ich auf dem ISP-Router nach, welche IP-Adresse er erhalten hat. Da bei der Installation bereits ein User inkl. Passwort gewählt werden konnte, gelang kurze Zeit später ein Login via ssh user@IP .

cgi-Scripte funktionieren unter Raspbian nicht
Nach der Installation von apache2
sudo apt-get install apache2
funktionierten die unter /usr/lib/cgi-bin abgelegten cgi-Scrips nicht: Error 404 Not Found :-(
Ein Test mittels "curl localhost/cgi-bin/temperature.cgi" ergab denselben Fehler.
Die Lösung war:
- 1. Wegen dem Aufruf /usr/bin/vcgencmd measure_temp musste der Benutzer www-data im File /etc/group in die Gruppe video eingefügt werden
- 2. Unter root Eingabe von: "a2enmod cgid" gefolgt von "systemctl restart apache2"
--> nun funktionieren die CGI-Scripte. :-)

Login via SSH ohne Passwort
Normalerweise kann das passwortlose Login via SSH zwischen zwei Rechnern A und B recht einfach hergestellt werden:

Auf Rechner A:
   cd .ssh
   ssh-keygen -t rsa   --> generiert die beiden Files id_rsa und id_rsa.pub
   scp -p id_rsa.pub B:.ssh/id_rsa.pub_A
Auf Rechner B:
   cd .ssh
   cat id_rsa.pub_A >> authorized_keys
   ssh-keygen -t rsa   --> generiert die beiden Files id_rsa und id_rsa.pub
   scp -p id_rsa.pub A:.ssh/id_rsa.pub_B
Auf Rechner A:
   cd .ssh
   cat id_rsa.pub_B >> authorized_keys
Da wir mittlerweile auf beiden Rechnern via SSH eingeloggt waren, wird die "Vertrauensfrage" nicht mehr gestellt und die beiden Hosts sind gegenseitig in den Files ~/.ssh/known_hosts eingetragen. FERTIG! :-)

Login via SSH ohne Passwort will einfach nicht funktionieren!
Bei mir klappte trotz oben beschriebenen Verfahrens die Sache in einem Fall einfach nicht. Rechner A hat "Debian Jessie" installiert und Rechner B "Raspberry Pi OS Bookworm"; was für ein lästiges Problem: Stets wurde beim SSH-Login nach dem Passwort gefragt. Schliesslich versuchte ich vom Rechner A aus ein Login wie folgt:

ssh -vvv B
und analysierte die ausführlichen Meldungen. Mittels Google-Recherche stiess ich auf die Seite https://www.deployhq.com/support/projects/uploading-a-custom-key-pair und fand folgende Lösung:
Auf Rechner A:
   cd .ssh
   ssh-keygen -t ed25519 -m PEM   -->  generiert die beiden Files id_ed25519 und id_ed25519.pub
   scp -p id_ed25519.pub B:.ssh/id_ed25519.pub_A
Auf Rechner B:
   cd .ssh
   cat id_ed25519.pub_A >> authorized_keys
   ssh-keygen -t ed25519 -m PEM   --> generiert die beiden Files id_ed25519 und id_ed25519.pub
   scp -p id_ed25519.pub A:.ssh/id_ed25519.pub_B
Auf Rechner A:
   cd .ssh
   cat id_ed25519.pub_B >> authorized_keys
Damit funktionierte das gegenseitige Einloggen auf beiden Rechnern mittels SSH ohne Passwortabfrage einwandfrei - puhhh - endlich!

Programm convert gibt Fehlermeldung
Für die Umwandlung von Graphik-Files (z.B. PostScript in png) benutze ich sehr oft das Programm convert. Obwohl das Paket ImageMagick installiert war, kam beim Aufruf von convert eine Fehlermeldung von wegen Sicherheitsproblemen.
Im File /etc/ImageMagick-6/policy.xml wurde die Zeile
  <!-- <policy domain="coder" rights="none" pattern="PS" /> -->
auskommentiert und wie folgt ersetzt:
  <policy domain="coder" rights="read|write" pattern="PS" />
Seither funktioniert convert wie gewünscht!

Ende Februar 2024 funktioniert (nach einem upgrade) das Programm 'convert' wiederum nicht. Abhilfe: Erneute Instatallation mittels
apt-get install imagemagick
- Im File /etc/ImageMagick-6/policy.xml die sechs Zeilen ab
policy domain="coder" rights="none" pattern="PS"
ersetzt durch
policy domain="coder" rights="read|write" pattern="PS"
und dann funktioniert 'convert' wieder!

ssh spezielle.domain.ch gibt Fehlermeldung wegen /etc/resolv.conf
Um Code einzusparen, habe ich in etlichen Shell-Scripts den Befehl
scp -p file rechner.spezielle.domain.ch abgekürzt durch
scp -p file rechner .
Aus diesem Grund wurde im File /etc/resolv.conf folgende Änderung in der Zeile mit 'search' vorgenommen:
  # search home
  search spezielle.domain
  nameserver 192.168.0.1
Nach jedem Reboot (und vermutlich gelegentlich auch zwischendurch) wurde diese Modifikation wieder rückgängig gemacht. Es gäbe hier einige 'Abwehrmassnahmen', die im Internet zu finden sind. Da dieser Raspi stets im denselben Netzwerk betrieben wird, wurde folgende simple Massnahme getroffen:
  chmod u-w /etc/resolv.conf
Damit kann dieses File von niemandem mehr modifiziert werden:
  ls -l /etc/resolv.conf
  -r--r--r-- 1 root root 81 Jan 21 09:24 /etc/resolv.conf
Sollte dies wider erwarten nicht funktionieren, werde ich hier weiter darüber berichten.
Update vom 26.1.2024: Dies hat leider *nicht* funktioniert: Mitten im Editieren eine Files war die Verbindung plötzlich unterbrochen - nach einer Weile konnte dann mit dem Editieren trotzdem weitergemacht werden, doch der raspi war zwischendurch nicht erreichbar. Das File /etc/resolv.conf war danach modifiziert und für root wieder beschreibbar... unglaublich!
LÖSUNG: Im File /etc/hosts wurde nun eine neue Zeile eingefügt:
IP-Nummer rechner # ohne ".spezielle.domain.ch"
Nun kann   ssh rechner   eingegeben werden und es funktioniert! :-)

Betrachten von PNG-Bildern
In den letzten Jahren benutzte ich für das Betrachten von Bildern und Graphiken im Format *.png meistens das Programm 'feh'. Dieses ist in Debian GNU/Linux 12 (bookworm) nicht mehr vorhanden und daher benutze ich nun das Programm 'gpicview'.
Nachtrag: 'feh' kann installiert werden, allerdings hängt es nach dem Aufruf... :-(

Vergrössern von Graphiken
Eine Möglichkeit, eine Graphik zu vergrössern ist:
convert -scale 200% rain_temp.ps rain_temp.png
doch die Qualität ist nicht eben gut.
--> atp-get install psutils
--> psresize ... Mhh, in meinem Fall hat das nicht gut geklappt; vorerst!

Automatische Bewässerung des Gartens
Dieses laufende Projekt wird hier beschrieben. Ein Raspi mit Shellys eignet sich hierzu bestens!

Redundanz bzw. Hochverfügbarkeit der Haussteuerung
Seit dem 21. Februar 2024 experimentiere ich mit einem Hochverfügbarkeits-System, bei dem zwei Raspis sicherheitshalber die Steuerung der Hausautomatik (Storen, Gartenbewässerung, etc.) übernehmen, um gegen mögliche Ausfälle gewappnet zu ein.

/etc/resolv.conf ist plötzlich leer
In den frühen Morgenstunden des 23. Feb. 2024 war das File /etc/resolv.conf plötzlich leer und daher fehlte dort auch der Eintrag mit dem Nameserver - sehr ärgerlich!! Als Abhilfe wurden in einem Script, das die Hochverfügbarkeit alle zwei Minuten testet, folgende Zeilen eingefügt:


grep -q 192.168.0.1 /etc/resolv.conf
if test $? -ne 0 ; then
      echo "`uname -n`: /etc/resolv.conf ist 'leer' - Neustart! `date +%d.%m.%Y_%H:%M`"
      sudo shutdown -r 0
fi
Nach dem Neustart des Systems ist das File /etc/resolv.conf wieder wie im Originalzustand!

kex_exchange_identification: Connection closed by remote host
Seit einiger Zeit erhalte ich Fehlermeldungen beim Kopieren von Files via 'scp' auf einen externen Webserver:


kex_exchange_identification: Connection closed by remote host
Connection closed by XXX.YYY.ZZZ.AAA port 22
scp: Connection closed
Mittels 'ls -l' erhalte ich Datum und Zeit des Error-Logfiles, allerdings nur auf die Minute genau. Um diese Zeit mit dem Logfile /var/log/auth.log auf dem Web-Server vergleichen zu können, benötige ich eine genauere Zeit; siehe unten.
Nun (25.3.24) versuche ich den kex_exchange_identification-Fehler mittels 'retry' wie folgt zu vermeiden:
retry -d 1 -t 2 scp -p -o ConnectTimeout=5 file.to_send webserver:/path

File-Datum und -Zeit genauer als eine Minute
Mittels dem Befehl ls --full-time file.name erhält man die exakte Zeit (inkl. Sekundenbruchteile) des Entstehen des Files (file creation time).

...more to come...


Last Update: 25Mar2024 - Created: 15Jan2024 / uk