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 Cloud-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 beobachten. Nach Durchlauf der Installation liegt ein wie unten beschriebener Rechner vor.
Betriebssystembasis
BOS basiert auf Debian 10. Das System wird automatisch eingerichtet und dabei wir unten genannt bespielt. Es wird eine Minimalkonfiguration vorgenommen. Insbesondere wird keine grafische Oberfläche installiert.
Der installierte Kernel ist ein Standard-Debian-Kernel, der mit der Option “PREEMPT” kompiliert wurde. Er bietet also alle Standardschnittstellen, unterstützt aber zusätzlich die Erstellung von Apps mit stabil reproduzierbarem Zeitverhalten, solange Programmierer dafür geeignete Scheduler für ihre Echtzeitthreads wählen (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.
