Posts Tagged ‘RPi’

Sonntag, 26. März 2023

Die Log-Syntax zu geöffneten root sessions in auth.log hat sich geändert

Ich verwende monit extensiv, um viele Aspekte meines Linux-Server Fuhrparks zu überwachen.

Ein detektivischer „Sicherheitscheck“, den ich mit monit abdecke, sind Alarme zu frisch geöffneten root Sessions (der Informationssicherheits-Mensch in mir erhofft sich damit, irgendeines Tages so einen Angreifer zu entdecken):

check file su_root with path /var/log/auth.log
  if match "session opened for user root by" then alert

Ich kriege jedes Mal ein Email, wenn jemand eine root-Session eröffnet. Denn in auth.log findet sich dann jeweils folgender Eintrag:

Mar 26 13:33:16 localhost sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)

Seit einiger Zeit sind diese Emails für einige meiner Debian-Server verstummt (konkret: die x86er, während die Raspberry Pis fröhlich vor sich hermelden).

Heute machte ich mich daran, das Problem zu erforschen und zu lösen.

Erkenntnis: Die Syntax hat sich leicht geändert:

Mar 26 13:33:05 SERVER su: pam_unix(su-l:session): session opened for user root(uid=0) by mario(uid=0)

Deshalb habe ich die monit-Konfiguration angepasst:

check file su_root with path /var/log/auth.log
  if match "session opened for user root" then alert

Jetzt kommen die Alarme wieder …

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 22. März 2022

Energiewende: It’s simple Math: Mein persönlicher Lackmustest

Ich bin nicht nur nicht vor Rechenfehlern gefeit, sondern vielleicht mache ich auch Überlegungsfehler. Bitte benutzt die Kommentarfunktion, um mich auf Probleme hinzuweisen.

Ich habe grundsätzlich nichts gegen die Energiewende, doch muss allen Betroffenen klarer Wein über die Vor- und Nachteile eingeschenkt werden. Die Grenzen der Technologien müssen aufgezeigt werden, und Zukunftsprognosen sowie Wunschdenken (Prinzip Hoffnung) müssen klar getrennt werden von dem, was heute machbar ist.

Und ich behaupte hier, dass Energiewendler allzuoft die Realität schönreden, und ich unterstelle ihnen, dass sie das (mehrheitlich) bewusst tun — das heisst sie lügen.

Mein Anwendungszweck

Wieso ich den Apologeten der Energiewende bis heute nicht traue? Ich habe meinen eigenen, persönlichen Lackmustest, der mir die (heutigen) Grenze erneuerbarer Energie (fast) tagtäglich aufzeigt. Ja, es ist ein n=1 Erfahrungswert, aber für mich reicht dieser aus, um hier zu polemisieren.

Mein Setup: Ich betreibe einen Raspberry Pi (RPi) 3B, um ADS-B Signale einzufangen. Hierzu habe ich Pi24 heruntergeladen und auf die SD-Card installiert, sowie einen RTL-SDR USB-Receiver gekauft, an welchem eine empfangsstarke ADS-B Antenne hängt.

Die Antenne muss im Freien stehen, um die Signale aus möglichst allen Himmelsrichtungen empfangen zu können. Deshalb ist sie bei uns auf unserer Terrasse platziert. Den RPi möchte ich in der Nähe, sprich ein paar Meter von der Antenne entfernt, betreiben. Die Kommunikation mit dem Internet erfolgt per WLAN. Explizit möchte ich weder Strom- noch Antennenkabel in die Wohnung ziehen (Stichwort: Kältebrücke).

Der Stromverbrauch

Der RPi benötigt ungefähr 5 bis 5.5 Watt (USB, d.h. ca. 5V mit ca. 1A). Ein lächerlich geringer Stromverbrauch, könnte man meinen (ein Zwölftel der Leistung einer 60W Glühbirne aus meiner Jugend). Aber das alleine scheint es schon in sich zu haben.

Um den RPi einen Tag lang zu betreiben, benötige ich somit 5 × 24 = 120 Watt-Stunden (Wh).

Mein grünes Vorhaben

Seit Jahren träume ich davon, den RPi rund um die Uhr autonom, d.h. ohne Anschluss an das Stromnetz, zu betreiben. Die Lösung dazu liegt auf der Hand: Ein Solarpanel lädt eine Batterie, an deren USB-Anschluss hängt der RPi. Den Tag hindurch lädt die Batterie auf, in der Nacht gibt sie ihre erneuerbar generierte Stromladung ab.

