Posts Tagged ‘Raspberry Pi’

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

Sonntag, 25. Februar 2018

Einen Raspberry Pi mit autonomer Stromversorgung betreiben

(Kontext: Mit einem Raspberry Pi, DVB-T-Stick und Flightradar 24 einen Hobby-ADS-B Empfänger aufbauen)

Wie im oben verlinkten Blog-Post beschrieben muss sich die Antenne im Freien befinden, um den bestmöglichen Empfang der ADS-B-Signale zu realisieren.

Bevor ich entdeckte, dass das DVB-T-Antennenkabel problemlos durch einen Fensterrahmen geführt werden kann und das Schliessen des Fensters überlebt, machte ich mir Gedanken, wie man Antenne UND den Raspberry Pi zusammen auf dem Balkon der Mietwohnung installieren könnte.

Das grösste Problem war hierbei die Stromversorgung, da sich auf unserem Balkon kein Stromanschluss befindet.

Stromverbrauch

Gemäss der Web-Seite Solar Power for Raspberry Pi verbraucht mein Raspberry Pi 1, Model B, mindestens 480mA, was einem Tagesverbrauch von 57.6Wh entspricht.

Ein anderer Artikel Power Consumption berechnet mindestens 220mA, wenn man den HDMI-Port deaktiviert und die LEDs ausschaltet (wie man das macht, ist in diesem Artikel beschrieben: Raspberry Pi Zero – Conserve power and reduce draw to 80mA).

Der DVB-T-USB-Dongle verbraucht gemäss (geleaktem?) Data Sheet des Chip-Herstellers maximal 178mA.

Der bei einem Outdoor-Betrieb zwingend nötige WLAN-USB-Dongle sollte dann auch noch dazugerechnet werden. In meinem Fall hatte ich geplant, einen ZyXEL NWD2205-Stick zu verwenden. Gemäss Datenblatt saugt das Ding 315mA beim Senden und 250mA beim Empfangen.

Zusammengerechnet hätte dies also in einem Verbrauch von 480 + 178 + 315 = 973 mA oder 0.973A entsprochen — multipliziert mit 5V also genau 4.865 Watt.

Da ich den Raspberry Pi mittlerweile mittels Power-over-Ethernet PoE mit Strom versorge (hierzu verwende ich einen Uctronics U5159 Umwandler, der aus dem Ethernet-Kabel den Strom extrahiert, transformiert und dann mit 5V und bis zu 2.4A auf einen Micro-USB-Port ausgibt — bspw. erhältlich auf Amazon.com für $10), kann ich über den Unifi Controller sehen, wie viel Leistung das Ding zieht: 5.31 Watt. Es kann aber gut sein, dass diese Messung durch den UniFi-Switch sowie auch den Uctronics stark verfälscht wird.

USB-Powerbanks?

Von dieser Lösung nahm ich rasch Abstand, da gewisse Dinger mit 10000, 15000 oder gar 20000 mAh zwar ordentlichen Stromspeicher besitzen, aber trotzdem nicht geeignet sind:

  • Wie lädt man die Dinger auf — musste man mindestens zwei Powerbanks anschaffen sie täglich rotieren? Das kam für mich nicht in Frage.
  • Sind sie für den Aussenbetrieb geeignet, d.h. verkraften sie Temperaturen wie jetzt gerade bis zu minus 5 Grad in der Nacht?

Solar!

Nach einigen Überlegungen kam ich dann auf die naheliegende Lösung: Solarstrom!

Zwar gibt es bei Amazon haufenweise Powerbanks mit integriertem Solarpanel (sogar eine mit 20000mAh, derzeit aber vergriffen) (Digitec hat auch einige, bspw. Sandberg Outdoor Solar (16000mAh, Solarbetrieb) sowie DÖRR Solar Powerbank SC-10000 black (10000mAh, Solarbetrieb)), doch nach einiger Lektüre im Netz kam ich zum Schluss, dass die Dinger nicht für einen 24/7-Betrieb eines RPi taugen (sie laden die Batterie nicht schnell genug auf, damit der RPi die Nacht überlebt).

