Was ist FabAccess? Grundkonzepte

Die Basics zu FabAccess (Server + Client + Konzepte) findest du hier!

Was ist FabAccess?
Grundkonzepte

Allgemeine Struktur
FabAccess Server-Client Konzept
Abhängigkeiten von Ressourcen
Aktoren (Actors) und Initiatoren (Initiators)
Audit Log (Revisionsprotokoll)
Ausleihen and Transfer
Auswahl Programmiersprache und Framework für BFFH
Cache (Zwischenspeicher)
Claims, Notify und Interest (das Konzept vom "Anspruch erheben")
Datenbank-Konzept (LMDB)
Federation (Föderation)
Measurements (Messwerte)
RBAC (Benutzerrollen und Berechtigungen)
Plugins
Projekte
Terminals
Externe Authentifikation
Nutzerverwaltung
Sensoren
Zustände (Traits)
URL und URN

Was ist FabAccess?

Video-Intro

Ein kurzes Erklärvideo zeigt dir, was FabAccess ist und was es kann:

Allgemein

FabAccess ist ein leistungsstarkes, zentrales Zugangs- und Ressourcenkontrollsystem für den automatisierten Verleih, Management und Zuweisung von Maschinen und Geräten, Türen, Schließfächern, Meetingräumen und sonstigen Dingen. Diese Selbstbedienungsfunktion ermöglicht es Benutzern über unsere App (Borepin) den Benutzungs-, Rückgabe- oder Verleihprozess eigenständig durchzuführen, wodurch Betreuer von offenen Werkstätten ihre Aufmerksamkeit auf andere Tätigkeiten wie Ausbildung und Wissensvermittlung richten können und einen besseren Überblick behalten.

Die Anforderungen für FabAccess wurden mit Mitgliedern des Verbunds Offener Werkstätten e.V. und mit Betreibern von FabLabs an Hochschulen (Fab:UNIverse) entwickelt. Das daraus entstandene Lastenheft ist im GitLab Projekt zu finden.

Ein Zugangssystem für offene Werkstätten. Das klingt einfach, oder? Hier 1 Bit setzen, Maschine an! 1 Bit zurücksetzen, Maschine aus! Fertig. Leider stellt sich heraus, dass es nicht ganz so einfach ist. Warum brauchen wir das trotzdem?

Es gibt 2 Arten von Maschinen: die, die Menschen verletzen ... und alle anderen
Es gibt 2 Arten von Werkstattnutzern: die, die aufräumen ... alle anderen

Wenn wir mit alledem klarkommen wollen, dann viel Spaß! Oder nutze doch FabAccess!

Warum ist das nicht so einfach?

Weil es verschiedene Hürden bzw. Aspekte gibt, die dafür Berücksichtigung finden sollten:

Rollenbasierter Zugriff
Föderation
Arbeitssicherheit
IT-Sicherheit
attributgesteuerter Zugriff
Stabilität
Einfachheit der Installation
Modularität
verschiedene Ressourcen
Zugänglichkeit
Zeit & Geld
verschiedene Werkstätten
komplexe Aktivierungsschemata

Wir wollen (und brauchen) viel mehr als ein "funktioniert für mich" Tool.

Perspektiven von FabAccess

Für die Werkstattleiter sollte das System ...

einen sicheren Betrieb garantieren
soziale Verhaltensrichtlinien etablieren bzw. erzwingen

... und ...

einfach installierbar und konfiguerbar sein
stabil in laufender Benutzung agieren
Wartungsaufwand mit wenig bis keinem Aufwand

.... es sollte sich der Werkstatt anpassen, nicht die Werkstatt an FabAccess

Für die Werkstattbenutzer sollte das System ...

einfach zugänglich sein
schnell und einfach zu nutzen sein
den Aufwand reduzieren

Ressourcenverwaltung

Das Prinzip von FabAccess ist es, Maschinen bzw. allgemein Ressourcen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit relativ ungefährlich. Erst, wenn Nutzer an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden. Wir wollen dabei die Idee von Neil Gershenfeld, dass Nutzer selbstständig den Umgang mit Maschinen lernen, mit den Anforderungen von offenen Werkstätten kombinieren, sodass Nutzer sich dabei nicht verletzen. Folglich benötigen Nutzer für gefährliche Maschinen idealerweise eine Einweisung - dieses Prinzip wird dann im Berechtigungssystem abgebildet.

Eine Ressource kann aber im generischen Fall auch eine Person sein, die für Support gebucht wird.

Beispiel für Supporter-Ressourcen "Joris hilft" und "Tanja hilft", Makerspace Bocholt

Noch nicht unterstützt, aber geplant: Die Abnahme von Maschinen, die eine Reinigung nach Gebrauch benötigen. So wird die Nutzbarkeit von Maschinen für den nächsten Nutzer sichergestellt und der Verschleiß verringert.

Noch nicht unterstützt, aber geplant: das Reservieren von Maschinen, wollen aber keine Zeitplanung für die Nutzer übernehmen. Daher ist der Kompromiss, den wir umsetzten, dass Nutzer Maschine nur beispielsweise eine halbe Stunde reservieren können, um so den Weg zum FabLab sich keine Sorgen darüber machen müssen, dass jemand anderes in der Zeit die Maschine für 5 Stunden verwendet.

Berechtigungsverwaltung

Ein zentraler Aspekt von FabAccess ist also das Management von Berechtigungen, das die Steuerung des Zugriffs auf bestimmte Ressourcen ermöglicht. Diese Berechtigungen bieten eine feingranulare Kontrolle darüber, welcher Benutzer auf welche Ressourcen zugreifen kann, und dienen als wichtiges Instrument für die Sicherheit und Effizienz des Systems. Mit FabAccess soll der Zugriff auf Ressourcen in Offenen Werkstätten verwaltet werden, um so Unfälle zu vermeiden. Auch der Zugang zu Räumen und Schränken kann organisiert werden.

Ein Anwendungsbeispiel: Die Kreissäge soll nur von denjenigen Personen angeschaltet werden können, die eine Einführung besucht haben. Nach der Einführung bekommen die Teilnehmer*innen über ihre Chip-Karte die Berechtigung für die Aktivierung der Kreissäge. Nur wer diese Berechtigung hat, kann die Kreissäge mit Hilfe der Chip-Karte einschalten.

API und Audit Log

Mit seiner flexiblen API können Ressourcenbesitz und -zustände effektiv abgebildet werden, wobei jede Ressource einem bestimmten Benutzer zugeordnet werden kann. Darüber hinaus bietet es die Möglichkeit, Statusänderungen von Ressourcen zu verfolgen, was eine präzise Überwachung und Verwaltung ermöglicht (Audit Log).

Zweck der API ist es auch eine Anbindung für Leute anzubieten, die keine Core-Coder sind.

Modularität per Plugins und Scripts

Die Modularität von FabAccess ermöglicht eine vollständige Anpassung an die Anforderungen unterschiedlicher Spaces. Die Ansteuerung der Ressourcen erfolgt über Plugins (Aktoren, Initiatoren).