Meine grüne (?) Ausrüstung

Mittlerweile bin ich dafür bei folgender Ausrüstung angekommen:

Nebenbemerkung: Man sieht es dem Titel an — wie „grün“ dieser Fuhrpark hergestellt wurde, lasse ich mal in den Raum gestellt. Sowohl das Panel als auch die Batterie wurden in China hergestellt, und danach vermutlich mit einem dieselbetriebenen Containerfrachter (Euro 0 Norm?) um die halbe Welt geschippt. Auch die lockeren Umweltvorschriften in China muss man sich hier in Erinnerung rufen. Panel und Batterieproduktion führen meines Wissens zu toxischen, umweltschädlichen Nebenprodukten. Die CO2-Bilanz dieser Produkte ist höchstwahrscheinlich fürchterlich, wie auch die lokale Umweltverschmutzungsbilanz.

Kosten-Nutzen

Insgesamt habe ich also fast 400 CHF ausgegeben, um ein Gerät rund um die Uhr mit ca. 5 Watt zu versorgen. Das sind im Jahr 5 × 8760 = 43800 Wh oder 43.8 kWh. Bei unserem Stromanbieter kostet die „dreckigste“ Kilowattstunde 22.40 Rappen (Quelle), das heisst der Stromkabelbetrieb der Installation würde mich 9.80 CHF/Jahr kosten. Damit ich mit der Solaranlage gemäss heutigen Zahlen den „break even“ erreichen würde, müsste ich diese 40.8 Jahre lang betreiben. Wetten, dass weder das Panel noch die Batterie so lange halten werden?

Unter uns: Irr. Aber die Spielerei macht es dennoch interessant.

Soviel zur reinen Kosten-Nutzen-Berechnung.

Technische Machbarkeit

Aber: Funktioniert die Lösung nun aber auch wirklich so, wie ich es mir vorstelle?

Vereinfachen wir die Situation zuerst ein wenig, damit sie einfacher fassbar wird: Wenn wir davon ausgehen würden, dass die Sonne 12 Stunden am Tag scheint, und ich mit dem Panel zu jeder Sekunde die angegebene Maximalleistung rausquetschen kann, dann reicht ein 5W Solarpanel nicht. Denn damit ist nur gerade der aktuelle Verbrauch gedeckt. Ich benötige also mindestens ein 10W Panel, welches während 12 Sonnenscheinstunden 5W an den RPi abgibt, und gleichzeitig die restlichen 5W in eine Batterie speichert. Wenn die Sonne während den restlichen 12 Stunden nicht mehr scheint, entleert sich die Batterie komplett.

Leider strotzt das Szenario vor einigen Denkfehlern: Wir müssen uns bewusst sein, dass Solarenergie (in unseren Breitengraden) vereinfacht gesagt zwei Gaussschen Glockenkurven folgt. Einerseits in der Mikro-Sicht, das heisst dem Tagesablauf. Mit einer Spitze beim höchsten Sonnenstand, vereinfacht gesagt um 12 Uhr mittags. Andererseits in der Makro-Sicht, das heisst im Jahresverlauf. Mit einer ähnlichen Spitze im Sommer.

Weatherspark hat für Orte eine Sektion „Solar Energy“, wo aufgezeigt wird, wie stark der Sonneneinfall pro Quadratmeter über das Jahr hindurch variiert (die Makro-Sicht).

Nebenbemerkung: Für Laupen (Neuenegg ist nicht auswählbar) beträgt der Unterschied zwischen dem tiefsten und höchsten Punkt fast Faktor 6. Ich deute das so, dass ich mein Panel mit der Zielleistung um diesen Faktor multiplizieren muss, um auch im Winter ausreichend Strom zu produzieren.

Weiter: Das Panel liefert am höchsten Sonnenstand und in perfekter Position vielleicht die gewünschten 10 Watt, aber eben nur gerade dann. Die Sonne scheint hier in Neuenegg nicht das ganze Jahr hindurch 12 Stunden pro Tag. Und ja, allzuoft haben wir keinen blauen, wolkenlosen Himmel, was die Leistung des Panels zusätzlich schmälert. Zudem hat mir ein Bekannter kürzlich mitgeteilt, dass es ein Irrglaube sei, dass die Panels im Sommer die höchste Leistung bringen — denn die Leistung von Solarpanels wird durch die Sommerhitze geschmälert. Wieder etwas gelernt.

Ich benötige also ein deutlich grösseres Panel, und eine deutlich grössere Batterie als eine mit 5 × 12 = 60 Wh.