Ein Solarpanel muss her. Da dieses aber nur am Tag bei Sonnenschein Strom liefert, muss man auch hier mit Batterien arbeiten. Nicht aber mit Powerbanks (Li-Ion) sondern besser mit Blei-Batterien, wie man sie von USVs kennt.

Nicht zu vergessen ist auch, dass Solarpanels 12V ausgeben, was für USB-Geräte nicht brauchbar ist (der USB-Standard sieht eine Spannung von 5V vor). Somit muss man noch einen Transformator dazwischenschalten, der 12V auf 5V heruntertransformiert.

Auf der Suche nach Lösungen fand ich zwei Arten von Produkten: Einerseits Sets, die primär für RPis gedacht sind, sowie Allzweck-Anlagen, mit welchen man Gartenhäuschen, Wohnwagen etc. mit Solarstromversorgung ausrüsten kann.

Die von mir entdeckten RPi-spezifischen Lösungen sind nachfolgend aufgelistet:

Für andere IoT-Geräte konzipierte respektive generische Lösungen:

Hätte ich nicht realisiert, dass das Antennenkabel durch den Fensterrahmen geführt werden kann, hätte ich mir wohl schlussendlich folgendes Produkt geleistet:

Solar-Set Poly Esotec 120005 20 Wp inkl. Akku, inkl. Anschlusskabel, inkl. Laderegler 179.95 CHF bei Conrad.ch (dasselbe Produkt für 168 CHF ohne Versand bei Westfalia.ch)

Die Batterie besitzt einen Speicher von 8 Ah (d.h. 8000 mAh), das Solarpanel generiert 20 Watt Spitzenleistung. Die kleinere Version der Anlage mit „nur“ 4000 mAh kostet 99.95 CHF.

Anschliessend hätte ich wohl auch noch den Laderegler mit einem Produkt ersetzt, das zwei USB-Anschlüsse direkt eingebaut hat (damit verzichtet man auf zusätzlichen Kabelsalat):

ALLPOWERS 20A Solarladeregler 12V / 24V Intelligenz USB Teil Solar Panel Regler mit USB Port Display

Was ich bis jetzt nicht klären konnte: Liefert der USB-Anschluss wirklich nur 500mA (gemäss Handbuch), oder geben die Laderegler trotzdem auch gegen die 1A Strom aus (wie die kleinere Lösung, gemäss dessen Handbuch)?

Links

Bei der Recherche zur Lösung notierte ich mir unzählige Links notiert. Hier die wichtigsten:

Tags: , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 25. Februar 2018

Mit einem Raspberry Pi, DVB-T-Stick und Flightradar 24 einen Hobby-ADS-B Empfänger aufbauen

Vor einigen Tagen wurde mein DVB-T-Empfänger und die ADS-B Antenne von jetvision.de geliefert.

Damit konnte ich einen alten, nicht mehr genutzten Raspberry Pi 1, Model B, zu einem Hobby-Empfänger für Flugzeugsignale (sog. ADS-B) umbauen.

Flightradar24 bietet dafür ein Raspberry Pi-Image an, mit welchem man den Radar in ein paar Minuten online hat — im Gegenzug erhält man als Dank kostenlos ein Business-Abonnement der Web-Site im Wert von mehreren hundert Dollar im Jahr.

Der Name meiner Antenne lautet T-LSZB123 (die Statistiken kann man sich nur ansehen, wenn man auf Flightradar24 registriert ist).

Aufstellen der Antenne

Flightradar24 hat eine Anleitung ins Internet gestellt, die den Hobby-Empfängern bildlich aufzeigt, wie man die Antenne installiert, um einen maximalen Empfang hinzukriegen.

Am Besten wäre die Installation auf dem Hausdach — als Mieter bleibt einem das selbstverständlich verwehrt. Auch muss man sich dann bezüglich Blitzeinschlag Gedanken machen und das Antennensignal mit einem Kabel irgendwo in die Wohnung verlegen.

In meinem Fall muss für die Platzierung der Antenne (leider) die äussere Fensterbank hinhalten — aber allemal besser, als den Empfänger mitsamt Antenne in der Wohnung zu platzieren. Die Alternative wäre gewesen, das gesamte Setup auf dem Balkon zu betreiben, was aber eine solar- und batteriebasierte Stromversorgung verlangt hätte. Das hätte aber grosse Kosten und noch einiges an Bastelaufwand verursacht.