Zudem bietet FabAccess die Möglichkeit, eigene Skripte über die FabAcess-API (angebunden werden kann alles, was Cap'n Proto anspricht - egal ob in Python, Bash, C, Perl, ...) anzubinden, um eine höhere Automatisierung zu erreichen. Diese Vielseitigkeit eröffnet nicht nur die effiziente Nutzung von Maschinen und Geräten, sondern bietet auch Raum für Flexibilität und Anpassungsfähigkeit an die individuellen Bedürfnisse verschiedener Umgebungen. Eine Referenzimplementierung für die FabAccess-API wird in Python bereitgestellt und nennt sich pyfabapi.

Einfachheit in Installation und Konfiguration

Die Installation von FabAccess wird aktiv dokumentiert
Die Konfguration erfolgt über dhall / toml Dateien
- eine GUI für das Erstellen von Konfigurationen ist wünschenswert
- die Dateien sollten gut dokumentiert sein - und du fasst sie nur einmal an
Das Anbinden neuer Ressourcen ist einfach - z.B. über Python, Bash, etc.
- eine wachsende Zahl von Beispielen finden sich auf GitLab, Github und anderen Plattformen

On-premise Ansatz

FabAccess ist ausschließlich selbst gehosted! Es gibt keinen Dienstleister dafür. Jeder Space soll seine eigene Infrastruktur damit abbilden und verwalten können.

Wartung

abwärtskompatible Konfiguration und API ab Version 1.0
strukturierte Log-Dateien von Ereignissen

Zugänglichkeit (Client App)

Die mobile App ist in den meisten App Stores zu finden (inkl. F-Droid). Eine APK ist frei zugänglich. Weitere Details siehe https://fab-access.org/downlooad.

Aufwand / Nutzungsbeschleunigung

Ressourcen können neben der manuellen Auswahl in der App-Übersichtsliste auch per QR-Code oder mit NFC Tags vorausgewählt und schneller aktiviert werden
Die Benutzerauthentifizierung kann auch mit Mifare DESFire EV2 Karten und FabReadern umgesetzt werden. In diesem Fall ist dann keine Client App für den Benutzer notwendig!

Unterstützte Hardware - out of the box

DESfire EV2 via FabReader
Shelly Plugs (v1 und v2)
Rasberry Pi / LXC Container / Proxmox / ...

Was ist FabAccess nicht?

Wie kann man verhindern, dass die Leute die Stecker aus der Maschine ziehen, um sie ein- oder auszuschalten? Die kurze Antwort: FabAccess ist kein System zum Lösen sozialer Probleme, z.B. wenn Nutzer in Spaces Maschinen unzweckmäßig verwenden, indem sie beispielsweise in der Werkstatt Maschinen oder Kabel manipulieren, um sie trotzdem einzuschalten! FabAccess dient lediglich dazu, Maschinen zu schalten und bei der Auswertung und Organisation zu helfen. Vertrauen und Umgang muss trotzdem von Mensch zu Mensch geschaffen werden!

Über Fragen und Antworten, wie unpflegsames Benutzerverhalten geahndet werden soll, sollte sich jede Werkstatt ein eigenes Konzept überlegen und die entsprechenden Möglichkeiten erörtern - zum Beispiel das Auswerten des Audit Logs.

FabAccess ist zudem kein ERP-System und kein System für die Abrechung von Kosten, der Pflege von Maschinenführerscheinen oder dem Inventar. Für diese Komponenten bedarf es separater Lösungen, die über geeignete Schnitstellen sinnvoll kommunizieren sollten. Wir haben jedoch eine Reihe von Softwaresammlungen angelegt, die ggf. bei genau diesen Fragestellungen weiterhelfen.

Schreibweise von FabAccess

Die richtige Schreibweise von FabAccess ist "FabAccess"

Falsch sind

"Fab Access"
"Fab-Access"

Außerdem gab es in den Anfangsjahren die Schreibweise "Fab:Access", als es aus dem FAB:UNIverse Kontext kam. Dadurch, dass jedoch verschiedene Begriffe wie FabInfra, FabHardware, FabFireCard, FabFire und FabReader dazu kamen, wurde auf den Doppelpunkt verzichtet.

Grundkonzepte

Ein Einstieg in die Grundkonzepte von FabAccess.

Die Anforderungen an FabAccess sind im Laufe der Jahre rasant gewachsen. Ursprünglich sollte nur eine Drehbank mit Strom versorgt werden, nun können jedoch auch Türen oder Schließfächer verwaltet werden. Um diesen vielfältigen Anforderungen gerecht zu werden, haben wir einige Konzepte erarbeitet, mit denen wir den Prozess zum Freischalten dieser Ressourcen vereinheitlichen und für alle verfügbar machen wollen.

Bitte beachte: noch nicht alle hier festgehaltenen Grundkonzepte sind in FabAccess implementiert. Hier bedarf es Entwicklerearbeit.

Die Implementierungen von FabAccess resultieren aus den Konzepten. Dabei müssen oft weitere Annahmen getroffen werden, wie genau die Implementierung aussehen soll. Für all diese Fälle werden hier die Entscheidungen festgehalten und möglichst nachvollziehbar erklärt, warum die Entscheidung so getroffen wurde.

Die hier aufgelisteten Konzepte haben viel mit Softwareimplementierung zu tun. Deshalb verwenden wir in den Titeln englische Begriffe, erläutern aber an geeigneten Stellen die deutsche Interpretation.

Grundkonzepte

Allgemeine Struktur

Strukturdiagramm von Joseph Langosch, Stand 27.05.2021, es zeigt die grundlegenden Komponenten und deren Interaktionen

Grundkonzepte

FabAccess Server-Client Konzept

Stream Initiierung

Bei einer Sitzung gibt es zwei Parteien: Die einleitende Stelle und die empfangende Stelle. Diese Terminologie bezieht sich nicht auf den Informationsfluss, sondern vielmehr auf die Seite, die eine Verbindung eröffnet bzw. auf die Seite, die auf Verbindungsversuche wartet. In dem derzeit angedachten Anwendungsfall ist die initiierende Instanz ...

a) ein Client (d.h. ein interaktives oder Batch/automatisiertes Programm), der versucht, auf die eine oder andere Weise mit einem Server zu interagieren,
b) ein Server, der versucht, Informationen mit/von einem anderen Server auszutauschen/anzufordern (d.h. Föderation). Die empfangende Einheit ist jedoch bereits ein Server.

Außerdem ist die Anzahl und Art der Clients vielfältiger und weniger aktuell als die der Server. Daraus ziehen wir folgende Schlüsse:

Es ist wahrscheinlicher, dass Clients eine veraltete Version des Kommunikationsprotokolls implementieren.
Der Ort für Rückwärtskompatibilität sollten die Server sein.
Daher sollte der Client (auslösende Einheit) zuerst die erwartete API-Version senden, auf deren Grundlage der Server dann entscheidet, mit welcher API-Version er antworten wird.

Stream Negotiation

Da die empfangende Stelle für die von ihr kontrollierten Ressourcen verantwortlich ist, stellt sie Bedingungen für die Verbindung entweder als Client oder als föderierender Server. Zumindest muss sich jede einleitende Stelle gegenüber der empfangenden Stelle authentifizieren, bevor sie weitere Aktionen durchführt oder Informationen anfordert. Eine empfangende Stelle kann aber auch andere Merkmale verlangen, z. B. eine Verschlüsselung auf der Transportschicht. Zu diesem Zweck informiert eine empfangende Stelle die einleitende Stelle über Merkmale, die sie von der einleitenden Stelle benötigt, bevor sie weitere Aktionen durchführt, sowie über Merkmale, die freiwillig ausgehandelt werden, aber die Qualität des Datenstroms verbessern können (z. B. Nachrichtenkompression).

Unterschiedliche Bedingungen machen eine Verhandlung erforderlich. Da die Funktionen möglicherweise eine strenge Reihenfolge erfordern (z. B. Verschlüsselung vor Authentifizierung), muss die Aushandlung in mehreren Schritten erfolgen. Weitere Einschränkungen ergeben sich daraus, dass einige Funktionen erst angeboten werden können, nachdem andere eingerichtet wurden (z. B. SASL-Authentifizierung wird erst nach der Verschlüsselung verfügbar, der EXTERNAL-Mechanismus ist nur für lokale Sockets oder Verbindungen verfügbar, die ein Zertifikat bereitstellen).

Verbindungsstatus

als Mermaid

stateDiagram
    state "TCP/SCTP connection established" as Establish
    state "TCP/SCTP connection closed" as Closed
    Open
    SASL
    Authenticated
    STARTTLS
    Encrypted

    Establish --> Open:open
    
    Open --> Closed:close

    Open --> SASL:auth
    SASL --> SASL:step
    %% Authentication fails
    SASL --> Closed:fails
    %% Authentication succeeds
    SASL --> Authenticated:successful

    Open --> STARTTLS:starttls
    %% TLS wrapping succeeds
    STARTTLS --> Encrypted:successful
    %% TLS wrapping fails
    STARTTLS --> Closed:fails

    Authenticated --> SASL_TLS:starttls
    SASL_TLS --> Closed:fails
    SASL_TLS --> AuthEnc:successful

    Encrypted --> TLS_SASL:auth
    TLS_SASL --> TLS_SASL:step
    TLS_SASL --> Closed:fails
    TLS_SASL --> AuthEnc:successful

    %% Only authenticated connections may open RPC. For "unauth", use the `Anonymous` SASL method.
    AuthEnc --> RPC:bootstrap
    Authenticated --> RPC:bootstrap

Andere Stati (Cluster Kommunikation BFFH und Aktoren)

als Mermaid

graph

    subgraph First[Cluster internal state]
        start((BFFH))
        created(Machine object created)
        start --> created

        created -- New state or loaded from disk --> attach
        attach[Attach actor]
        unapplied(Unapplied)
        applied(Applied)
        verified(Verified)

        wait_apply[Wait ∀ Actors]
        wait_verify[Wait ∀ Actors]

        unapplied --> wait_apply
        wait_apply --> applied
        applied --> wait_verify
        wait_verify --> verified

        applied -- statechange received --> unapplied
        verified -- statechange received --> unapplied
        unapplied -- statechange received --> unapplied

        unapplied --> attach
        attach --> unapplied
        applied --> attach
        attach --> unapplied
        verified --> attach
        attach --> unapplied
    end


    subgraph Second[cluster actor]
        actor_start((Actor))
        actor_fresh(Actor was just constructed)
        actor_start --> actor_fresh

        actor_attached(Attached)
        actor_unapplied(Unapplied)
        actor_applied(Applied)
        actor_verified(Verified)

        wait_initial[Recv]
        wait_state[Recv]

        actor_fresh --> wait_initial
        wait_initial --> actor_attached

        actor_attached -- initialize/apply --> actor_applied
        actor_unapplied -- apply --> actor_applied
        actor_applied -- verify --> actor_verified

        actor_unapplied --> wait_state
        actor_applied --> wait_state
        actor_verified --> wait_state

        wait_state --> actor_unapplied
    end

    attach -. Send initial state to that actor .-> wait_initial
    unapplied -. Send new state to all actors .-> wait_state
    actor_applied -. Confirm apply .-> wait_apply
    actor_verified -. Confirm verify .-> wait_verify