Zu prüfende Hypothese

Ich habe derzeit kein Vertrauen, dass selbst die 400 CHF-Anlage im Winter mit den kurzen, nicht immer sonnigen Tagen durchgehend Strom liefern wird: Im Winter 2021/22 (Dezember bis und mit Februar) registrierte Bern 300 Sonnenstunden auf insgesamt 90 × 24 = 2160 Stunden (Quelle). Das heisst ich kann nur während 14 Prozent der Zeit mit Sonne rechnen, und in dieser Zeit muss die Batterie so weit wie möglich gefüllt werden.

Und selbst im Sommer befürchte ich reichen auch ein, zwei sonnenarme Tage, um meinen RPi wieder zurück an die Steckdose zu bringen.

Der Erfahrungsbericht folgt über das restliche Jahr verteilt.

Was hat das mit der Energiewende zu tun?

Das Problem im Kleinen lässt sich auf das Problem im Grossen übertragen: Wir können noch so viel Photovoltaik auf unsere Dächer pappen — in der Nacht und im Winter brauchen wir eine Energiequelle, die unabhängig von der Sonne Strom liefert. Sprich entweder Kraftwerke (mein Favorit: Kernkraftwerke), die egal ob Sonne oder Dunkelheit, egal ob bei Sturm oder Windstille, zuverlässig Strom liefern. Oder aber wir haben nicht nur irgendwo gigantische Batterien rumstehen, sondern sie müssen auch gefüllt sein, damit wir sie anzapfen und unseren Stromengpass überbrücken können. Korrekt: Staumauern! Im Sommer nutzen wir Solarenergie, um das Wasser hochzupumpen, im Winter verbrauchen wir das Wasser dann, indem wir es ins Tal fliessen lassen, Generatoren antreiben und den damit produzierten Strom in das Stromnetz einspeisen. Für die Überbrückung der Nacht ist das aber nicht praktikabel, oder?

Wenn ich doch auch nur das Äquivalent einer Staumauer auf meiner Terrasse installieren könnte …

Tags: , , , , , , , , , ,
Labels: Energie, Politik

3 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

Sonntag, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Raspberry Pi zeigt ständig „Can’t update Chromium“ Overlay an

Mein Dashboard zu Hause läuft auf einem Raspberry Pi 3 mit Debian Buster 10.2. Der RPi lädt beim morgendlichen Neustart um Punkt 05:00 Uhr den Chromium-Browser, welcher die Web-Site mit dem Dashboard aufruft.

Seit ein paar Tagen zeigt Chromium oben rechts ein Layover mit folgender Meldung an:

Can’t update Chromium

Chromium couldn’t update to the latest version, so you’re missing out on new features and security fixes.

(da ich selber kein Photo des Dashboards angefertigt habe, verlinke ich hier auf einen Screenshot eines anderen Benutzers aus dem Internet)

Da Debian kein Update von Chromium anbietet, hilft ein apt-get upgrade chromium hier leider nicht weiter.

Das Symptom behebt man, indem man Chromium mit einem zusätzlichen Kommandozeilenargument startet — nachfolgend ein Auszug aus /home/pi/.config/lxsession/LXDE-pi/autostart:

...
@chromium-browser --no-default-browser-check --check-for-update-interval=604800 --disable-pinch --incognito --kiosk

Den Tipp mit --check-for-update-interval=604800 (Eintrag in der Liste der Kommandozeilenargumente) habe ich auf Stack Overflow in der Frage Disable “chrome is out of date” notification gefunden.

Da man als verantwortungsvoller SysAdmin entweder Debian unattended-upgrades respektive cron-apt (Vergleich) eingerichtet hat, oder sich zumindest automatisiert über Paket-Aktualisierungen informieren lässt, ist diese Symptombekämpfung vertretbar.

Die Entwickler von Chromium könnten sich meiner bescheidenen Meinung nach überlegen, ob es nicht besser wäre, nur dann eine Meldung anzuzeigen, wenn auch tatsächlich ein Update verfügbar ist. Denn die Meldung erscheint rein basierend auf dem Alter der Applikation, nicht basierend darauf, ob eine neue Version verfügbar ist:

there’s background process that checks the build date against the current time, and will start to complain if it’s more than 12 weeks ago.

Quelle: Debian Bug report logs – #943668 Getting „Can’t update Chromium“ notifications

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. Oktober 2018

USB-Kabel ist nicht gleich USB-Kabel, oder: Wieso ein Raspberry Pi 3 einen gelben Blitz anzeigt