Zum Glück realisierte ich bald einmal, dass man das Antennenkabel durch den Fensterrahmen legen und das Fenster schliessen kann, ohne das Kabel zu beschädigen (hoffe ich jedenfalls):

image-7702

image-7703

image-7704

Reichweite der Antenne

Beim Betrieb des o.g. Sets aus DVB-T-Dongle mitsamt mickriger Antenne in der Wohnung (am grossen Fenster zum Balkon) konnte die Software Signale von Flugzeugen in der Distanz von 20 Nautischen Meilen empfangen.

Nachdem ich den Empfänger probehalber auf dem Balkontisch platziert hatte, stieg die Reichweite auf 40 Nautische Meilen an.

Nach der Festinstallation auf dem äusseren Fensterbank und 48 Stunden Dauerbetrieb konnte ich die Reichweite in einigen wenigen Fällen auf 56 Nautische Meilen erhöhen (103.71 Kilometer).

image-7702

Bessere Antennen

Bei jetvision.de könnte man sich leistungsfähigere Antennen kaufen. Mein Favorit wäre die „A3 ADS-B“ Antenna (1090 MHz) für 77.95 EUR. Doch momentan zögere ich mich mit der Aufrüstung noch, da ich diese Antenne weiterhin auf dem äusseren Fensterbank montieren müsste.

Auf Amazon und AliExpress finden sich auch 1090 MHz-Antennen, teils deutlich günstiger, aber über deren Qualität kann ich nichts aussagen.

Web-Interfaces

Sobald der Raspberry Pi aufgesetzt und der Radar bei Flightradar24 registriert ist, kann man auf das lokale Web-Interface der Lösung zugreifen. Es ist unter folgender URL erreichbar:

http://%IP%:8754

image-7706

Folgende zwei Unterseiten sind nützlich:

  • http://%IP%:8754/settings.html Hier kann man Einstellungen vornehmen. Bei mir scheinen diese aber nicht übernommen worden zu sein (ist evtl. ein Neustart des Servers nötig? Ein Neustart der Software über das Web-Interface hat keinen Effekt gezeigt)
  • http://%IP%:8754/tracked.html Die Liste der aktuell empfangenen Signale von Flugzeugen

Weiter gibt es noch ein, zwei technische Interfaces, die Messdaten in strukturierter Form ausgeben:

  • http://%IP%/dump1090/data/aircraft.json
  • http://%IP%/dump1090/data/stats.json
  • http://%IP%/dump1090/data/receiver.json

Via: Raspberry Pi: Dump1090 erzeugt auch JSON-Dateien die extern verwendet werden können

Diese JSON-Daten eignen sich vorzüglich, um mit Cacti schöne Graphen zu erstellen.

Die Aufschlüsselung der JSON-Werte finden sich in folgendem Artikel: JSON output formats

Sonstige Interfaces

Mit netstat findet man schnell heraus, auf welchen Port fr24 Netzwerkdienste anbietet (ssh, snmpd, dhclient und avahi-daemon sind Systemdienste, die mit fr24 nichts zu tun haben):

# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      417/lighttpd        
tcp        0      0 0.0.0.0:30002           0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:8754            0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:30003           0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      366/sshd            
udp        0      0 0.0.0.0:161             0.0.0.0:*                           352/snmpd           
udp        0      0 0.0.0.0:51123           0.0.0.0:*                           326/fr24feed        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           262/avahi-daemon: r 
udp        0      0 0.0.0.0:36590           0.0.0.0:*                           262/avahi-daemon: r 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           561/dhclient        
udp        0      0 0.0.0.0:59213           0.0.0.0:*                           326/fr24feed

Prozesse

Auf den Raspberry Pi kann man nach der Installation des Flightradar24-Images mit den gewohnten Zugangsdaten per SSH zugreifen.

Auf dem Gerät laufen folgende zwei Prozessbäume, die zum Empfang und für die Verarbeitung der Signale zuständig sind:

  • /usr/bin/fr24feed
  • /usr/bin/dump1090-mutability --raw --mlat --write-json /run/dump1090-mutability/

