Die ersten Erfahrungen mit einem Raspi durfte ich dank einem Geschenk machen.
Informationen zur Installation eines Raspis sind auf einer separaten Seite vorhanden.
Unten beschreibe ich die bisherigen Erfahrungen damit; Probleme und deren Lösungen inklusive.
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_keysDa 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 Bund 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_keysDamit 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 fiNach 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 closedMittels '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.
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...