Immer wieder gibt es den Wunsch, insbesondere bei den kleinen Feuerwehren, für die nach wie vor die Sirene der Hauptalarm darstellt, eine Anzeige der Alarmierung im Feuerwehrhaus zu haben, wohin es geht und welcher Auftrag dahinter steckt.
Quelle der Inspiration
Inspiriert durch eine Anzeige auf Basis eines Oelmann-Alarmempfängers in einem Feuerwehrhaus ging es an die ersten Überlegungen. Dazu erstmal ein Blick, wie das Oelmann-System grob funktioniert:
Empfang der Alarmierung über einen Steuerempfänger
Ausgabe der Meldung über eine serielle Schnittstelle
Umwandlung der Meldung über einen Seriell-VGA-Konverter
Darstellung auf einem Monitor
Soweit recht einfach und damit auch nahezu ausfallsicher konzipiert. Die Schwächen des Systems sollen aber nicht unerwähnt bleiben: es wird jede Meldung angezeigt, die im Steuerempfänger als Adresse hinterlegt ist, lange Meldungen werden umgebrochen, aber nicht durchgescrollt, so dass Meldungsteile fehlen und die Meldungen bleiben dort bis zum Eingang einer neuen Meldung stehen.
Zielsetzung
Es sollte ein System werden, dass die Schwächen ausgleicht und im Sinne einer Vernetzung an mehreren Standorten genutzt werden kann, ohne dort einen eigenen Steuerempfänger zu installieren.
Die Auswertung der Alarmierung musste also irgendwo zentral erfolgen und eine differenzierte Ansteuerung mehrerer Monitore ermöglichen.
Meldungen sollten nach einer Ablaufzeit von der Anzeige verschwinden, da nicht selten sensible Daten in der Alarmmeldung enthalten sind und manchmal auch Nicht-Feuerwehrangehörige in den Gerätehäusern zu Gast sind.
Erste Umsetzung im Sommer 2018
Die Grundversion brauchte von der Idee zur Umsetzung rund ein Vierteljahr. Im Kern gibt es einen „Displayserver“ der über eine API die Meldungen für den jeweiligen Monitor entgegen nimmt und in einer Datenbank speichert. Über die selbe API melden sich die Monitore als „Client“ an und prüfen ob eine Meldung vorhanden ist.
Die Ansteuerung übernimmt dabei ein bereits seit 2015 in der Stadtfeuerwehr eingesetztes System, mit dem SMS- und Mail- und Push-Nachrichten auf Basis der im Landkreis eingesetzten POCSAG-Alarmierung erzeugt werden. So können zu jeder Alarmierung differenziert die Monitore angesteuert werden.
Auf der Clientseite läuft das ganze als HTML/Javascript-Kombination, die so mit verschiedenen Systemen und Browsern betrieben werden kann.
Zusammen mit einem Freund wurde noch eine Wetter/Unwetter-Leiste integriert. Im Ruhezustand zeigt sie Wetterdaten, bei ausgewählten Warnereignissen im Stadtgebiet verfärbt sich die Leiste entsprechend des DWD-Farbschemas und zeigt die Headline der Meldung an, so dass Kameraden wissen, was sie draußen noch erwarten könnte.
Die erste Testphase
Neben meinem Client auf einem Raspi 3b gab es noch einen auf einem Android-Tablet, einem Windows PC und einen weiteren Linux-PC – alle mit verschiedenen Broswern und Systemen.
Als Hardware im Feuerwehrhaus kam im ersten Test ein Raspberry Pi Zero W zum Einsatz, der aber durch die grafische Oberfläche mit Browser manchmal ins straucheln kam. Da stand schnell die Entscheidung weitere Clients nur noch als 3b auszurüsten.
Es wurden einige Fehler gefunden, neue Ideen gesammelt und so manche Stunde damit verbracht das System weiter zu optimieren.
Geocoding in 2019
Als wesentliche Neuerung gab es dann im Frühjahr 2019 das Geocoding-Routing. Der Displayserver versucht aus den Einsatztexten den Einsatzort rauszulesen und mit Hilfe der Google-Geocoding-API in eine Koordinate umzusetzen. Als Freund von freier Software habe ich zuvor die OSM-Variante getestet, musste aber feststellen, dass die Anzahl der falschen Georeferenzen sehr hoch war. Selbst mit der Google-API gibt es zuweilen Einsatzstellen in mehreren 100km Entfernung.
Die gewonnene Koordinate wird nun genutzt um eine kleine Karte mit Anfahrtsweg inkl. geschätzter Fahrzeit und Strecke anzuzeigen. Dazu gibt es eine Luftbildkarte der Einsatzstelle um einen Blick auf die Bebauung zu haben.
Mit diesen Kartenausschnitten und Informationen sollte auch eine Möglichkeit entstehen Einsatzdepeschen auszudrucken, jedoch ist aufgrund verschiedener Schwierigkeiten hier noch keine stabile Version entstanden. *to be continued*
Remote Control in 2019
Ein weiterer Punkt ist die Steuerung eigenen Monitors an der Wand. Der Raspi an sich wird ohne Maus und Tastatur betrieben. Im Alltag „heilt“ er sich durch Cronjobs selbst, wenn mal was abstürzt. Für die Administation gibt es einen Zugang über einen SSH-Tunnel vom Displayserver aus, so dass Updates vorgenommen und kleine Probleme headless behoben werden können.
Zum Nutzen der Client-Funktionen (Letzte Meldung, Reload, Signalton) brauchte es weiterhin mindestens eine Maus oder einen Touchscreen. Alternativ ist noch eine VNC-Verbindung aus dem selben LAN möglich.
Da wir hier über Feuerwehr sprechen, musste noch eine einfache Lösung her. Auf dem Client-PC wurde mittels eines Python-Skripts ein Mini-Webserver eingerichtet, der eine kleine Fernsteuerung anzeigt. Hier sind jetzt die Funktionen für Ausschalten des Displays, Neustart und letzte Meldung sowie eine Testfunktion einfach aus dem Netzwerk erreichbar.
Was noch fehlt und geplant ist
Es fehlt noch die stabile Funktion der Alarmdepesche, die auf dem lokalen bzw. Netzwerk-Drucker im Feuerwehrhaus landen soll. Ein Ansatz ist da, aber es fehlt noch der letzte Kniff.
Ein Relais-Ausgang via USB-Port wird auch von einigen erwartet, sei es um das Licht anzuknipsen oder eine Tür im Feuerwehrhaus zu öffnen. Auch hier gibt es einen Ansatz, aber es fehlt die Implementierung auf der Client-Seite.
Und einen ganz anderen Gedanken, banalen und ökologischen hat auch ein Kamerad zurecht geliefert: Warum muss der Monitor an sein, wenn gar keiner da ist? Hier gibt es auch verschiedene Möglichkeiten:
Monitor mit einem Bewegungsmelder ausstatten
Power-Management-Funktionen am HDMI-Ausgang nutzen. Dafür Bedarf es aber einer ähnlichen Implementierung wie beim Relais und der Depesche, denn das liegt außerhalb des HTML/Javascript-Universums.
Die Ideen und Wünsche gehen nicht aus – manchmal sind es ganz kleine Dinge, die aber eine komplexe Umsetzung erfordern.
Nachdem ich meinen Raspi irgendwann von Jessie auf Stretch aktualisiert habe, war mein USB2VGA-Adapter von DisplayLink nutzlos geworden. Der auf die armhf-Architektur portierte DisplayLink-Treiber steht für Stretch nicht zur Verfügung.
Ich hatte mich schon damit abgefunden, dass mein zweiter Monitor für immer dunkel bleiben würde, bis ich letzte Woche durch Zufall auf rasppishop.de das Gert VGA666-Board gesehen habe.
Gert VGA666-Board
Dort wurde die DualScreen-Funktionalität erwähnt und ich vertraute blind. Ein Bekannter warnte mich schon, dass er bei anderen Händlern gelesen hätte, dass es nicht so ohne weitere funktionierte.
Gestern konnte ich dann mein Gert VGA666 zusammenbauen, welches als Bausatz daher kommt. Man bekommt eine Platine, ein paar Widerstände und eine Buchsenleiste für die GPIO-Pins und natürlich eine DSub-VGA-Buchse. Man könnte das Gebilde auch komplett ohne den Bausatz nachbauen, denn die Schaltung ist kein Geheimnis. Infos gibts unter anderem über GitHub unter PiSupply. Das Löten erfordert keine besonders hohen Löterfahrungen und geht recht schnell mit Hilfe der Bestückungsanleitung aus dem Git.
Danach musste mein TekBerry-Gehäuse dran glauben, damit der VGA-Port seinen Weg nach draußen findet. Die notwendigen Treiber sind im Raspian bereits implementiert. Man muss das nur noch in der config.txt das DPI-Interface aktivieren und entsprechend einstellen. Jetzt kann man wahlweise HDMI, Composite oder eben VGA als primäre Anzeige verwenden. Mein Monitor am VGA lief sofort ohne Bildfehler, somit war meine Lötarbeit erfolgreich.
Nun kommt der schwierige Teil – nativ kann der der Raspberry auch im Jahr 2018 noch kein DualScreen. Man kann zwar zwischen Display per HDMI, SPI, DPI (VGA) und Composite wählen, aber es gibt in der Firmware per default nur ein Framebuffer-Device, sprich eine Adresse und einen Speicherbereich für die grafische Anzeige. Es gibt einen „workaround“ mit dem man wohl mittels omxplayer ein Video auf den zweiten Screen „zaubern“ kann, aber eben keinen Desktop. Wenn man sich in den Foren berichte zum Gert VGA666 durchließt, stößt man immer wieder an diese Grenze.
DualScreen am Raspi mit Beta-Firmware
Durch Zufall habe ich dann im Raspberry-Forum einen Beitrag von JamesH gefunden, der eben genau an dieser Problematik getüftelt hat, da auch mit den „originalen“ SPI-Touch-Displays kein DualScreen möglich ist. Er hat sich hingesetzt und die Firmware modifiziert, damit diese einen weiteren Framebuffer bereitstellen kann – also einen autarken zweiten Screen erzeugt, der dann über andere Software angesteuert werden kann.
Gesagt getan – Downgrade des Kernels auf meinem Raspi (es muss nämlich die Kernel-Umgebung exakt zur Firmware passen) und dann Kernel und Firmware von Jamesh in meinen Raspi gespielt. Ein paar Änderungen an der config.txt vorgenommen und dann den Raspi neu gestartet – jetzt wacht der zweite Monitor schon mal aus dem PowerSafe auf – bekommt also Signal aus dem Raspi.
Xorg – eine manuelle Konfig muss her
Nun blauäugig wie ich war habe ich meine „alte“ DualScreen-xorg.conf genommen und ein bißchen drin rumgeändert – aber es lief nicht. Der zweite Schirm bleibt schwarz – als primary Display zeigt er eine vermurkste Grafik – irgendwas passt also nicht. Ein Test mit fbi (FrameBuffer Imageview) zeigt, dass ohne xorg beide Framebuffer sauber arbeiteten – aber warum klappt es mit meiner xorg.conf nicht?
Auch dieses Rätsel konnte ich heute nach nochmaligem Nachdenken und probieren rausfinden. Während USB2VGA-DisplayLink auf dem zweiten Monitor eine Farbtiefe von maximal 16-Bit erwartet, kam das Gert-Board damit nicht zurecht. Es möchte genau wie der HDMI-Port mit 24-Bit angesteuert werden. Nach Änderung der xorg.conf hat es sofort meinen zweiten Bildschirm erkannt und ich konnte (wie beim DisplayLink) dort einen zweiten Desktop mit zweitem Launcher und eigener Browserinstanz starten.
Wer, anders als ich, einen erweiterten Desktop nutzen möchte, kann in der xorg.conf Xinerama aktivieren. Alternativ dürfte auch Clone möglich sein, habe ich nicht getestet, weil ich es nicht brauche).
Nachtrag: ich nutze jetzt seit einigen Wochen Xinerama am Raspi mit HDMI und GERT-VGA – was soll ich sagen: ich bin sehr begeistert, denn es funktioniert tadellos und ohne merkliche Leistungseinbußen auf dem Raspi 3B+.
Upgrade des Raspian-Systems
Damit bei einem Update des Systems der Bootloader und der Kernel im Beta-Status bleiben, muss man vor einer Systemaktualisierung die entsprechenden Pakete auf „hold“ setzen:
user@pi:~ $ sudo aptitude hold raspberrypi-bootloader
user@pi:~ $ sudo aptitude hold raspberrypi-kernel
Danach werden bei einem apt update und apt upgrade die beiden Pakete ausgelassen, aber das restliche System wird trotzdem aktuell gehalten.
Ich gehe davon aus, dass irgendwann der Kernel-Hack offiziell in das Raspbian einfließen wird.
Code-Schnipsel
config.txt
[...]
# GERT VGA666
dtoverlay=vga666
enable_dpi_lcd=1
#display_default_lcd=0 ## =1 macht den VGA-Ausgang zum primären Monitor
dpi_group=2
dpi_mode=35
start_x=1
max_framebuffers=2
framebuffer_priority=2 ## =2 macht den HDMI-Port zum primären Monitor wenn die Beta-Firmware eingespielt ist
Lange habe ich überhaupt keinen Sinn und Zweck in Zertifikaten gesehen – geht ja auch ohne. Mittlerweile kommt man bei Facebook und Google als Seitenbetreiber nicht mehr um verschlüsselte Verbindungen herum. Wenn man es mal genau betrachtet … jede Seite auf der ich irgendetwas persönliches eingebe (Newsletter-Anmeldung, irgendwelche Login-Daten, usw.) sollte entsprechend meine Daten schützen, wir lassen uns ja auch bei der Eingabe der PIN am Bankautomat nicht über die Schulter gucken.
Meine ersten Zertifikate
Wie so ziemlich jeder, der irgendwann in die Welt der Zertifikate eintaucht, stand ich vor der ersten Hürde … sie kosten Geld. Einziger Ausweg waren damals self-signed-Zertifikate. Unter Linux kein großes Problem, schnell ist eins erstellt und muss dann in die jeweilige Serveranwendung eingebunden werden. Eine kleine „Ernüchterung“ stellt sich beim ersten Test der mit self-signed gesicherten Webseite schon ein … der Browser warnt uns, das es ein Zertifkat gibt, er aber nicht weiß, ob man ihm vertrauen kann. Das speichern einer Ausnahmeregel gestatten eigentlich alle Browser, so dass es uns nicht weiter belastet. Wenn man aber Dienste für möglicherweise unbekannte Dritte anbietet, ist das schon etwas störend.
Die Alternativen
Heute gibt es schon mehrere Anbieter, die kostenlose Zertifikate anbieten. Die Leistungen sind unterschiedlich, was Anzahl Domains, Gültigkeit und vor allem das Handling angeht. Es ist schon wenig komfortabel, wenn man alle 30 Tage sein Zertifikat manuell verlängern muss und dann auch in allen Anwendung neu einbinden muss.
Deshalb sticht der Anbieter LetsEncrypt heraus … er bietet kostenlose Zertifikate für bis zu 100 Domains und mit einer Laufzeit von 90 Tagen an. Der Clou … dank einer Software lässt sich das Renewal sogar automatisieren. Das macht es jetzt schon recht einfach seine Webseiten und Mailserver mit einem SSL-Zertifikat zu sichern.
Voraussetzungen
Wir kennen uns etwas mit Linux aus und wissen grundsätzlich, wie wir selbst Skripte erstellen und haben auch schon den Apache auf unserem Server selbst eingerichtet. Vielleicht haben wir auch schon mit self-signed-Zertifikaten gearbeitet, dann ist vor allem die Apache-Konfig mit SSL nichts Neues.
Ziel ist nun das Ganze mit einem LetsEncrypt-Zertifikat zu versehen, dass sich selbst aktualisiert. Die folgenden Schritte sollten unter Ubuntu 14/16 und Raspbian Wheezy/Jessie funktionieren. Python muss auch installiert sein, da der Certbot darauf aufbaut.
Das Setup
Zuerst müssen wir den so genannten Certbot laden und installieren, der für uns das Zertifikat anfordern und aktualisieren kann …
Damit haben wir nun den Certbot betriebsbereit auf dem System. Er bietet viele Automatisierungen für das Ausstellen des Zertifikates und sogar für das Konfigurieren von Apache an. Letzteres habe ich nie ausprobiert, da ich es nicht so gerne mag, wenn irgendwer in meinen Konfigurationen Sachen ändert. Gerade, wenn man ein komplexes Gebilde mit verschiedenen SNI-basierten VirtualHosts hat und vielleicht auch noch mehrere Zertifikate verwaltet, traue ich dabei keinem Automatismus.
Zertifikat ausstellen
Ich habe mir dafür ein Skript in /usr/local/sbin/certbot-sign.sh erstellt. Wenn ich die Domains im Zertifikat ändern muss, dann gebe ich die Änderung in der Datei ein und weiß so immer, was im Zertifikat sein sollte.
Das Skript wird als root gestartet und startet den Certbot ohne Konfigurationsskript (–standalone) und fordert EIN Zertifkat für ALLE Domains, die jeweils mit -d angegeben werden. Der Apache wird gestoppt und im Anschluss wieder gestartet (–pre-hook / –post-hook), denn der Certbot braucht den Port 80, damit bei der Zertifikaterstellung geprüft werden kann, ob denn der Server auch wirklich unter dem Domainnamen erreicht werden kann.
Wenn ich eine neue Domain hinzufüge, schreibe ich ein weiteres -d einfach vor das –pre-hook und starte es manuell per sudo. Das Zertifikat wird dann neu erstellt. Das Löschen einer Domain geht auf diesem Wege auch. Wissenswert ist, dass die erste Domain der Stammname für das Zertifikat ist, womit der Certbot unter /etc/letsencrypt die Zertifikate und eine Konfig anlegt.
Einbinden im Apache
Das Einbinden im Apache ist recht einfach. Wenn nicht schon geschehen, weil ein self-signed-Zertifikat eingesetzt wurde, muss das Modul mod_ssl installiert und im Apache geladen sein.
Dann braucht es eine Grundkonfig für mod_ssl, damit das Zertifikat schon bei der ersten Verbindung zum Apachen zur Verfügung steht. Bei mir sieht es in /etc/apache2/sites-available/default-ssl.conf so aus …
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@server.tld
DocumentRoot /var/www/html
SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/server.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/server.tld/privkey.pem
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>
Jetzt müssen wir noch den einzelnen Webseiten eine Konfiguration für SSL verpassen. Wir nehmen an, dass wir einen VirtualHost unter ssl.server.tld in der Datei ssl.conf eingerichtet haben …
<VirtualHost *:80>
ServerName ssl.server.tld
ServerAdmin webmaster@server.tld
DocumentRoot /var/www/ssl
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] ## umleiten auf ssl
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:443>
ServerName ssl.server.tld
ServerAdmin webmaster@server.tld
DocumentRoot /var/www/ssl
SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/server.tld/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/server.tld/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/server.tld/chain.pem
</VirtualHost>
<Directory /var/www/domain1>
Options FollowSymLinks
AllowOverride None
Order deny,allow
Require all granted
</Directory>
Die im oberen Block für Port 80 eingefügten Rewrite-Optionen bewirken, dass auch Besucher auf dem Port 80 auf den SSL-Port 443 umgeleitet werden. Wir lassen also keine ungesicherte Kommunikation mehr zu.
Jetzt noch den Apache neu starten und es sollte dann die Seite ssl.server.tld mit https: und einem gültigen Zertifikat erscheinen.
Zertifikat aktuell halten
Hier werden uns ein weiteres Skript und ein Eintrag im Crontab helfen. Theoretisch müsste man das Renewal nur exakt 90 Tage nach dem letzten lauf durchführen. Seien wir ehrlich … so wird es keiner machen. Zuerst das Skript in /usr/local/sbin/certbot-renew.sh anlegen …
Alte Bekannte sind die hooks … die wieder den Apache kurzzeitig abschalten. Da sich der Certbot die Domains im Zertifikat unter /etc/letsencrypt gemerkt hat, brauchen wir sie hier nicht angeben.
Das Skript schreiben wir jetzt in /etc/crontab so dass es regelmäßig das Wohl unseres Zertifikates pflegt …
Warum lasse ich den Job nun wöchentlich (d.h. Sonntags 0 Uhr) erledigen? Theoretisch würde monatlich ja auch reichen, aber ich hatte folgende Rechnung:
ich erstelle mein Zertifikat am 1. des Monats
@monthly läuft am Monatsersten 0:00 Uhr
beim ersten Lauf von certbot-renew.sh ist das Zertifikat noch 60 Tage gültig
beim zweiten Lauf noch 30 Tage – da macht der certbot von sich aus noch keine Neuanforderung, macht er erst bei 15 Tagen
beim dritten Lauf ist es jetzt der Ablauftag. Geht nun irgendwas schief, sehe ich morgens zwar die Fehlermeldung in meinem Posteingang, habe aber im ungünstigsten Fall schon ein abgelaufenes Zertifikat.
Also lasse ich wöchentlich prüfen. Das dauert nur ein paar Sekunden und dem Apache schadet ein wöchentlichen Neustart auch nicht. Soweit mein Setup für den Apache mit LetsEncrypt.
meine Erfahrung mit LetsEncrypt
Ich bin ein Fan von diesen Zertifkaten geworden und habe das System auf verschiedenen Rechnern laufen. Bisher hatte ich nur einmal das Problem, dass ich beim „re-sign“ (also das Hinzufügen einer Domain) die neue Domain an den Anfang der Kette geschrieben habe und dann ein neues Zertifikat mit einer neuen Stammdomain hatte.
Das ist aber kein unlösbares Problem. Mit dem Befehl
erhält man eine Übersicht der Zertifikate. In dieser Übersicht sieht man neben dem Stammnamen (den brauchen wir) auch die Restgültigkeit und den Speicherort. Das zu löschende Zertifikat kann man dann mit dem Befehl
erforderliche Kenntnisse: Umgang mit der Konsole, Bearbeiten von Konfigurationsdateien, einfache Bash-Skripte erstellen, Anwendungen aus Paketquellen installieren.
Mit dem Raspi lässt sich ja so einiges anstellen – ich nutze einen auf dem Schreibtisch als Desktop-Ersatz, denn mit dem geringen Stromverbrauch ist er zum Mails abholen und surfen im Web durchaus eine Alternative. Daneben läuft er als quasi als ThinClient, um eine RDP-Session einer VM auf dem Homeserver auf den Schreibtisch zu holen.
Aus meinem Nutzungsverhalten entstand auch der Wunsch einen zweiten Bildschirm am Raspi zu betreiben, um dort parallel eine Webseite (z.B. WhatsApp) offen und vor allem im Blick zu haben.
Ich hatte vor einiger Zeit schon mal im Netz gesucht und viele erfolglose Geschichten gelesen. Ein Arbeitskollege kaufte sich kürzlich USB2VGA-Adapter von DisplayLink und brachte diese unter Windows 10 zum laufen. Dank Google fand ich heraus, dass RaspbianJessie mittlerweile DisplayLink unterstützt, also in die Bucht und Hardware besorgt.
Erster Kontakt mit dem Raspi
Nach dem Auspacken des USB2VGA-Adapters einfach mal an der einen Seite einen weiteren Monitor dran, das andere Ende mit einem USB-B-Kabel an den USB-Hub am Raspi (Anmerkung: funktioniert auch direkt am Raspi, wie ich bei diversen Versuchen herausfand). Eine schnelle Kontrolle mit lsusb und dmesg zeigte, dass der Adapter korrekt erkannt wurde und als /dev/fb1 eingehängt wurde. Auf dem Monitor war ein grünes Bild … sonst nix.
Auch die LXDE-Bildschirmeinstellung brachte mich nicht weiter … hier gab es nur den „Standardmonitor“ und keine weiteren Geräte. Also weiter mit xrandr … das soll ja sowas können.
ein nervenaufreibender Tag mit xrandr
Ich nehme die Pointe mal vorweg – ich habe es nicht hinbekommen, trotz vieler Versuche, stundenlangem googeln und lesen … ich konnte xrandr nicht bewegen den HDMI-Ausgang und den USB2VGA-Adapter zu verwalten.
Es scheitert schon am HDMI-Ausgang, denn xrandr erkennt nur „default“ als Display und setzt es mit einer festen Auflösung an. Die Abfrage xrandr --listproviders bringt als Ergebnis immer 0 und auch das Hinzufügen und Ändern von Bildschirmmodi hat nicht funktioniert.
Um sicher zu gehen, dass es nicht an meinem Image liegt (Raspbian Jessie LITE mit manuell installiertem X-Server, LXDE und Openbox) habe ich auf anderen Raspis im Haus versucht …. xrandr hat mir nirgends mehr ausgespuckt.
Da xrandr nicht korrekt funktioniert, brachte mich also auch das GUI-Tool Arandr nicht weiter, dass auch immer nur das „default“-Display mit der fixen Auflösung anzeigte.
X-Server mittels xorg.conf überzeugen
Nachdem nun das moderne und flexible xrandr seinen Dienst versagte, muss nun eine feste Konfig gebastelt werden …
Dann ein sudo systemctl restart lightdm und der X-Server brachte mir auf dem zweiten Monitor ebenfalls einen Desktop, nur ohne Panel und mit den Default-Einstellungen zum Desktop-Hintergrund. Ein Verschieben von Fenstern über beide Desktops war natürlich nicht möglich, da es eben kein ausgedehntes Desktop ist, sondern irgendwie ein weiteres Desktop unter dem gleichen Benutzer.
Xinerama mit Pi-HDMI und USB2VGA
Hoch motiviert habe ich dann versucht mittels der Zeile Option "Xinerama" "on" die Desktoperweiterung zu aktivieren. Ihr ahnt es … versucht heißt, dass es nicht funktioniert hat.
Ich habe in der Folge gefühlt 100 Varianten der Konfig getestet, immer mit dem Ergebnis, dass der X-Server abstürzt oder eben nur ein Screen voll nutzbar ist. Irgendwann bin ich dann auch mal auf die Idee gekommen unter /var/log/Xorg.0.log zu forschen, warum … es war erstaunlich einfach:
Der X-Server kann Xinerama nicht starten, wenn die beiden Screens unterschiedliche Farbtiefen (Depth) verwenden und stürzt dann ganz ab. Der Pi läuft standardmäßig mit 24 Bit, der USB2VGA-Adapter kann 16 Bit und 32 Bit, letzteres aber leider nur unter Windows.
Ich mache es auch hier kurz … man hat jetzt eine Möglichkeit mit zwei Optionen das erweiterte Desktop zu bekommen … man freundet sich mit 16-Bit Farbtiefe auf beiden Bildschirmen an
Weg 1: den HDMI-Framebuffer des Raspi über die config.txt ebenfalls fest auf 16-Bit runterschrauben
Weg 2: zwei USB2VGA-Adapter nehmen und den HDMI-Port des Rapsi ungenutzt lassen
Mit Weg 2 habe ich problemlos mittels xorg.conf einen erweiterten Desktop eingerichtet bekommen. Über die Performance brauchen wir gar nicht reden, wenn das Bild komplett über 2 USB-Adapter an einem Hub erzeugt wird und 16-Bit Farben fand ich das letzte mal unter Win2k schön.
Wer damit leben kann, kann diese Konfig nehmen – alle anderen müssen unter der Konfig mein Workaround lesen 😉
Mich hat diese Lösung nicht erfüllt. Ich wollte gerne auf dem Hauptscreen weiterhin meine 24-Bit-Farben nutzen. Der zweite Screen, nicht dauerhaft benötigt, darf gerne mit weniger laufen und soll ohnehin nur bei Bedarf ne Webseite anzeigen, oder ein weiteres Terminal beherbergen.
Mein Workaround: den geteilten Desktop bewirtschaften
Basierend auf meiner ersten xorg.conf habe ich nun also den zweiten Desktop angenommen. Dort kann man vom ersten Desktop aus auch Programme starten. Von einem Terminal oder aus einem Skript heraus kann man zum Beispiel mit
DISPLAY=:0.1 lxterminal
auf dem zweiten Screen ein Terminalfenster starten. Das hat aber keine Titelleiste, keine Fensterkontrollelemente und kann auf seinem Screen nicht verschoben werden. Mit etwas Recherche im Netz habe ich die Ursache auch gefunden … der Fenstermanager openbox läuft aktuell nur auf dem ersten Bildschirm. Um das Problem zu lösen habe ich mir mal ein Skript erstellt …
1
2
3
4
#!/bin/bash#Startet Fenstermanager auf zweitem ScreenDISPLAY=:0.1 openbox &
exec openbox-session
#!/bin/bash
#Startet Fenstermanager auf zweitem Screen
DISPLAY=:0.1 openbox &
exec openbox-session
Das startet nun openbox auf dem zweiten Screen und sorgt für eine ordentliche Session. Jetzt haben die Fenster Titelleisten und die gewohnten Steuerelemente und können nach belieben innerhalb des zweiten Screens verschoben werden.
jetzt kann auf dem zweiten Screen über ein Terminal mit obconf das Aussehen angepasst werden, so dass beide Desktopteile „harmonisch“ wirken.
Ein Problem bleibt aber noch … die Fenster aus dem zweiten Screen tauchen aber logischerweise nicht im lxpanel auf dem ersten Screen auf und es gibt kein Menü/keine Programmstarter auf dem zweiten Screen.
Der erste Gedanke … einfach auf dem zweiten Screen auch das lxpanel starten – geht leider nicht, anders als openbox, lässt sich lxpanel nur einmal starten. Also muss ein anderes Panel her, mit dem man die Tasks des zweiten Screens verwalten kann
ein Panel für den zweiten Screen: tint2
Ich habe mich für tint2 entschieden, weil es klein ist, recht einfach an die eigenen Bedürfnisse angepasst werden kann und noch dazu aus den Paketquellen zu bekommen ist.
Nach der Installation kann man es einfach im Terminal des zweiten Screens mittels tint2 starten und hat in der Grundkonfig schon mal ein Panel mit Taskleiste und Uhr.
Das Aussehen und die Funktion des Panels lässt sich in der ~/.config/tint2/default.tint2rc beeinflussen. Man kann diese auch einfach kopieren und in der Kopie nach Herzenslust Farben, Rahmen, Panelaufteilung und vor allem Starter, mit denen man gezielt auf dem zweiten Screen Dinge starten kann, erstellen. Mit dem Tool tint2conf kann man dann eine Konfig auswählen und aktivieren ohne das Panel selbst neu zu starten.
das Finetuning: Skripte und Starter fürs zweite Panel
Ich habe mir für das Starten des zweiten Desktops oben erwähntes Skript angelegt und auf meinem Desktop als Starter platziert, da ich aus Ressourcengründen diesen nicht immer mit laufen lassen möchte.
Für das Starten der verschiedenen Apps auf dem zweiten Screen habe ich mir entsprechende Skripte und Starter erzeugt, die ich dann im zweiten Panel verknüpft habe.
Chromium aufdem zweiten Screen parallel starten
Chromium startet standartmäßig neue Fenster immer im selben Screen. Das kann man aber umgehen, indem man für den zweiten Screen ein eigenes „User-Data-Dir“ für den Browser definiert und dann kann man sogar zwei verschiedene Browser-Konfigurationen parallel laufen lassen. Mein Skript start_chromium2.sh …
… startet den Browser mit einem anderen Datenverzeichnis und damit auch in einem anderen Kontext. Ich habe einfach dafür ein neues Verzeichnis im Homedir angelegt. Vielleicht ginge es auch mit einem Softlink auf das „normale“ Datenverzeichnis, dann hätten beide Browser den selben Cache, die selben Cookies … aber ich finde es ok quasi zwei verschiedene Browser zu haben, sind eh über den Google-Account synchronisiert.
Für diese Skript habe ich dann einen Starter chromium2.desktop erstellt …
1
2
3
4
5
6
7
[Desktop Entry]Type=Application
Name[de_DE]=Chromium 2ndExec=/home/pi/Skripte/start_chromium2.shGenericName=Startet Chromium auf zweitem Screen
Comment[de_DE]=Startet Chromium auf zweitem ScreenIcon=/home/pi/Skripte/chromium.png
[Desktop Entry]
Type=Application
Name[de_DE]=Chromium 2nd
Exec=/home/pi/Skripte/start_chromium2.sh
GenericName=Startet Chromium auf zweitem Screen
Comment[de_DE]=Startet Chromium auf zweitem Screen
Icon=/home/pi/Skripte/chromium.png
… den ich nun im zweiten Panel eingebunden habe. Man kann ihn natürlich auch im lxpanel oder dem Desktop verlinken, wollte ich aber nicht. So erscheint er nämlich nur auf dem zweiten Screen, also auch nur, wenn dieser verfügbar ist.
In meiner default.tint2rc habe ich das so eingebunden …
tint2conf.desktop ist ein Starter für das oben erwähnte Konfig-Tool von tint2.
thunar2.desktop bringt mir einen Dateimanager auf den zweiten Screen, denn der LXDE-Standard pcmanfm lässt sich auch mit verschiedenen Tricks nicht auf dem zweiten Screen parallel starten.
lxterm.desktop ist, ihr ahnt es, ein Starter für das Terminal auf dem zweiten Screen.
Die Starter sind alle nach dem Prinzip vom Chromium-Starter aufgebaut … der Starter greift auf ein Skript zurück und im Skript werden die Anwendungen immer mit der DISPLAY-Variable vorweg gestartet. Diese Variante hat den Vorteil, dass alle Starter auch vom Hauptscreen aus funktionieren, solange der zweite Screen verfügbar ist.
Fazit
Das Verschieben von Fenstern vom einen auf den anderen Screen oder ein Screen-übergreifendes Fenster ist mit dieser Variante natürlich nicht möglich. Dazu muss man zwingend Xinerama zum Laufen bringen. Wer, wie ich, auf diese Funktion verzichten kann, kann auf diese Weise aber auch ein nutzbaren Desktop auf einem weiteren Bildschirm erzeugen.
DualScreen mit dem Raspi über HDMI und einem USB2VGA-Adapter für den zweiten Monitor rechts
Ein alternativer Weg für einen zweiten Desktop, sogar mit eigenem Benutzer ist die MultiSeat-Funktionalität von lightdm. Das habe ich auch ausprobiert, ist sehr interessant, weil man damit an einer Maschine mehrere unabhängige X-Server erzeugen und auf verschiedene Monitore verteilen kann. Trickreich ist dann das Konfigurieren der Eingabegeräte, denn ohne weitere Zutun werden Eingaben und Mausbewegungen parallel an beide X-Server gesendet (witziger Effekt), aber das war dann nicht das, was ich gesucht habe.
Nachdem das WLAN als Accesspoint funktioniert steht nun das Finetuning an, denn auch kabelgebundene Geräte wie ein SIP-Telefon sollen sich am Pi anmelden können. Dafür müssen sie auch an der LAN-Schnittstelle (eth0) eine IP per DHCP bekommen.
Haken an der Sache, wenn man eth0 auch mit DHCP-Server konfiguriert, kann sich der Pi nicht mehr mit einem bestehenden Netzwerk verbinden um ggf. auf das Internet zugreifen zu können. Zudem gibt es Probleme, wenn man den Pi mit DHCP-Server auf eth0 an ein bestehendes LAN verbindet, denn dann gibt es höchstwahrscheinlich zwei DHCP-Server und das sorgt für unvorhersehbares Verhalten bei der IP-Vergabe. Aber nun erstmal zur grundsätzlichen Einrichtung. NotrufSim (4) Optimierung Netzwerk weiterlesen →
Als Ende August die ersten Außenstellen vom Lager Friedland in der Region belegt wurden, hatte Sascha Leibecke die Idee, dass der Elternbeirat der ev. Kindertagesstätte Schoningen eine Sachspendensammlung für die Flüchtlinge organisieren könnte. Sein Gedanke: Kita-Eltern haben vielleicht ein paar Spielzeuge die nicht mehr benötigt werden oder Bekleidung aus denen die Kinder rausgewachsen sind über, um damit ein paar Kinderherzen in den Flüchtlingsfamilien glücklich machen können.
Heute soll der Raspi sein eigenes WLAN für Smartphones mit SIP-Client und den Zugriff auf die Weboberfläche bereitstellen, damit er quasi Plug&Play in freier Wildbahn ohne weitere Netzwerkhardware auskommt.
Ich verwende einen EDIMAX WLAN-Dongle EW7811UN, der oft mit dem Pi in Bundles verkauft wird. Der Treiber ist bereits im Raspbian enthalten und so sollte der Stick direkt am Pi laufen. NotrufSim (3) WLAN-AP mit DHCP weiterlesen →
Widmen wir uns nun der praktischen Umsetzung. Ich setze voraus, dass ein paar Linux-Kenntnisse vorhanden sind, weshalb nicht alle Schritte ausführlich erklärt sind.NotrufSim (2) Praxis weiterlesen →
Immer wieder gibt es den Wunsch, insbesondere bei den kleinen Feuerwehren, für die nach wie vor die Sirene der Hauptalarm darstellt, eine Anzeige der Alarmierung im Feuerwehrhaus zu haben, wohin es geht und welcher Auftrag dahinter steckt.