Als Services werden installiert:

  • dump1090-mutability.service
  • fr24feed.service
  • fr24gui.service

fr24feed startet und stoppt man folgendermassen:

# systemctl start fr24feed
# systemctl stop fr24feed

Log-Dateien

Nach der Installation fand sich bei mir unter /var/log/fr24feed/fr24feed.log eine Log-Datei, die in Echtzeit aktualisiert wurde.

Nach ca. zwei Tagen Betrieb stoppten die Log-Meldungen plötzlich und ich konnte noch nicht herausfinden, wieso die Anwendung nichts mehr in die Datei schreibt.

Die Einstellungen habe ich zwar angepasst (Logfile mode: Keep up to 72h, rotate every 24h und Log file location: /var/log/fr24feed/custom.log), bisher wurden diese aber nicht geschluckt.

Offizielle Statistiken

Loggt man sich auf Flightradar24 ein, kann man sich ausführliche Statistiken zu seinem Empfänger anzeigen lassen (die Zahlen sind aus der Sicht von Flightradar24, d.h. die Informationen, die vom Raspberry Pi an den Dienst gesendet und effektiv dort ankommen):

image-7707

Die URL lautet www.flightradar24.com/account/data-sharing, wo man dann alle registrierten Empfänger angezeigt bekommt. Klickt man dort auf Show Statistics, erscheinen die ausführlichen Statistiken:

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Oktober 2017

Vergesst Intel NUCs und RPIs als Linux-Server zu Hause

Bei mir im Haushalt habe ich beides stehen:

Einen Raspberry Pi 3, der auf einem 22 Zoll-Bildschirm neben der Wohnungstüre hochkant ein Dashboard mit Zeitzonen, Abfahrten von Trams und Bussen, Temperaturen von Netatmo und Sense Peanut-Sensoren, Wetterprognosen, Twitter-Meldungen, Aktienkurse und Umrechnungskurse anzeigt (vor Jahren inspiriert durch einen Besuch bei Cyon in Basel).

Der Raspberry Pi ist (vermeintlich) günstig, benötigt aber ein Gehäuse und flinke SD-Karten. Immerhin läuft er mit dem Strom eines USB-Ports eines Bildschirms und hat mittlerweile Bluetooth und WLAN direkt eingebaut. Trotzdem ein Gefrickel, was die Installation und Konfiguration angeht. Mit nicht immer zeitnahem Software-Support. Wehe, wenn ein Software-Update fehlschlägt oder eine Fehlkonfiguration ausgerollt wird — viel Spass, die SD-Karte unter macOS zu mounten, die Konfigurationsdateien anzupassen, neu zu booten und das Spiel von vorne zu wiederholen, bis man den wirklich Schuldigen gefunden hat (der DAU an der Tastatur, meistens). Ausserdem ist die Hardware sehr schwachbrünstig (Chrome im Fullscreen lässt ihn fast austicken) und eignet sich nicht für jeden Einsatzzweck.

Andererseits einen Intel NUC, welcher primär Netzwerkaufgaben übernimmt: OpenVPN, DHCP, DNS und UniFi-Controller.

Performance-mässig nichts auszusetzen, aber auf Grund der Dimensionen nicht wartungsfreundlich. Und teuer, weshalb meistens Overkill für Standardaufgaben im heimischen Haushalt.

Mein Tipp: Wer die perfekte Hardware für einen Linux-Server sucht, halte nach älteren, gebrauchten Lenovo-Laptops Ausschau. Auf dem Gebrauchtmarkt kriegt man die Modelle X200, X201 und X220 (12 Zoll-Monitor) sowie T400 und T420 (14 Zoll-Monitor) zwischen 50 und 250 CHF.