Von meinem Dashboard, meinem ganzen Stolz über all die Jahre, habe ich hier ja bereits mehrere Male berichtet (Ausgangspunkt).

Seit Juni 2016 verwende ich zum Betrieb des Dashboards einen Raspberry Pi 3 — und wahrscheinlich genau so lange hat das Ding mir auf dem Bildschirm einen gelben Blitz angezeigt:

Bis letzte Woche hatte ich keinen blassen Schimmer, was dieses Symbol zu bedeuten hat — nerven tat es auf jeden Fall. Doch dann stolperte ich auf Grund folgender Fehlermeldung im Debian Kernel Log (unter /var/log/kern.log) …

...
Oct  9 05:00:06 DASHBOARD kernel: [    2.116304] Under-voltage detected! (0x00050005)
Oct 10 05:00:08 DASHBOARD kernel: [    2.089827] Under-voltage detected! (0x00050005)
Oct 11 05:00:07 DASHBOARD kernel: [    2.080389] Under-voltage detected! (0x00050005)
Oct 11 05:17:06 DASHBOARD kernel: [    2.080005] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.071669] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.089371] Under-voltage detected! (0x00050005)
...

… über folgenden Artikel:

If a lightning bolt image appears in the top-right corner of the screen, it means Raspberry Pi is not getting enough voltage (4.65V according to this forum post).

Quelle: Lightning Bolt (Under-Voltage Warning) on Raspberry Pi

All die Jahre erschien dieses Symbol, aber ich realisierte nicht, dass mir mein RPi3 etwas Wichtiges damit sagen wollte!

Ich hätte das Problem wie im Artikel beschrieben mit der Quick-and-Dirty-Symptombekämpfungslösung wegmachen können (avoid_warnings=1-Eintrag in /boot/config.txt), doch ich war an der tatsächlichen Lösung des Problems interessiert: Mehr Volt für meinen RPi!

Der Raspberry Pi hängt seit 2014 an einem AOC E2460SHU Monitor, für welchen der Hersteller mit einem roten und einem Power-Schriftzug markierten USB-Anschluss wirbt (Direktlink auf das Bild). Daran konnte es doch nun kaum liegen?!

Zu Beginn der Recherche machte ich den Fehler, dass ich nach Lösungen für zu wenig Ampere (Strom) über den USB-Bus suchte. Dabei stiess ich auf folgendes Kabel („Dual Input USB Power“) und war kurz davor, es zu bestellen — bis ich mir noch einmal die Fehlermeldung zu Gemüte rief. Dort liest man nichts von „under-current“, sondern von „under-voltage“, das heisst zu tiefer Spannung!

Nach wenigen Minuten stiess ich auf unzählige Forumsbeiträge zum Thema; einen Interessanten hier:

Stutzig wurde ich, als in mehreren anderen Forenbeiträgen empfohlen wurde, nicht zuerst die Stromquelle selber als Problem zu vermuten, sondern auch das verwendete USB-Kabel genauer anzuschauen und gegebenenfalls auszuwechseln. Begleitet wurden diese Empfehlungen von Rückmeldungen vieler Benutzer, die rein mit dem Austausch des Kabels die Meldung weggebracht hatten.

Doch wieso ist das so? Folgende zwei Artikel geben Auskunft über das Phänomen:

In vielen Fällen rührt das Problem davon, dass man keine qualitativ hochstehenden USB-Kabel verwendet (ja, ich weiss, vergoldete HDMI-Kabel für 99 CHF …). Das heisst anstelle von explizit „Charging Cable“ genannten Waren nur „Data Cables“. Das Problem der qualitativ minderwertigen Kabel ist, dass sie einen zu kleinen Querschnitt und somit einen zu hohen Widerstand haben. Dies führt dazu, dass die 5V Betriebsspannung am USB-Anschluss (der Stromquelle) bis zum RPi problemlos um 0.25V bis über 0.5V abnehmen kann — und somit wie oben genannt weniger als 4.65V beim Raspberry Pi ankommen (Grafik).

Kann wirklich das USB A-auf-USB Mikro-Kabel das Problem sein?! Offenbar schon, wenn man folgenden Artikel in einem RPi-Forum durchliest: Best Micro USB cables

Ein gutes Kabel erkennt man, wenn es einen Aufdruck mit einem numerisch tiefen AWG-Wert enthält.

