FabAccess Konfiguration
Nach jeder FabAccess Installation ist eine Anpassung (Konfiguration) an die nötigen Umstände sinnvoll und wünschenswert.
- Benutzerkonfiguration - users.toml
- Benutzer mit externen Systemen synchronisieren
- Hauptkonfiguration - bffh.dhall
- Einfache Konfiguration mit dem FabAccess Config Generator
- Server Logs konfigurieren und Debugging
- Server Hardening
- Cheat Sheet - Wichtigste Befehle (Übersicht)
- Client benutzen und typische Konfigurationsfehler bei Server und Clients
- Script-Sammlung
Benutzerkonfiguration - users.toml
Wichtige Informationen zur Benutzerdatenbank
BFFH selbst nutzt eine interne Datenbank in bffh.db
für die Benutzer, jedoch wird diese erstmalig über die Datei users.toml
gespeist.
Das Speisen von Benutzern kann auch über die Python-API pyfabapi erfolgen (siehe Beispielscript zum Hinzufügen und Löschen von Benutzern).
Nachdem mindestens eine erste Verwaltungsrolle inkl. zugewiesenem Benutzer (Admin, Manager) zum System hinzugefügt wurde, kann anschließend auch die Benutzerverwaltung der Client-Anwendung Borepin genutzt werden. Über diese lassen sich Benutzer hinzufügen und entfernen, sowie Rollen und Passwörter managen.
Die in der App hinzugefügten bzw. modifizierten Benutzer werden nicht automatisch in die erstmalig genutzte users.toml
geschrieben, sondern direkt in die interne Benutzerdatenbank. Das Exportieren erfolgt explizit durch /usr/bin/bffhd --dump-users
. Für unsere Handhabe bedeutet das, dass die parallele Bearbeitung der Benutzerdatenbank per App und users.toml
sorgfältig getätigt werden sollte, um etwaige Änderungen nicht ungewollt rückgängig zu machen.
Intro
In der TOML-Datei users.toml
werden die Benutzer, sowie ihre jeweiligen Passwörter, Rollen und Kartenschlüssel gespeichert. Die Datei befindet sich üblicherweise in /etc/bffh/
. Die Datei wird nicht automatisch von BFFH geladen - egal, ob sie komplett neu ist oder nur modifiziert wurde. Das Importieren der users.toml
erfolgt durch /usr/bin/bffhd --load-users
.
Offizielles TOML-Logo
Aufbau einer users.toml
Der grundlegende Aufbau folgt dem oben verlinkten TOML-Standard.
Benutzer
Jeder Nutzer wird dabei durch eine eigene Sektion userid
angegeben (in einem Paar eckiger Klammern, z.B. [AdminUser]
). Die userid
Kennungen werden von BFFH z.B. beim Ausführen von Aktionen verwendet (Aktoren, Initiatoren) - dort werden sie in die Befehlskette hinten angefügt.
Der Benutzername kann direkt in eckige Klammern ohne Hochkommas geschrieben werden, solange keine Sonderzeichen wie Umlaute enthalten sind. Wir empfehlen aus genau diesem Grund prinzipiell jeden Nutzer ausschließlich in Hochkommas zu schreiben. So kann der Nutzer [Ö]
von BFFH nicht erfolgreich importiert werden (da ungültige Deklaration), der Nutzer ["Ö"]
jedoch schon. Bei Nichtbeachtung folgt eine Fehlermeldung:
Error: × unexpected character found: `\u{d6}` at line x column y
Achtung: Der Name kann unter anderem auch Leerzeichen und Sonderzeichen enthalten, sowie nahezu beliebig viele Zeichen. Folgender Username ist beispielsweise gültig:["Ein seeeeeeeeeeeeeeeeeeeeeeeeeehr langer Nutzername mit Sond@rze!chen_ "]
. Dem Administrator wird angeraten eine Nutzernamenkonvention aufzustellen, die z.B. verschiedene Sonderzeichen vermeidet, die häufig auch bei LDAP-gestützten Anwendungen Probleme bereiten. Es wird im Zweifelsfall empfohlen sich auf Klein- und Großbuchstaben, sowie Ziffern und einfache Zeichen wie .-_
zu beschränken.
Rollen, Passwörter, Cardkeys
Unter jeder userid
werden Schlüssel-Wert-Paare abgelegt. Die aktuell genutzten Schlüsselnamen lauten:
roles
(Rollen) - diese Rollen werden in der Hauptkonfiguration definiert und dann derusers.toml
zugewiesenpasswd
(Passwort - unverschlüsselt (plaintext) oder als Argon2-Hash)cardkey
(DESFire EV2 UUID) - diese wird entweder aus der Borepin App oder über das FabFire Provisioning Tool erzeugtcardtoken
- eine anonyme Alternative zuruserid
und gilt as Mapping zwischenuserid
undcardtoken
. So muss dieuserid
auf einer DESFire EV2 Karte nicht gespeichert werden. Siehe auch Datei 0003.
Weitere Schlüssel und Kommentare
Beliebige weitere Schlüssel können in der users.toml
angelegt werden und werden ebenso von BFFH geladen (key-value store) und auch wieder exportiert. Sie werden jedoch nicht vom System verwendet!
Kommentare können mit #
vorangestellt erzeugt werden oder auf gleicher Zeile hinter dem Wert ("Inline comment"):
[Admin1]
# this is the admin role
roles = ["Admin"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" #some inline comment
Kommentare werden spätestens beim Laden innerhalb der BFFH-Datenbank verworfen. Es empfiehlt sich im Falle des Kommentarbedarfs mit Exportstabilität einen Pseudoschlüssel anzulegen, zum Beispiel comment
:
[Admin1]
roles = ["Admin"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
comment = "this is the admin role"
Beispielbenutzer und -rollen
Rollen werden in der bffh.dhall-Konfiguration definiert. Das Docker-compose Repository https://gitlab.com/fabinfra/fabaccess/dockercompose hat ein gutes Beispiel:
[Admin1]
roles = ["Admin"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[Admin2]
roles = ["Admin"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[ManagerA1]
roles = ["ManageA", "UseA", "ReadA", "DiscloseA"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[ManagerA2]
roles = ["ManageA", "UseA", "ReadA", "DiscloseA"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[ManagerB1]
roles = ["ManageB", "UseB", "ReadB", "DiscloseB"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[ManagerB2]
roles = ["ManageB", "UseB", "ReadB", "DiscloseB"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
[ManagerC1]
roles = ["ManageC", "UseC", "ReadC", "DiscloseC"]
passwd = "secret"
cardkey = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
Manuelles Anlegen neuer Benutzer
Lasse alle neuen Nutzer ihre Passwörter verschlüsselt an den Admin übertragen, indem diese ihr Passwort als verschlüsselten Argon2 String übermitteln. Prinzipiell unterstützt FabAccess die Typen
- Argon2i
- Argon2d
- Argon2id
Die Passwörter können beliebig komplex werden. Es gibt verschiedene Parameter, die ein Passwort besonders sicher machen. Folgende Werte und ihrer empfohlenen Standardwerte können genutzt werden. Mit folgenden Settings hashed BFFH die Passwörter intern und exportiert sie auch so (bffhd --export
):
- Salt: eine zufällige Zeichenkette , z.B.
16
bytes lang (Empfehlung) - Parallelism Factor:
1
- Memory Cost:
4096
kilobytes - Iterations:
3
- Hash Length:
32
bytes
Je sicherer das Passwort gewählt wird, desto höher ist die benötigte CPU-Leistung zum Entschlüsseln und das Einloggen in FabAccess dauert entsprechend länger. Ein Passwort mit Parallelism Factor 10, Memory Cost 100000, Iterations 20 und Hash Length 100 benötigt auf einem Raspberry Pi 3 B+ ca. 15 Sekunden zur Entschlüsselung. Siehe auch https://www.ory.sh/choose-recommended-argon2-parameters-password-hashing und https://de.wikipedia.org/wiki/Argon2#Empfohlene_Parameter
Argon2 Passwort auf der Kommandozeile erzeugen ...
... mit Ubuntu Linux
apt install argon2
PASSWORD="mypassword" && echo | argon2 $PASSWORD -i -k 4096 -p 1 -t 3 -l 32
... mit Windows
Eine Implementierung für Windows existiert zum Beispiel unter https://github.com/philr/argon2-windows
Wir laden das Release-Zip herunter, entpacken es und führen Argo2Opt.exe
aus:
set PASSWORD="mypassword"
echo %PASSWORD% | Argon2Opt.exe %PASSWORD% -i -k 4096 -p 1 -t 3 -l 32
Wir übermitteln die kodierte Zeichenkette in die users.toml
, hier im Beispiel: $argon2i$v=19$m=4096,t=3,p=1$UEFTU1dPUkQ$VMwncjCWdW+f6x8qzshLaA
. Der Eintrag in der users.toml
könnte so lauten:
[vmario]
roles = ["mitglied"]
passwd = "$argon2i$v=19$m=4096,t=3,p=1$UEFTU1dPUkQ$VMwncjCWdW+f6x8qzshLaA"
cardkey = "70AFE9E6B1D6352313C2D336ADC2777A"
Argon2 Passwort mit Argon2 Hash Generator Tool
Argon2 Hashes können auch online erstellt werden:
Wir übermitteln dem Administrator von FabAccess letztlich die kodierte Zeichenkette, hier im Beispiel:$argon2i$v=19$m=4096,t=3,p=1$VHJCT0xBRkpIZGdyQkY4WA$7V9o957iuOYX/UoEHMpYncmTCNJ06dQ9YOJyZnxv3OU
Benutzerkonfiguration in BFFH importieren
Eine einmal angelegte users.toml
kann und muss in die BFFH-interne Datenbank importiert werden. Details siehe
Benutzerkonfiguration aus BFFH exportieren
Die in der BFFH-Datenbank gespeicherten Benutzer können mit dem Zusatz --dump-users
in eine users.toml
Datei exportiert werden (hier im Beispiel nach /etc/bffh/config_backup/users.toml
):
mkdir -p /etc/bffh/config_backup/
/usr/bin/bffhd --verbose --config /etc/bffh/bffh.dhall --dump-users /etc/bffh/config_backup/users.toml --force
Siehe auch Cheat Sheet - Wichtigste Befehle (Übersicht)
Weitere Tipps und und Tricks mit TOML Dateien
Ein paar weitere Tools, die das digitale Leben ggf. vereinfachen.
TOML-Dateien sortieren (nach Sektionen, Arrays, etc.) mit toml-sort
https://pypi.org/project/toml-sort
cd /opt/fabinfra/scripts/
python3 -m venv env
. env/bin/activate #activate venv
/opt/fabinfra/scripts/env/bin/pip3 install toml-sort
chown -R bffh:bffh /opt/fabinfra/scripts/env/
toml-sort --help
usage: toml-sort [-h] [--version] [-o OUTPUT] [-i] [-I] [-a] [--no-sort-tables] [--sort-table-keys]
[--sort-inline-tables] [--sort-inline-arrays] [--sort-first KEYS] [--no-header] [--no-comments]
[--no-header-comments] [--no-footer-comments] [--no-inline-comments] [--no-block-comments]
[--spaces-before-inline-comment {1,2,3,4}] [--spaces-indent-inline-array {2,4,6,8}]
[--trailing-comma-inline-array] [--check]
[F ...]
Mit folgendem Kommando lassen sich users.toml
Dateien sortieren und gleichzeitig überschreiben.
toml-sort --in-place --all /etc/bffh/users.toml
TOML-Dateien als JSON ausgeben/verarbeiten
Analog zum bekannten Werkzeug jq
(JSON-Parser) gibt es das Tool yq
für das TOML-Format (als Wrapper für jq
): https://kislyuk.github.io/yq/#toml-support
cd /opt/fabinfra/scripts/
python3 -m venv env
. env/bin/activate #activate venv
/opt/fabinfra/scripts/env/bin/pip3 install yq
chown -R bffh:bffh /opt/fabinfra/scripts/env/
Durch dieses Paket wird ebenfalls die Binary tomlq
automatisch mit installiert. Bitte beachten: Das gleichnamige Paket tomlq
gibt es separat auf PyPI, ist jedoch stark veraltet und inkompatibel zu neuen Python Versionen. Es wird daher empfohlen das beinhaltende, aktuellere Paket yq
zu installieren.
Unsere users.toml
als JSON-Objekt ausgeben:
tomlq '.' /etc/bffh/users.toml
Mit dem nachfolgenden Befehl überschreiben wir eine users.toml
Datei so, dass z.B. alle Kommentare entfernt werden:
tomlq -t -i '.' /etc/bffh/users.toml
Benutzer mit externen Systemen synchronisieren
Grundsätzlich gibt es mehrere Möglichkeiten, um Benutzer in FabAccess anzulegen:
- über eine
users.toml
Datei - direkt über die Client App (als Administrator)
- über die API. Hierzu gibt es eine Referenzimplementation pyfabi mit einem Beispielscript
add_del_user.py
Hinweise zum Arbeiten mit users.toml Dateien
Wer mit einer automatisierten Erstellung einer users.toml
aus externen Nutzerquellen arbeitet, der sollte folgenden Workflow erarbeiten:
- BFFH Server herunterfahren
- Aktuelle Benutzerkonfiguration per
/usr/bin/bffhd --dump-users users.toml
sichern - die soeben gesicherte
users.toml
Datei benutzen, um die aktuellsten Änderungen an der Benutzerbasis hinzuzufügen, zu löschen oder zu ändern. Hier muss selbst entschieden werden, welche Benutzerdaten aktuell sein sollen: Die durch die App geänderten Daten, oder die aus der externen Quelle? Eine von beiden muss die andere überschreiben bzw. überlagern. Entsprechend muss das verwendete Script programmiert sein: bei Vorhandensein von Nutzern, Rollen, Passwörter, Cardkeys rückfragen, ob bei Differenzen der bestehende oder der neue Datensatz verwendet werden soll oder per Config-Parameter automatisiert durchführen. - die neue
users.toml
Datei laden:/usr/bin/bffhd --load-users users.toml
(siehe auch Nutzerdatenbank laden / hashen / prüfen) - BFFH Server starten
Unter Umständen ist die Arbeit mit der pyfabapi sinnvoller!
LDAP Anbindung
Hierzu gibt es einen dedizierten Artikel.
Authentik
Nutzer geben ein zweites Passwort an und ein Skript checkt jede Minute Authentik ob es neue Nutzer gibt, sich Gruppen/Passwort geändert haben und nimmt entsprechend Änderungen über die FabAccess API vor. Das Passwort wird dann aus den Nutzerattributen gelöscht. Die Daten liegen in einer MySQL Datenbank.
Mögliche Ansprechartner dafür könnten das Creative Lab der Hochschule München oder Michael Prange vom MakerSpace Gütersloh sein!
CiviCRM
CiviCRM erlaubt den Export von Nutzern als CSV-Tabelle. Diese kann verwendet werden, um Nutzer in FabAccess zu importieren.
Roy Böttcher vom MakerSpace Leipzig fragen!
VereinOnline
Nutzer und Gruppen aus VereinOnline lassen sich mit dem Tool csv-to-fabaccess-user-toml vom Sternenlabor Plauen direkt als users.toml
ausgeben. Dazu wird eine Datei namens Mitglieder.csv
mit Spaltenseparator ;
und den Spalten Login
und Gruppen
(mit Separator ,
) erzeugt. Für das Tool muss Node.js installiert sein.
cd ~
git clone https://github.com/Sternenlabor/csv-to-fabaccess-user-toml.git
cd csv-to-fabaccess-user-toml/
sudo apt install nodejs
npm install csv-parser
Mitglieder-CSV Datei - Beispiel:
https://docs.fab-access.org/data-csv-to-fabaccess-user-toml/Mitglieder.csv
# Ausführen
node run.mjs
[
{ Login: 'Anton', Gruppen: 'Admins' },
{ Login: 'Peter', Gruppen: 'Mitglieder,Admins' },
{ Login: 'Jonny', Gruppen: 'Mitglieder' },
{ Login: 'Sarah', Gruppen: 'Mitglieder' }
]
users: 4
File created successfully
Beispiel-Output:
cat user.toml
[Admin1]
roles = [ "Admin" ]
passwd = "secret"
[Anton]
roles = [ "User", "Admins" ]
passwd = "secret"
[Peter]
roles = [ "User", "Mitglieder,Admins" ]
passwd = "secret"
[Jonny]
roles = [ "User", "Mitglieder" ]
passwd = "secret"
[Sarah]
roles = [ "User", "Mitglieder" ]
passwd = "secret"
easyVerein
Für das Programm easyVerein sind noch keine Schnittstellen in der Community bekannt. Jedoch nutzen es viele offene Werkstätten.
Hauptkonfiguration - bffh.dhall
BFFH verwendet Dhall für die Struktur von Ressourcen (z.B. Maschinen), Rollen, Aktoren und Initiatoren. Die Konfiguration von BFFH befindet sich in der Datei bffh.dhall
. Die Datei kann auch umbenannt werden. Wichtig ist, dass sie dann überall korrekt referenziert wird (z.B. in Service Scripts). Der betreffende Quellcode findet sich in GitLab.
Offizielles Dhall Logo
Tipps & Tricks in Dhall
Dhall ist eine umfangreiche Sprache für die Konfiguration und erlaubt äußerst komplexe Datenstrukturen. Vieles davon wird für FabAccess vermutlich nur im kleineren Rahmen benötigt, jedoch besteht die Kompatibilität auch für komplizierte Gebilde. Im Rahmen dieser Dokumentationen gehen wir nur auf grundlegende, wichtige und besonders praktische Konfigurationsaspekte ein.
Ein nutzbringenden Cheatsheet für Dhall findet sich unter https://docs.dhall-lang.org/howtos/Cheatsheet.html
Literal für leere Einträge
Dhall-Records können auch leer übergeben werden. Dafür gibt es eine spezielle Syntax: {=}
. Siehe https://hackage.haskell.org/package/dhall-1.42.1/docs/Dhall-Tutorial.html#g:6
Beispiel:
initiators = {=}
Literal "Some"
Die folgenden beiden Angaben sind inhaltlich gleich. Das Wörtchen "Some" macht in unserem Beispiel den Wert port
optional. Diese Notation kann verwendet werden, um innerhalb einer Konfiguration darauf hinzuweisen, dass ein Wert fest gesetzt werden könnte, aber aktuell nicht von Nöten ist. Siehe https://hackage.haskell.org/package/dhall-1.42.1/docs/Dhall-Tutorial.html#g:5
Beispiel:
listens = [{ address = "127.0.0.1" }]
listens = [{ address = "127.0.0.1", port = Some 59661 }]
Kommentare
Siehe https://docs.dhall-lang.org/tutorials/Language-Tour.html#comments
Zeilen, die mit --
beginnen, werden automatisch als Kommentar gewertet. Das kann auch verwendet werden, um z.B. nicht mit dem Literal "Some
" zu arbeiten. So können wir z.B. eine Originalzeile auskommentieren und darunter unsere angepasste Zeile schreiben.
Beispiel Zeilenkommentar:
--listens = [{ address = "127.0.0.1", port = 59661 }]
listens = [{ address = "127.0.0.1" }]
Kommentare können auch in Blöcken geschrieben werden, wenn sie in einem Block beginnend {-
und endend mit -}
stehen. So werden diese bei etwaigen Formatieroperationen mit dhall format <Datei>
nicht entfernt!
Beispiel Blockkommentar:
{- Main configuration file for bffh
================================
In this configuration file you configure almost all parts of how bffh operates, but most importantly:
* Machines
* Initiators and Actors
* Which Initiators and Actors relate to which machine(s)
* Roles and the permissions granted by them
-}
Beispiel Blockkommentar an beliebiger Stelle:
roles = ./roles.dhall, {- Kommentar mitten im Text -}
Zeichenketten erzeugen
Werte können zusammengefügt werden (concatenation). Das geht zum Beispiel mit dem Syntax ++
wie folgt:
certfile = env:BFFH_CFG_PATH as Text ++ "/cert/bffh.crt"
Oder als Verkettungsbefehl:
hobbies = concatSep ", " [ "piano", "reading", "skiing" ]
Dhall-Konfigurationen verschlanken
Folgende Möglichkeiten der Vereinfachung und Granulierung von Dhall-Dateien stellen wir vor. Wir berufen uns unter anderem auf die Dokumentation https://github.com/dhall-lang/dhall-lang/blob/master/standard/imports.md
Variablen/Konstanten innerhalb einer Datei setzen
Folgendes Beispiel erzeugt ein Listing VARS
, welches drei Variablen enthält, die vereinheitlicht angesprochen werden können. Variablen lassen sich auf diese Art und Weise beliebig tief schachteln. Zu beachten ist das kleine Wörtchen in
, welches im darauffolgenden Block (Record) eine Ersetzung bzw. Referenzierung anstrebt.
let VARS = {
BFFH_CFG_PATH = "/etc/bffh/",
MQTT_USER = "fabinfra101",
MQTT_PASSWD = "fablocal"
}
in {
listens = [
{ address = "0.0.0.0", port = 59661 }
],
certfile = VARS.BFFH_CFG_PATH ++ "certs/bffh.crt",
keyfile = VARS.BFFH_CFG_PATH ++ "certs/bffh.key",
mqtt_url = "mqtt://" ++ VARS.MQTT_USER ++ ":" ++ VARS.MQTT_PASSWD ++ "@0.0.0.0:1883",
db_path = VARS.BFFH_CFG_PATH ++ "bffh.db"
}
Umgebungsvariablen verwenden
Wir setzen z.B. ein einer Bash-Umgebung einen Variablenwert und führen ein Kommando aus, welches die nachfolgende Dhall-Datei verwendet. Der Prozess, der die Dhall-Datei interpretiert, sucht in seiner übergebenen Umgebung (Environment) nach passenden Variablen und ersetzt die Werte entsprechend.
Als Rohtext in Dhall:
# bash
export BFFH_CFG_PATH="/etc/bffh"
bffh_cfg = env:BFFH_CFG_PATH as Text
oder als aufgelöster Pfad in Dhall:
# bash
export BFFH_CFG_PATH="~/bffh"
bffh_cfg = env:BFFH_CFG_PATH as Location
Inhalte aus URLs importieren
Folgender Syntax lädt den Content der entfernten URL als Variableninhalt:
let concatSep = http://prelude.dhall-lang.org/Prelude/Text/concatSep sha256:fa909c0b2fd4f9edb46df7ff72ae105ad0bd0ae00baa7fe53b0e43863f9bd34a
Importe können mit Integritätsprüfungen geschützt werden, wenn ein SHA-256-Hash angehängt wird (wie beim obigen concatSep
-Import). Dadurch verhindern wir Manipulation von außerhalb.
Dhall-Dateien innerhalb anderer Dhall-Dateien referenzieren (verschachteln)
Importierte Ausdrücke können transitiv andere Ausdrücke importieren. Eine exemplarische Datei ./schema.dhall
kann andere Dateien importieren:
{
name : ./schema/name.dhall,
age : ./schema/age.dhall,
hobbies : ./schema/hobbies.dhall
}
... und wenn ./schema/hobbies.dhall
einen relativen Import enthielte wie z.B.:
List ./hobby.dhall
... dann würde sich der relative Import von ./hobby.dhall
tatsächlich auf ./schema/hobby.dhall
beziehen. Dies ist als "Importverkettung" bekannt: die Auflösung von Importen relativ zur Position des aktuellen Ausdrucks.
Auf Kommas achten
In verschiedenen Konfigurationssprachen wie JSON, TOML und Dhall verhalten sich die Syntaxregeln unterschiedlich. In Dhall-Dateien ist es für einige Parser schädlich, wenn innerhalb einer List oder eines Records ein "trailing" Komma auftaucht. Folgendes sollte vermieden werden:
listens = [
{ address = "127.0.0.1" },
{ address = "::1" },
]
Syntaktisch korrekt ist:
listens = [
{ address = "127.0.0.1" },
{ address = "::1" }
]
BFFH kommt mit diesem Kommaproblem aus, jedoch der offizielle dhall-haskell Parser nicht.
Kurze oder lange Schreibweise
Wir können die Unterlemente Dummy_123
, Dummy_234
und Dummy_345
im Beispiel in ein neues Klammernpaar schreiben oder direkt mit einem Punkt abtrennen und auf die gleiche Zeile schreiben:
actors = {
Dummy_123 = {
module = "Dummy",
params = {=}
},
Dummy_234 = {
module = "Dummy",
params = {=}
},
Dummy_345 = {
module = "Dummy",
params = {=}
}
}
Oder entsprechend eingekürzt:
actors.Dummy_123 = {
module = "Dummy",
params = {=}
},
actors.Dummy_234 = {
module = "Dummy",
params = {=}
},
actors.Dummy_345 = {
module = "Dummy",
params = {=}
}
Oder bei Rollen:
roles = {
Admin = {
permissions = [
"bffh.users.manage",
"bffh.users.info",
"bffh.users.admin"
]
}
}
... eingekürzt:
roles.Admin.permissions = [
"bffh.users.manage",
"bffh.users.info",
"bffh.users.admin"
]
Das eignet sich bei Rollen, Aktoren und Initiatoren! Wie es verwendet werden soll ist hier Geschmackssache.
Dhall-Dateien parsen, prüfen und formatieren
Dhall-Dateien können mit einer eigenen Bibliothek geparsed und auf Fehler geprüft werden. Das Resultat kann zudem neu formatiert ausgegeben werden - auch unter den Stichworten Beautify oder Prettyprint bekannt. Hierfür muss die Bibliothek dhall
installiert werden.
sudo apt install dhall
Falls die Installation scheitert, kann das Paket auch manuell installiert werden (siehe https://pkgs.org/search/?q=dhall) - Beispiel für Raspberry Pi mit Debian Bookworm:
wget http://ports.ubuntu.com/pool/universe/h/haskell-dhall/dhall_1.32.0-1build1.1_arm64.deb
dpkg -i dhall_1.32.0-1build1.1_arm64.deb
Das Folgende Kommando setzt zunächst die Konfigurationsdatei als Variable. Wenn diese Datei erfolgreich geparsed werden konnte, dann formatieren wir diese und überschreiben dann die Originaldatei - beim Scheitern unternehmen wir nichts.
Warnung:
Durch das automatische Formatieren werden alle etwaigen Kommentare entfernt (bekanntes Problem von Dhall, siehe hier), es sei denn diese werden in als Blockkommentar an den Anfang der Datei esetzt (siehe oben). Falls der FabAccess Config Generator genutzt wird, gehen dabei u.a. auch die Anfangs- und End-Tags --- ||| GENERATOR START
und --- ||| GENERATOR END
verloren!
Unterreferenzierte Dhall-Dateien werden nicht automatisch mitgeprüft. Eine Rekursion findet also nicht statt. D.h. jede Dhall-Datei muss einzeln geprüft/formatiert werden.
Wir nutzen folgende Kommandos zum Formatieren:
CFG="/etc/bffh/bffh.dhall" && \
dhall format < $CFG && \
dhall format < $CFG > $CFG.bup && \
rm $CFG && \
mv $CFG.bup $CFG
Es können jedoch auch die offiziellen Flags verwendet werden. Siehe:
Usage: dhall format [--inplace FILE] [--check]
Standard code formatter for the Dhall language
Available options:
--inplace FILE Modify the specified file in-place
--check Only check if the input is formatted
-h,--help Show this help text
#nur formatieren
dhall format --inplace /etc/bffh/bffh.dhall --check
# formatieren und überschreiben
dhall format --inplace /etc/bffh/bffh.dhall
Siehe auch Konfiguration von BFFH auf Synax und Inhalt prüfen für eine BFFH-spezifische Kontrolle der Daten.
Syntax-Highlighting: Dhall-Dateien schöner bearbeiten
Für verschiedene Editoren gibt es Highlighter-Plugins, dabei unter anderem für Vim, VS Code und Emacs. Siehe hier. Eine Referenz findet sich auch in https://docs.dhall-lang.org/howtos/Text-Editor-Configuration.html.
Für Vim funktioniert das zum Beispiel so:
curl -fLo ~/.vim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
vim ~/.vimrc
call plug#begin()
Plug 'vmchale/dhall-vim'
call plug#end()
Beim nächsten Öffnen des Editors führen wir das Kommando :PlugInstall
aus, installieren damit das Plugin und öffnen dann beliebige Dhall-Dateien und sehen, dass uns Syntax-Highlighting nun zur Verfügung steht.
Damit die Datei als Dhall erkannt wird, muss die Dateiendung *.dhall lauten.
Die Konfiguration von BFFH
Den FabAccess Server zu konfigurieren ist zweifellos eine der wichtigsten Aufgaben und erfordert die Auseinandersetzung mit einigen Konzepten.
Bei jeder Änderung der Konfigurationsdatei muss BFFH neugestartet werden, um die Änderungen zu übernehmen!
Übersicht über alle Einstellungen
In der Config gespeichert werden grundlegende, überwiegend pflichtmäßig anzugebende Informationen zu ...
- allgemeine Einstellungen (z.B. Interface, Port, Zertifikate, Audit, Datenbank, etc.)
listens
db_path
certfile
keyfile
tls_min_version
(optional)ciphers
(optional)mqtt_url
auditlog_path
- Rollen, Berechtigungen, Ressourcen (Maschinen)
- Aktoren, Initiatoren und ihre Mappings
- Föderation & FabFire
Allgemeine Einstellungen
listens
::List
Enthält eine Liste aus Einträgen mit einer Adresse (address
::String (notwendig)), auf die BFFH bei der Verbindung für die API hört sowie einer Portangabe (port
::Integer (optional)). Die Adresse kann eine IPv4, IPv6 oder ein Hostname sein. Wird der Port nicht angegeben, dann wird der Standardport verwendet. Dieser Port lautet für BFFH 59661
und dabei handelt es sich um einen dynamischen/privaten Port, der auch ohne Root-Zugriff genutzt werden kann (siehe auch "registrierte Ports").
Es ist möglich mehrere Einträge (verschiedene Adressen und Ports) anzugeben. BFFH versucht alle Verbindungen zu etablieren. BFFH kann also z.B. auch gleichzeitig auf 0.0.0.0:59661
und 0.0.0.0:5961
lauschen.
Achtung: Wenn BFFH keinen Port für die angegebene Kombination binden kann, wird ein Fehler protokolliert, aber mit den übrigen Ports fortgefahren.
Beispiele für listens:
listens = [
{ address = "127.0.0.1", port = Some 59661 },
{ address = "::1", port = 59661 },
{ address = "steak.fritz.box", port = 59661 } ]
mqtt_url
::String
Enthält die Adresse des MQTT-Servers, mit dem sich BFFH verbindet.
Die Adresse hat das Format <protocol>://[user]:[password]@<server>:[port]
protocol
(notwendig) - kann eins der folgenden Werte annehmen:mqtt
,tcp
,mqtts
,ssl
user
(optional)password
(optional)server
(notwendig) - kann IP-Adresse oder Hostname seinport
(optional) - Der Standardport ist1883
Beispiele für mqtt_url:
mqtt_url = "tcp://localhost:1883"
mqtt_url = "mqtts://user:password@server.tld:port"
Achtung: Der MQTT-Server muss laufen und erreichbar sein, sonst startet BFFH nicht. Wird die MQTT-Verbindung getrennt, während BFFH läuft, stürzt BFFH nicht ab und protokolliert stattdessen die Verbindungsfehler in die Log-Ausgabe.
certfile
::String und keyfile
::String
Unsere Kommunikation über Cap'n Proto erfolgt grundsätzlich verschlüsselt. Dafür benötigen wir ein TLS-Zertifikat. Details, wie man ein TLS-Zertifikat generiert: Server - Anleitung zum selber kompilieren.
BFFH benötigt ein PEM-kodiertes Zertifikat und den zugehörigen Schlüssel als zwei separate Dateien. BFFH verwendet TLS standardmäßig und ausschließlich in Version 1.2 bzw 1.3. Dabei implementiert es die Rust-Bibliothek rustls im Code.
Beispiel für certfile und keyfile:
certfile = "/etc/bffh/certs/bffh.crt"
keyfile = "/etc/bffh/certs/bffh.key"
ciphers
::String (optional)
Es kann eine Cipher Suite vorgegeben werden, die genutzt werden soll.
Wir empfehlen diesen Wert nicht zu vergeben und beim Standard zu belassen (standardmäßig wird diese Option in bffh.dhall nicht gesetzt).
Die Definition erfolgt als String, nicht als List und kann deshalb aktuell nur eine einzelne Cipher Suite enthalten. Siehe Issue 109.
Beispiel für ciphers:
ciphers = "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
Mögliche Cipher Suites sind:
- TLS v1.2 + TLS v1.3
- TLS v.1.3 only
tls_min_version
::String (optional)
Die TLS Version von BFFH kann erzwungen werden.
Wir empfehlen diesen Wert nicht zu vergeben und beim Standard zu belassen (standardmäßig wird diese Option in bffh.dhall nicht gesetzt).
Mögliche Werte:
tls12
für TLS v1.2tls13
für TLS v1.3
Beispiel für tls_min_version:
tls_min_version = "tls12"
protocols
::List (optional)
Gibt an, welche Protokolle durch BFFH genutzt werden dürfen.
Diese Einstellung kann gesetzt werden, hat aber keine Auswirkungen und wird im Code aktuell nicht genutzt. Sie wird nur zur Vollständigkeit hier gelistet. Es ist nicht bekannt, welche Protokolle unterstützt werden sollen!
Beispiel für protocols:
protocols = ["tcp"],
db_path
::String
Enthält den Pfad für die interne Datenbank auf LMDB-Basis, die BFFH verwendet. BFFH wird beim Start zwei Dateien erstellen, falls nicht bereits existent: /var/lib/bffh/bffh.db
und /var/lib/bffh/bffh.db-lock
. BFFH erstellt selber keine fehlenden Verzeichnisse. Es sollte sichergestellt werden, dass BFFH Schreibzugriff auf das entsprechende Verzeichnis hat.
Die interne Datenbank wird im Produktivbetrieb nicht riesig (nur einige Kilobyte bis wenige Megabyte). In ihr werden die aktuellen Ressourcenzustände (states) gespeichert (welche Ressource ist z.B. gerade durch einen Nutzer INUSE
) und welche Nutzer mit Rollen, Passwörtern und Cardkeys zugreifen dürfen. Diese interne Datenbank kann exportiert werden (Benutzerdaten können als *.toml
Datei ausgegeben werden oder die ganze Datenbank inklusive Zuständen kann exportiert werden). Wir empfehlen die Ablage im Standardverzeichnis /var/lib/bffh/
.
Beispiel für db_path:
db_path = "/var/lib/bffh/bffh.db"
BFFH Datenbank "Werkszustand" wiederherstellen:
Die Datenbankdatei und die Lock-Datei können prinizipiell nach Beenden des Dienstes gelöscht werden, jedoch gehen dabei die gespeicherten aktuellen Ressourcenzustände und Nutzer verloren. Die Nutzer können über eine aktuelle users.toml
wieder importiert werden. Dass die Ressourcenzustände verloren gehen, ist je nach Werkstattsetup u.U. einfach zu verkraften. Entsprechend kann damit ein Reset durchgeführt werden. Ggf. sollten alte Audit-Einträge (siehe auditlog_path
) ebenso bereinigt werden.
Vor jedem Update / Recompile unbedingt beachten:
Die Datenbank speichert ihre Daten nicht im Klartext. Die als Datei erzeugte Datenbank bffh.db
ist abhängig vom System, wo sie angelegt wurde. Jeder Recompile oder Umzug auf einen anderen Host bzw. Architektur macht die Datenbank unbrauchbar. Deshalb muss auch vor jedem Update eine Sicherung erstellt werden, die jedoch re-importiert werden kann.
Bei Nichtbeachtung droht Verlust der angelegten Benutzerdatenbank und den gespeicherten Ressourcenzuständen.
Die automatisch beim Start erstellte Lock-Datei /var/lib/bffh/bffh.db-lock
wird nach dem Beenden von BFFH nicht automatisch gelöscht, kann aber manuell immer dann entfernt werden, so lange BFFH nicht läuft. Während des Betriebs sollte die Lock-Datei nicht gelöscht werden, da es sonst zu Korruption in Lese- und Schreibprozessen kommen kann.
auditlog_path
::String
Pfadangabe zur Auditdatei, die BFFH im laufenden Prozess schreibt. Die Ausgabe erfolgt im JSON-Format. Siehe Audit Log (Revisionsprotokoll) für Details zum Audit. Die Datei kann zum Beispiel mit Tools wie Grafana Loki ausgelesen werden. Wir empfehlen deshalb den Pfad so zu definieren, dass entsprechende Dienste korrekte Leseberechtigungen auf die Datei haben. Der bei Linux-Systemen verwendete Standardpfad for Log-Dateien ist per se /var/log/
.
Beispiel für auditlog_path:
auditlog_path = "/var/log/bffh/audit.json"
Falls BFFH wegen einem Log-Berechtigungsfehler nicht startet, kann folgender Trick angewendet werden.
Error:
× audit log failed
╰─▶ Permission denied (os error 13)
Lösung: die fehlende Datei neu und leer erzeugen und manuell die passende Berechtigungen setzen:
sudo touch /var/log/bffh/audit.json
sudo chown bffh:root /var/log/bffh/audit.json
sudo chmod 750 /var/log/bffh/audit.json
Alternativ kann auch mit setfacl
eine ACL angelegt werden. Hierzu gibt es ein nettes Tool unter https://techgeeks.io/unix/acl-generator.
sudo setfacl -R -m u:bffh:rw-,d:u:bffh:rw- /var/log/bffh/audit.json
Konfiguration von Rollen, Berechtigungen und Ressourcen
FabAccess verwendet eine Role-Based Access Control (RBAC)-Struktur zur Verwaltung von Berechtigungen. Dabei werden Berechtigungen Ressourcenrollen zugewiesen, und diese Rollen werden dann den Benutzern zugewiesen. Auf diese Weise lässt sich ein komplexes Berechtigungssystem einfach, ufassend und flexibel abbilden. Details finden sich unter RBAC (Benutzerrollen und Berechtigungen).
roles
::Record
Enthält die Einträge der definierten Rollen. Rollen haben eine Liste von Berechtigungen und können vererbt werden. Die Berechtigung kann ein Platzhalter in der Berechtigungsliste sein. Jede Rolle muss eine Role-ID
haben. Unterhalb des Eintrags roles
schachteln sich Listen vom Typ parents
::List (optional) und vom Typ permissions
::List (notwendig).
Standardberechtigungen
BFFH verfügt über einige Standardberechtigungen, die der Verwaltung und den Admin-Rechten zugewiesen werden können. Die lauten exakt:
bffh.users.info
- Nutzerliste bekommen und Infos über diese Accounts erhaltenbffh.users.manage
- Nutzerliste bekommen und Nutzer verwaltenbffh.users.admin
- Globale Administration: Nutzer hinzufügen, löschen, ändern (z.B. Passwort-Reset)
Beispiel für eine Admin-Rolle mit Standardberechtigungen:
roles = {
Admin = {
permissions = [
"bffh.users.manage",
"bffh.users.info",
"bffh.users.admin"
]
}
}
Modellieren von Berechtigungen für Ressourcen
Allgemeines Schemaspace.type.category.permission.model
Administratorspace.machines.printers.*
Offene Berechtigungspace.machines.printers.read.*
Allgemeine Erläuterungen zum Pfadformat und Platzhaltern (*
, +
)
BFFH verwendet eine pfadähnliche Zeichenkette als Erlaubnisformat, getrennt durch einen .
Punkt. So besteht zum Beispiel this.is.a.permission
aus den Teilen this
, is
, a
und permission
. Bei der Anforderung von Berechtigungen, z. B. in Ressourcen, muss immer eine genaue Berechtigung angegeben werden, also z. B. test.write
.
Bei der Erteilung von Berechtigungen, z. B. in Rollen, können entweder eine genaue Berechtigung angegeben oder die beiden Platzhalter *
und +
verwendet werden. Diese Wildcards verhalten sich ähnlich wie Regex- oder Bash-Wildcards:
*
gewährt alle Berechtigungen in diesem Teilbaum. So wirdperms.read.*
für jedes von passen:
perms.read
perms.read.machineA
perms.read.machineB
perms.read.machineC.manage
+
gewährt alle Berechtigungen unter des Wertes. So wirdperms.read.+
für jedes von passen:
perms.read.machineA
perms.read.machineB
perms.read.machineC.manage
- aber nicht
perms.read
Wildcards sind wahrscheinlich am nützlichsten, um Ressourcen zu gruppieren, z.B. 3D-Drucker und eine Bandsäge:
- Write (schreiben) Berechtigungen
machines.printers.write.prusa.sl1
machines.printers.write.prusa.i3
machines.printers.write.anycubic
machines.bandsaws.write.bandsaw1
- Manage (verwalten) Berechtigungen
machines.printers.manage.prusa.sl1
machines.printers.manage.prusa.i3
machines.printers.manage.anycubic
machines.bandsaws.manage.bandsaw1
- Admin Berechtigungen
machines.printers
- Für alle Drucker
- Für alle Drucker
machines.bandsaws
- Für alle Bandsägen
- Für alle Bandsägen
Dann erteilen wir den Rollen die entsprechenden Rechte:
- Nutze beliebige 3D-Drucker:
machines.printers.write.+
- Erlaube nur die Nutzung "billiger" Drucker:
machines.printers.write.anycubic.*
machines.printers.write.prusa.i3
- Erlaube das Verwalten der Drucker:
machines.printers.+
- Erlaubte das Administrieren aller Drucker:
machines.printers.*
Auf diese Weise klappt es trotzdem mit der Aufteilung, wenn später ein weitere Anycubic Drucker gekauft wird:
machines.printers.write.anycubic.i3
machines.printers.write.anycubic.megax
Beispiel für verschiedene Rollen mit Berechtigungen:
- Wildcard-Rolle
testrole
- "normale" Rolle
anotherrole
- Rolle
somerole
mit vererbter Rolletestparent
:
roles = {
testrole = {
permissions = [ "lab.some.*" ]
},
somerole = {
parents = [ "testparent" ],
permissions = [ "lab.some.admin" ]
},
testparent = {
permissions = [
"lab.some.write",
"lab.some.read",
"lab.some.disclose" ]
},
anotherrole = {
permissions = [
"lab.some.disclose.*",
"lab.some.read.*",
"lab.some.write.*" ]
}
}
machines
::Record
Info: Der Record machines
wird in Zukunft resources
heißen!
Enthält die Einträge der definierten Ressourcen. Jede Ressource muss eine Resource-ID
haben, um in anderen Teilen dieser Konfiguration oder über die API auf die Ressource verweisen zu können. Und jede Ressource muss einen Namen haben. In FabAccess ist die Ressource ein wichtiger Schlüsselbegriff und steht für Dinge wie Türen, Schließfächer, Geräte oder Maschine. Kurzum: Dinge, die sich ein- und ausschalten lassen sollen.
Allgemeine Ressourceninformationen
Um weitere Informationen über die Ressource bereitzustellen, können Namen, Kategorien, Beschreibungen oder ein externer Wiki-Link eingefügt werden:
name
::String (notwendig) - ein Klarname, zum Beispiel ein Spitzname für eine Maschine oder eine Modellbezeichnung (Unicode-Support)description
::String (optional) - eine allgemeine, kurze Beschreibung der Ressource (Unicode-Support)wiki
::String (optional) - Link zu einer Wiki- bzw. Dokumentationsseitecategory
::String (optional) - eine beliebige Kategorie, z.B. "Holzwerkstatt" oder "Handgerät, elektrisch"(Unicode-Support)prodable
::Boolean (optional) - definiert, ob die Ressource ein Türschloss ist - zum Beispiel an einem Werkzeugschrank, Schließfach ode Eingangstür (abv0.4.4
). Dieses Attribut schaltet im Borepin Client zwei Buttons frei, die sonst nicht sichtbar sind:
UNLOCK
öffnet bzw. entsperrt die Ressource, ohne sie für andere zu blockieren und ohne sie zurückgeben zu müssenIDENTIFY
löst eine einfache Aktion aus wie z.B. das Aufleuchten einer LED an der Ressource, um das Fach bzw. die Ressource optisch leichter zu identifizieren
Was heißt Unicode-Support?
Durch diese Eigenschaft können wir neben einfachen Bezeichnungen auch beliebige Sonderzeichen einfügen. Das erlaubt unter anderem die Verwendung von Emojis, die innerhalb der Client-Anwendung visuell unterstützen können. Dafür kann ein beliebiger Emoji-Picker genutzt werden, zum Beispiel https://www.freetool.dev/emoji-picker. D.h. wir können z.B.description = "Saug dir Energie ;-) 🪫",
konfigurieren. Das sieht dann in Borepin so aus:
Zugewiesene Berechtigungen für Ressourcen
Die Ressourcen haben verschiedene Berechtigungsstufen, mit denen interagiert werden kann und welche sich in den Records in roles
wiederspiegeln:
disclose
::String (notwendig) - Offenlegen: Der Benutzer kann die Ressource in der Übersichtsliste sehen (entdecken), jedoch keine Details zu ihr aufrufen (Detailansicht erfordertread
Berechtigung)read
::String (notwendig) - Lesen: Der Benutzer kann allgemeine Informationen über die Ressource und ihren Zustand lesen, sowie z.B. den Wiki Link anklickenwrite
::String (notwendig) - Schreiben: Der Benutzer kann die Ressource bedienen und dabei folgende Zustände verändern:- Benutzen (
InUse
) bzw. Zurückgeben (Free
, auch als GIVEBACK in der Client App bezeichnet) - Reservieren (
Reserve
)
- Benutzen (
manage
::String (notwendig) - Verwalten: Der Benutzer kann als Manager sehen, wer die Maschine aktuell benutzt und wer sie zuletzt benutzt hat. Außerdem können Mananger mit dem System interagieren und dabei folgende Zustände verändern:- Freigeben erzwingen (force
Free
) - Blockieren (
Blocked
) - Deaktivieren (
Disabled
) - Überprüfen (
ToCheck
) - Transferieren (
totakeover
)
- Freigeben erzwingen (force
Tipp: Wenn einer Ressource die read
Berechtigung, aber nicht disclose
Berechtigung gegeben wird, dann taucht die Ressource nicht in der Übersichtsliste auf. Sie kann auf diese Weise nur noch direkt angesprochen werden, indem ein QR-Code oder ein NFC-Tag gescannt wird. So lässt sich erzwingen, dass ein Nutzer zur Maschine lokal hingehen muss und die Ressource nicht von weiter weg bedienen kann (es sei denn der Benutzer klont den QR-Code oder NFC-Tag und nimmt ihn mit).
Bitte beachten:
- Jeder Ressource müssen alle Berechtigungsstufen zugewiesen sein.
- Berechtigungsstufen sind nicht additiv, d.h. ein Benutzer mit der Berechtigung
manage
erhält nicht automatischread
oderwrite
Berechtigung. disclose
ist im Moment nicht vollständig implementiert. Benutzer, die keinedisclose
Berechtigung haben, werden in keiner Weise über diese Ressource informiert und sie wird vor ihnen im Client verborgen. Es ist deshalb am sinnvollsten, wennread
unddisclose
die gleiche Berechtigung zugewiesen bekommen, zum Beispieldisclose = "lab.test.read"
.- Benutzern ohne
read
wird eine Resource mit Namen, Beschreibung, Kategorie und Wiki angezeigt, aber nicht ihr aktueller Zustand. Der aktuelle Benutzer der Ressource wird nicht offengelegt.
Beispiel einer Ressource mit allen Parametern:
machines = {
machine_123 = {
name = "Testmachine",
description = Some "A test machine",
wiki = "https://someurl",
category = "Testzone",
prodable = True,
disclose = "lab.some.read",
read = "lab.some.read",
write = "lab.some.write",
manage = "lab.some.admin"
}
}
Im Beispiel heißt unser Resource-ID
machine_123
.
Konfiguration von Aktoren (actors)
actors
::Record
Enthält eine Liste von Aktoren. Aktoren werden durch ein Modul module
::String (notwendig) und einen oder mehrere Parameter params
::Record definiert. Aktuell von Haus aus unterstützte Aktoren (ohne zusätzliche Plugins) sind Dummy Actor, Shelly Actor und Process Actor.
Konkret nutzbare Aktoren-Beispiele finden sich hier.
Aktoren werden durch ein Modul und einen oder mehrere Parameter definiert. Die Liste kann bzw. muss leer sein, wenn keine Aktoren verwendet werden:
Beispiel für leere actors:
actors = {=}
Sonst kann die Liste einen oder mehrere Aktoren mit ihrem Name (Actor-ID
) enthalten:
Dummy Actor
Für Testzwecke kann ein interner Dummy-Initiator genutzt werden. Der „Dummy“-Initiator versucht alle paar Sekunden, einen Rechner als den angegebenen Benutzer zu verwenden und zurückzugeben. Er ist gut geeignet, um das System zu testen, führt aber zu Spam im Log und ist daher standardmäßig deaktiviert.
Beispiel für Dummy Actor:
actors = {
Dummy_123 = {
module = "Dummy",
params = {=}
}
}
Im Beispiel heißt unser Actor-ID
Dummy_123
.
Shelly Actor
Dieser Aktor verbindet BFFH über einen MQTT-Server mit einem Shelly Gerät (dafür wird intern die MQTT-Bibliothek rumqttc verwendet). Der Parameter topic
::String (optional) des Shelly kann auf das Shelly-spezifische MQTT-Topic gesetzt werden. Wird kein topic
definiert, dann verwendet der Actor automatisch die definierte Actor-ID
.
Anleitung zum Auffinden des Shelly Topic
Beispiel für Shelly Actor:
actors = {
Shelly_123 = {
module = "Shelly",
params = {
topic = "shellyplug-s-123456"
}
}
}
Im Beispiel heißt unser Actor-ID
Shelly_123
.
Process Actor
Dieser Aktor ermöglicht es, eigene Prozesse (z.B. Python, Bash, Perl, Java ...) mit dem BFFH Server zu verbinden.
cmd
::String (notwendig) - Pfad der ausführbaren Dateiargs
::String (optional) - Argumente der ausführbaren Datei. Hier übergebene Argumente werden durch Leerzeichen getrennt, so dass in unserem Beispiel 5 separate Argumente übergeben werden.
Beispiel für Process Actor:
actors = {
Bash_123 = {
module = "Process",
params = {
cmd = "./examples/actor.sh",
args = "your ad could be here"
}
}
}
Im Beispiel heißt unser Actor-ID
Bash_123
.
Wichtige Info: BFFH baut aus den Argumenten cmd
und args
einen vollständigen Befehl, der ausgeführt wird und fügt automatisch zwei weitere Argumente am Ende hinzu - nämlich den zu erzielenden Status state
(z.B. INUSE
oder GIVEBACK
) und den Benutzername userid
. Der vollständige Befehl, der als Prozess ausgeführt wird, lautet folglich $ ${cmd} ${args} ${state} ${userid}
.
actor_connections
::List
Verknüpfung (Mapping) von Ressourcen mit Aktoren. Einer Ressource können mehrere Aktoren zugewiesen werden, aber ein Aktor kann nur einer Ressource zugewiesen werden.
Das Mapping actor_connections
wird als Liste von Einträgen gespeichert. Die Parameter:
machine
::String (notwendig) - dieResource-ID
actor
::String (notwendig) - dieActor-ID
Achtung:
Die Reihenfolge ist wichtig. An erster Stelle kommt machine
, dann actor
!
Außerdem darf die Definition actor_connections
::List in bffh.dhall
erst nach actors
::Record und nach machines
::Record kommen!
Beispiel für leere actor_connections:
actor_connections = [] : List { machine : Text, initiator : Text },
Beispiel für init_connections mit drei Mappings:
actor_connections = [
{ machine = "Testmachine", actor = "Shelly_123" },
{ machine = "Another", actor = "Bash_123" },
{ machine = "Yetmore", actor = "Bash_234" } ]
Konfiguration von Initiatoren (initiators)
Initiatoren werden fast genauso konfiguriert wie Aktoren. Es gibt aktuell die beiden Initiatorentypen Dummy Initiator und Process Initiator. Konkret nutzbare Initiatoren-Beispiele finden sich hier.
initiators
::Record
Enthält eine Liste von Initiatoren. Initiatoren werden durch ein Modul und einen oder mehrere Parameter definiert. Die Liste kann bzw. muss leer sein, wenn keine Initiatoren verwendet werden:
Beispiel für leere initiators:
initiators = {=}
Sonst kann die Liste einen oder mehrere Initiatoren mit ihrem Name (Initiator-ID
) enthalten:
Dummy Initiator
Für Testzwecke kann ein interner Dummy-Initiator genutzt werden:
Der „Dummy“-Initiator versucht alle paar Sekunden, einen Rechner als den angegebenen Benutzer zu verwenden und zurückzugeben. Er ist gut geeignet, um das System zu testen, führt aber zu Spam im Log und ist daher standardmäßig deaktiviert.
Die Initiator-Parameter:
uid
::String (notwendig) - Nutzername
Beispiel für Dummy Initiator:
initiators = {
Initiator_123 = {
module = "Dummy",
params = {
uid = "Testuser"
}
}
}
Process Initiator
Dieser Initiator vom module
::String Typ Process ermöglicht es, eigene Prozesse (z.B. Python, Bash, Perl, Java ...) mit dem BFFH Server zu verbinden.
Das Mapping initiator_connections
wird als Liste von Einträgen gespeichert. Die Parameter:
cmd
::String (notwendig) - Pfad der ausführbaren Dateiargs
::String (optional) - Argumente der ausführbaren Datei. Hier übergebene Argumente werden durch Leerzeichen getrennt, so dass in unserem Beispiel 5 separate Argumente übergeben werden.
Beispiel für Process Initiator:
initiators = {
Bash_567 = {
module = "Process",
params = {
cmd = "./examples/init.py",
args = "your ad could be here"
}
}
}
Im Beispiel heißt unser Initiator-ID
Bash_567
.
Wichtige Info: BFFH baut aus den Argumenten cmd
und args
einen vollständigen Befehl, der ausgeführt wird und fügt automatisch zwei weitere Argumente am Ende hinzu - nämlich den zu erzielenden Status state
(z.B. INUSE
oder GIVEBACK
) und den Benutzername userid
. Der vollständige Befehl, der als Prozess ausgeführt wird, lautet folglich $ ${cmd} ${args} ${state} ${userid}
.
init_connections
::List
Verknüpfung (Mapping) von Ressourcen mit Initiatoren. Einer Ressource können mehrere Initiatoren zugewiesen werden, aber ein Initiator kann nur einer Ressource zugewiesen werden.
Das Mapping init_connections
wird als Liste von Einträgen gespeichert. Die Parameter:
initiator
::String (notwendig) - dieInitiator-ID
actor
::String (notwendig) - dieActor-ID
Achtung: Die Reihenfolge ist wichtig. An erster Stelle kommt machine
, dann initiator
!
Außerdem darf die Definition init_connections
::List in bffh.dhall
erst nach initiators
::Record und nach machines
::Record kommen!
Beispiel für leere init_connections:
init_connections = [] : List { machine : Text, initiator : Text }
Beispiel für init_connections mit einzelnen Mapping:
init_connections = [
{ machine = "Testmachine", initiator = "Initiator_123" }
]
FabFire und Föderation
spacename
::String
Der Name des Spaces (die offene Werkstatt, das FabLab, der HackerSpace, etc.) wird im URN-Schema urn:fabaccess:lab:{spacename}
verwendet. Wird er nicht definiert, wird der Wert "generic" vergeben. Diese Angaben benötigen wir für QR-Codes von Ressourcen oder für DESFire Karten zur Nutzung von FabFire.
Beispiel für spacename:
spacename = "FabAccess DemoSpace"
instanceurl
::String
Wird für eine allgemeine Space Info genutzt und als URN im Code genutzt: urn:fabaccess:lab:{spacename}\x00{instanceurl}
. Dieser Wert wird aktuell nicht verwendet, muss jedoch ausgefüllt werden, damit die Konfiguration bffh.dhall
valide ist! Es wird empfohlen die URL mit dem Protokoll vollständig anzugeben, also mit http://
oder https://
.
Beispiel für instanceurl:
instanceurl = "https://demo.fab-access.org"
Hinweise zu unkonfigurierbaren Variablen
Folgende Variablen werden intern von BFFH gesetzt und können aktuell nicht über die bffh.dhall verändert werden. Wir führen sie nur zur Vollständigkeit auf:
verbosity
filter
format
Hinweise zur Vergabe von IDs
Wir verwenden in der Konfiguration IDs wie Resource-ID
, Actor-ID
, Initiator-ID
oder Role-ID
.
Diese IDs müssen folgendes Namensschema einhalten:
- ASCII Format
- Alphanumerisch
- muss mit einem Buchstaben beginnen
Für die Vergabe von IDs ist die Groß- und Kleinschreibung zu beachten! Wir empfehlen generell die Kleinschreibung. So ist zum Beispiel eine Rolle namens RoleAdmin
ungleich roleadmin
.
Wir empfehlens außerdem ein konsisentes, leicht nachvollziehbares (logisches) Namenskonzept über alle ID-Typen, wo immer es möglich ist.
IDs müssen eindeutig bzw. einzigartig sein. IDs dürfen also nicht doppelt vergeben werden!
Minimal funktionierende Standardkonfiguration
Wie bereits eingangs erwähnt, werden alle obigen Einstellungen für die Konfiguration benötigt. Für die absolut minimale Startfähigkeit eines BFFH Servers kann folgendes Konfigurationssample verwendet werden.
Vorraussetzungen für die Lauffähigkeit von BFFH:
- Dienst muss sich auf Interface:Port binden lassen
- MQTT-Server muss laufen und erreichbar sein (siehe mqtt_url::String).
- Zertifikat und Keyfile müssen existieren
- Datenbankdatei und Auditlog müssen schreibbar sein
{
spacename = "fabaccess.sample.space",
instanceurl = "https://fabaccess.sample.space",
listens = [{address = "127.0.0.1"}],
certfile = "/etc/bffh/certs/bffh.crt",
keyfile = "/etc/bffh/certs/bffh.key",
mqtt_url = "mqtt://127.0.0.1:1883",
db_path = "/var/lib/bffh/bffh.db",
auditlog_path = "/var/log/bffh/audit.json",
roles = {=},
machines = {=},
actors = {=},
actor_connections = [] : List { machine : Text, initiator : Text },
initiators = {=},
init_connections = [] : List { machine : Text, initiator : Text }
}
Ein ebenso funktionales und umfangreicheres Standardsample kann auch per bffhd --print-default
ausgegeben werden (siehe Cheat Sheet).
Konfiguration per Config Generator
Ein Großteil der Konfiguration (Ressourcen, Berechtigungen, Aktoren, Aktorenverbindungen, etc.) kann mit einem generischen Arbeitswerkzeug effizient und übersichtlich erzeugt und verwaltet werden. Siehe Einfache Konfiguration mit dem FabAccess Config Generator.
Konfiguration von BFFH auf Synax und Inhalt prüfen
Konfiguration erstellt, aber unsicher, ob sie vollständig und syntaktisch korrekt ist?
Wir können das per /usr/bin/bffhd --check --config /etc/bffh/bffh.dhall
überprüfen. Siehe hier. Das Kommando kann mit dem --check
Parameter unabhängig und vor dem Neustart von BFFH ausgeführt werden und verhindert so die Unverfügbarkeit des Service bei Fehlkonfiguration (alternativ kann auch ein Staging-System für derartige Tests angelegt werden). Etwaige Fehlkonfigurationen werden auch erkannt, da geprüft wird, ob wichtige Konfigurationschlüssel fehlen, unvollständig oder falsch sind.
Siehe auch Dhall-Dateien parsen, prüfen und formatieren für die reine Überprüfung des Syntax und das automatische Umformatieren (Prettyprint).
Ein letzter Blick in die von BFFH geladene Config kann auch über unsere systemd Journaleinträge gemacht werden, falls wir BFFH als Service installiert haben, oder aber über über die Log-Umgebungsvariable BFFH_LOG
. Wir sehen damit, wie BFFH die Dhall nach dem Parsen vollständig auflöst und dass Log-Variablen beispielsweise auch gesetzt werden, welche jedoch nicht über bffh.dhall
konfigurierbar sind, sondern über Umgebungsvariablen.
sudo systemctl restart bffh.service; sudo journalctl -n2000 -e -u bffh.service
Jan 02 22:31:07 fabaccess systemd[1]: Starting bffh.service - FabAccess BFFH Service...
Jan 02 22:31:07 fabaccess bffhd[34844]: Config {
Jan 02 22:31:07 fabaccess bffhd[34844]: listens: [
Jan 02 22:31:07 fabaccess bffhd[34844]: Listen {
Jan 02 22:31:07 fabaccess bffhd[34844]: address: "0.0.0.0",
Jan 02 22:31:07 fabaccess bffhd[34844]: port: Some(
Jan 02 22:31:07 fabaccess bffhd[34844]: 59661,
Jan 02 22:31:07 fabaccess bffhd[34844]: ),
Jan 02 22:31:07 fabaccess bffhd[34844]: },
Jan 02 22:31:07 fabaccess bffhd[34844]: ],
Jan 02 22:31:07 fabaccess bffhd[34844]: machines: {},
Jan 02 22:31:07 fabaccess bffhd[34844]: actors: {},
Jan 02 22:31:07 fabaccess bffhd[34844]: initiators: {},
Jan 02 22:31:07 fabaccess bffhd[34844]: mqtt_url: "mqtt://fabinfra101:fablocal@0.0.0.0:1883",
Jan 02 22:31:07 fabaccess bffhd[34844]: actor_connections: [],
Jan 02 22:31:07 fabaccess bffhd[34844]: init_connections: [],
Jan 02 22:31:07 fabaccess bffhd[34844]: db_path: "/var/lib/bffh/bffh.db",
Jan 02 22:31:07 fabaccess bffhd[34844]: auditlog_path: "/var/log/bffh/audit.json",
Jan 02 22:31:07 fabaccess bffhd[34844]: roles: {},
Jan 02 22:31:07 fabaccess bffhd[34844]: tlsconfig: TlsListen {
Jan 02 22:31:07 fabaccess bffhd[34844]: certfile: "/etc/bffh/certs/bffh.crt",
Jan 02 22:31:07 fabaccess bffhd[34844]: keyfile: "/etc/bffh/certs/bffh.key",
Jan 02 22:31:07 fabaccess bffhd[34844]: ciphers: None,
Jan 02 22:31:07 fabaccess bffhd[34844]: tls_min_version: None,
Jan 02 22:31:07 fabaccess bffhd[34844]: protocols: [],
Jan 02 22:31:07 fabaccess bffhd[34844]: },
Jan 02 22:31:07 fabaccess bffhd[34844]: tlskeylog: None,
Jan 02 22:31:07 fabaccess bffhd[34844]: verbosity: 0,
Jan 02 22:31:07 fabaccess bffhd[34844]: logging: LogConfig {
Jan 02 22:31:07 fabaccess bffhd[34844]: filter: None,
Jan 02 22:31:07 fabaccess bffhd[34844]: format: "full",
Jan 02 22:31:07 fabaccess bffhd[34844]: },
Jan 02 22:31:07 fabaccess bffhd[34844]: spacename: "FabAccess Demo Setup",
Jan 02 22:31:07 fabaccess bffhd[34844]: instanceurl: "https://docs.fab-access.org",
Jan 02 22:31:07 fabaccess bffhd[34844]: }
Jan 02 22:31:07 fabaccess systemd[1]: Started bffh.service - FabAccess BFFH Service.
Einfache Konfiguration mit dem FabAccess Config Generator
Wolfram vom MakerSpace Leipzig hat 2024 ein umfangreiches Tool - den FabAccess Config Generator - entwickelt, um eine Konfiguration (bffh.dhall
) anhand einer Maschinenliste im CSV-Format zu erzeugen.
Funktionsumfang
- Generierung von Ressourcen (Maschinen)
- Generierung von Rollen
- Generierung von Aktoren
- Generierung von einfachen Aktoren-Verbindungen
- Export einer gesonderten Rollenliste (interne ID & Anzeigename der Rolle)
- Abbildung der Struktur mittels Mermaid-Diagramm
- Direkte Aktualisierung einer bestehenden
bffh.dhall
- Modulare dhall-Erzeugung (
rolls.dhall
,actors.dhall
,actorconnections.dhall
undmachines.dhall
) lassen sich in derbffh.dhall
referenzieren und verbessern die Übersicht.
Funktionsweise
Die CSV-Datei enthält pro Zeile einen Eintrag für eine Maschine. Neben Angaben zur Maschine selbst (ID, Wiki-URL etc.) werden Angaben zum Bereich vermerkt, in dem sich die Maschine befindet. Aus den Angaben zu den Bereichen werden dann alle Rollen abgeleitet.
Vollständige Dokumentation
Hier ist nur eine kurze Erklärung über das HowTo abgebildet. Eine umfangreiche und aktuelle Dokumentation findest du hier: https://elem74.github.io/fabaccess-config-generator-docs
Installation
Das Tool kann direkt auf dem Server oder auf einem beliebigen Client installiert werden. Das ist Geschmackssache.
mkdir -p /opt/fabinfra/tools/
cd /opt/fabinfra/tools/
git clone https://github.com/elem74/fabaccess-config-generator.git
cd fabaccess-config-generator/
Anpassungen
Alle Erklärungen zum Konzept und zu verschiedenen Einstellmöglichkeiten finden sich im Repository unter https://github.com/elem74/fabaccess-config-generator/tree/main?tab=readme-ov-file#nutzung-des-python-skripts
Config Generator verwenden
Konfigurationsdatei maschinenliste.csv mit dem favorisierten Editor bearbeiten:
vim maschinenliste.csv
http://docs.fab-access.org/data-fabaccess-config-generator/maschinenliste.csv
Danach kann der Generator ausgeführt werden:
python3 config-generator.py
Das Tool schreibt automatisch ins Unterverzeichnis output/
die folgenden Dateien:
bffh-dhall-data.txt
Die Beispiel Dhall Daten sehen dabei wie folgt aus:
bffh-dhall-data.txt
roles = {
Admin = {
permissions = [
"bffh.users.manage",
"bffh.users.info",
"bffh.users.admin",
"beispielw.*",
]
},
_manager_schichtleitung = {
permissions = [
"beispielw.*",
]
},
beispielw_holz_manager = {
permissions = [
"beispielw.holz.*",
]
},
beispielw_holz_bandsaege_user = {
permissions = [
"beispielw.holz.bandsaege.disclose.*",
"beispielw.holz.bandsaege.read.*",
"beispielw.holz.bandsaege.write.*",
]
},
beispielw_holz_hobelmaschine_user = {
permissions = [
"beispielw.holz.hobelmaschine.disclose.*",
"beispielw.holz.hobelmaschine.read.*",
"beispielw.holz.hobelmaschine.write.*",
]
},
beispielw_holz_holzcnc_user = {
permissions = [
"beispielw.holz.holzcnc.disclose.*",
"beispielw.holz.holzcnc.read.*",
"beispielw.holz.holzcnc.write.*",
]
},
beispielw_holz_user = {
permissions = [
"beispielw.holz.disclose.*",
"beispielw.holz.read.*",
"beispielw.holz.write.*",
]
},
beispielw_textil_manager = {
permissions = [
"beispielw.textil.*",
]
},
beispielw_textil_user = {
permissions = [
"beispielw.textil.disclose.*",
"beispielw.textil.read.*",
"beispielw.textil.write.*",
]
},
beispielw_fablab_manager = {
permissions = [
"beispielw.fablab.*",
]
},
beispielw_fablab_3dprint_manager = {
permissions = [
"beispielw.fablab.3dprint.*",
]
},
beispielw_fablab_3dprint_user = {
permissions = [
"beispielw.fablab.3dprint.disclose.*",
"beispielw.fablab.3dprint.read.*",
"beispielw.fablab.3dprint.write.*",
]
},
beispielw_fablab_laser_manager = {
permissions = [
"beispielw.fablab.laser.*",
]
},
beispielw_fablab_laser_user = {
permissions = [
"beispielw.fablab.laser.disclose.*",
"beispielw.fablab.laser.read.*",
"beispielw.fablab.laser.write.*",
]
},
beispielw_siebdruck_manager = {
permissions = [
"beispielw.siebdruck.*",
]
},
beispielw_siebdruck_user = {
permissions = [
"beispielw.siebdruck.disclose.*",
"beispielw.siebdruck.read.*",
"beispielw.siebdruck.write.*",
]
},
beispielw_drucker = {
permissions = [
"beispielw.siebdruck.disclose.a3drucker",
"beispielw.siebdruck.read.a3drucker",
"beispielw.siebdruck.write.a3drucker",
"beispielw.buero.disclose.drucker",
"beispielw.buero.read.drucker",
"beispielw.buero.write.drucker",
]
},
beispielw_buero_manager = {
permissions = [
"beispielw.buero.*",
]
},
},
machines = {
beispielw-holz-bandsaege-bandsaege = {
name = "Bandsäge",
description = "Bandsäge im Holzbereich",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.bandsaege.disclose.bandsaege",
read = "beispielw.holz.bandsaege.read.bandsaege",
write = "beispielw.holz.bandsaege.write.bandsaege",
manage = "beispielw.holz.bandsaege.manage.bandsaege",
},
beispielw-holz-hobelmaschine-hobelmaschine = {
name = "Hobelmaschine",
description = "Hobelmaschine im Holzbereich",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.hobelmaschine.disclose.hobelmaschine",
read = "beispielw.holz.hobelmaschine.read.hobelmaschine",
write = "beispielw.holz.hobelmaschine.write.hobelmaschine",
manage = "beispielw.holz.hobelmaschine.manage.hobelmaschine",
},
beispielw-holz-holzcnc-holzcncfraese = {
name = "CNC-Fräse",
description = "CNC Fräse im Holzbereich",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.holzcnc.disclose.holzcncfraese",
read = "beispielw.holz.holzcnc.read.holzcncfraese",
write = "beispielw.holz.holzcnc.write.holzcncfraese",
manage = "beispielw.holz.holzcnc.manage.holzcncfraese",
},
beispielw-holz-kappsaege = {
name = "Kappsäge",
description = "Kappsäge mit allgemeiner Einweisung Holz",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.disclose.kappsaege",
read = "beispielw.holz.read.kappsaege",
write = "beispielw.holz.write.kappsaege",
manage = "beispielw.holz.manage.kappsaege",
},
beispielw-holz-bandschleifer = {
name = "Bandschleifer",
description = "Bandschleifer mit allgemeiner Einweisung Holz",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.disclose.bandschleifer",
read = "beispielw.holz.read.bandschleifer",
write = "beispielw.holz.write.bandschleifer",
manage = "beispielw.holz.manage.bandschleifer",
},
beispielw-holz-staenderbohrmaschine = {
name = "Ständerbohrmaschine",
description = "Ständerbohrmaschine mit allgemeiner Einweisung Holz",
wiki = "",
category = "Holzwerkstatt",
disclose = "beispielw.holz.disclose.staenderbohrmaschine",
read = "beispielw.holz.read.staenderbohrmaschine",
write = "beispielw.holz.write.staenderbohrmaschine",
manage = "beispielw.holz.manage.staenderbohrmaschine",
},
beispielw-textil-naehmaschine1 = {
name = "Nähmaschine 1",
description = "Nähmaschine Nummer 1",
wiki = "",
category = "Textilwerkstatt",
disclose = "beispielw.textil.disclose.naehmaschine1",
read = "beispielw.textil.read.naehmaschine1",
write = "beispielw.textil.write.naehmaschine1",
manage = "beispielw.textil.manage.naehmaschine1",
},
beispielw-textil-naehmaschine2 = {
name = "Nähmaschine 2",
description = "Nähmaschine Nummer 2",
wiki = "",
category = "Textilwerkstatt",
disclose = "beispielw.textil.disclose.naehmaschine2",
read = "beispielw.textil.read.naehmaschine2",
write = "beispielw.textil.write.naehmaschine2",
manage = "beispielw.textil.manage.naehmaschine2",
},
beispielw-fablab-3dprint-3ddrucker1 = {
name = "3D-Drucker 1",
description = "3D-Drucker Modell 111",
wiki = "",
category = "FabLab",
disclose = "beispielw.fablab.3dprint.disclose.3ddrucker1",
read = "beispielw.fablab.3dprint.read.3ddrucker1",
write = "beispielw.fablab.3dprint.write.3ddrucker1",
manage = "beispielw.fablab.3dprint.manage.3ddrucker1",
},
beispielw-fablab-3dprint-3ddrucker2 = {
name = "3D-Drucker 2",
description = "3D-Drucker Modell 222",
wiki = "",
category = "FabLab",
disclose = "beispielw.fablab.3dprint.disclose.3ddrucker2",
read = "beispielw.fablab.3dprint.read.3ddrucker2",
write = "beispielw.fablab.3dprint.write.3ddrucker2",
manage = "beispielw.fablab.3dprint.manage.3ddrucker2",
},
beispielw-fablab-laser-laser3000 = {
name = "Lasercutter",
description = "Modell Laser3000",
wiki = "https://www.fiktivedoku.de",
category = "FabLab",
disclose = "beispielw.fablab.laser.disclose.laser3000",
read = "beispielw.fablab.laser.read.laser3000",
write = "beispielw.fablab.laser.write.laser3000",
manage = "beispielw.fablab.laser.manage.laser3000",
},
beispielw-fablab-laser-kuehlung3000 = {
name = "Kühlung",
description = "Modell Kühlung3000",
wiki = "",
category = "FabLab",
disclose = "beispielw.fablab.laser.disclose.kuehlung3000",
read = "beispielw.fablab.laser.read.kuehlung3000",
write = "beispielw.fablab.laser.write.kuehlung3000",
manage = "beispielw.fablab.laser.manage.kuehlung3000",
},
beispielw-siebdruck-sdbelichter = {
name = "SD-Belichter",
description = "Belichter für die Siebe",
wiki = "",
category = "Siebdruck",
disclose = "beispielw.siebdruck.disclose.sdbelichter",
read = "beispielw.siebdruck.read.sdbelichter",
write = "beispielw.siebdruck.write.sdbelichter",
manage = "beispielw.siebdruck.manage.sdbelichter",
},
beispielw-siebdruck-a3drucker = {
name = "A3-Drucker",
description = "A3 Drucker im Siebdruck Bereich",
wiki = "",
category = "Siebdruck",
disclose = "beispielw.siebdruck.disclose.a3drucker",
read = "beispielw.siebdruck.read.a3drucker",
write = "beispielw.siebdruck.write.a3drucker",
manage = "beispielw.siebdruck.manage.a3drucker",
},
beispielw-buero-drucker = {
name = "Drucker",
description = "",
wiki = "",
category = "Büro",
disclose = "beispielw.buero.disclose.drucker",
read = "beispielw.buero.read.drucker",
write = "beispielw.buero.write.drucker",
manage = "beispielw.buero.manage.drucker",
},
},
actors = {
tasmota_1 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 1",
}
},
tasmota_2 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 2",
}
},
tasmota_6 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 6",
}
},
tasmota_7 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 7",
}
},
tasmota_8 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 8",
}
},
tasmota_9 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 9",
}
},
tasmota_10 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 10",
}
},
tasmota_11 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 11",
}
},
tasmota_12 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 12",
}
},
tasmota_13 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 13",
}
},
tasmota_14 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 14",
}
},
tasmota_15 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 15",
}
},
tasmota_16 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 16",
}
},
tasmota_17 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 17",
}
},
tasmota_18 =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota 18",
}
},
},
actor_connections = [
{ machine = "beispielw-holz-bandsaege-bandsaege", actor = "tasmota_1" },
{ machine = "beispielw-holz-hobelmaschine-hobelmaschine", actor = "tasmota_2" },
{ machine = "beispielw-holz-holzcnc-holzcncfraese", actor = "tasmota_6" },
{ machine = "beispielw-holz-kappsaege", actor = "tasmota_7" },
{ machine = "beispielw-holz-bandschleifer", actor = "tasmota_8" },
{ machine = "beispielw-holz-staenderbohrmaschine", actor = "tasmota_9" },
{ machine = "beispielw-textil-naehmaschine1", actor = "tasmota_10" },
{ machine = "beispielw-textil-naehmaschine2", actor = "tasmota_11" },
{ machine = "beispielw-fablab-3dprint-3ddrucker1", actor = "tasmota_12" },
{ machine = "beispielw-fablab-3dprint-3ddrucker2", actor = "tasmota_13" },
{ machine = "beispielw-fablab-laser-laser3000", actor = "tasmota_14" },
{ machine = "beispielw-fablab-laser-kuehlung3000", actor = "tasmota_15" },
{ machine = "beispielw-siebdruck-sdbelichter", actor = "tasmota_16" },
{ machine = "beispielw-siebdruck-a3drucker", actor = "tasmota_17" },
{ machine = "beispielw-buero-drucker", actor = "tasmota_18" },
],
mermaid-code.txt
Der Beispiel Mermaid Code sieht wie folgt aus und kann in https://mermaid.live gerendet werden.
mermaid-code.txt
%%{init: {"flowchart" : {"curve" : "linear"}}}%%
flowchart TD
subgraph legende["<b>Legende</b><p style="text-align:left;">👑 = Administrator
🛠️ = Manager
👷♂️ = Benutzer
👩🚀 = Benutzer (Alternativrolle)"]
end
subgraph root["
<p style="font-size: 2em">Infrastruktur</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>👑_Admin FabAccess<br>🛠️_Manager Schichtleitung</p></p>
<p style="text-align: left; margin-top: 0px;"></p>
<p style="opacity: 0;">.</p>
"]
end
subgraph root_beispielw["
<p style="font-size: 1.75em">Beispielwerkstatt </p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Beispielwerkstatt </p></p>
<p style="text-align: left; margin-top: 0px;"></p>
<p style="opacity: 0;">.</p>
"]
end
root ------ root_beispielw
root_beispielw ---- root_beispielw_buero_wrapper
subgraph root_beispielw_buero_wrapper["<p style="opacity: 0;">.</p>"]
style root_beispielw_buero_wrapper stroke: none, fill: none
subgraph root_beispielw_buero["
<p style="font-size: 1.5em">Büro</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Büro<br>👷♂️Benutzer Büro<br>👩🚀Benutzer Druckernutzung</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Drucker (👩🚀Benutzer Druckernutzung)</p>
<p style="opacity: 0;">.</p>
"]
end
subgraph filler_root_beispielw_buero_1["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_buero_1 fill: none, stroke: none
root_beispielw_buero~~~~~~filler_root_beispielw_buero_1
subgraph filler_root_beispielw_buero_2["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_buero_2 fill: none, stroke: none
filler_root_beispielw_buero_1~~~~~filler_root_beispielw_buero_2
end
root_beispielw ---- root_beispielw_fablab_wrapper
subgraph root_beispielw_fablab_wrapper["<p style="opacity: 0;">.</p>"]
style root_beispielw_fablab_wrapper stroke: none, fill: none
subgraph root_beispielw_fablab["
<p style="font-size: 1.5em">FabLab</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager FabLab<br>👷♂️Benutzer FabLab</p></p>
<p style="text-align: left; margin-top: 0px;"></p>
<p style="opacity: 0;">.</p>
"]
end
subgraph root_beispielw_fablab_3dprint["
<p style="font-size: 1.25em">3D-Druck</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager FabLab 3D-Druck<br>👷♂️Benutzer FabLab 3D-Druck</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>3D-Drucker 1<br>3D-Drucker 2</p>
<p style="opacity: 0;">.</p>
"]
end
root_beispielw_fablab ------ root_beispielw_fablab_3dprint
subgraph root_beispielw_fablab_laser["
<p style="font-size: 1.25em">Laser</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager FabLab Laser<br>👷♂️Benutzer FabLab Laser</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Lasercutter<br>Kühlung</p>
<p style="opacity: 0;">.</p>
"]
end
root_beispielw_fablab ------ root_beispielw_fablab_laser
end
root_beispielw ---- root_beispielw_holz_wrapper
subgraph root_beispielw_holz_wrapper["<p style="opacity: 0;">.</p>"]
style root_beispielw_holz_wrapper stroke: none, fill: none
subgraph root_beispielw_holz["
<p style="font-size: 1.5em">Holzwerkstatt</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Holzwerkstatt<br>👷♂️Benutzer Holzwerkstatt</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Kappsäge<br>Bandschleifer<br>Ständerbohrmaschine</p>
<p style="opacity: 0;">.</p>
"]
end
subgraph root_beispielw_holz_bandsaege["
<p style="font-size: 1.25em">Bandsäge</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Holzwerkstatt Bandsäge<br>👷♂️Benutzer Holzwerkstatt Bandsäge</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Bandsäge</p>
<p style="opacity: 0;">.</p>
"]
end
root_beispielw_holz ------ root_beispielw_holz_bandsaege
subgraph root_beispielw_holz_hobelmaschine["
<p style="font-size: 1.25em">Hobelmaschine</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Holzwerkstatt Hobelmaschine<br>👷♂️Benutzer Holzwerkstatt Hobelmaschine</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Hobelmaschine</p>
<p style="opacity: 0;">.</p>
"]
end
root_beispielw_holz ------ root_beispielw_holz_hobelmaschine
subgraph root_beispielw_holz_holzcnc["
<p style="font-size: 1.25em">CNC-Fräse</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Holzwerkstatt CNC-Fräse<br>👷♂️Benutzer Holzwerkstatt CNC-Fräse</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>CNC-Fräse</p>
<p style="opacity: 0;">.</p>
"]
end
root_beispielw_holz ------ root_beispielw_holz_holzcnc
end
root_beispielw ---- root_beispielw_siebdruck_wrapper
subgraph root_beispielw_siebdruck_wrapper["<p style="opacity: 0;">.</p>"]
style root_beispielw_siebdruck_wrapper stroke: none, fill: none
subgraph root_beispielw_siebdruck["
<p style="font-size: 1.5em">Siebdruck</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Siebdruck<br>👷♂️Benutzer Siebdruck<br>👩🚀Benutzer Druckernutzung</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>SD-Belichter<br>A3-Drucker (👩🚀Benutzer Druckernutzung)</p>
<p style="opacity: 0;">.</p>
"]
end
subgraph filler_root_beispielw_siebdruck_1["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_siebdruck_1 fill: none, stroke: none
root_beispielw_siebdruck~~~~~~filler_root_beispielw_siebdruck_1
subgraph filler_root_beispielw_siebdruck_2["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_siebdruck_2 fill: none, stroke: none
filler_root_beispielw_siebdruck_1~~~~~filler_root_beispielw_siebdruck_2
end
root_beispielw ---- root_beispielw_textil_wrapper
subgraph root_beispielw_textil_wrapper["<p style="opacity: 0;">.</p>"]
style root_beispielw_textil_wrapper stroke: none, fill: none
subgraph root_beispielw_textil["
<p style="font-size: 1.5em">Textilwerkstatt</p><p style="text-align: left; margin-top: 20px;"><b><center>Rollen</center></b>🛠️Manager Textilwerkstatt<br>👷♂️Benutzer Textilwerkstatt</p></p>
<p style="text-align: left; margin-top: 0px;"><b><center>Maschinen</center></b>Nähmaschine 1<br>Nähmaschine 2</p>
<p style="opacity: 0;">.</p>
"]
end
subgraph filler_root_beispielw_textil_1["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_textil_1 fill: none, stroke: none
root_beispielw_textil~~~~~~filler_root_beispielw_textil_1
subgraph filler_root_beispielw_textil_2["
<p style="opacity: 0;">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</p>"]
end
style filler_root_beispielw_textil_2 fill: none, stroke: none
filler_root_beispielw_textil_1~~~~~filler_root_beispielw_textil_2
end
roles.csv
http://docs.fab-access.org/data-fabaccess-config-generator/roles.csv
Tipps
Wer die maschinenliste.csv per CLI bearbeiten oder ansehen möchte, hier ein paar Tipps:
- CSV-Dateien in der Kommandozeile editieren: https://www.visidata.org/install
- CSV-Dateien in der Kommandozeile übersichtlich formatieren:
column -t -s ';' -o '|' < maschinenliste.csv
In der Datei settings.ini kann fa_update_dhall = True
gesetzt werden, sowie ein Dateifpad fa_dhall_file
gesetzt werden. In unsere Konfigurationsdatei bffh.dhall
muss dann nur noch das folgende Snippet (siehe https://github.com/elem74/fabaccess-config-generator/blob/main/docs/bffh-vorlage.dhall) eingebunden werden:
---||| GENERATOR START
---||| GENERATOR END
Server Logs konfigurieren und Debugging
Der Log Level und die Formatierung von BFFH Logzeilen können über folgende Wege konfiguriert werden.
Log Level per Umgebungsvariable
Über die Umgebungsvariable BFFH_LOG=debug
- zum Beispiel eingebunden per systemd Service
Unterstützte Level für BFFH_LOG
sind:
- info
- warn
- error
- debug
- trace
Log Parameter in bffhd
Über bffhd
Parameter kann das Kommando beliebig angepasst werden (und ebenso im systemd Service verwendet werden):
--log-format
Gültige Werte sind:
Full
(Standard)Compact
Pretty
Die Groß- bzw. Kleinschreibung spielt hierbei keine Rolle!
Full
2024-12-07T11:10:48.198579Z DEBUG bffh:tls: difluoroborane::tls: TLS secret logging is disabled. keylog=false
2024-12-07T11:10:48.198685Z DEBUG bffh:tls: difluoroborane::tls: reading certificates path=/etc/ssl/fablabchemnitz.de.cert.pem
2024-12-07T11:10:48.198959Z DEBUG bffh:tls: difluoroborane::tls: reading private key path=/etc/ssl/fablabchemnitz.de.privkey.pem
2024-12-07T11:10:48.199608Z DEBUG difluoroborane::actors::process: Process actor updating state name=actor-process-test cmd=/opt/fabinfra/actor-process-test.sh state=SendState(ArchivedState { inner: ArchivedMachineState { state: Free, previous: Some(ArchivedUserRef { id: "local_lab_admin" }) } })
2024-12-07T11:10:48.200451Z DEBUG difluoroborane::actors::process: Process actor updating state name=Tasmota_Mjolnir cmd=/opt/fabinfra/adapters/tasmota/main.py state=SendState(ArchivedState { inner: ArchivedMachineState { state: InUse(ArchivedUserRef { id: "local_lab_admin" }), previous: Some(ArchivedUserRef { id: "local_lab_admin" }) } })
2024-12-07T11:10:48.203817Z INFO bffh:binding API listen sockets: difluoroborane::capnp: Opened listen socket on 127.0.0.1:5961
2024-12-07T11:10:48.204079Z INFO bffh:binding API listen sockets: difluoroborane::capnp: Opened listen socket on 192.168.1.192:5961
Compact
Das kompakte Layout ist identisch zu Full
2024-12-07T11:10:48.198579Z DEBUG bffh:tls: difluoroborane::tls: TLS secret logging is disabled. keylog=false
2024-12-07T11:10:48.198685Z DEBUG bffh:tls: difluoroborane::tls: reading certificates path=/etc/ssl/fablabchemnitz.de.cert.pem
2024-12-07T11:10:48.198959Z DEBUG bffh:tls: difluoroborane::tls: reading private key path=/etc/ssl/fablabchemnitz.de.privkey.pem
2024-12-07T11:10:48.199608Z DEBUG difluoroborane::actors::process: Process actor updating state name=actor-process-test cmd=/opt/fabinfra/actor-process-test.sh state=SendState(ArchivedState { inner: ArchivedMachineState { state: Free, previous: Some(ArchivedUserRef { id: "local_lab_admin" }) } })
2024-12-07T11:10:48.200451Z DEBUG difluoroborane::actors::process: Process actor updating state name=Tasmota_Mjolnir cmd=/opt/fabinfra/adapters/tasmota/main.py state=SendState(ArchivedState { inner: ArchivedMachineState { state: InUse(ArchivedUserRef { id: "local_lab_admin" }), previous: Some(ArchivedUserRef { id: "local_lab_admin" }) } })
2024-12-07T11:10:48.203817Z INFO bffh:binding API listen sockets: difluoroborane::capnp: Opened listen socket on 127.0.0.1:5961
2024-12-07T11:10:48.204079Z INFO bffh:binding API listen sockets: difluoroborane::capnp: Opened listen socket on 192.168.1.192:5961
Pretty
2024-12-07T11:09:18.093419Z DEBUG difluoroborane::tls: reading certificates, path: /etc/ssl/fablabchemnitz.de.cert.pem
at bffhd/tls.rs:113
in difluoroborane::tls::tls
in bffh::bffh
2024-12-07T11:09:18.093835Z DEBUG difluoroborane::tls: reading private key, path: /etc/ssl/fablabchemnitz.de.privkey.pem
at bffhd/tls.rs:123
in difluoroborane::tls::tls
in bffh::bffh
2024-12-07T11:09:18.097839Z INFO difluoroborane::capnp: Opened listen socket on 127.0.0.1:5961
at bffhd/capnp/mod.rs:99
in difluoroborane::capnp::binding API listen sockets
in bffh::bffh
2024-12-07T11:09:18.098140Z INFO difluoroborane::capnp: Opened listen socket on 192.168.1.192:5961
at bffhd/capnp/mod.rs:99
in difluoroborane::capnp::binding API listen sockets
in bffh::bffh
--log-level
Die Level sind die gleichen wie BFFH_LOG
Siehe auch Cheat Sheet - Wichtigste Befehle (Übersicht)
Hinweis. Der --log-level
Parameter funktioniert auf einer normalen Kommandozeilenausgabe derzeit nicht. Details finden sich in https://gitlab.com/fabinfra/fabaccess/bffh/-/issues/83. Als Workaround empfehlen wir die Verwendung der Umgebungsvariable BFFH_LOG
.
--verbose
(-v
)
Dieser Parameter kann bis zu drei mal als Argument angegeben werden und erhöht die Log-Ausgabe zusätzlich. Beispiel:
/usr/bin/bffhd --config /etc/bffh/bffh.dhall --verbose --verbose --verbose
oder
/usr/bin/bffhd --config /etc/bffh/bffh.dhall -vvv
--tls-key-log
Dieser Parameter wird nur für Entwickler benötigt. Wenn für Debug Zwecke der Inhalt der verschlüsselten Verbindungen eingesehen werden soll, werden in der angegeben Datei <PATH>
die Schlüssel für jede Verbindung gespeichert und können z.B. von Wireshark geladen werden.
Log File schreiben
bffhd
nicht über systemd startet und deshalb auch keine Logs mit journalctl auslesen möchte, der kann den Output auch konventiell in eine Log-Datei schreiben - hier im Beispiel bffh.log
. Wir fangen dabei die Output-Streams stdout
und stderr
gemeinsam in einem Ausgabestrom ab (2>&1
). Den Parameter --log-level
verwenden wir nicht, da er bei der normalen Systemausgabe ignoriert wird (siehe Issue #83) und führen stattdessen mit BFFH_LOG
an:BFFH_LOG=debug /usr/bin/bffhd --config /etc/bffh/bffh.dhall --log-format Pretty > bffh.log 2>&1
Erweitertes Logging
Für Entwickler gibt es verschiedene Möglichkeiten aus der Laufzeit ein detaillierteres Fehlerbild zu erzeugen, über die Umgebungsvariable RUST_BACKTRACE
zum Beispiel:
RUST_BACKTRACE=1 /usr/bin/bffhd
... oder ...
RUST_BACKTRACE=full /usr/bin/bffhd
Audit Log
Der Audit Log ist das Log File, was bffhd
schreibt und in bffh.dhall
konfiguriert wird. Es gibt Aufschluss über "Wer hat wann welche Ressource genutzt oder zurückgegeben?". Details finden sich in Audit Log (Revisionsprotokoll). Es ist also kein Programmlog im eigentliche Sinne. Jedoch zeigt es auch die eventuell letzten Lebenszeichen des Servers an.
Debugging
Wer nicht nur Logs möchte, sondern debuggen will, der benötigt die Laufzeit inklusive Debug Symbolen. Im Falle der Installation mit *.deb oder *.rpm Paketen gibt es dafür gesonderte Pakete. Alternativ kann BFFH auch mit cargo
kompiliert werden. Letzteres erlaubt das Beeinflussen des Builds mit entsprechenden Parametern. Siehe BFFH testen / entwickeln.
Hilfreiche Debugging Tools
strace
- ein in Linux-Distros standardmäßig eingebautes Kommandogdb
- GNU Debuggervalgrind
- https://valgrind.org
Versionsinformationen anzeigen
Welche BFFH Version läuft, bzw. ist installiert? Un mit welchem Branch, Commit ID und Rustumgebung wurde bffhd
gebaut? Siehe hier: Version anzeigen
Bugs melden
Bugs können zum einen in den Community Kanälen besprochen werden und/oder auf GitLab gemeldet werden.
Server Hardening
Wie sichern wir unseren Server (Host) ab, auf dem BFFH läuft und verhindern Angriffe? Auf dieser Seite finden sich Ansätze für ein stabiles, sicheres Setup in einer Linux-Umgebung.
Offene Ports prüfen
netstat -an | grep LISTEN | grep -v LISTENING
Unattended Upgrades
Automatische Updates per apt
sudo apt update
sudo apt upgrade -y
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades
Fail2ban
sudo apt install fail2ban
sudo systemctl enable fail2ban.service
cd /etc/fail2ban/
sudo cp jail.conf jail.local
sudo vim /etc/fail2ban/jail.local
[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .
sudo vim /etc/fail2ban/jail.d/defaults-debian.conf
[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd
[sshd]
enabled = true
sudo systemctl restart fail2ban.service
Cheat Sheet - Wichtigste Befehle (Übersicht)
Auf dieser Seite finden sich wichtige Befehle im Zusammenhang mit der Benutzung von Difluoroborane.
bffh Daemon (bffhd) Befehlsübersicht (-h
, --help
)
/usr/bin/bffhd --help
difluoroborane 0.4.4
USAGE:
bffhd [OPTIONS]
OPTIONS:
-c, --config <config> Path to the DHALL config file to use
--check Check DHALL config for validity
--dump-db <FILE> Dump all internal databases (states and users) to the given
file as TOML
--dump-users <FILE> Dump the users db to the given file as TOML
--force Force owerwriting existing files
-h, --help Print help information
--load-db <FILE> Load values from TOML into the internal databases
--load-users <FILE> Load users from TOML into the internal databases
--log-format <log format> Use an alternative log formatter. Available: Full, Compact,
Pretty [possible values: Full, Compact, Pretty]
--log-level <log level> Set the desired log levels. [possible values: info, warn,
error, debug, trace]
--print-default Print a default DHALL config to stdout instead of running
--quiet Decrease logging verbosity
--tls-key-log [<PATH>...] Log TLS keys into PATH. If no path is specified the value of
the envvar SSLKEYLOGFILE is used.
-v, --verbose Increase logging verbosity. Stackable from -v up to -vvv
-V, --version Print version information
Logging-Konfiguration (--log-level
, --log-format
, --quiet
, -v
, --verbose
, --tls-key-log
)
Log-spezifische Parameter inklusive Audit Log sind zusammenfassend in Server Logs konfigurieren genauer erklärt.
Alle internen Datenbanken exportieren (--dump-db <bffh-db.toml file>
)
BFFH speichert zwei Datenbanken intern ab und trennt sie auf in Benutzer (users) und Zustände (states).
Die BFFH Datenbank muss bei jedem Versionsupgrade exportiert und sauber importiert werden.
Dazu muss --config <Pfad zu bffh.dhall>
angegeben werden, damit bffhd weiß, welche Datenbank angefragt werden soll.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --dump-db <bffh-db.toml file>
Soll eine bereits existierende Datei überschrieben werden, nutzen wir zusätzlich den optionalen Parameter --force
.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --dump-db <bffh-db.toml file> --force
Wird kein Dateiname hinter --dump-db
angegeben, wird die Datei automatisch bffh-db.toml
benannt
Datenbeispiel eines Dumps
Dump-Beispiel anzeigen
Ein Datenbank-Dump sieht wie folgt aus und enthält sowohl die Benutzer, als auch die States.
[users."Raum 1 Manager"]
roles = ["zam_raum1_manager"]
passwd = "$argon2i$v=19$m=4096,t=3,p=1$aE7DYpmOPy+ZAB305S26iQ$G+cx4wEQzaVsB4Vq05+mvvxBgqXlYnejbzpLcK24SPg"
[users.Werkstattleiter]
roles = ["_manager_schichtleitung"]
passwd = "$argon2i$v=19$m=4096,t=3,p=1$nqY/EsDGzlwLzRgtZQUBzA$a55mDPB20CxYixvafyYGRIZH/EsPBguzhTBm7O3D3QA"
[users.Admin]
roles = ["zam_raum1_ecke1_user", "zam_raum1_ecke2_user", "zam_raum1_ecke3_user", "zam_raum1_ecke4_user", "zam_raum1_ecke5_user", "zam_raum1_ecke6_user", "zam_raum1_ecke7_user", "zam_raum1_ecke8_user", "zam_raum1_ecke9_user", "_manager_schichtleitung", "Admin", "zam_raum1_manager"]
passwd = "$argon2i$v=19$m=4096,t=3,p=1$Ykyx7xGXwWKPMP7Q5FysBA$lbMnVRwZZheYt5u2kEZYuwkWW8DwaHF/JNgqH791WdQ"
[state.zam-raum1-ecke7-random3."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke2-arrow."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke5-random1."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke6-random2."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke9-shutdown."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke8-macgyver."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke10-restartbffh."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke10-restartbffh."1.3.6.1.4.1.48398.612.2.4".previous]
id = "Admin"
[state.zam-raum1-ecke3-fan."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke1-lamp."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
[state.zam-raum1-ecke4-mesh."1.3.6.1.4.1.48398.612.2.4"]
state = "Free"
Alle internen Datenbanken importieren (--load-db <bffh-db.toml file>
)
Dieses Kommando lädt die angegebene *.toml
Datei in die internen Datenbanken innerhalb bffh.db
hinein.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --load-db <db.toml file>
Benutzerdatenbank exportieren (--dump-users <users.toml file>
)
Einmal importiere Nutzerdaten können genauso wieder aus der bffh Datenbank exportiert werden. Dazu muss --config <Pfad zu bffh.dhall>
(oder in kurz -c
) angegeben werden, damit bffhd weiß, welche Datenbank (db_path
) angefragt werden soll. Außerdem muss auch der Ausgabepfad für --dump-users
angegeben werden.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --dump-users /etc/bffh/users.toml
Soll eine bereits existierende Datei überschrieben werden, nutzen wir zusätzlich den optionalen Parameter --force
.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --dump-users /etc/bffh/users.toml --force
Wird kein Dateiname hinter --dump-users
angegeben, wird die Datei automatisch users.toml
benannt
Benutzerdatenbank importieren (--load-users <users.toml file>
)
Dieses Kommando lädt die angegebene *.toml
Datei in die Benutzerdatenbank innerhalb bffh.db
hinein.
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --load-users <users.toml file>
Es kann auch ein Alias --load
verwendet werden, der das gleiche bewirkt:
/usr/bin/bffhd -c /etc/bffh/bffh.dhall --load <users.toml file>
Praxistipps zum smarten Umgang mit der users.toml
findest du unter Nutzerdatenbank laden / hashen / prüfen.
Das Laden einer users.toml
Datei tauscht alle Nutzer in der internen BFFH-Datenbank aus. Etwaige, nicht gesicherte Nutzer, die per App angelegt wurden, werden somit unwiederbringlich verworfen! Hier ist ein ggf. ein Diff zwischen der dann vorher zu sichernden users.toml
(kann per --dump-users
erzeugt werden) und der neuen users.toml
lohnenswert. Ein geeignetes Diff-Werkzeug ist beispielweise Meld.
Konfigurationsdatei prüfen (--check
)
Dieser Parameter prüft die angegebene Konfigurationsdatei auf fehlende oder fehlerhafte Angaben und überprüft generell, ob die *.dhall Datei geparsed werden kann. Sobald eine z.B. eine eckige oder geschweifte Klammer, ein Hochkomma oder normales Komma fehlt, gibt es in der Regel Probleme. Für das Prüfen muss ebenso --config <Pfad zu bffh.dhall>
angegeben werden.
Die Ausgabe ist granuliert (Fehler werden mit Zeile und Spalte angezeigt) und sieht zum Beispiel so aus:
failed to parse config: --> 2:2
|
2 | let mqtt_password =
| ^---
|
= expected any_label_or_some or empty_record_literal
Konfigurationsstandard ausgeben (--print-default
)
/usr/bin/bffhd --print-default
Dieser Befehl gibt eine minimale Beispielkonfiguration im Dhall-Format aus, die wir direkt in eine bffh.dhall
Datei pipen können. Die ausführliche Erläuterung der bffh-Konfiguration findest du hier.
{ actor_connections = [{ actor = "actor_123", machine = "resource_a" }], actors = { actor_123 = { module = "Shelly", params = {=} } }, auditlog_path = "/var/log/bffh/audit.json", certfile = "/etc/bffh/certs/bffh.crt", db_path = "/var/lib/bffh/bffh.db", init_connections = [{ initiator = "initiator_123", machine = "resource_a" }], initiators = { initiator_123 = { module = "Process", params = { args = "", cmd = "echo" } } }, instanceurl = "https://fabaccess.sample.space", keyfile = "/etc/bffh/certs/bffh.key", listens = [{ address = "127.0.0.1" }], machines = { resource_a = { category = Some "A category", description = Some "A description", disclose = "lab.some.disclose", manage = "lab.some.manage", name = "Resource A", prodable = True, read = "lab.some.read", wiki = Some "https://some.wiki.url", write = "lab.some.write" }, resource_b = { category = Some "A category", description = Some "A description", disclose = "lab.some.disclose", manage = "lab.some.manage", name = "Resource B", read = "lab.some.read", wiki = Some "https://some.wiki.url", write = "lab.some.write" } }, mqtt_url = "mqtt://127.0.0.1:1883", roles = { admin = { permissions = ["bffh.users.info", "bffh.users.manage", "bffh.users.admin"] }, member = { permissions = ["lab.some.disclose", "lab.some.read", "lab.some.write", "lab.some.manage"] } }, spacename = "fabaccess.sample.space" }
Sofern das Paket dhall
installiert wurde, kann auch die Ausgabe sauber formatiert werden:
/usr/bin/bffhd --print-default | dhall format > bffh.dhall
{ actor_connections = [ { actor = "actor_123", machine = "resource_a" } ]
, actors.actor_123 = { module = "Shelly", params = {=} }
, auditlog_path = "/var/log/bffh/audit.json"
, certfile = "/etc/bffh/certs/bffh.crt"
, db_path = "/var/lib/bffh/bffh.db"
, init_connections = [ { initiator = "initiator_123", machine = "resource_a" } ]
, initiators.initiator_123 =
{ module = "Process", params = { args = "", cmd = "echo" } }
, instanceurl = "https://fabaccess.sample.space"
, keyfile = "/etc/bffh/certs/bffh.key"
, listens = [ { address = "127.0.0.1" } ]
, machines =
{ resource_a =
{ category = Some "A category"
, description = Some "A description"
, disclose = "lab.some.disclose"
, manage = "lab.some.manage"
, name = "Resource A"
, prodable = True
, read = "lab.some.read"
, wiki = Some "https://some.wiki.url"
, write = "lab.some.write"
}
, resource_b =
{ category = Some "A category"
, description = Some "A description"
, disclose = "lab.some.disclose"
, manage = "lab.some.manage"
, name = "Resource B"
, read = "lab.some.read"
, wiki = Some "https://some.wiki.url"
, write = "lab.some.write"
}
}
, mqtt_url = "mqtt://127.0.0.1:1883"
, roles =
{ admin.permissions =
[ "bffh.users.info", "bffh.users.manage", "bffh.users.admin" ]
, member.permissions =
[ "lab.some.disclose"
, "lab.some.read"
, "lab.some.write"
, "lab.some.manage"
]
}
, spacename = "fabaccess.sample.space"
}
Version anzeigen (--version
, -V
)
Folgendes Kommando kann genutzt werden, um die von dir derzeitig verwendete Version von BFFH auszulesen:
/usr/bin/bffhd -V
diflouroborane 0.4.3
Wer BFFH als Debian-Paket installiert hat, kann es auch wie folgt herausfinden:
dpkg -l | grep fabaccess-bffh
ii fabaccess-bffh 0.4.3 amd64 FabAccess Diflouroborane Server (bffh)
Wer den genauen Feature Branch auslesen will, von dem kompiliert wurde:
VERSION_DETAIL=$(BFFH_LOG=trace timeout 1s /usr/bin/bffhd | grep "branch:") && echo -e $VERSION_DETAIL | tail -n +2
pkg_version:0.4.4
branch:feature/cardloginwithtoken
commit_hash:2d127d5c
build_time:2025-03-11 01:30:34 +01:00
build_env:rustc 1.84.1 (e71f9a9a9 2025-01-27),stable-x86_64-unknown-linux-gnu"
FabFire Provisioning Tool
Die Kommandos für dieses kleine Tools sind separat in FabFire Tools beschrieben.
Helfer-Skripte
Diverse Helfer-Scripts, die verschiedene Optionen/Parameter automatisieren (z.B. Benutzerdankbank zuverlässig sichern) finden sich in der Script-Sammlung.
Ein paar Tipps für Git
Für BFFH nutzen wir diverse Git-Repositories, die teilweise externe Abhängigkeiten laden. Hier finden sich ein paar Tipps für den Alltag.
Git Repository ausgecheckt, aber Untermodule vergessen auszuchecken?
Wer z.B. das Repo von BFFH auscheckt, muss die externen Module laden, um das Projekt erfolgreich zu kompilieren. Wenn das vergessen wurden, ist das kein Problem, das geht auch nachträglich:
git submodule update --init --recursive
Und reguläre Updates vom Projekt inklusive Untermodulen dann mit:
git pull --recurse-submodules
Untermodule updaten
git submodule update --remote --merge
Client benutzen und typische Konfigurationsfehler bei Server und Clients
Nach Download und Installation des Clients kann's endlich praktisch werden!
Der FabAccess Client "Borepin"
Anwendung starten
Der Client sieht beim ersten Öffnen so aus:
Borepin ist nun in Deutsch und Englisch verfügbar. Die Sprache wird automatisch anhand des erkannten Betriebssystems justiert.
Mit Server(n) verbinden (Connect to Server)
Das Verbinden mit einem FabAccess BFFH Server kann durch Eingabe des Hosts erfolgen. Entweder ist die Adresse bekannt und wird manuell angegeben oder ein QR-Code (SCAN QR-CODE
) wird gescannt. Der QR-Code enthält den Host im Plaintext-Format (keine URN-Syntax wie bei Ressourcen notwendig). Die Hostadresse erlaubt verschiedene, übliche Formate. Zum Beispiel:
- FQDN, ohne Port (z.B.
test.fab-access.org
) - FQDN, mit Port (z.B.
test.fab-access.org:59661
) - ein Hostname aus dem lokalen Netzwerk, ohne Port, z.B.
fabaccess.local
- ein Hostname aus dem lokalen Netzwerk, inkl. Port, z.B.
fabaccess.local:59661
- eine IPv4-Adresse, ohne Port, z.B.
192.168.188.31
- eine IPv4-Adresse, mit Port, z.B.
192.168.188.31:59661
- eine IPv6-Adresse, ohne Port, z.B.
[2003:f3:1736:db00:3e10:77ba:cb8b:6633]
- eine IPv6-Adresse, mit Port, z.B.
[2003:f3:1736:db00:3e10:77ba:cb8b:6633]:59661
Die vorausgefüllte Adresse test.fab-access.org kann reell genutzt werden. Obwohl das Feld vorasugefüllt ist, muss diese URL jedoch exakt so von Hand eingetragen werden!
Die stabilste Art und Weise der Verbindung kann dir dein FabAccess-Administrator des Vertrauens mitteilen. Wir verbinden uns mit dem Button CONNECT TO SERVER
. Das Verbinden dauert in der Regel ein paar Sekunden - je nach Leistungsfähigkeit des Servers, des Clients, des Netzwerks und der Komplexität der Gesamtkonfiguration des Systems.
Nach dem Verbinden: Einloggen
Nach erfolgreicher Verbindung zum Server folgt der nächste Screen, der nach Login-Daten fragt. Hier gibt es drei Interaktionsmöglichkeiten:
- Mit Passwort einloggen (
LOGIN WITH PASSWORD
) - mit Karte einloggen (
LOGIN WITH CARD
) - aktuell nicht funktional ??? - Account anlegen, also neu registrieren (
REGISTER
) - aktuell nicht funktional ???
Hauptmenü
Ist der Nutzer mit dem Server verbunden, so hat er verschiedene Möglichkeiten der Interaktion. Zum einen kann die Ressourcenübersicht (MACHINES
) aufgerufen werden. Ist der Nutzer Administrator, so können auch serverweit die Benutzer verwaltet werden (USERS
). Außerdem kan das eigene Profil angepasst werden (MY PROFILE
). Zudem gibt es eine Übersicht über alle auf dem Endgerät aktuell konfigurierten Serververbindungen (SERVERS
: Borepin kann mit mehreren Servern bzw. auch je Server mit verschiedenen Benutzern verbunden werden).
Ressourcenübersicht
Die Ressourcenübersicht zeigt alle für den Nutzer sichtbaren Geräte bzw. Maschinen an (Berechtigung disclose
), getrennt nach Kategorie bzw. Raum, Zone oder Sektor. Die Übersicht zeigt an, welche Geräte vom Benutzer gerade in Benutzung sind (In Use by Me
), sowie welche Ressourcen noch frei (Free
) oder durch jemand anderen gerade in Benutzung sind (In Use
). Die Ansicht aktualisiert sich nicht automatisch - dafür gibt es den Button REFRESH
.
Ein praktischer Button ist der große ganz oben: es ist möglich eine Ressource direkt aufzurufen, indem wir einen speziell formatierten QR-Code beispielsweise von einem gedruckten Sticker scannen (SCAN QR-CODE
).
Eine Ressource bedienen
Nach Auswahl einer Ressource aus der Übersicht gibt es verschiedene Handlungen, die ein Nutzer ausführen kann:
- Benutzen (
USE
) oder zurückgeben, falls gerade in der eigenen Benutzung (GIVEBACK
) - Wiki-Link öffnen (falls eine URL hinterlegt wurde) - hier öffnet sich ein Browser im Vollbildmodus durch Klick auf
OPEN WIKI
- Falls die manage-Berechtigung zur Verfügung steht:
- Ressource freigeben (erzwungene Rückgabe) (
FREE MACHINE
) - Ressource reservieren (
BLOCK MACHINE
). ÜberFREE MACHINE
wird die Ressource wieder freigegeben! - Ressource deaktivieren (z.B. für eine anstehende Wartung oder weil ein Defekt eingetreten ist) (
DISABLE MACHINE
). ÜberFREE MACHINE
wird die Ressource wieder aktiviert!
- Ressource freigeben (erzwungene Rückgabe) (
- Falls die Ressource als Prodable definiert ist (z.B. für ein Spind oder eine Tür), dann gibt es zwei weitere Buttons:
UNLOCK
öffnet bzw. entsperrt die Ressource, ohne sie für andere zu blockieren und ohne sie zurückgeben zu müssenIDENTIFY
löst eine einfache Aktion aus wie z.B. das Aufleuchten einer LED an der Ressource, um das Fach bzw. die Ressource optisch leichter zu identifizieren
In der rechten oberen Ecke ist zudem der aktuelle Zustand der Ressource erkennbar, z.B. Free
, In Use
, Blocked
, Disabled
, ToCheck
, Reserved
Die Zustände ToCheck
und Reserved
sind nicht funktional im Client implementiert, können jedoch durch Initiatoren oder die FabAccess-API gesetzt werden. Geräte mit diesen Zuständen werden zumindest entsprechend im Client angezeigt.
Eine hilfreiche Information ist außerdem auch die Anzeige, welcher Nutzer die Ressource zuletzt benutzt hat (Last User
).
Benutzer verwalten
Dieses Menü obliegt der Rolle des Administrators bzw. Managers und erlaubt das Filtern (Search User
), sowie das Anpassen oder Löschen (DELETE
) bestehender Nutzer (Rollen zuweisen, Passwort zurücksetzen per FORCE PASSWORD RESET
) und das Anlegen neuer Nutzer (ADD NEW USER
). Beim Anlegen eines neuen Nutzers können lediglich Benutzername und Passwort konfiguriert werden. Etwaige Keycard-Codes müssen durch den Administrator in der users.toml
Konfiguration hinterlegt werden. Das Löschen bestehender Nutzer erfolgt mit Bestätigungsdialog.
Servers - Verbindungen managen
In diesem Menü werden alle Verbindungen (Server + Login) angezeigt, die erfolgreich zum Borepin Client hinzugefügt wurden (Historie). Es wird auch die aktuell genutzte Verbindung angezeigt. Hier kann eine Verbindung ausgewählt und als Standardverbindung gesetzt werden (SET AS DEFAULT CONNECTION
). Außerdem können wir uns hier auch vom aktuellen Server abmelden (DISCONNECT
) oder eine andere Verbindung zum Verbinden wählen (CONNECT
). Selbstverständlich können unbenötigte Verbindungen entfernt werden (DELETE
). Das Löschen erfolgt mit Rückvergewisserungsdialog zur Bestätigung des Vorgangs (weiter mit CONFIRM
oder abbrechen durch CANCEL
).
Profil verwalten
Die eigene Profilverwaltung ist relativ übersichtlich. Hier kann lediglich das Passwort neu gesetzt werden. Das Ändern des Namens muss vom Administrator beauftragt werden. Der Benutzer kann seinen Account nicht selbst löschen.
Probleme mit dem Client
"Authentication failed. Credentials are invalid."
Dieser Fehler taucht in der Regel auf, wenn Benutzername und/oder Passwort falsch sind.
"Connection failed. Connection time exceeded."
Ein Typischer Fehler und dieser kann verschiedene Gründe haben. Prüfen:
- läuft der BFFH Server? Log bzw. Journal überprüfen!
- läuft der MQTT Server? Log bzw. Journal überprüfen!
- Laufen MQTT und BFFH auf den korrekten Netzwerk-Interfaces?
- ist die Client Version mit dem Server kompatibel?
- möglicherweiser gibt es ein Port-Problem auf dem Client (Firewall überprüfen!)
- Tipp: Verbindung mit telnet prüfen:
telnet fabaccess.local 59661
"Connection failed. Unable to connect to server."
Dieser Fehler drückt aus, dass der Server nicht per DNS auflösbar ist. Hier ist es sinnvoll verschiedene Verbindungskonstellationen durchzuprobieren, zum Beispiel:
- fabaccess
- fabaccess.local
- fabaccess:59661
- fabaccess.local:59661
- 192.168.188.1:59661
- sonstige FQDNs
- Tipp: Verbindung mit telnet prüfen:
telnet fabaccess.local 59661
Unter Umständen wird der Fehler auch hervorgerufen, weil der Client mit einem VPN-Netwerk verbunden ist und es Konflikte in der DNS-Auflösung oder IP-Adressbereich gibt.
"Connection failed. TLS certificate is invalid."
Möglicherweise wurde in der Konfiguration bffh.dhall die minimale Version von TLS auf 1.3 gesetzt. Borepin unterstützt aktuell nur TLS 1.2.
"Connection failed. Unexpected Error."
Dieser Error wurde möglicherweise verursacht, weil das vom Benutzer eingegebene Passwort zu komplex ist. Der Administrator des Server sollte überprüfen, ob für den Nutzer ein zu komplexer Argon2-Hash erzeugt wurde, der die Rechenkapazität übersteigt. Siehe auch Benutzerkonfiguration - users.toml.
Eine andere Ursache kann auch der Absturz des Serverdienstes sein, z.B. durch eine unbehandelte Ausnahme (z.B. SIGSERV
oder SEGFAULT
Error).
"No Connection to Server. Please select a Server."
Dieser Fehler wird u.U. angezeigt, wenn der Nutzer gerade in FabAccess aktiv eingeloggt ist, aber der Server neu gestartet wurde und sich dabei das Passwort für den Nutzer geändert hat. Am besten ausloggen und erneut versuchen bzw. Rücksprache mit dem Administrator halten.
Ich habe die users.toml Datei editiert, aber der oder die Nutzer können sich trotzdem nicht einloggen
Das Editieren ist nur ein Schritt in der Prozesskette! Hast du nach dem Editieren auch einen neuen Import durchgeführt? Erst durch Importieren der users.toml
in BFFH werden die Änderungen auch wirksam.
Serverseitige Fehlermeldungen
Fehlkonfigurationen auf dem Server (z.B. wegen fehlenden Ordnern oder Berechtigungen darauf) oder ungeeigneten oder unvollständigen Einstellungen in bffh.dhall
führen zu Fehlern beim Start von bffhd
. Wir empfehlen die Referenz zur Hauptkonfiguration zu lesen.
config::notfound
Error: config::notfound
× The config file '/etc/diflouroborane.dhall' does not exist or is not readable
help: Make sure the config file and the directory it's in are readable by the user running bffh
Dieser Fehler tritt dann auf, wenn bffhd ohne Konfigurationsdatei gestartet wird. Verwende den Parameter --config
, um eine entsprechende dhall-Datei (z.B. bffh.dhall
) anzugeben.
Failed to open socket on 127.0.0.1:59661: Address already in use (os error 98)
ERROR diflouroborane::capnp: Failed to open socket on 127.0.0.1:59661: Address already in use (os error 98)
at bffhd/capnp/mod.rs:103
Auf dem angegebenen Port und Interface läuft bereits eine (andere) Anwendung. Prüfen Sie, ob bffh bereits läuft oder ein anderer Dienst den gleichen Port für sich beansprucht oder ob Firewall-Einschränkungen dazu führen.
Ermitteln von Anwendungen, die auf dem Port lauschen:
sudo lsof -i tcp:59661
netstat -an | grep LISTEN | grep 59661
failed to initialize state database
Error:
× failed to initialize state database
├─▶ opening the state db environment failed
╰─▶ Permission denied
Dieser Fehler drückt aus, dass die Datenbankdatei bffh
nicht zum Schreiben geöffnet werden kann. Möglicherweise existiert das Zielverzeichnis nicht oder es gehört dem falschem Benutzer. Prüfen Sie den Schlüssel db_path
.
audit log failed
Error:
× audit log failed
╰─▶ Permission denied (os error 13)
Dieser Fehler drückt aus, dass die Datenbankdatei bffh.audit
nicht zum Schreiben geöffnet werden kann. Möglicherweise existiert das Zielverzeichnis nicht oder es gehört dem falschem Benutzer. Prüfen Sie den Schlüssel auditlog_path
.
error in actor subsystem
× error in actor subsystem
├─▶ MQTT connection failed
├─▶ I/O: failed to lookup address information: Name or service not known
╰─▶ failed to lookup address information: Name or service not known
Die Verbindung zum MQTT Server konnte nicht hergestellt werden. Der Schlüssel mqtt_url
sollte überprüft werden:
- Ist das Protokoll (z.B.
tcp://
,mqtt://
odermqtts://
) korrekt vorrangestellt? - Stimmen Benutzername, Passwort, Host und Port?
- Läuft der Mosquitto MQTT Server korrekt und ist er vom Server aus erreichbar? (Firewall prüfen!)
failed to initialize TLS config
Error:
× failed to initialize TLS config
├─▶ failed to open certificate file at path examples/cert.pem
╰─▶ No such file or directory (os error 2)
Das angegebene SSL Zertifikat konnte nicht gefunden werden. Überprüfen Sie den Schlüssel certfile
in bffh.dhall
. Existiert die Datei? Hat bffhd Zugriff darauf?
Error:
× failed to initialize TLS config
├─▶ failed to open private key file at path examples/key.pem
╰─▶ No such file or directory (os error 2)
Der Private Key für das SSL Zertifikat konnte nicht gefunden werden. Überprüfen Sie den Schlüssel keyfile
in bffh.dhall
. Existiert die Datei? Hat bffhd Zugriff darauf?
Script-Sammlung
Eine Sammlung verschiedener Scripts über das Basic-Setup hinaus, um dem Admin Dinge zu erleichtern
Backup für die Benutzerdatenbank einrichten
Mit folgendem Backup-Script (bash) können wir die Benutzerdatenbank sichern. Diese können wir außerdem mit systemd
per Service und Timer automatisieren. Alternativ kann das Bash-Script auch als Cronjob eingebunden werden. Folgendes Script sollte je nach Bedarf angepasst werden (Pfade).
Es ist generell sehr empfehlenswert die Benutzerdatenbank regelmäßig zu sichern. Immer dann, wenn ein Administrator bzw. Manager per Client App neue Accounts hinzufügt, Accounts löscht oder Accounts ändert (z.B. Passwortwechsel), dann werden diese Änderungen in einen transienten Zwischenspeicher (bffh
Datenbankdatei) gelegt. Dieser sollte mit der lokalen users.toml
zusammengeführt werden, um alle Nutzer im Fall der Fälle wiederherstellen zu können. Das erfolgt über den dump-users
Parameter.
Wird dieser zusammengeführte Dump nicht ausgeführt und crasht der Serverdienst, dann sind alle etwaigen Remote-Änderungen u.U. nicht wiederbringbar.
Backup Script anlegen und konfigurieren
Wir können theoretisch auch die komplette Datenbank sichern (Benutzerdatenbank + Statusdatenbank). Im Script muss dann DB_DUMP_CMD
der Parameter --dump-users
gegen --dump-db
getauscht werden.
vim /opt/fabinfra/scripts/bffh-backup.sh
#!/bin/bash
# Database dump command
DB_DUMP_CMD="/usr/bin/bffhd -c /etc/bffh/bffh.dhall --dump-users"
# Backup directory
BACKUP_DIR="/etc/bffh/config_backup"
# Number of backups to keep
NUM_BACKUPS_TO_KEEP=5
# Dry run flag
DRY_RUN=false
# Parse command-line options
while getopts ":n:r" opt; do
case $opt in
n)
NUM_BACKUPS_TO_KEEP="$OPTARG"
;;
r)
DRY_RUN=true
;;
\?)
echo "Invalid option: -$OPTARG" >&2
exit 1
;;
:)
echo "Option -$OPTARG requires an argument." >&2
exit 1
;;
esac
done
# Current date and time
CURRENT_DATE=$(date +"%Y%m%d%H%M%S")
# Create a backup file name
BACKUP_FILE="$BACKUP_DIR/db_backup_$CURRENT_DATE.toml"
# Create backup dir, if not existent
if [ ! -d $BACKUP_DIR ]; then
mkdir -p $BACKUP_DIR
fi
# Execute the database dump command
if [ "$DRY_RUN" = true ]; then
echo "Dry run mode: Database backup command will not be executed."
echo "Backup command: $DB_DUMP_CMD $BACKUP_FILE"
else
$DB_DUMP_CMD $BACKUP_FILE
fi
# Check if the database dump was successful
if [ $? -eq 0 ]; then
echo "Database backup completed successfully."
# Sort backup files by modification time in ascending order
sorted_backup_files=($(ls -rt "$BACKUP_DIR"))
# Determine number of backups to delete
num_backups_to_delete=$((${#sorted_backup_files[@]} - NUM_BACKUPS_TO_KEEP))
cd $BACKUP_DIR
# Delete oldest backups if necessary
if [ $num_backups_to_delete -gt 0 ]; then
for ((i = 0; i < $num_backups_to_delete; i++)); do
if [ "$DRY_RUN" = true ]; then
echo "Dry run mode: Would remove old backup: ${BACKUP_DIR}/${sorted_backup_files[$i]}"
else
rm "${sorted_backup_files[$i]}"
echo "Removed old backup: ${BACKUP_DIR}/${sorted_backup_files[$i]}"
fi
done
fi
else
echo "Error: Database backup failed."
fi
chmod +x /opt/fabinfra/scripts/bffh-backup.sh
Das Script kann einzeln getestet werden. Es kann mit Parametern gestartet werden:
- n = Anzahl der aufzuhebenden Backups
- r = dry run
# Trockenlauf (dry run) - nur testen und nichts löschen
/opt/fabinfra/scripts/bffh-backup.sh -r -n 2
# Backup durchführen und nur die letzten 5 aufheben, alle anderen löschen
/opt/fabinfra/scripts/bffh-backup.sh -n 5
Backup-Script mit systemd Timer
Das Script kann als timed Service eingebunden werden, um es so zu automatisieren. Unter Beachtung obiger Parameter in ExecStart
kann folgendes eingebunden werden:
vim /opt/fabinfra/scripts/bffh-backup.service
[Unit]
Description=BFFH Backup Service
[Service]
Type=oneshot
ExecStart=/opt/fabinfra/scripts/bffh-backup.sh -n 10
Außerdem als Timer. Dieser muss den gleichen Name haben wie der Service (siehe https://wiki.ubuntuusers.de/systemd/Timer_Units)
vim /opt/fabinfra/scripts/bffh-backup.timer
[Unit]
Description=BFFH Backup Timer
[Timer]
# Run every day at midnight
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
Wir aktivieren und starten das Backup schließlich einmal manuell und prüfen dessen Ausgabe.
Hinweis: Da wir einen Timer für den Service verwenden, müssen wir den Service nicht "enablen". Denn das macht der Timer selbst.
sudo ln -sf /opt/fabinfra/scripts/bffh-backup.service /etc/systemd/system/bffh-backup.service
sudo ln -sf /opt/fabinfra/scripts/bffh-backup.timer /etc/systemd/system/bffh-backup.timer
sudo systemctl daemon-reload
sudo systemctl start bffh-backup.service
journal -f -u bffh-backup.service
Backup-Script mit cron
Wer lieber auf einen klassischen Cronjob setzten möchte, kann statt dem Service folgendes machen:
sudo vim /etc/cron.d/bffh-backup
#“At 00:00.”
0 0 * * 0 bffh /opt/fabinfra/scripts/bffh-backup.sh -n 10
Der Cronjob wird um 00:00 Uhr vom Benutzer bffh
gestartet. Es gibt keinen Log Output. Dieser lässt sich jedoch leicht ergänzen.
Nutzerdatenbank laden / hashen / prüfen
Nutzerdatenbank laden / hashen
Für das Laden und ggf. Rehashen der Nutzerdatenbank (users.toml
) kann folgendes Script genutzt werden. Es prüft zunächst, ob die Konfiguration bffh.dhall
von BFFH valid ist. Wenn nicht, wird nichts unternommen. Im Anschluss werden die Nutzer neu geladen und anschließend in die gleiche Datei optional wieder exportiert, um etwaige unverschüsselte Passwörter automatisch zu hashen. BFFH prüft beim Laden die users.toml auf Syntaxfehler. Wem diese Checks nicht ausreichen, der kann sich dem erweiteren Validator-Script widmen,
Hinweis: Das Script basiert auf einem auf dem System aktiven systemd Service namens bffh.service
mkdir -p /opt/fabinfra/scripts/
vim /opt/fabinfra/scripts/bffh-load-users.sh
#!/bin/bash
#check config
BFFHD="/usr/bin/bffhd"
DATA="/etc/bffh"
CFG="$DATA/bffh.dhall"
USERS="$DATA/users.toml"
while [[ $# -gt 0 ]]; do
case $1 in
-h|--help)
echo "-h|--help - show help"
echo "-r|--rehash - overwrite users.toml with hashed passwords (ensure secure secrets)"
exit 1
;;
-r|--rehash)
REHASH="y"
shift
;;
-*)
;;
esac
done
echo "use -h|--help to show additional script options!"
$BFFHD --check --config $CFG > /dev/null
if [ $? == 0 ]; then
#pre-check bffh.dhall
echo "Config is valid. Loading users ..."
$BFFHD --verbose --config $CFG --load-users=$USERS
if [ $? == 0 ]; then
#then load users.toml
$BFFHD --verbose --config $CFG --dump-users /tmp/users.toml --force
else
echo "Error: Newly given users.toml is invalid!"
exit 1
fi
#if this was successful and service is running, restart it, elso do nothing
if [ $? == 0 ]; then
if [[ $REHASH == "y" ]]; then #overwrite users if --rehash option is given (not null)
echo "Rehasing users.toml!"
cat /tmp/users.toml > $USERS
rm /tmp/users.toml
fi
FAS="bffh.service"
STATUS="$(systemctl is-active $FAS)"
if [ "${STATUS}" = "active" ]; then
echo "restarting $FAS"
systemctl restart $FAS
else
echo -e "\n\n$FAS not active/existing. Not restarting bffh service!"
fi
fi
else
echo "Error: Currently loaded users.toml is invalid!"
exit 1
fi
chmod +x /opt/fabinfra/scripts/bffh-load-users.sh
Nutzerdankenbank prüfen (users.toml validator)
Ein Python-Script erlaubt die Auswertung einer users.toml
Datei mit folgenden Features:
- zählt die Nutzer und deren zugewiesene Rollen
- überprüft auf Duplikate bei Nutzernamen, Passwörtern und Cardkeys
- validiert Passwörter auf Verschlüsselung (Argon2)
- validiert eventuell vergebene Cardkeys (UUID)
- gibt Hinweise bei möglichen Datenbankfehler (z.B. falsche Datentypen)
- erzeugt eine Statistik über die Verwendung von Passwörtern, Cardkeys und Rollen
Das Script benötigt mindestens Python 3.11. Erst ab dieser Version wird tomllib
unterstützt!
Tool installieren:
cd /opt/fabinfra/tools/
git clone https://github.com/vmario89/fabaccess-users-toml-validator.git
Benutzen:
python3 /opt/fabinfra/tools/fabaccess-users-toml-validator/validate.py
Über den optionalen Parameter --db /opt/fabinfra/bffh-data/config/users.toml
kann auch eine andere Benutzerdatenbankdatei an Stelle der Standarddatei /etc/bffh/users.toml
angegeben werden!
Fehlermeldungen und deren Bedeutung
Invalid initial character for a key part (at line x, column y)
Möglicher enthält der Benutzername Sonderzeichen wie Umlaute und ist nicht in Hochkommas geführt. In diesem Falle bricht das Script ab. [Ö]
ist kein gültiger Benutzername, ["Ö"]
schon.
FabAccess State Script (Email-Warnung bei Fehlerzustand)
Ein kleines Helferscript, was an ein beliebiges Mail-Postfach eine Email sendet, wenn unser systemd Service bffh.service
nicht mehr korrekt läuft. Falls der Service nicht installiert wurde, dann wird das Script einen Fehler werfen.
Wir verwenden außerdem im Script das smarte smtp-cli Tool von mludvig: https://github.com/mludvig/smtp-cli/tags. Es kann jedoch auch jeder andere beliebige Mail-Client verwendet werden, um cli-basierte Nachrichten zu versenden. Kleiner Fix: https://github.com/mludvig/smtp-cli/issues/28
# smtp-cli installieren
sudo apt install cpanminus
sudo cpanm Net::DNS
sudo apt install libio-socket-ssl-perl libdigest-hmac-perl libterm-readkey-perl libmime-lite-perl libfile-libmagic-perl libio-socket-inet6-perl
cd /opt
sudo wget https://github.com/mludvig/smtp-cli/archive/refs/tags/v3.10.zip
sudo unzip v3.10.zip
sudo rm v3.10.zip
sudo mv /opt/smtp-cli-3.10/smtp-cli /usr/bin/
sudo rm -rf /opt/smtp-cli-3.10/
mkdir -p /opt/fabinfra/scripts/
vim /opt/fabinfra/scripts/bffh-state.sh
#/!bin/bash
SMTP_SERVER="smtp.fablabchemnitz.de:587"
SMTP_MAILBOX="REDACTED"
SMTP_PW='REDACTED'
FROM="fabaccess.noreply@stadtfabrikanten.org"
TO="webmaster@stadtfabrikanten.org"
SUBJECT="FabAccess BFFH Service failed"
MAILFILE="/tmp/mail.txt"
systemctl status bffh.service 2>&1 > ${MAILFILE}
if [ $? != 0 ]; then #wenn exit code von systemd unit nicht 0
cat ${MAILFILE}
/usr/bin/smtp-cli --server ${SMTP_SERVER} --user ${SMTP_MAILBOX} --password ${SMTP_PW} --from "${FROM}" --to "${TO}" --subject "${SUBJECT}" --body-plain ${MAILFILE}
fi
chmod +x /opt/fabinfra/scripts/bffh-state.sh
Und dann testen wir das Script. Es gibt den Status auf der Kommandozeile aus und sollte parallel eine Email an das Zielpostfach mit gleichem Inhalt senden.
Einbinden in systemd Service
Wir können dieses Script auch direkt in unseren bffh.service einbinden.
Dazu fügen wir folgende Zeile in die Sektion [Service]
ein:
vim /etc/systemd/system/bffh.service
ExecStopPost=/usr/bin/bash /opt/fabinfra/scripts/bffh-state.sh $EXIT_CODE
Danach muss der Service neu gestartet werden:
sudo systemctl daemon-reload
sudo systemctl restart bffh.service
Echtzeituhr (RTC) Modul DS3231 für Raspberry Pi
Wer FabAccess auf einem Raspberry Pi betreiben möchte und eine Echtzeituhr für genaue und unabhängige Zeitstempel wünscht, kann ein RTC Modul installieren und konfigurieren:
Diese Anleitung basiert auf https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/set-rtc-time
Das von uns verbaute Uhrenmodell ist DS3231
Wir fügen in der Boot-Konfiguration folgende Device Tree Overlays (dtoverlay
) ein:
sudo vim /boot/config.txt
# Additional overlays and parameters are documented /boot/overlays/README
dtoverlay=i2c-rtc,ds3231
sudo vim /etc/modules
i2c-bcm2708
i2c_dev
Danach starten wir den Pi neu
sudo reboot
Nach dem Restart prüfen wir, ob unsere Echtzeituhr verfügbar ist.
i2cdetect -y 1 #should be visible at 0x68
Wenn ja, dann können wir die standardmäßig installierte "Fake Hardware Clock" deinstallieren:
sudo apt remove fake-hwclock
sudo update-rc.d -f fake-hwclock remove
sudo systemctl disable fake-hwclock
Noch etwas nachstellen und dann die Uhr in Betrieb nehmen:
sudo vim /lib/udev/hwclock-set
#!/bin/sh
# Reset the System Clock to UTC if the hardware clock from which it was copied by the kernel was in localtime.
dev=$1
/sbin/hwclock --rtc=$dev --hctosys
sudo hwclock -r
sudo hwclock --verbose -r
sudo hwclock -w #write the time
sudo hwclock -r #read the time