Wieso ich auf diese Dinger schwöre?

  • x86 respektive x86_64 Prozessorarchitektur, auf welchem ein hundsnormales Linux ohne irgendwelche Handstände läuft
  • Ausgezeichneter Linux-Treibersupport — das neueste Debian ISO mit Etcher auf einen USB-Stick schreiben, Standardinstallation durschpielen, läuft (abgesehen von der leidigen Geschichte mit den WLAN-Treibern, aber solche Server betreibt man am Ethernet, nicht im WLAN).
  • Günstig
  • Man findet sie auf Ricardo, Tutti und Anibis wie Sand am Meer
  • Eingebaute Tastatur und Bildschirm — Debugging leichtgemacht (man wird nie einen Ersatzbildschirm und eine USB-Tastatur anschleppen müssen, wenn das Ding mal die Netzwerkverbindung verliert)
  • Stromsparend
  • Leise
  • Überhitzen nicht kaum
  • RAM und Festplatten lassen sich problemlos aufrüsten; entweder mit kleinen, flinken SATA SSDs oder aber mit fetten, aber etwas teureren Magnetplatten
  • Funktionieren zugeklappt und nehmen dann etwas mehr als die Fläche eines Papierstapels und die Höhe eines Buches (kein Tolstoi) ein
  • Haben die „USV“ (richtig geraten, die Laptop-Batterie) gleich eingebaut. Und wenn deren Kapazität wegen Memory-Effekten und dergleichen nachlässt: Günstig ersetzbar.
  • Docks findet man auf dem Gebrauchtmarkt auch viele (wobei ich immer noch nicht sicher bin, ob es besser ist, diese Dinger im oder ausserhalb des Docks zu betreiben)

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

1 Kommentar | 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

Samstag, 27. August 2016

Dem Raspberry Pi 3 chinesische Schriftzeichen beibringen

Seit einigen Woche betreibe ich mein heimisches Dashboard auf einem Raspberry Pi 3 und bin von der Performance begeistert! Sogar Chrome kriegt man nun als Installationspaket mitgeliefert.

Leider zeigte Chrome nach der Standardinstallation chinesische Schriftzeichen (bei den Währungsinfos) nicht an. Folgende Pakete rüsten chinesische Schriftzeichen nach:

# apt-get install fonts-arphic-bkai00mp fonts-arphic-bsmi00lp fonts-arphic-gbsn00lp

Quelle: Chinese Debian Mini Howto — 2. Installing Chinese Fonts

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 5. Februar 2016

Einen UniFi Controller von einem Server auf einen anderen migrieren

Mit Blick auf den Mitte Januar 2016 bestellten Glasfaser-Anschluss von Fiber7 habe ich mich entschieden, das heimische WLAN aufzurüsten (nicht zuletzt, weil ich den Router wegen des Glasfaseranschlusses in der Stube nicht am selben Ort betreiben möchte wie den Wireless Access Point). Hierzu habe ich die WLAN-Funktionalität meines Asus RT-AC66U deaktiviert und mir danach einen Ubiquiti UniFi AP-Pro n450 angeschafft, mitsamt eines PoE-Switches von TP-Link.

Eine Besonderheit des UniFi-Access Points ist es, dass er selber keine Web-Oberfläche zur Konfiguration anbietet, wie es Consumer-Geräte sonst tun (auch eine Router-Funktionalität sucht man vergebens). Stattdessen benötigt man den sog. UniFi Controller, eine auf Java und MongoDB basierende Software, die auf einem Rechner im heimischen LAN installiert werden muss. Die Software muss übrigens nicht ständig laufen — wenn man die Konfiguration des APs abgeschlossen hat, benötigt der AP keine ständige Verbindung mehr zum Controller. Ich entschied mich gegen diese Lösung, da ich den Controller jederzeit zugriffsbereit und funktionstüchtig haben möchte — man weiss ja nie. Ausserdem zeichnet die Software in dem Modus Vitalparameter des APs und der WLAN-Netzwerke auf.

Zuerst hatte ich den UniFi Controller auf meiner „Workstation“, einem Mac mini, installiert, welcher ständig läuft. Da mir dabei nie wirklich wohl war, entschied ich mich, den alten Raspberry Pi 1 auszugraben und den Controller darauf zu installieren. Das ist insofern etwas weniger trivial als bei einem x86-Server, weil die ARM-CPU andere Softwarepakete benötigt (insbesondere MongoDB). Ich habe es dank Anleitungen im Internet trotzdem hingekriegt (das Material wird dereinst zu einem eigenständigen Blog-Artikel verwurstet). Da ich anschliessend auch Smokeping auf dem Raspberry Pi installierte und mir die Performance zur Generierung der RRDtool-Graphen überhaupt nicht mehr reichte, entschied ich mich diese Woche, auf einen (gebrauchten) Intel Next Unit of Computing NUC DC3217IYE zu migrieren. Mitkommen sollte auch der UniFi Controller.