Zurück von der Arbeit durchsuchte ich meinen USB Mikro ZIP-Lock-Sack. Rasch musste ich feststellen, dass kaum (mehr) Kabel einen AWG-Wert angeben. Einige wenige Kabel hatten einen Aufdruck, und ich machte mich daran, das bis heute genutzte USB-Kabel des RPi auszutauschen.

  1. Das erste Kabel war fälschlicherweise ein USB A- auf USB Mini-Kabel (statt Micro). Dabei wäre es perfekt gewesen: 28AWG/1P+24AWG/2C plus zusätzlich ein Ferritkern an einem Ende.
  2. Das zweite Kabel mit 26AWG/1P 26AWG/2C wäre brauchbar gewesen, doch leider scheint es defekt zu sein — der RPi3 tat keinen Wank, weshalb ich auf Kabelbruch tippte.
  3. Das dritte Kabel funktionierte schlussendlich. Es ist sehr, sehr kurz und trägt den Schriftzug 28AWG/1P and 28AWG/2C. Zuerst befürchtete ich, dass dies bereits ein zu hoher AWG-Wert ist — doch der gelbe Blitz ist seither nicht mehr sichtbar.

Kabel Nummer 1:

Kabel Nummer 2:

Kabel Nummer 3:

Nachtrag 1

Ich muss noch bemerken, dass ich das Kabel seit langem nicht mehr direkt in den USB-Port des Monitors einstecke, sondern noch ein USB-Winkelstück (90 Grad; männlich, weiblich) gekauft habe, damit das Kabelende nicht so hässlich am oberen Ende des Monitors heraussticht. Ein solches Stück kann selbstverständlich auch noch zu Spannungsverlusten führen; in meinem Fall ist der Verlust zusammen mit einem qualitativ hochstehenden Kabel aber offenbar vernachlässigbar.

Nachtrag 2

Leider sind die Kernel-Meldungen nicht ganz weg. Seit Austausch des Kabels habe ich in kern.log folgende Einträge gefunden:

...
Oct 16 19:18:55 DASHBOARD kernel: [  370.259369] Under-voltage detected! (0x00050005)
Oct 16 19:20:06 DASHBOARD kernel: [  440.980952] Under-voltage detected! (0x00050005)
Oct 16 20:31:53 DASHBOARD kernel: [ 4748.658891] Under-voltage detected! (0x00070005)
Oct 16 20:38:41 DASHBOARD kernel: [ 5156.348023] Under-voltage detected! (0x00050005)
Oct 16 20:49:53 DASHBOARD kernel: [ 5828.208492] Under-voltage detected! (0x00070005)
Oct 16 20:53:00 DASHBOARD kernel: [ 6015.403857] Under-voltage detected! (0x00070007)
...

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

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 7. März 2018

Folien meines Lightning Talks zum Thema „RPi Dashboard“ (Backup)

Da letzte Woche die Web-Site der bernischen Lightning Talks offline gegangen ist, habe ich mich entschieden, den Foliensatz meines Vortrages vom 17. März 2014 auf meinem Blog zu Archivzwecken aufzuschalten:

2014-03-14-dashboard-lightning-talk.pdf

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 29. Juli 2017

Backup der Raspberry Pi SD-Karte anfertigen

Kürzlich hatte ich während eines Anfalls aus geistiger Umnachtung versucht, meinen Raspberry Pi 3 von Raspbian Jessy auf Raspbian Stretch zu „lüpfen“. Scheiss-Idee. Im Gegensatz zu Debian ist Raspbian Stretch leider noch nicht stabil genug, um auf einem produktiven Raspberry Pi zu laufen.

Nicht nur das, es war tatsächlich so, dass ich zwar seit wohl fünf Jahren hier in der Wohnung einen Raspberry Pi betreibe — und nicht wusste, dass man auf einfachste Weise eine Kopie einer sauber aufgesetzten Raspbian-Installation anfertigen kann.

Das Vorgehen ist im Internet mehrfach beschrieben; ich habe mich an den Artikel Back-up a Raspberry Pi SD card using a Mac gehalten.

Das Vorgehen:

  1. Raspberry Pi herunterfahren
  2. Die SD-Karte mit einer Pinzette aus dem Gerät holen
  3. Die SD-Karte mit einem Adapter an einen Mac (oder Linux-Rechner) anschliessen
  4. Mit diskutil list oder df die Device-Adresse der SD-Karte herausfinden; in meinem Fall /dev/rdisk4
  5. Die gesamte SD-Karte in eine Datei auf dem lokalen Mac klonen:
    # dd if=/dev/rdisk4 of=~/Desktop/emeidi-dashboard.img bs=1m

