User Tools
Sidebar
This is an old revision of the document!
Brinkhaus-OS (BOS) ist eine Betriebssystemvorlage, mit der ein Embedded-PC mit einem für Brinkhaus-Projekte standardmäßig genutzten Echtzeitbetriebssystem ausgestattet werden kann.
Erreichte Ziele:
- Standardisierte Betriebssystemvorlage für Edge-PCs
- Installation anhand spezieller Boot-USB-Sticks; Installation als automatischer Ablauf
- Modifizierter Kernel unterstützt echtzeitfähiges Verhalten von Apps
- Standartisiertes Ausrüsten mit Apps
- Trennung von Daten/Einstellungen/Logs unterstützt separates Backup von Apps
- Boot-Sticks-Erstellung und Platzierung von BOS-Spezifischen Inhalten auf dem Boot-Stick aus Codeverwaltung; Generierung des Boot-Stick-Images als automatischer Ablauf
Kurzfristig noch offene Ziele:
- Schutz des Kernsystems per Overlay-FS
- Update per swupdate per A/B-Partitionsschema
Erstinbetriebnahme
Der mit BOS einzurichtende PC muss per DHCP mit dem Internet verbunden sein. Bevor er mit Spannung versorgt wird, muss ein von Brinkhaus gestellter USB-Stick gesteckt werden.
Schließt man den PC an Spannung an, kann man die automatische Installation verfolgen. Danach liegt ein wie unten beschriebener standardisiert eingerichteter Edge-PC vor.
Betriebssystembasis
BOS basiert auf Debian 10. Das System wird automatisch eingerichtet und dabei wir unten genannt bespielt. Es wird eine Minimalkonfiguration - ohne grafische Oberfläche - vorgenommen.
Der installierte Kernel wurde anhand der Standard-Debian-Kernelquellen mit der Option “PREEMPT” neu kompiliert. Er bietet also alle Standardschnittstellen, unterstützt aber zusätzlich die Erstellung von Apps mit stabil reproduzierbarem Zeitverhalten. Damit Programmierer dies erreichen, müssen sie ihre Echtzeittasks in geeignete Scheduler verschieben (insbesondere SCHED_FIFO).
Zugriff innerhalb des Systems
Es gibt im System keine über die Standardmechanismen des Debian hinausgehenden hinausgehenden Schutzmechanismen. Insbesondere gibt es keine Trennung von Apps in einzelne Schutzbereiche. Apps werden, damit sie auf Hardware zugreifen können, als Benutzer “root” ausgeführt.
Login
Im Auslieferungszustand gilt: es gibt zwei User: root und bos.
Beide haben das Passwort “bos1234!”. Man kann sich per SSH auf das System einloggen. Dabei ist es nicht möglich, sich direkt per SSH als root einzuloggen. Stattdessen muss ein Login als Benutzer bos erfolgen. Danach kann man per su in eine Root-Shell wechseln.
Verzeichnisstruktur, Partionierung im Auslieferungszustand
- 500MB EFI-Partition
- 4GB System (gemounted auf /)
- 4GB System (gemounted auf /reserve), genutzt für Updates
- kein Swap
- 2 GB unter /var/bos/apps
- 2 GB unter /var/bos/settings
- 2 GB unter /var/bos/logs
In jedem der Verzeichnisse unter /var/bos existiert ein Verzeichnis APP_NAME pro App mit APP_NAME als Namen der App.
- /var/bos/apps/APP_NAME: beinhaltet die eigentliche App; bei Systemstart wird /var/bos/apps/APP_NAME/run.sh ausgeführt
- /var/bos/settings/APP_NAME: beinhaltet die Einstellungen der App
- /var/bos/logs/APP_NAME: beinhaltet die Logs der App
Start von Apps
Unter /var/bos/bin liegen drei Skripte, welche bei Servicetätigkeiten relevant sind.
- reInitBosApps.sh : stoppt alle zuvor von diesem Skript eingerichteten Dienste. Legt hiernach pro Verzeichnis in /var/bos/apps einen SystemD-Dienst im Modus “simple” an, der bei Hochlauf das Skript run.sh im jeweiligen Verzeichnis startet.
- stopBosApps.sh: stoppt alle mit reInitBosApps angelegten Dienste manuell per Aufruf an SystemD.
- startBosApps.sh: startet alle mit reInitBosApps angelegten Dienste manuell per Aufruf an SystemD.
Ausführung von Containern
Container können eine BOS-App sein. Dazu wird empfohlen, den Container als tar-File zu exportieren. Das Tar-File sollte dann mit dem Dockerfile im App-Verzeichnis platziert werden. In der run.sh ist dann als erstem Schritt ein “docker load -i” auf das tar-File auszuführen. Dann kann man per “docker-compose up” den Container starten.
Updates von Apps und deren Einstellungen per SFTP
Apps können per SFTP verzeichnisweise geschrieben und ausgetauscht werden. Ebenso ihre Einstellungen. Mittels der o.g. Skripte kkann die run-sh von Apps in den Status von SystemD-Diensten erhoben werden.