Da ich das Spielchen bereits einmal gemacht hatte, hier die im Grunde recht triviale Anleitung (Kurzfassung):

  1. In den alten UniFi-Controller einloggen und unter Settings > Maintenance > Backup > Download Backup ein aktuelles Backup herunterladen
  2. Den neuen UniFi-Controller auf dem neuen Server installieren (Anleitungen für Raspberry Pi und Debian folgen dereinst)
  3. Mit dem Browser auf den neuen UniFi-Controller verbinden
  4. Auf dem Homescreen des neuen UniFi-Controllers im Abschnitt „Alternatively you can restore from a previous backup“ die soeben generierte Backup-Datei auf „Choose File“ ablegen und warten (auf dem Raspberry Pi dauerte das Einlesen des Backups mehrere Minuten, unter dem NUC wenige Sekunden)
  5. Login auf den neuen UniFi-Controller — WLAN sollte Rot leuchten
  6. Login auf den Server des alten UniFi-Controllers und diesen Controller stoppen (service stop unifi)

UniFi Controller Import Backup
image-6517

Soweit so gut. Als nächstes muss man sich per SSH auf den Access Point verbinden — bei mir völlig ohne Interaktion, da ich den Access Point mit meinem SSH Public Key ausgestattet habe:

$ ssh unifi

Anschliessend startet man das CLI des lokalen Management Utility:

# mca-cli

Dort gibt man folgenden Befehl ein:

$ set-inform http://10.0.1.12:8080/inform

Wechselt man nun in den Browser zur Web-Oberfläche des neuen UniFi-Controllers, leuchtet WLAN grün — der Access Point wurde in der Zwischenzeit erkannt.

Voila, that’s it!

PS Eins: In Anleitungen im Netz liest man gelegentlich, dass man den AP im Web-GUI noch „adoptieren“ und danach noch einmal den set-inform-Befehl ausführen müsse — bei mir klappte dies auch ohne.

PS Zwei: Der alte UniFi-Controller lief unter 4.7.6, der neue läuft unter 4.8.12. Beim Import der Backup-Konfiguration gab es keine Probleme.

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

4 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

Montag, 22. Juni 2015

Raspberry Pi 2 einrichten (6/n): Automatisch in einen Web-Browser starten

Da ich meinen Raspberry Pi 2 dazu verwende, ein Dashboard anzuzeigen, soll der Taschencomputer nach einem Kaltstart automatisch aufstarten, sich mit dem Standardbenutzer in die graphische Oberfläche einloggen und danach ein Web-Browser-Fenster mit einer bestimmten URL öffnen. Dabei soll nur der Web-Site-Inhalt angezeigt werden, nicht aber die Fensteroberfläche des Window-Managers.

Automatischer Login

Auf der Kommandozeile öffnet man raspi-config und aktiviert dort die Option Enable Boot to Desktop/Scratch. Wichtig ist, dass man die Option mit den Cursortasten auswählt und danach mittels Tabulator auf „OK“ springt und dieses auch betätigt.

Quelle: RASPI-CONFIG

Automatischer Start des Web-Browsers mit einer bestimmten URL

Damit nun die gewünschte Web-Site angezeigt wird, muss man dem Betriebssystem nun noch sagen, dass bei jedem Login in die grafische Oberfläche ein entsprechender Befehl ausgeführt werden soll:

~/.config/lxsession/LXDE-pi/autostart

@xset s off
@xset -dpms
@xset s noblank

@unclutter -idle 1
# PROD
#@chromium-browser --incognito --kiosk http://dashboard.local/

# DEBUG
@chromium-browser --remote-debugging-port=4444 --show-fps-counter --incognito --kiosk http://dashboard.local/

Quelle: How to auto start chromium after boot on the Raspberry 2 (2015-01-31 debian wheezy)?

Ferner: How To Autostart Apps In Rasbian LXDE Desktop

Auch: Raspberry Pi Dashboard Kiosk