Fertig! Verbockt man sich in Zukunft den Raspberry Pi, schliesst man einfach wieder die SD-Karte an den Mac an und schreibt das Image zurück.

Dies funktioniert auch wieder auf der Kommandozeile mit dd (mit umgekehrten if– und of-Parametern), doch hier war ich zu Faul und habe stattdessen das quelloffene Etcher mit graphischer Oberfläche und Fortschrittsanzeige verwendet.

Übrigens: Nachdem ich das Image testhalber auf eine zweite SD-Karte zurückgeschrieben und verifiziert hatte, dass der Raspberry Pi 3 vom Backup bootet, habe ich das Image mit ZIP komprimiert und so eine Platzreduktion von 50 Prozent hingekriegt.

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 21. Januar 2016

smokeping auf einem Raspberry Pi installieren

Gestern habe ich einen verstaubten Raspberry Pi 1 aus meinem Endlager für obsolete IT-Hardware gerettet und ihn als arpwatch-Überwachungsstation aufgesetzt. Auf dem Gerät läuft folgendes Debian:

Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux

Etwas später stiess ich in Vorbereitung auf meinen Wechsel von upc cablecom zu Fiber7 auf den Artikel Fiber7 performance, in welchem Michael Stapelberg aufzeigt, wie sich die Latenz seiner Internetverbindung nach dem Wechsel von Swisscom auf Fiber7 verbessert hat.

Gedacht — getan: So etwas benötige ich natürlich auch, um meinen bevorstehenden Providerwechsel mit harten Fakten zu untermauern — wobei, ehrlich gesagt, ist mir die Latenz nicht so wichtig (bin kein Gamer), sondern viel mehr der vierfache Durchsatz und die symmetrische Down- und Upload-Geschwindigkeit zum selben Preis wie beim Kabelriesen.

Nichtsdestotrotz installierte ich mir also das Softwarepaket smokeping und seine Dependencies, wie das berühmte rrdtool aus dem Hause Oetiker:

# apt-get update
...
# apt-get upgrade
...
# apt-get install smokeping

Es wurde zwar alles nett installiert, doch konnte ich danach noch nicht auf die Web-Oberfläche unter http://localhost/smokeping/smokeping.cgi zugreifen. Unter einem x86-64 Debian war das nach der Installation automatisch möglich.

Zuerst wohl mal den Apache starten, dachte ich mir:

# /etc/init.d/apache2 start

Der Web-Server kam hoch, zeigte unter http://localhost/ die obligate Startseite an, doch unter dem Smokeping-Link kam ich statt der Smokeping-Oberfläche nur einen HTTP 403er zu Gesicht (mangels Screenshot und Text-Kopie mittels Auszug aus dem Apache error.log unter /var/log/apache2/):

...
[Wed Jan 20 22:52:59.338858 2016] [authz_core:error] [pid 2706:tid 3036673072] [client 10.0.1.101:56967] AH01630: client denied by server configuration: /usr/lib/cgi-bin/smokeping.cgi
...

Oookey … da ich smokeping auch noch auf einem „richtigen“ Linux-Server im Elternhaus laufen hatte, kopierte ich kurzerhand dessen VirtualHost-Konfiguration auf den Raspberry Pi (natürlich als Symlink auf conf-available):

# cat /etc/apache2/conf-enabled/smokeping.conf 
ScriptAlias /smokeping/smokeping.cgi /usr/lib/cgi-bin/smokeping.cgi
Alias /smokeping /usr/share/smokeping/www

<Directory "/usr/share/smokeping/www">
    Options FollowSymLinks
</Directory>

<Directory "/usr/lib/cgi-bin/">
    Options FollowSymLinks
    Require all granted
</Directory>

Noch ein …

# apache2ctl graceful

… und der 403er war weg. Das smokeping-GUI wurde aber weiterhin nicht angezeigt, sondern nur der Inhalt des CGI-Scripts im Klartext:

#!/bin/sh

exec /usr/share/smokeping/smokeping.cgi /etc/smokeping/config

Was zur Hölle … ? Doch auch diesem Fehlverhalten schaffte ich nach 15 Minuten googlen, Artikel lesen und pröbeln den Garaus: Ein simples

# a2enmod cgi

Via: Perl Apache : Perl script displayed as plain text

reichte aus, und plötzlich führte Apache das CGI-Script aus. Halleluja!

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

Keine Kommentare | neuen Kommentar verfassen