Hinweis: Die Mermaid-Diagramme sind mit https://mermaid.live gerendert und als PNG exportiert und hier importiert worden, da BookStack keinen integrierten Mermaid Renderer besitzt.

Grundkonzepte

Abhängigkeiten von Ressourcen

FabAccess unterstützt die Verwaltung von Ressourcenabhängigkeiten. Dabei werden automatisch Claims auf Ressourcen an die Nutzer vergeben, die eine Ressource beanspruchen, die von einer anderen abhängt.

Die abhängige Ressource kann zusammen mit der anderen Ressource zurückgegeben werden. Auch die Zustände der Traits werden bei abhängigen Ressourcen berücksichtigt. Auf diese Weise kann verhindert werden, dass Ressourcen wie Absaugungen oder Kühlungen ausgeschaltet werden, wenn die Ressource, die diese benötigt, noch aktiv ist.

Dieses Konzept ist auch als "Primary-Secondary" oder "Master-Slave" bekannt.

Grundkonzepte

Aktoren (Actors) und Initiatoren (Initiators)

Um FabAccess erweiterbar zu halten, basiert die Steuerung externer Geräte wie Wifi-Schaltsteckdosen oder Türschlössern auf einem Aktoren- und Initiatorenkonzept.

Aktoren (Actors)

Aktoren in FabAccess haben die Aufgabe, die digitalen Zustände von Ressourcen in reale Zustände umzusetzen. Vom Server aus werden die Übergänge der Traits (Zustände) an kleine Skripte oder Prozesse weitergegeben, die entsprechend darauf reagieren.

Aktoren erhalten vom Server Mitteilungen über Änderungen an Ressourcen, beispielsweise wenn eine Ressource ausgeliehen wird, und passen dann den realen Zustand der Ressource an. Dadurch wird die Ressource für Nutzer freigeschaltet / eingeschaltet. Darüber hinaus ermöglichen Aktoren die Steuerung zusätzlicher Anzeigen wie Maschinenampeln oder Displays.

Aktoren werden in der Hauptkonfiguration bffh.dhall definiert und an Ressourcen (Maschinen) gebunden (Mapping actor_connections).

Initiatoren (Initiators)

Initiatoren sind STDOUT/Prozess-basierte Plugins. Mit Initiatoren werden reale Zustände auf die digitalen Zustände in FabAccess abgebildet. Initiatoren sind Plugins, die den Status einer Ressource aktiv verändern können, also zum Beispiel von Free auf InUse setzen. Sie fungieren sozusagen als Callbacks. Die Auslösevents (Trigger) sind in der Regel asynchron, von der App entkoppelt und lösen automatisiert aus.

Initiatoren werden in der Hauptkonfiguration bffh.dhall definiert und an Ressourcen (Maschinen) gebunden (Mapping init_connections).

Beispiele

Mit Initiatoren können im einfachsten Fall fest definierte Initialzustände an Ressourcen übersendet werden, nachdem BFFH neugestartet wurde - zum Beispiel für einen täglichen "Werkstattreset". So können u.a. bestimmte Dinge automatisch ein-/ausgeschalten bzw. in einen klar definierten Ausgangszustand versetzt werden. Ein Beispiel dafür findet sich in Initiator: Generisches Python-Template für "Process".

Initiatoren ermöglichen auch Zeitschaltungen für die automatische Rückgabe von Ressourcen, wenn sie nicht mehr verwendet werden (z.B. wenn Stromverbrauch für mehrere Minuten unterhalb eines Verbrauchsschwellwerts, dann MQTT-Nachricht versenden und Ressource freigeben). Eine Beispielimplementation findet sich in Initiator: Shelly Timeout.

Türkontakte, die den aktuellen Zustand der Tür übertragen können, können ebenso als Initiator geschrieben werden und BFFH kann dann entsprechend darauf reagieren.

Sammlung von Aktoren und Initiatoren

Eine Sammlung von Initiatoren und Aktoren ist hier zu finden.

Grundkonzepte

Audit Log (Revisionsprotokoll)

Interaktionen und Ergebnisse der Verwendung von Ressourcen werden protokolliert, um sie später auswerten zu können - zum Beispiel im Fehlerfall, in der Schadensaufklärung oder für die Abrechnung der Nutzung (Nutzungsgebühren).

Über das Audit Log File

Das Audit-Log leitet alle Änderungen an Ressourcen vom Server aus weiter. Über selbst geschriebene Plugins kann man diese Informationen nutzen, um z.B. Abrechnungen zu erstellen oder Maschinenzeiten grafisch auszuwerten. Diese Funktion bietet auch Möglichkeiten für eine detaillierte Analyse und Optimierung der Maschinennutzung.
Als zusätzliche Option können eigene Prozesse an die API gebunden werden. Diese ermöglichen einen direkten Zugriff auf die Funktionen des Servers über die API und eröffnen die Möglichkeit für Massenänderungen oder die zeitgesteuerte Zuweisung von Rollen.

Beim Erzeugen von Vorratsdaten ist stets dabei darauf zu achten, nur die minimal notwendigen Daten zu speichern und auszuwerten, um die Privatsphäre der Nutzer zu schützen und das Vertrauen nicht zu verletzen. FabAccess ist hier sehr sparsam und schreibt generisch je Ereignis eine Zeile im JSON-Format. Der Zeitstempel ist dabei im Unix-Format:

{"timestamp":<UNIX Zeitstempel>,"machine":"Ressourcen-ID","state":"<Status> <Benutzer>"}

Bffh protokolliert Zustandsänderungen in der Audit-Log-Datei (der Pfad wird über auditlog_path in der Konfigurationsdatei (*.dhall) festgelegt). Ausschnitt einer Beispiel Log File:

{"timestamp":1726239904,"machine":"Fokoos","state":"inuse local_lab_admin"}
{"timestamp":1726239905,"machine":"Fokoos","state":"free"}
{"timestamp":1726239932,"machine":"Ender","state":"inuse local_lab_admin"}
{"timestamp":1726239933,"machine":"Ender","state":"free"}
{"timestamp":1726240081,"machine":"Ender","state":"inuse local_lab_admin"}
{"timestamp":1726240088,"machine":"Ender","state":"free"}
{"timestamp":1726240112,"machine":"Mjolnir","state":"inuse local_lab_admin"}
{"timestamp":1726240122,"machine":"Mjolnir","state":"disabled"}
{"timestamp":1726240125,"machine":"Mjolnir","state":"disabled"}
{"timestamp":1726240126,"machine":"Mjolnir","state":"blocked local_lab_admin"}
{"timestamp":1726240128,"machine":"Mjolnir","state":"free"}
{"timestamp":1726240132,"machine":"Mjolnir","state":"inuse local_lab_admin"}
{"timestamp":1726240134,"machine":"Mjolnir","state":"free"}
{"timestamp":1726240139,"machine":"BashMachine","state":"inuse local_lab_admin"}
{"timestamp":1726240141,"machine":"BashMachine","state":"free"}

Parsing mit JQ

sudo apt install jq

Allgemeines Parsen

jq . /var/log/bffh-audit.json