Wichtig: In vielen Anleitungen liest man, dass man die Datei /etc/xdg/lxsession/LXDE-pi/autostart (Raspberry Pi 2) respektive die Datei /etc/xdg/lxsession/LXDE/autostart (Raspberry Pi 1) mit den obigen Befehlen ergänzen soll. In meinem Fall hat das zu einer einstündigen Debugging-Session geführt, die erst mit folgendem Hinweis gelöst werden konnte:

Note: If both files are present, lxsession only executes the local file as of v0.4.9

Aus irgendeinem Grund war bei meiner Installation die Datei ~/.config/lxsession/LXDE-pi/autostart vorhanden, weshalb die Einträge in den generischen autostart-Dateien nie berücksichtigt wurden.

Quelle: LXDE

Mauszeiger ausblenden

Damit der Mauszeiger ausgeblendet wird, muss noch folgendes Paket installiert werden:

# apt-get install unclutter

Das Programm wird anschliessend beim Ausführen der Autostart-Datei ausgeführt.

Quelle: Step 16: Hiding the mouse pointer

Alternative: Window Manager umgehen und direkt in ein Browser-GUI starten

Dank an Simon Jenny für den Hinweis — leider bleibt der Bildschirm schwarz, diese Lösung funktioniert also derzeit nicht.

~/.xinitrc

xset -dpms &
xset s off &
unclutter -idle 1 &

exec chromium-browser \
--window-position=0,0 \
--window-size=1080,1920 \
--incognito \
--kiosk \
http://dashboard.local/

Folgende zusätzliche Parameter könnten ebenfalls hinzugefügt werden:

...
--no-first-run \
--disable \
--disable-translate \
--disable-infobars \
--disable-suggestions-service \
--disable-save-password-bubble \
--disk-cache-dir=/tmp/chromium/cache/ \
--user-data-dir=/tmp/chromium/user_data/ \
--show-fps-counter \
--remote-debugging-port=4444 \
...

/etc/rc.local

...
/usr/bin/xinit /home/pi/.xinitrc &
exit 0

Quelle: Raspberry Pi Information Radiator: Booting into a Browser

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

4 Kommentare | neuen Kommentar verfassen

Montag, 22. Juni 2015

Raspberry Pi 2 einrichten (4/n): Chromium installieren

Nachdem der Raspberry Pi 2 auf Raspbian Jessy läuft, können wir die neueste verfügbare Version des Chromium-Browsers herunterladen und installieren. Wir bedienen uns dazu der Repositories von Ubuntu und laden uns (Stand 22. Juni 2015) folgende zwei .deb-Pakete herunter:

Die Links zu den vorkompilierten Binaries finden sich auf den beiden Paket-Seiten rechts im Abschnitt „Downloadable Files“.

WICHTIG: Unter Raspberry Pi 1 läuft nur die unter Wheezy verfügbare Version 22 von Chromium. Neuere Versionen funktionieren unter diesem System nicht, weil die ARMv6-CPU des Raspberry Pi 1 keine hardwarebasierte Fliesskommaeinheit mitbringt. Das armhf-Paket von Ubuntu setzt diese CPU-Einheit aber leider voraus. Wer Chromium trotzdem auf dem nachfolgenden Weg installiert, erhält spätestens beim Start von Chromium folgende Fehlermeldung:

$ chromium-browser --version
Illegal instruction

Raspberry Pi 2 basiert glücklicherweise auf der ARMv7-Plattform und hat diese Einheit mit an Bord.

Sobald die Dateien im lokalen Dateisystem vorliegen, installiert man sie folgendermassen:

# dpkg -i chromium-browser_43.0.2357.81-0ubuntu0.15.04.1.1170_armhf.deb chromium-codecs-ffmpeg-extra_43.0.2357.81-0ubuntu0.15.04.1.1170_armhf.deb

Quelle: Installing Google Chromium on ARM devices with Flash plugin – solution

Ob die Installation erfolgreich war, zeigt folgender Befehl auf der Kommandozeile:

$ chromium-browser --version
Chromium 43.0.2357.81 Built on Ubuntu 15.04, running on Raspbian 8.0

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

Keine Kommentare | neuen Kommentar verfassen