Bereits 2015 begann ich eine Artikelreihe mit dem Ziel einen „Wunderkasten“ als kleine Telefonanlage zur Simulation von Notrufen auf Basis Raspberry und Asterisk zu bauen und nachdem die Grundfunktion damals gegeben war, verschwand das Projekt wieder in der Versenkung und wurde nie fertig gestellt.
Nachdem wir im beruflichen Umfeld immer mehr mit Simulation arbeiten und diese aufgrund technischer Änderungen in unserem Schulungszentrum nicht mehr mit dort vorhandenen „Bordmitteln“ aufbauen können, braucht es nun doch wieder einen „Wunderkasten“.
Welche Funktionen sollte das System haben
bis zu 3 Leitstellenplätze
bis zu 2 Regieplätze
verschiedene Leitungen (Amt, 112, 19222, 116117)
aus der Regie müssen gezielt Anrufe an die verschiedenen Leitungen in der Leitstelle getätigt werden können und in der Leitstelle muss eine Unterscheidung der angerufenen Leitung möglich sein
die Regie soll verschiedene abgehende Rufnummern simulieren können (Spoofing)
die Leitstelle muss beliebige Rufnummern anrufen können und in der Regie muss ersichtlich sein, welche Rufnummer die Leitstelle angerufen hat
Die Funktionen der TK-Anlage sollen in der Leitstelle möglichst ohne jegliche Einweisung nutzbar sein
Die Anrufe sollen wie in der echten Leitstelle aufgezeichnet werden. Sie sollen an den Plätzen auch als „Kurzzeitdoku“ zur Verfügung stehen
Die aufgenommenen Anrufe sollen am Ende der Simulation aus der Regie einfach gelöscht werden können
Für eine spätere Anbindung einer Mini-Leitstellen-Software sollen Daten der TK-Anlage über eine Datenbank/Schnittstelle nutzbar sein
Umsetzung
Wie bereits in der 2015er-Version ist der Kern ein Raspberry (Pi3b+ mit Raspbian Buster Lite) und ein Asterisk (16.2.1 mit de-Sounds). Auf die Installation von Raspbian und Asterisk werde ich nicht weiter eingehen.
Als Hardware-Telefone werden OpenStage 40 SIP zum Einsatz kommen, da diese bei Pollin gerade mal wieder für knapp 10 Euro zu haben sind. Dazu gibt’s einen gebrauchten PoE-Switch von HPenterprise aus der Bucht.
Anrufe aus der Regie
In der Regie wird für jedes Telefon nur ein SIP-Account im Asterisk eingerichtet. Für die Anrufsimulation gibt es einen umfangreichen Kontext, in dem die Ziel-Leitungen der Leitstelle gezielt ansprechbar sind und abgehenden Rufnummern per Nachwahl gesetzt werden können.
Bei Wahl einer beliebigen Nummer, wird diese Rufnummer als Anrufernummer auf der Amtsleitung der Leitstelle signalisiert. Wird lediglich eine 0 gewählt, erfolgt ein anonymer Anruf.
Ein Anruf auf der 112 wird mit einer zufälligen Nummer auf der Notrufleitung in der Leitstelle signalisiert. Wird an die 112 eine Rufnummer angehängt, wird diese als Anrufernummer gesetzt.
Die Sondernummern 19222 oder 116117 werden ohne weitere Nachwahl als anonymer Anruf auf der jeweiligen Leitung in der Leitstelle signalisiert. Mit angehängter Rufnummer wird wie bei 112 die Anrufernummer gesetzt.
mit einer 1 als Nachwahl hinter der 112 oder den Sondernummern wird eine zufällige Handynummer als Absender erzeugt. Eine 5 erzeugt eine Festnetznummer aus der Bereich 0555x.
Anrufe aus der Leitstelle
In der Leitstelle erhält jedes Telefon vier SIP-Accounts (Amt, 112, 19222, 116117) um eine Unterscheidung der angerufenen Leitung am Endgerät zu ermöglichen. Abgehende Anrufe sind nur über die Leitung „Amt“ möglich. Versucht man über die anderen Leitungen abgehend zu telefonieren kommt eine entsprechende Fehleransage.
Grundsätzlich sind alle Rufnummern von der Leitstelle aus an- bzw. rückrufbar. Eine Ausnahme bilden die anonymen Anrufe, die ebenfalls mit einer Fehleransage beendet werden.
Aufzeichnung der Anrufe
Alle Anrufe, die über die Anrufsimulation in die Leitstelle gehen oder von dort geführt werden, werden als WAV-Datei in einem Ordner abgespeichert. Sie stehen damit in einem späteren WebTool als Kurzzeitdokumentation an den Leitplätzen zur Verfügung.
Die Regie kann die Anrufe ebenfalls nochmals anhören und später im Debriefing der Simulation verwenden. Wenn der Simulationsdurchgang abgeschlossen ist, können die Aufzeichnungen per Telefoncode direkt gelöscht werden.
Anrufe, die gezielt an eine Nebenstelle in der Leitstelle oder der Regie geführt werden, sind von der Aufzeichnung ausgenommen.
Bereitstellen von Anrufdaten
Für alle Anrufe wird bei Beginn ein Datensatz in einer Datenbank angelegt. Hier werden bereits die Anrufernummer, das Anrufziel, der „Platz“ von dem er gestartet wurde sowie der Name der WAV-Datei gespeichert. Wenn eine Annahme des Anrufes erfolgt, wird der „Platz“ der Annahme gespeichert. Beim Beenden des Gespräches erfolgt ein weiterer Zeitstempel im Datensatz.
Damit sind dann später in einem WebTool alle anstehenden, alle aktiven sowie die beendeten Gespräche nachvollziehbar und alle notwendigen Daten für die Kurzzeit-Doku vorhanden.
In einem weiteren Schritt soll an diese Datenbank ein Mini-ELR als WebApp anknüpfen, um Einsätze zu verwalten und diese mit Anrufern zu verknüpfen – aber das ist noch Zukunftsmusik.
Was als nächstes kommt
Ich warte auf die Telefon-Hardware, denn bisher erfolgten nur kleine Tests per Softphone. Eine „Auslastung“ der Leitstelle konnte damit noch nicht getestet werden.
Das erste WebTool für das Anrufmanagement steht relativ weit oben auf der Liste. Auf der Leitstellenseite wird es primär als Anzeige dienen, die Kurzzeitdoku realisieren und vielleicht irgendwann Rückruffunktion bieten. Auf der Regieseite soll das Tool vorbereitete Rufnummer wählen können, so dass in Szenarien möglichst realistisch erneute Anrufe, Anrufe aus dem selben Ort, etc. per Klick erzeugt werden können.
Kurzer Ausflug in die Vorgeschichte … nachdem ich bereits mit dem 3b einen Dual-Screen-Desktop aufgesetzt hatte, diesen dann aber aufgrund der geringen Leistung nicht alltagstauglich fand, konnte ich einen Samsung Thinclient TX-WN für nicht mal 50 Euro aus der Bucht erobern. Dieser kommt mit allen gängigen Anschlüssen (2x DVI, USB3, Gigabit-LAN) daher und hat 2GB RAM und eine 16GB SSD mit Win7 embedded. Letzteres fand ein schnelles Ende und wurde durch Lubuntu 18.04 LTS ersetzt. Das Setup lief besser als der Pi 3b, braucht allerdings mehr Platz auf dem Schreibtisch, setzt mehr Energie (12W laut Herstellerangabe, davon gefühlt 100% als Wärme) um und zeigte im Chromium bei Facebook und Youtube seine Schwächen.
Raspberry Pi 4b 4GByte
Mit Freude erwartete ich nun den Pi4, dessen neue Hardware etwas mehr Performance versprach:
1,5 GHz -Quadcore
4 GByte DDR4-RAM (gibt auch 1 oder 2 GByte-Versionen)
2x USB 3.0, 2x USB 2.0
Gigabit Ethernet
2x Micro-HDMI für Dualscreen-Betrieb in 4K
WLAN 2,5 & 5 GHz
Bluetooth 5.0
Ich habe eine Weile gewartet und wollte erstmal die Kinderkrankheiten abwarten, denn es gibt unter anderem einen Bug im Bereich der neuen USB-C Spannungsversorgung – da ich aber eh ein eigenes Netzteil verwenden will, stört es mich nicht und ich wollte einfach nicht länger warten.
Eine Funktion der 3er-Serien hat leider aufgrund neuer Bootloader-Strategie auf EEPROM noch keinen Einzug bei Pi4 gefunden: der Systemstart via USB oder Netzwerk (PXE). Schade, denn ich wollte den neuen Bewohner gerne komplett von einem USB-SSD-Speicher betreiben – so muss die SD leider weiterhin die boot-Partition liefern und dann an den SSD-Stick übergeben.
Einkaufsliste
Nun aber mal zu den Fakten, in diesem Fall die Einkaufsliste:
Raspberry Pi 4b 4 GByte
SanDisk Ultra 16GB SDHC
SanDisk Extreme PRO 128GB SSD-Stick
GeeekPi Gehäuse mit Kühlkörpersatz (4 Stück) und 40mm-Lüfter
Beris 5V / 3A Netzteil mit Schalter und USB-C
2 x Micro-HDMI auf HDMI-Buchse
Gesamtkosten 150 Euro – vielleicht kein Schnäppchen, aber ein Quadcore PC mit 4 GB RAM und 128 GB SSD, der weniger Platz auf dem Schreibtisch braucht als mein Locher – verlockend !
Die erste(n) Installation(en)
Vorweg – ich bin kein Freund von Geräuschen am Schreibtisch, deswegen habe ich den 40mm-Lüfter beim Zusammenbau des Gehäuses erstmal nicht angeschlossen. Die passiven Kühlkörper(-chen) wurden brav montiert (verstehe auch nicht, wie man nen Pi ohne betreiben kann).
Als erstes habe ich ein Raspbian Lite auf die SD und den SSD-Stick kopiert. Dabei habe ich mich an der Anleitung von James Chambers orientiert und die SD als boot-Device und den Stick als root-Device verknüpft. Ein erster Start machte mich fast sprachlos, denn der Pi bootete in gerade mal 20 Sekunden bis zum Login.
Ich versuchte dann das Lite zum LXDE aufzuwerten und stellte aber fest, dass es irgendwie nicht so harmonierte, wie ich es mir vorgestellt habe. Scheinbar werden doch irgendwie nicht alle Pakete so installiert, als wenn ich Raspbian Full nehme. Es gelang mir zum Beispiel nicht Anydesk zum laufen zu bringen.
Zeit noch mal was anderes zu probieren: ich nahm ein Lubuntu-Arm64 und hoffte auf mein gewünschtes und gewohntes LXDE-Linux. Das startete im grafischen Desktop ebenfalls deutlich unter 30 Sekunden, aber es gelang mir auch in diesem Setup nicht Anydesk zu installieren, weil dies offensichtlich nicht mit Arm64 kompatibel ist.
das endgültige Setup mit Rasbian Full und LXDE
Na ist ja nicht schlimm, im dritten Anlauf kommt halt Raspbian Full auf Karte und Stick. Die notwendigen Schritte nun schon fast auswendig beherrschend ist das ganze in gut 5 Minuten bootbar und der Raspbian Desktop wird nach gerade mal 23 Sekunden angezeigt.
LXDE, Chromium und Anydesk installiert um einen ersten Vergleich zum Samsung-Thinclient herstellen zu können. Alles startet sehr schnell, die Webseiten scrollen flüssig (insbesondere Facebook, dass auf dem Samsung oft für Probleme sorgte) und auch Youtube läuft ruckelfrei. Nun folgte ein bisschen Feintuning, Aussehen anpassen, gewohnte Software installieren, Netzwerk-Links und Desktop-Starter installieren – immer wieder beeindruckt, wie schnell der Raspi Zugriffe im Dateisystem erledigt und neu startet – auch mit mehr Software im Gepäck.
Kühlen wird Pflicht
Nun kam die Stunde der Wahrheit: er soll endlich mal im Dual-Screen-Betrieb zeigen, was er kann und ich mache es kurz – er tut, was er soll. Im Betrieb ohne Lüfter mit ein bisschen Internetnutzung kommt die CPU auf 72 °C. Bei intensiver Nutzung mit mehreren Fenstern und vielen Zugriffen im Dateisystem erreichte er dann irgendwann die 80 °C-Grenze und zeigte das Symbol für Temperaturwarnung oben rechts im Bild an. Für mich war der Zeitpunkt gekommen ihn nun aktiv zu kühlen – mit Lüfter ging er dann auf rund 50 °C runter. Für mich stehen damit 2 Dinge fest: es braucht einen leisen 40mm-Lüfter und eine kleine GPIO-Steuerung, die den Lüfter ansteuert, wenn die Temperatur hoch geht.
Fazit
Nach einem Tag Raspberry 4b 4GB als Desktop-Ersatz kann ich sagen, dass ich den Kauf nicht bereut habe. Er läuft und erledigt die Alltagsaufgaben mit sehr guter Performance im Vergleich zum Samsung TX-WN und dem davor genutzten Pi 3b+. Insbesondere das echte Gigabit-LAN und der SSD-Stick bringen in vielen Dingen den nötigen Durchsatz und Dual-Screen ist nun ohne Bastelarbeiten (Gert-Board) und Kernel-Patch out-of-the-box möglich.
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 →