{
  "timestamp": 1727110784,
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": 1729189184,
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": 1729189186,
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

UTC Timestamps

Parsen mit allgemeingültiger UTC-Zeitstempelformatierung:

{
  "timestamp": "2024-09-23T18:59:44 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": "2024-10-17T20:19:44 CET",
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": "2024-10-17T20:19:46 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

Mit lokaler Zeitzone

Oder zum Beispiel mit der Zeitzone Europe/Berlin:

TZ=Europe/Berlin jq '.|.timestamp |= strflocaltime("%Y-%m-%dT%H:%M:%S %Z")' /var/log/bffh-audit.json

{
  "timestamp": "2024-09-23T18:59:44 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": "2024-10-17T20:19:44 CET",
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": "2024-10-17T20:19:46 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

oder noch lesbarer durch Umstellen des Formats:

TZ=Europe/Berlin jq '.|.timestamp |= strflocaltime("%d.%m.%Y %H:%M:%S Uhr")' /var/log/bffh-audit.json

{
  "timestamp": "08.12.2024 00:57:27 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "free"
}
{
  "timestamp": "08.12.2024 00:57:29 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "inuse Admin"
}
{
  "timestamp": "08.12.2024 00:57:30 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "free"
}

Zum Parsen und Patterns testen empfehlen wir das Online-Tool https://jqplay.org

Grafische Darstellung des Audits und Auswertung

Für die Dashboard-Anzeige in Grafana können die Werkzeuge Alloy und Loki verwendet werden.

Achtung: Das Parsen des Audit Logs ist nur so lange zuverlässig, wie das Log nicht gelöscht oder rotiert wird. Für eine Langzeitarchivierung und eine tiefergehende Analyse von Statistiken sollte u.U. in Betracht gezogen werden den Audit in einer Datenbank zu speichern, z.B. PostgreSQL oder MariaDB. Mit Hilfe einer Datenbank könnten dann tiefergreifende Auswertungsabfragen programmiert werden, die sich dann wiederrum z.B. in Grafana grafisch auswerten und exportieren ließen, oder aber für die Abrechnung genutzt werden könnten. Es sollte auch beachtet werden, dass immer größer werdende json-Dateien sich nicht mehr performant parsen lassen, um darüber akkumulierte Gesamtstatistiken zu erzeugen.

Statistiken aus dem Audit gewinnen

Statistikabfragen könnten z.B. sein:

Wer nutzt den Space bzw. bestimmte Ressourcen am meisten oder wenigsten?
Welche Ressourcen werden generell am häufigsten genutzt?
Welche Ressourcen werden generell am längsten genutzt?
wer nutzt am meisten Dinge im Space gleichzeitig?
Wann ist der Space in Nutzung und wann ruht er?
wieviele Maschinenstunden kommen pro Tag, Woche, Monat, Jahr zusammen?

Log Rotation

Sind Log Files zu groß, werden sie in der Regel "rotiert" und in Archiven komprimiert, um Speicher zu sparen. Folgende Konfiguration kann angewendet werden. Wir heben maximal 10 als *.gz komprimierte Log-Archive auf. Die Logs werden automatisch rotiert, wenn sie 1 Megabyte überschreiten.

sudo vim /etc/logrotate.d/bffhd

/var/log/bffh/audit.json 
{
	rotate 10
	size 1M
	copytruncate
	missingok
	notifempty
	compress
}

Logs manuell rotieren (testen)

sudo logrotate /etc/logrotate.d/bffhd -f

Weitere Links

Siehe auch Aktor: Logger (CSVlog)

Grundkonzepte

Ausleihen and Transfer

Um die soziale Interaktion im Space zu fördern, ermöglicht FabAccess das Weitergeben von Claims. Benutzer können somit Ressourcen direkt an andere Benutzer weitergeben oder diese zum Zwecke der Ausbildung an andere Benutzer verleihen (englisch: "lending").

Diese Funktionen ermöglichen eine flexible Nutzung der Ressourcen und fördern die Zusammenarbeit zwischen den Benutzern. Zum Beispiel kann ein Benutzer, der eine Ressource nicht mehr benötigt, diese einem anderen Benutzer übertragen, der sie gerade benötigt, oder ein Ausbilder kann einem Auszubildenden vorübergehend Zugriff auf eine Ressource gewähren, um bestimmte Fähigkeiten zu erlernen.

Durch diese Funktion kann die soziale Interaktion über FabAccess nachverfolgt und unterstützt werden.

Grundkonzepte

Auswahl Programmiersprache und Framework für BFFH

Dieses Dokument basiert auf dem ADR-Commit https://gitlab.com/fabinfra/fabaccess/bffh/-/commit/a62a5678dc35cb32c899483cfab48ce218694d11 und wurde ins Deutsche übersetzt.

Der technische Hintergrund: Entscheidung über die zu verwendende Programmiersprache und das Framework für BFFH / den Backend-Code von FabAccess

Kontext und Problemstellung

Programmiersprachen-Diskussionen sind das perfekte Thema für einen Fahrradausflug. Unabhängig davon muss irgendwann eine Entscheidung getroffen werden, damit die Leute anfangen können, Code zu schreiben und allgemein nützlich zu sein. Da FabAccess als Projekt mit mehreren potenziellen Entwicklern und noch mehr Beteiligten, die am Erfolg der Software interessiert sind, gestartet wurde, war diese Diskussion besonders pikant. Die entsprechenden Diskussionen fanden im Zeitraum von etwa November 2019 bis März 2020 statt.

Entscheidungstreiber

Verfügbare Entwickler, sowohl kurz- als auch mittelfristig, sollte das Projekt ein erfolgreiches Standbein für deutsche/europäische/irdische Makerspaces werden
Einstiegshürde für neue/zusätzliche Entwickler.
Tooling-Unterstützung, insbesondere für Nicht-Entwickler (Dokumentation, einfache Selbstkompilierung, ...)
Bibliotheksunterstützung / Ökosystem in der Problemdomäne
Bestehende Projekte, die erweitert werden könnten, um das Rad nicht noch einmal zu erfinden
Sprachliche Merkmale

Geprüfte Optionen

Python
TypeScript
Rust
Erlang
Ruby
Haskell

Entscheidungsergebnis

Gewählte Option: „Rust“, weil das Projekt schließlich größtenteils von FabInfra entwickelt wird, dessen Kosten-Nutzen-Analyse der Typensicherheit Vorrang vor der Entwicklungsgeschwindigkeit einräumt.

Positive Konsequenzen

Die Typsicherheit von Rust ist im Vergleich zu allen anderen Optionen mit Ausnahme von Haskell sehr hoch
Eine einzige statisch gelinkte Binärdatei mit sehr wenigen Abhängigkeiten macht die Bereitstellung trivial
Kompilierte Software nahe an Baremetal ermöglicht den Betrieb des Servers auf leistungsschwacher Hardware wie Raspberry Pis, selbst bei mittelgroßen Einsätzen.

Negative Konsequenzen

Die Geschwindigkeit der Entwicklung leidet kurzfristig. Rust ist eine Sprache mit niedrigerem Niveau als alle anderen evaluierten Optionen und erfordert mehr Denkarbeit und Entwicklerzeit, um Funktionen auf hohem Niveau zu implementieren.
Der verfügbare Entwicklerpool ist klein und teuer. Rust ist keine gute Einstiegssprache und für Entwickler, die keine Erfahrung mit C++ haben, vergleichsweise schwer zu erlernen. Es können zwar Entwickler eingestellt werden, aber die Gehaltsvorstellungen von Rust-Entwicklern sind im Vergleich zu Python/Java hoch.
Kleines Ökosystem / wenige Bibliotheken. Rust ist eine sehr junge Programmiersprache und verfügt, obwohl sie seit mehreren Jahren als die beliebteste Sprache auf stackoverflow.com eingestuft wird und kommerziell genutzt wird, über weniger Bibliotheken als die meisten anderen Optionen. Die Unterstützung für z.B. LDAP ist nicht ausgereift. Aber die Problemdomäne von FabAccess liegt in dem Bereich, für den Rust die meiste Unterstützung hat.

Vor- und Nachteile der Optionen

Python

Gut, weil großer verfügbarer Entwicklerpool
Gut, weil ein großer Teil der an der Entwicklung interessierten Entwickler Erfahrung mit Python hat
Gut, weil Python leicht zu erlernen ist und eine gute Einstiegssprache darstellt
Gut, weil Python über umfangreiche Bibliotheksunterstützung und ein auf Automatisierung ausgerichtetes Ökosystem verfügt
Schlecht, weil vergleichsweise langsam. Langsamste oder zweitlangsamste Option in Betracht.
Schlecht, weil die hochdynamische Typisierung und die mittelmäßige statische Analyse dazu führen können, dass Edgecase-Fehler lange Zeit verborgen bleiben
Schlecht, weil Python wenig Kontrolle über den Absturzprozess bietet. Das Abfangen von Exceptions ist sehr grob.

TypeScript

Gut, weil stärkere Typisierung als bei Python und Ruby
Schlecht, weil interpretierte Sprache und zwar schneller als Ruby/Python, aber immer noch viel langsamer als die kompilierten Optionen.
Schlecht, weil das Node.js Ökosystem groß ist, aber nicht so sehr auf Automatisierung auf niedriger Ebene ausgerichtet ist.

Rust

Gut, weil Rust ein gutes Typensystem hat, das es erlaubt, viele Fehler und Abstürze durch die in den Compiler eingebaute statische Analyse zu verhindern.
Gut, weil Rust-Code sehr effizient ist.
Gut, weil viele Leute sehr daran interessiert sind, Rust zu lernen und ihnen nur ein Grund dafür fehlt.
Schlecht, weil die Geschwindigkeit der Entwicklung langsamer ist als bei den meisten anderen Optionen.
Schlecht, weil nur ein Entwickler in der Gruppe Erfahrung mit Rust hat.
Schlecht, weil der verfügbare Entwicklerpool klein ist.

Erlang

Gut, weil speziell für hochverfügbare, absturzsichere Software entwickelt
Gut, weil es ein extrem feinkörniges Absturzsystem mit gekapselten Prozessen bietet, die sich nicht gegenseitig ausschalten können
Gut, weil das Ökosystem und die Bibliotheken von Erlang generell auf die Problemdomäne von FabAccess ausgerichtet sind
Gut, weil Erlang im Vergleich zu TypeScript, Pyton und Ruby eine umfangreiche statische Analyse ermöglicht
Schlecht, weil Erlang ein schlechteres Typsystem hat als Rust und Haskell.
Schlecht, weil nur ein Entwickler in der Gruppe Erfahrung mit Erlang hat.
Schlecht, weil der Entwicklerpool der zweitkleinste ist.

Haskell

Gut, weil das stärkste Typensystem viele Fehler und Abstürze durch die im Compiler integrierte statische Analyse verhindern kann
Schlecht, weil nur ein Entwickler Erfahrung mit Haskell hat.
Schlecht, weil der Entwicklerpool am kleinsten ist.

Cache (Zwischenspeicher)

In FabAccess gibt es eine Unterscheidung zwischen statischen und dynamischen Daten, die von Ressourcen besessen werden.

Dynamische Daten umfassen Zustände oder Messwerte, die von Ressourcen erzeugt werden.

Statische Daten hingegen sind Eigenschaften, die sich nicht regelmäßig ändern, sondern nur in größeren zeitlichen Abständen. Diese statischen Daten werden in FabAccess zwischengespeichert, um die Antwortzeiten des Servers zu reduzieren und Ressourcen in Clients schneller anzeigen zu können.

Hinweis: Das Konzept zu Cache exitiert zwar, jedoch gibt es noch keine Spezifikation!

Grundkonzepte

Claims, Notify und Interest (das Konzept vom "Anspruch erheben")

Das Konzept von Claims dient als Abstraktion des Verleihens einer Ressource in FabAccess. Ihr Hauptzweck besteht darin, die Möglichkeiten zu verwalten, wie Benutzer Zugriff auf eine Ressource erhalten und diesen Zugriff untereinander teilen können bzw. wie Maschinen voneinander abhängig gemacht werden. Sie vereinfachen den Ausleihprozess für den Space und dessen Nutzer. Claims enthalten sog. "Interests" und "Notifies".

Zum Beispiel kann konfiguriert werden, dass eine Bandsäge nur angeschalten werden kann, wenn auch die Absaugung an ist oder der Laserschneider nur einschaltbar ist, wenn die Kühlung aktiv ist.

Claim (Anspruch erheben)

Ein "Claim" in FabAccess repräsentiert den gewährten Zugriff auf eine Ressource.

Die Flexibilität von Claims ermöglicht es, verschiedene Szenarien des Ressourcenzugriffs effektiv zu unterstützen. Zum Beispiel können mehrere Benutzer gleichzeitig einen Claim für eine Ressource erhalten, was besonders in Umgebungen mit kollaborativem Arbeiten von Vorteil ist. Darüber hinaus bietet die Möglichkeit, sich in eine Warteschlange mit einem Interest einzutragen, eine praktische Lösung für Situationen, in denen die Verfügbarkeit einer Ressource begrenzt ist und Benutzer darauf warten müssen, darauf zugreifen zu können.

in weiterer wichtiger Aspekt von Claims ist ihre Fähigkeit, Ressourcen zwischen Benutzern zu transferieren oder auszuleihen. Diese Funktionen ermöglichen eine flexible Nutzung der Ressourcen und fördern die Zusammenarbeit zwischen den Benutzern. Zum Beispiel kann ein Benutzer, der eine Ressource nicht mehr benötigt, diese einem anderen Benutzer übertragen, der sie gerade benötigt, oder ein Ausbilder kann einem Auszubildenden vorübergehend Zugriff auf eine Ressource gewähren, um bestimmte Fähigkeiten zu erlernen.

Interest (Interesse anmelden)

Ein wichtiger Bestandteil des Claims-Konzepts sind "Interests", die Reservierungen abbilden, die entweder zeitbasiert oder auf einer Warteschlange basieren können. Diese Interessen bieten den Benutzern die Möglichkeit, einen zukünftigen Zugriff auf eine Ressource zu sichern, entweder basierend auf einer vordefinierten Zeit oder in der Reihenfolge des Eintritts in die Warteschlange.

Mit einem Interest signalisiert der Nutzer dem System sein Interesse an einer bestimmten Ressource. Bei der nächsten Gelegenheit erhält der Nutzer entweder einen Claim auf die Ressource oder hat die Möglichkeit, seinen Interest auf einen Claim zu aktualisieren. Diese Flexibilität ermöglicht es den Benutzern, ihre Bedürfnisse anzupassen und auf Änderungen in der Verfügbarkeit der Ressourcen zu reagieren.

Notify (Benachrichtigen)

Das letzte Element des Claims-Konzepts ist der "Notify". Durch den Notify können Nutzer den Status einer Ressource einsehen und sich über Änderungen benachrichtigen lassen.

Der Notify ermöglicht es Benutzern, den aktuellen Zustand einer Ressource abzurufen und bei Bedarf auf Änderungen zu reagieren. Dies bietet eine wichtige Möglichkeit, den Zustand von Ressourcen zu überwachen und zeitnah auf relevante Ereignisse zu reagieren.

Durch die Möglichkeit, sich für Benachrichtigungen über Zustandsänderungen zu registrieren, können Benutzer effektiv mit den Ressourcen interagieren und sicherstellen, dass sie stets über wichtige Entwicklungen informiert sind.

Grundkonzepte

Datenbank-Konzept (LMDB)

FabAccess BFFH nutzt derzeit eine auf Datenbank auf Dateibasis. Hierzu bedient es sich der Rust-Implementierung lmdb_rs für die original in C geschriebene LMDB (Lightning Memory-Mapped Database). Das ist eine eingebettete transaktionale Datenbank in Form eines Key-Value-Speichers.

BFFH schreibt in die Datenbank zwei wesentliche Informationsspeicher:

users: Benutzerdatenbank (Nutzernamen, Passwörter, Cardkeys, Rollenzuweisungen)
states: Ressourcenzustände

Wichtig zu wissen: 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.

Grundkonzepte

Federation (Föderation)

FabAccess ist als selbstständiges selbstgehostetes System für jeden Space gedacht, so können die Spaces selber über das komplette System verfügen und es eigenständig bis in kleinste Detail konfigurieren. Um die Zusammenarbeit von Spaces zu ermöglichen und zu fördern, können die einzelnen FabAccess Instanzen (BFFH) mit einander föderieren. Dadurch können Nutzer zwischen diesen Spaces mit verringertem Verwaltungsaufwand hin und her wechseln. Wir wollen so die Spezialisierung von Spaces ermöglichen, ohne dass Nutzer die Vorteile eines vollausgestatten Spaces verlieren. Auch kleineren Spaces wird so der Einstieg vereinfacht.

Föderation ist dabei als aktive Zusammenarbeit erdacht, also müssen sich die Betreiber dieser Spaces dazu entscheiden zu föderieren. Jeder Space kann so den Partner für die Föderation selber wählen.

Der FabAccess Client Borepin ist bereits insofern für Föderation ausgelegt, als dass er mehrere Serveradressen und Benutzer speichern kann. So ist ein Wechsel zwischen verschiedenen Spaces und/oder Nutzermodellen praktisch möglich.

Vorteile und Ziele der Föderation

beliebiger Wechsel der Nutzer verschiedener Spaces trotz technisch getrennter FabAccess-Instanzen
Zusammenarbeit von Spaces unterstützen - durch Teilen von Berechtigungen ihrer Nutzerschaften
FabAccess verbreiten, ähnlich wie das Matrix Chat-Protokoll dies mit Kommunikation macht
kann langfristig dabei helfen, Maschinendokumentationen und Maschineneinweisungen (Maschinenführerscheinen) zu vereinheitlichen
Spart NFC Karten (FabFireCards) ein, denn die Karten können dann in alle föderierten Spaces genutzt werden
Mit Föderation is theoretisch auch das Bilden von standortübergreifenden Clustern möglich, also eine Art Filialbildung (das ist ein wertungsfreier Fakt)
ist dabei als aktive Zusammenarbeit erdacht: die Betreiber der Spaces können sich selbst entscheiden, ob sie föderieren wollen. Föderation ist also immer optional und kann zudem jederzeit wieder deaktiviert werden

Modi oder Stufen der Föderation

Die folgenden Stufen bauen aufeinander auf, so können sich Betreiber einfacher an eine Föderation wagen und die Vorteile mit jeder Stufe erfahren.

1. Stufe (Authentifizierung: Teilen von Nutzern)

- Nutzer aus anderen Spaces können ihre FabFireCard auch in deinem Space verwenden
- Die Nutzer sind auch in deinem Space registriert
- Der föderierte Space übernimmt die Authentifizierung für den anderen Nutzer (wie bei SSO)

Unter dem Teilen von Nutzern verstehen wir, dass Nutzer von Space B bei dir im Space A sich mit der FabFireCard aus Space B authentifizieren können. Um bei dir im Space A die Maschinen nutzen zu dürfen, müssen die Nutzer aus Space B sich bei dir anmelden und deinen Nutzungsvertrag ausfüllen. Da die Nutzer aus Space B FabAccess schon kennen, werden Sie sich selbstständig registrieren und du musst nur nach einer kurzen Prüfung der Daten diese Nutzer akzeptieren. Dabei erhältst du immer die Kontaktdaten deiner Nutzer und bist nicht auf die Nutzerdaten des anderen Spaces angewiesen, sollte bei dir mal ein Unfall passieren. Die Authentifizierung der Nutzer übernimmt dann die BFFH Instanz des Space B. Um nicht immer mit jedem Space sofort aktiv föderieren zu müssen, ermöglichen wir es dir auch das Teilen von Nutzern für unbekannte Spaces zu erlauben. So kannst du nach einer aktiven Föderation mit dem anderen Space gleich die Nutzerdaten übernehmen, um so nicht noch mal alle Nutzer anzupassen. Bei einer Föderation sind nämlich die IDs der Nutzer in den beiden Spaces gleich und ermöglichen den nächsten Schritt in der Föderation.

2. Stufe (1. Stufe ergänzt um Teilen von Berechtigungen)

- Nutzer aus anderen Spaces können ihre FabFireCard und ihre Gruppen auch in deinem Space verwenden
- Die Nutzer sind auch in deinem Space registriert
- die Gruppen des anderen Space können in deinem Space verwendet werden, wenn zum Beispiel die gleichen Maschinen im Besitz sind. Das spart Zeit bei der Einweisung und der Dokumentation.

Nach dem das Teilen von Nutzern erfolgt ist und du sich mit dem Betreiber des Space B gut verstehst, stellt ihr beide fest, dass ihr einige gleiche Maschinen in euren Spaces besitzt. Da du dem Betreiber von Space B auch bei den Einweisungen von den Maschinen vertraust, könnt ihr in der 2. Stufe auch Berechtigungen teilen. Somit müssen Nutzer von Space B, die bei dir die gleiche Maschine wie im Space B verwenden wollen, von dir nicht noch mal eingewiesen werden. Das spart Zeit bei dir und bei den Nutzern von Space B. Du behältst dabei die Kontrolle, welche Gruppen von Space B bei dir im Space A welche Maschinen nutzen können, somit kannst du dir sicher sein, dass die Nutzer wirklich eingewiesen sind.

3. Stufe (2. Stufe ergänzt um Teilen von Abrechnungen)

- Nutzer aus anderen Spaces können ihre Karte und ihre Gruppen auch in deinem Space verwenden
- Die Abrechung für diese Nutzter übernimmt dabei der andere Space für deinen Space. Über beispielsweise monatlich gesammelte Differenzrechnungen kann gegen den andere Spacecs abgerechnet werden. Das spart Zeit bei der Buchführung und die Nutzer können auch Ihre Rechnungen besser im Blick behalten.

Das Teilen von Abrechnungen stellt die letzte Stufe der Föderierbarkeit da. Da wir uns bei dem Thema noch nicht vollständig sicher sind, inwieweit das umgesetzt werden kann, steht es noch in Klammern. Die Idee zu der Föderation ist, dass Nutzer von Space B, die bei dir eine kostenpflichtige Maschine nutzen, ihre Abrechnung von Space B erhalten und nicht von dir. Das Geld der Nutzer von Space B kannst du dann mit dem Betreiber von Space B zum Beispiel monatlich verrechnen. Der Vorteil für den Nutzer liegt dabei darin, dass sie nicht bei jedem Space ihre Abrechnung machen müssen, sondern gesammelt bezahlen können.

Entwurf für einen Lastenfahrradverleih - Ablaufbeispiel "DEMOKrAtIS"

Wie sicher ist Föderation?

Föderation benötigt Vertrauen, jedoch möchten wir nicht, dass dieses Vertrauen einfach missbraucht werden kann. Daher ist der oben beschriebene Ansatz, dass du jeden deiner Nutzer auch kennst.

Sicherheit des Servers

Für den Austausch von Benutzern und Berechtigungen ist ein sicherer Datenaustausch über das Internet notwendig. Das bedeutet auch, dass ein Dienst Ziel eines Angriffs von außen sein kann. Sobald der Dienst auf einem geöffneten Port lauscht, muss sichergestellt sein, dass nur authorisierte Server bzw. Personen darauf Zugriff haben und keinen Missbrauch begehen. Daraus ergeben sich verschiedene Fragen und Anforderungen, wie zum Beispiel

erfolgt der Informationsaustausch zwischen den föderierenden Servern auf dem gleichen Port oder gibt es hierfür z.B. eine https-verfügbare API (z.B. REST, Json, XML RPC, ...)?
wie wird das Verhalten gemonitored und Schadverhalten abgewehrt (z.B. Greylisting, Blacklisting, DDoS Vermeidung, Bruteforce-Login Attacken, Fail2Ban Jails, Firewall-Regeln...)
welche APIs sind unterinander kompatibel? Nicht jeder Space wird schnell genug seinen Server auf die aktuelle Version updaten können
Wie isolieren wir den FabAccess-Server ausreichend gegen Angriffe von außerhalb? Immerhin hat bffh Zugriff auf physische Geräte durch das Schalten von Strom an Aktoren

Sicherheit von FabFire Karten

Um die Authentifizierung sicher zu gestalten, haben wir uns für die etwas teureren NXP MIFARE DESFire EV2 Karten entschieden (ca. 1-5 € pro Karte bzw. Tag). Diese haben den Vorteil, dass sie ein Ende-zu-Ende (E2EE) Verfahren unterstützen und bisher als ungehacked gelten. Somit musst Du nicht die Schlüssel deiner Karten an jeden Reader in einem anderen Space verteilen, sondern deine BFFH Instanz kommuniziert verschlüsselt direkt mit der Karte. Auf den FabFireCards befinden sich auch keine Informationen der Nutzer, sondern nur der DNS-Eintrag deines Space sowie eine pseudonymisierte Nutzer ID. Somit wollen wir die technische Seite der Föderation absichern und eine Zusammenarbeit möglichst einfach gestalten.

Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Die DESFire-Karte besitzt ein Feature, mit dem eine Karte via OTA-Verfahren (Over-the-Air) direkt mit einem entfernten Server kommunizieren kann, ohne dass der Reader Schlüssel für die Karte benötigt. Der Reader übernimmt dabei nur die Rolle eines Proxys (Brücke/Vermittler). Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.

Das föderative Verfahren für FabFire Karten wurde in folgendem Grobschema veröffentlicht:

Fragen und Ansprüche an Föderation und potentielle Probleme

muss stabil sein
es muss sicher sein (siehe oben)
Benutzer und Berechtigungen anderer Spaces können sich ändern. Nutzer könnten dem Space nicht mehr angehören. Wie halten wir den Informationsstamm ausreichend aktuell?
es müssen verschiedene Server-/API-Versionen interoperabel funktionieren
es braucht eine Whitelist bzw. ggf. sogar Blacklist für alle Spaces, die für FabAccess nutzbar sein sollen
Vertrags-, Datenschutz- und Haftungsfragen: ist die Übertragung der Nutzerdaten an andere Spaces geregelt, und wenn ja, wie? Welche vertraglichen Regeln müssen für eine Föderation mit FabAccess festgehalten werden?
Föderierte Spaces arbeiten ggf. sehr unterschiedlich, was Maschineneinweisungen und Co. angeht - wie kann sichergestellt werden, dass dazu übergreifende Standards geteilt werden?

Stand der Föderation

Das Feature Föderation ist aktuell (Stand Dezember 2024) noch nicht in der beschriebenen Art nutzbar in FabAccess implementiert. Ein direkter Datenaustausch zwischen mehreren BFFH-Servern findet nicht statt und es gibt auch kein zentrales Server-Register.

Möglich ist bereits im Borepin Client das Speichern von verschiedenen Verbindungsprofilen (Serveradressen + Kombination Nutzer/Passwort) unterschiedlicher Spaces.

Wer nutzt heute schon FabAccess?

Potentielle Nutzer für FabAccess-Föderation findest du unter Mitmachen / Unterstützen / Join the Community

Grundkonzepte

Measurements (Messwerte)

Durch "Measurements" in FabAccess werden Daten von Ressourcen gesammelt, um deren Leistung und Nutzung zu erfassen. Das Ziel ist es, dass FabAccess diese Messwerte sammelt und an die Nutzer weitergibt.

Die Funktion Measurements ermöglicht es FabAccess, wichtige Daten über die Nutzung von Ressourcen zu erfassen und den Nutzern zur Verfügung zu stellen. Dies umfasst Informationen wie Betriebsstunden, Auslastung und andere Leistungsindikatoren, die es den Nutzern ermöglichen, die Effizienz und Produktivität ihrer Arbeitsprozesse zu optimieren.

Hinweis: Das Konzept zu Measurements exitiert zwar, jedoch gibt es noch keine Spezifikation!

Grundkonzepte

RBAC (Benutzerrollen und Berechtigungen)

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.

Das Berechtigungssystem ermöglicht es, die Zugriffe auf Ressourcen nur für bestimmt Nutzer zu erlauben. Somit kann darüber die Einweisungen für gefährliche Ressourcen abgebildet werden. Auch die Abbildungen von einfachen Ressourcen, die keine Einweisung benötigen, ist möglich.

Berechtigungsübersicht

Die Resourcen haben folgende Berechtigungen, die zugewiesen werden und dem Nutzer folgendes ermöglichen:

disclose (offenlegen)
die Resource über die API zu entdecken, also in einer Liste zu erhalten. Mit dieser Berechtigung können Nutzer die Ressource in der Übersichtsliste der App sehen. Ohne diese Berechtigung wird die Ressource in der Liste nicht angezeigt.

read (lesen)
statische Informationen aus der Resource erhalten. Diese Berechtigung ermöglicht es Nutzern, Informationen zur Ressource abzurufen. Dazu gehört das Auslesen des aktuellen Zustands der Ressource und das Lesen weiterer Informationen wie Wiki-Links. Es ist wichtig zu beachten, dass ein Nutzer ohne disclose, aber mit read, die Ressource dennoch auslesen kann. Diese Funktion kann z.B. durch QR-Codes auf der Ressource als Präsenzfunktion genutzt werden.

write (schreiben)
Die write-Berechtigung ermöglicht es einem Nutzer, die Ressource zu verwenden. Auch das Ändern von Zuständen der Ressource wird dadurch möglich.

manage (verwalten)
einen claim zu überschreiben. Mit dieser Berechtigung kann die Ressource verwaltet werden. Ein Nutzer mit dieser Berechtigung kann eine verwendete Ressource freigeben oder als defekt markieren.

Nicht implementierte Berechtigungen

Folgende Berechtigungen sind konzipiert, aber aktuell nicht implementiert:

notify (benachrichtigen)
Notify aufrufen, um statische Informationen zu erhalten

claim (Anspruch erheben)
Die Resource leihen und Traits auszuführen

transfer (transferieren)
Die Resource an einen anderen Nutzer weitergeben

lend (ausleihen)
Die Resource an andere verleihen, die nicht die Berechtigung haben die Resource zu verwenden

Grundkonzepte

Plugins

Die modulare Struktur von FabAccess benötigt Plugins, um das System an die Bedürfnisse des Spaces anzupassen. Plugins ermöglichen die Erweiterung der Grundfunktionen von FabAccess und die Integration zusätzlicher Features, ohne dass die Kompatibilität des Kernsystems beeinträchtigt wird.

Plugins können an folgenden Hauptstellen eingesetzt werden:

Grundkonzepte

Projekte

"Projects" in FabAccess sollen die Zusammenarbeit zwischen den Nutzern fördern und gleichzeitig die Abrechnung von Ressourcennutzungszeiten verbessern. Ein wichtiger Aspekt der Projektstruktur ist die Möglichkeit für Nutzer, Claims innerhalb desselben Projekts miteinander zu teilen, um gleichzeitig auf Ressourcen zugreifen zu können.

Durch die Zuweisung von Nutzern zu Projekten können Teams effizient zusammenarbeiten und ihre Ressourcen optimal nutzen. Das Teilen von Claims innerhalb eines Projekts ermöglicht es den Teammitgliedern, nahtlos auf benötigte Ressourcen zuzugreifen und gemeinsam an Projekten zu arbeiten. Darüber hinaus erleichtert diese Funktionalität die Abrechnung von Ressourcennutzungszeiten, da die Nutzung der Ressourcen innerhalb eines Projekts besser nachverfolgt und zugeordnet werden kann.

Hinweis: Das Konzept zu Projekten exitiert zwar, jedoch gibt es noch keine Spezifikation!

Grundkonzepte

Terminals

Terminals in FabAccess bieten einen eingeschränkten Zugang zum Server. Diese Terminals können nur auf die ihnen zugewiesenen Ressourcen zugreifen und haben die Möglichkeit, Ressourcen an andere Benutzer auszuleihen.

Aufgrund ihrer eingeschränkten Zugriffsrechte sind Terminals ideal für die Authentifizierung in FabFire. Durch die Verwendung von Terminals als Authentifizierungsmethode können Benutzer sicherstellen, dass nur autorisierte Personen auf die Ressourcen zugreifen und diese nutzen.

Die Verwendung von Terminals zur Authentifizierung bietet eine zusätzliche Sicherheitsebene und hilft, die Integrität des Systems zu wahren. Darüber hinaus ermöglicht es eine effiziente Verwaltung der Ressourcennutzung, indem der Zugriff nur autorisierten Benutzern gewährt wird.

Unsere eigene Terminal-Implementierung nennt sich FabReader und verwendet dafür Mifare DESFire EV2 Karten.

Grundkonzepte

Externe Authentifikation

Das Authentifizieren in FabAccess basiert vollständig auf SASL und unterstützt daher verschiedene Mechanismen.

Die Rollen, die aus den Gruppen bei LDAP und OAuth abgeleitet werden, werden additiv zu denen betrachtet, die intern in FabAccess vergeben werden.

Authentifikation per KeyCloak

Das folgende Tool nutzt Keycloak im Zusammenhang mit FabReadern und umgeht die eigentlich FabAccess-Funktionalität. Ggf. hilft dieses Projekt jedoch weiter bei der eigenen Systemintegration: https://gitlab.com/sfz.aalen/infra/fabaccess

Authentifikation per OAuth

In Entwicklung seit 10/2024 - Ansprechpartner: Jonathan Krebs

Authentifikation per LDAP

In Entwicklung seit 10/2024 - Ansprechpartner: Jonathan Krebs

Es besteht keine native LDAP Integration. Es gibt jedoch Tools zum Importieren von LDAP-Benutzern in die bffh-Datenbank. Siehe LDAP Anbindung.

Authentifikation per FabFire

FabFire ist eine Entwicklung, die auf NXP Mifare DESFire basiert und die Anwendung von Karten nutzt, um Benutzer über das OTA (Over the Air)-Verfahren zu authentifizieren.

Grundkonzepte

Nutzerverwaltung

Die Nutzerverwaltung ermöglicht es, den Überblick über die Nutzer im Space nicht zu verlieren. FabAccess ist als SmartCard System gedacht, somit erhält jeder Nutzer eine NXP Mifare DESFire (FabFireCard) Karte, um sich an der Ressource zu authentifizieren.

Um den administrativen Aufwand zu verringern, können sich Nutzer selbstständig anmelden und können dann nach der Prüfung der Daten durch den Betreiber freigeschaltet werden. Die Schließung eines Nutzungsvertrages wird dabei abgebildet.

Mit der FabFireCard können Nutzer sich sowohl an den Ressourcen authentifizieren als auch an unserem Client Borepin.

Grundkonzepte

Sensoren

Sensoren sind abstrahierte Datengeneratoren, die es BFFH ermöglichen, Ereignisse mit dem in der realen Welt auftretenden Verhalten zu verknüpfen und Entscheidungen darauf zu gründen. Ziel ist das regelmäßige Abfragen von Sensordaten, die dann für Folgeentscheidungen weiterverarbeitet werden können.

Das Konzept der Sensoren ist aktuell nur als Draft in einem Ticket formuliert, aber bis auf einen leeren Unterodner im bffh-Projekt nicht implementiert

Zweck

Insbesondere bei Abhängigkeiten und ähnlichem ist es wichtig, dass sich Ressourcen in einem bestimmten (gemessenen) Zustand befinden und nicht nur von ein und derselben Person genutzt werden. Sensoren ermöglichen solche Muster, indem sie z.B. einer Pumpe erlauben, BFFH mitzuteilen, dass sie die Nennleistung erreicht hat oder dass sie damit aufgehört hat, oder einem 3D-Drucker, der BFFH mitteilt, dass der aktuelle Druckauftrag beendet ist.

Limitierungen

BFFH arbeitet nur mit abgetasteten Ereignissen und hat keine Vorstellung von absoluter oder gar quantifizierbarer Zeit. Ereignisse können in Relation zueinander geordnet werden, aber die Zeit zwischen zwei Ereignissen ist nicht bestimmbar. Daher macht es absolut keinen Sinn, das reaktive Ereignisnetz, das den Kern des BFFH bildet, für Histogramme oder ähnliche Messungen zu verwenden. Stattdessen sollten die Sensoren so weit wie möglich zusammengefasste Daten liefern, die sofort für die Entscheidungsfindung verwendet werden können. So ist z.B. „Kühlpumpe hat Nennleistung erreicht“ gut, „Kühlpumpe fördert 12l/min“, die jede Sekunde zurückkommt, nicht.

Grundkonzepte

Zustände (Traits)

Traits bieten die Möglichkeit, den Zustand von Ressourcen zu ändern. Ressourcen können mehrere Traits besitzen und diese kombiniert nutzen. Mit Traits erhalten Nutzer Zugriff auf die Ressource, nachdem sie einen Claim erhalten haben. Dabei können Traits verwendet werden, um Ressourcen aus bestehenden Traits zusammenzusetzen oder spezifische Traits zu implementieren. Um eine optimale Anzeige der Traits für Nutzer in Clients zu ermöglichen, kann einer Ressource ein "Hint" hinzugefügt werden. Dieser ermöglicht es einem Client, eine verbesserte Ansicht der Ressource für Nutzer zu generieren.

Traits und OIDs

Traits werden anhand einer OID (Object Identifier) bereitgestellt. Die OID-Struktur von FabAccess folgt dem Schema:

1.3.6.1.4.1.61783.612.1.2
              │    │  │ │
  RLKM UG PEN ╯    │  │ │
                   │  │ │
 FabAccess subtree ╯  │ │
                      │ │
               Traits ╯ │
                        │
               Doorable ╯

Für das Projekt wurde eine gesonderte Private Enterprise Numer (PEN) bei IANA auf "FabInfra" registiert. Das feste PEN-Präfix lautet 1.3.6.1.4.1. Die PEN-Nummer für RLKM lautet 61783 (Siehe https://www.iana.org/assignments/enterprise-numbers/?q=61783.). Das Projekt FabAccess hat eine fest vergebene Unternummer 612. Danach folgt die Unterklasse 1 (Traits) und dann die möglichen Zustandsnummern (Enumeration) 0 ... 5 (z.B. Doorable, Locatable, ...).

In älteren Versionen der API wurde die PEN 48398 genutzt ("Paranoidlabs").

Die OID-Bezeichner werden in der Zustandsdatenbank abgespeichert. Siehe auch Datenbeispiel eines Dumps.

Übersicht über die vorhandenen Traits und OIDs

In FabAccess gibt es bereits vordefinierte Traits für grundlegende Funktionen, mit denen viele Zustände von Ressourcen abgebildet werden können.

FabAccess-API

Aktuell ist diese API in Verwendung. Siehe https://gitlab.com/fabinfra/fabaccess/fabaccess-api

In diesem API-Modell gibt es nur die folgenden 7 Zustände (Traits) von 0 bis 6:

0: Free - eIne Ressource frei verfügbar für Nutzer mit Zugriff machen
1: InUse:<UserId> - eine Ressource durch einen Nutzer "In Benutzung" setzen
2: ToCheck:<UserId> - eine Ressource auf "muss überprüft werden" setzen (z.B. ob Reinigung nach Benutzung notwendig ist) - Achtung: Dieser Zustand kann nur über die API und nicht über Client genutzt werden (weil nicht implementiert. Siehe auch eine Ressource bedienen)
3: Blocked:<UserId> - eine Ressource blockieren (z.B. weil die Maschine defekt ist)
4: Disabled - eine Ressource deaktivieren (z.B., weil die Ressource zum aktuellen Zeitpunkt zu laut wäre und deshalb die Benutzung verboten ist)
5: Reserved:<UserId> - eine Ressource für die spätere Nutzung vorreservieren - Achtung: dieser Zustand kann aus dem Borepin Client nicht gesetzt werden (Siehe auch eine Ressource bedienen), jedoch im Process Aktor und im Python Process Actor Template schon
6: totakeover - eine Maschine von einem anderem Nutzer übernehmen - Achtung: dieser Zustand ist weder in BFFH, noch im Process Aktor, noch im Python Process Actor Template implementiert. Dieser Zustand existiert aktuell nur in der API-Beschreibung.

Neben den definierten Zuständen gibt es auch die Möglichkeit, direkte Rohdaten zu liefern:

Raw:<data> - Ressourcen können bei Statuswechsel auch direkt mit Binärdaten versorgt werden, um zum Beispiel spezielle Operationen wie das Übersenden einer STL-Datei an einen 3D-Drucker zu erlauben

Die API verwendet in einen OID-Wert (value) 1.3.6.1.4.1.48398.612.2.4 vom OID-Typ (type) 1.3.6.1.4.1.48398.612.2.14 für den Zustand (state) im Allgemeinen.

Prodable

Kommt vom englischen Wort "prodded" und bedeutet soviel wie "anstubsen". Ein Prodable ist also etwas Anstubsbares. Das lässt sich im Sinne einer Ereignisschleife verstehen, in der eine Sache die Möglichkeit hat, etwas zu tun. Wird im BFFH Server verwendet - es findet Nutzen beim FabLock. Dort hat es den Zweck vor dem Öffnen eines Schließfachs in einem Spind mit mehreren Fächern vorher kurz eine LED aufleuchten zu lassen, die signalisiert, wo genau sich das Fach befindet.

Prodable protokollieren keine Ressourcennutzung durch einen Nutzer.

Der Prodable Trait existiert namentlich so in der neuen C# API nicht mehr - er wurde in Locatable umbenannt. Weiterhin gibt es spezialisierte Traits Doorable für Eingangstüren und Lockers für Schließfächer.

FabAccess-API-cs

Diese API Version ist aktuell noch nicht in Verwendung. Siehe https://gitlab.com/fabinfra/fabaccess/fabaccess-api-cs

Claimable (OID 1.3.6.1.4.1.61783.612.1.0)

Der Trait "Claimable" stellt einen Sonderfall dar, da er dazu dient, dass sich ein Nutzer über den Claim-Zustand einer Ressource informieren kann.

Nutzer können auf diesem Trait keine Aktionen ausführen, sondern lediglich den Zustand abfragen.

Powerable (OID 1.3.6.1.4.1.61783.612.1.1)

"Powerable" ist der grundlegendste Trait, den FabAccess unterstützt. Er dient dazu abzubilden, ob eine Ressource eingeschaltet bzw. mit Strom versorgt ist.

Doorable (OID 1.3.6.1.4.1.61783.612.1.2)

Der Trait "Doorable" ermöglicht die Abbildung von Türen oder anderen Schließsystemen. Dabei besteht die Möglichkeit, kurzzeitige Öffnungen zu realisieren. Die genaue Zeitdauer, für die die Ressource geöffnet wird, wird dabei vom Server bestimmt.

States

als Mermaid

stateDiagram
    [*] --> CLOSED
    CLOSED --> OPEN: unlock
    OPEN --> CLOSED: lock
    CLOSED --> tempOPEN: unlocktemp
    tempOPEN --> OPEN: unlock
    tempOPEN --> CLOSED: lock
    tempOPEN --> CLOSED: AUTO

Checkable (OID 1.3.6.1.4.1.61783.612.1.3)

Der komplexere Trait "Checkable" ermöglicht die Abbildung von Ressourcen, die nach der Benutzung überprüft werden müssen. Bei einer Überprüfung durch einen berechtigten Nutzer kann die Ressource entweder für alle wieder freigegeben oder zurückgewiesen werden. Falls die Ressource zurückgewiesen wurde, kann der ursprüngliche Nutzer die Ressource weiterhin verwenden oder erneut zur Überprüfung einreichen, nachdem die Fehler behoben wurden.

States

als Mermaid

stateDiagram
    [*] --> FREE
    FREE --> INUSE: use
    INUSE --> CHECK: giveback
    CHECK --> FREE: accept
    CHECK --> REJECTED: reject
    REJECTED --> INUSE: use
    REJECTED --> CHECK: giveback
    REJECTED --> FREE: accept

Lockers (OID 1.3.6.1.4.1.61783.612.1.4)

"Lockers" ist einer der komplexeren Traits, mit dem Schlösser von Ressourcen genauer abgebildet werden können. Der Nutzer kann die Ressource nicht in jedem Zustand zurückgeben; erst wenn alles korrekt zurückgegeben wurde, kann die Ressource auch wieder gesperrt werden.

Die Zustandsänderungen zwischen den vom Nutzer verwendbaren Übergängen können von einem Initiator herbeigeführt werden.

States

als Mermaid

stateDiagram
    [*] --> locked
    locked --> unlocked: unengage
    unlocked --> locked: engage
    unlocked --> open: AUTO
    open --> unengaged: AUTO
    unengaged --> locked: engage
    unengaged --> open: AUTO

Locatable (OID 1.3.6.1.4.1.61783.612.1.5)

Der Trait "Locatable" ermöglicht die Identifizierung von Ressourcen, wie beispielsweise Schließfächer oder 3D-Drucker in einer Druckerfarm. Dabei kann entweder eine kurzfristige Identifikation abgegeben werden oder die Identifizierung dauerhaft gesetzt werden.

Hinweis: Die Mermaid-Diagramme sind mit https://mermaid.live gerendert und als PNG exportiert und hier importiert worden, da BookStack keinen integrierten Mermaid Renderer besitzt.

Grundkonzepte

URL und URN

Ressourcen in FabAccess werden durch einen Namen dargestellt. Um jedoch die Suche nach Ressourcen zu verbessern, können diese Referenzen als URN (Uniform Resource Name) oder URL (Uniform Resource Locator) geschrieben werden.

Die URN ist ein Identifikator ohne Bezug zum Space, während die URL auch den Space referenzieren kann, um einen Austausch von Ressourcen zu ermöglichen.

Genutzte Schemata in FabAccess

Folgende URN Schemata werden in FabAccess verwendet:

von FabFire genutzte URNs:
- Space Name: urn:fabaccess:lab:{spacename}
- Space Info: urn:fabaccess:lab:{spacename}\x00{instanceurl}
  - dieser Wert wird aktuell nicht verwendet, muss jedoch ausgefüllt werden, damit die Konfiguration bffh.dhall valide ist!
Ressourcen (Maschinen): urn:fabaccess:resource:{machine id} (ideal für QR Codes).
Hinweis: für das Scannen von NFC Tags kann stattdessen das folgende Schema verwendet werden (kompatibel sind z.B. Mifare NTags):
fabaccess://{spacename}/resource/{machine id}. Siehe auch Ressourcen per NTag scannen