Archiv der Kategorie: Allgemein

Code Refresh beim Zugangskontrollsystem und Containerisierung

Veröffentlicht am von
Antworten

Was in letzter Zeit passiert ist

Die letzten Wochen habe ich nun dazu genutzt das Zugangskontrollsystem etwas zu überarbeiten. Nicht die interne Codebasis, aber das drum herum.
Zum einen werden die Einzelteile immer mehr in Container Images (Docker) gepackt. Dies wird zukünftig dabei helfen, die Skalierbarkeit zu verbessern und auch die Ausfallsicherheit weiter zu erhöhen. Der Schritt ist noch nicht entgültig abgeschlossen aber ich bin auf einem guten Weg.

Dieser Schritt hat nun vorausgesetzt, die aktuelle FEIG SDK (Generation 2) (OBIDISC4J v5.6.3) zu verwenden. Leider haben wir ja gelernt, dass die aktuellste Generation 3 der SDK nicht mehr (oder auch noch nicht) verschlüsselt mit dem RFID Leser kommuniziert. Das folglich ein Ausschlußkriterium darstellt für den Betrieb als Zugangskontrollsystem.
Also bleiben wir vorerst auf der Generation 2 des SDKs.

Weiterhin setze ich nun Java 17 ein, da es im Docker Container doch deutlich besser performt und weniger Speicherprobleme hat als die älteren Java Versionen. Das hatte aber zur Folge, alle bislang vewendeten Java Extensions (javax Klassen) zu den Neuen (jakarta Klassen) zu migrieren (Danke Oracle).
Das war zum Glück nicht so aufwändig und konnte ohne größere Schwierigkeiten erledigt werden. Hier hing dann aber auch der gesamte Build-Prozess dran und da musste ich auch noch einiges gerade rücken. So ist das eben mit dem „Rattenschwanz“.
Vorteil ist, ich bin wieder up-to-date mit den Maven Repos und der Build-Prozess ist nun ausgelagert in eine Azure DevOps Pipeline.

Docker

Allgemein

Nicht alle Probleme kann man mit Docker lösen, aber es gibt uns durchaus Möglichkeiten einige der Probleme in den Griff zu bekommen.
Zum einen wird das „Shipping“ einfacher, da alles im besagen Container liegt was für die Laufzeit benötigt wird. Die FEIG Bibliotheken sind ja „closed source“ und die Java Libraries sind nur Wrapper rund um diese Linux Bibliotheken die im System zu installieren sind. Das macht es schwer die Software „mal eben schnell“ wo anders einzusetzen.
Zum anderen, wenn nun aber alles in handliche Päckchen (Container Images) gepackt wurde, kann man eben mal die Version tauschen und ratzfatz zurückrollen. Was Upgrades deutlich einfacher macht und auch wenn man mal die Hardware darunter tauschen möchte.

ACS Tag-Manager

Hier plane ich auch bereits seit längerem den ACS TAG Manager umzubauen. Diese Anwendung ist dafür verantwortlich, die RFID Tags zu beschreiben. Die Kernfunktionalität soll hier zukünftig als REST API in einem Docker Container laufen. Das Ganze mit API first Ansatz mt der aktuellen OpenAPI Spezifikation.
Das wird es deutlich einfacher machen, die Kommunikation zwischen Anwendung und RFID TAG zu abstrahieren.
Am Ende steht dann die Integration in den ACS-Manager. Diese Anwendung ist in PHP geschrieben und würde die REST API verwenden, um die Tags direkt aus der Management Anwendung heraus zu beschreiben.

Aber bis dahin ist es noch ein langer Weg. Kurzfristig muss nun die zentrale ACS-Server Komponente erfolgreich in den Docker Container gepackt werden, damit ist dann schon viel gewonnen.

Docker Basiscontainer

2021 hatte ich versucht mit Alpine Linux als Basiscontainer zu arbeiten. Damals noch mit OpenJRE 11. Dort scheiterte es dann erst an der FEIG Bibliothek v4 (Gen 2) und danach an einer nicht kompatiblen libc Bibliothek. Daher musste ich auf Debian als Basis ausweichen mit dem Upgrade auf die FEIG Bibliothek v6 (Gen 3).
Dann kam allerdings die Gen 3/Gen 2 Thematik und das Fehlen der Verschlüsselung was mich so frustrierte, dass ich dann zunächst nicht weiter daran gearbeitet habe.

Nun, 2 Jahre später, versuche ich mal einen Neuanfang. Zunächst auf Basis Debian. Problem ist hier aber, dass der Debian Container schon so viele ungepatchte Sicherheitslücken enthält, dass ich da ein ungutes Gefühl habe, dass so zu betreiben.
Allerdings darf man sich da nichts vor machen, denn wenn man Debian auch so als OS laufen hat, hat man ja auch die selben Lücken. Aber beim Containerbau hat man ja so schicke Tools, die einem das gleich zeigen. Bei einer Bare-Metal Installation fällt das ja erst mal nicht auf.

Wichtig ist aber erstmal, dass es überhaupt funktioniert, dann kann man sich um die Optimierung kümmern. Da fallen mir schon noch Dinge dazu ein. Man könnte z.B. die Teile löschen die eine Sicherheitslücke haben (soweit diese nicht benötigt werden) oder rman nähert sich doch von Alpine Linux und versucht die fehlenden Dinge zu integrieren.

Stand der Containerisierung

Die einzelnen Bestandteile des Zugangskontrollsystems haben folgenden Stand was die Containerisierung angeht:

KomponenteStand
ACS ServerContainerisiert (aber ungetestet)
ACS ManagerContainerisiert
ACS Tag Manageroffen
ACS Pushover ServiceContainerisiert
REDISContainerisiert
LDAPContainerisiert
MQTTContainerisiert
ACS, Stand der Containerisierung

Die Homepage WG

Veröffentlicht am von
Antworten

Seit 2 Wochen komme ich etwas zur Ruhe und habe mir endlich die Zeit genommen meine Homepages zu konsolidieren. Besser gesagt habe ich die Inhalte der Homepages:

  • Cybcon Industries
  • Oberdorf IT-Consulting
  • Cybcon’s Blog

nun in einer Homepage vereinigt. Nach langem hin und her habe ich mich dazu durchgerungen den WordPress Blog „Cybcon’s Blog“ als neue Heimat für die bestehenden Inhalte zu verwenden. Der Blog ist nun im Menü unter „Cybcon’s Blog“ zu finden, die anderen Inhalte sind größten Teils die Inhalte meiner Oberdorf IT-Consulting Seite. Diese wird auch das Erscheinungsbild hier verändern bzw. hat das bereits getan, da es sich ja um den gewerblichen Teil handelt der gewisse Anforderungen erfüllen muss.

Aber der Blog wird weiter bestehen mit allen alten (und hoffentlich auch neuen) Inhalten.

FEIG Java SDK v3 noch immer ohne Cryptofunktion

Veröffentlicht am von
1

Nachdem ich letztes Jahr angefangen habe mit dem Java SDK v3 preview (Version 6.0.0-rc3) meine Software zu migrieren stockte es ja an der fehlenden Authentisierung zum Leser. Leider musste ich nun 1 1/2 Jahre später feststellen, dass Version 6.2.0 noch immer keine Authentisierung zum Leser unterstützt.

Ticket bei FEIG ist offen – mal sehen wie die Antwort aussieht.

Nachtrag

Zwischenzeitlich gab es Feedback von FEIG. Aktuell gibt es keinen Zeitplan für die Re-Implementation des Features. Es wird auf die Verwendung von SDKv2 verwiesen.

Da dieses SDK nicht im Container läuft (so war jedenfalls das Ergebnis meiner Tests), geht die Entwicklung hier wieder schlafen.

ACS Manager endlich verfügbar

Veröffentlicht am von
Antworten

Allgemein

Nach sehr stockender Entwicklungszeit ist nun endlich das Webfrontend zur Verwaltung der Transponder, Benutzer, Rollen und Regeln fertig gestellt. Ein paar Funktionen fehlen noch aber für die tägliche Arbeit sollte es zunächst mal ausreichen.

Screenshot der Transponderverwaltung

Funktionsumfang

  • Benutzer: Hinzufügen, Löschen und Bearbeiten von Benutzern.
    Wichtig sind die Pflege der zentralen Informationen eines Benutzers. Auch werden die dem Benutzer zugeordneten Transponder aufgelistet, die durch Klick auf das Symbol einfach deaktiviert werden können. Jeder Benutzer können eine oder mehrere Rollen zugeordnet werden.
  • Transponder: Aktivieren und Deaktivieren von Transpondern. Pflege der Benutzerzurdnung.
  • Rollen: Definition von Rollen mit einem beschreibenden Text.
  • Regeln: Regeln können den Zugang einschränken. Folgende Regeln werden unterstützt:
    • Zugang innerhalb von Datumsgrenzen
    • Zugang innerhalb von Uhrzeitgrenzen
    • Zugang nur an geraden/ungeraden Kalenderwochen (Pflege eines Teilers und eines Offset)
  • Zugangspunkte: Verknüpfung von Rollen und Regeln.
  • Monitor: Anzeige der Zugangsversuche und ob dieser erfolgreich war oder abgelehnt wurde.

Gesamtarchitektur

Mit dem ACS Manager (und dem darin eingebetteten Access Monitor) schließt sich nun die Lücke in der Gesamtarchitektur.
Hinzugekommen sind außerdem ein Pushover Gateway, welches sich auf die Statusmeldungen im MQTT subscribed und die Nachrichten versendet. Sowohl ACS Manager als auch Pushover Gateway laufen als Docker Container.

Gesamtarchitektur

Offene Punkte im ACS Manager

Bislang wird das Codieren der Transponder über die Weboberfläche nicht unterstützt. Daher ist das Management der Transponder noch in einem frühen Stadium.

Next Steps

Die Containerisierung soll weiter vorangebracht werden, da ich hierdurch eine hohe Flexibilität als auch eine saubere Verwaltung der Infrastruktur mit Container Boardmitteln hinbekomme.
Das ist die Fortführung aus dem letztes Jahr begonnen Code Refresh, der leider Mitte letzten Jahres eingeschlafen ist. Allerdings fehlt hier nicht mehr so viel, um den Server komplett mit der neuen Feig Java Bibliothek am Laufen zu haben. Letztes Jahr fehlte ja noch Unterstützung für die SSL Verschlüsselung zwischen Leser und Server. Ich hoffe, dass dies zwischenzeitlich implementiert ist. Nach dem Code Refresh ist der nächste Schritt die Containerisierung des Servers und der komplette Umzug auf Docker.

Danach werde ich mich an die Neuentwicklung des Tag Managers machen. An Stelle des lokal laufenden Java Programms, soll ein Webbasierter REST Microservice als Herzstück eingesetzt werden um mit dem Leser zu kommunizieren. Die Programm und Ablauf Logik wird dann in den ACS Manager integriert werden (jedenfalls so der Plan).

Blog kaputt – Blog wieder da

Veröffentlicht am von
Antworten

Nach einem ungeplanten Ausfall meines Blogs bin ich seit heute wieder online. OK, mir war klar, dass PHP 5 outdated war und dass es früher oder später keine Updates mehr gibt. Aber dass die Updates der Plugins funktionieren mir dann diese den Dienst verweigern, daran hatte ich nicht gedacht.

Zum Glück war ich eh dabei die Seite umzuziehen, nun war es etwas ruppig aber immerhin, der Blog läuft wieder und die Daten konnte ich auch alle retten. Alles schick auf WordPress 6 und PHP8.

MQTT mit Eclipse Mosquitto

Veröffentlicht am von
Antworten

Zwischenzeitlich läuft das Zugangssystem stabil. In der Zwischenzeit sind einige Umstellungen erfolgt:

  • Umstellung auf Maven für die Java Builds
  • Veröffentlichung einiger OpenSource Artefakte auf Maven Central
  • Installation eines neuen Docker Hosts
  • Installation eines Eclipse Mosquitto MQTT Servers (als Docker Container)

Den MQTT Server hatte ich ursprünglich für die geplante IoT Infrastruktur (mit ESP8266 und ESP32 basierten Sensoren – hier werde ich auch berichten sobald die ersten Sensoren in Betrieb gehen) installiert. Ich habe diesen auf einem alten Raspberry Pi 1 Model A aufgesetzt als Docker Container.

Für das User Management System hatte ich bereits länger geplant einen Access Monitor geplant. Dieser sollte die letzten Zutritte visuell darstellen. Also wer hat wann zuletzt einen Zugang angefragt und wie war der Status dazu. Hier soll unter anderem auch ein Bild des Benutzers kommen angezeigt werden das aus dem LDAP Server geladen wird.

Ich hatte lange überlegt wie man einen solchen Monitor implementieren könnte. Vorallem wie dieser die Daten übermittelt bekommt.

Mit MQTT ist die Sache nun relativ einfach. Das Zugangskontrollsystem muss nur den Status eines Zutritts in einen Topic des MQTT Servers Publishen. Der Zutrittsmonitor subscribed auf diesen Topic und erhält so alle notwendigen Informationen zur Visualisierung.

Für den Publish der Nachricht aus dem Zugangskontrollsystem verwende ich nun den Eclipse Paho Java Client. Die Bibliothek war unkompliziert zu integrieren.
Der Zutritts Monitor ist eine Webanwendung. Für den subscripe verwende ich aktuell Eclipse Paho JavaScript Client. Dieser war etwas Tricky, denn das Beispiel auf der Seite hat bei mir nicht funktioniert.

Folgender JavaScript Sourcecode führte dann zum Erfolg:

<head>
<script>
  // configuration
  var mqtt;
  var reconnectTimeout=2000;
  var host="myMQTTServer";
  var port=9001;
  var clientId="oitc-acs-monitor";
  var topic="/oitc-acs"

  // called when the client connects
  function onConnect()
    {
    // Once a connection has been made, make a subscription and send a message.
    console.log("Successfully connected to " + host + ":" + port);
    console.log("Subscribing to topic " + topic);
    mqtt.subscribe(topic);
    }

  // called when a message arrives
  function onMessageArrived(message)
    {
    // console.log(message.payloadString);
    obj = JSON.parse(message.payloadString);
    console.log(obj);

    }

  function MQTTconnect()
    {
    console.log("Try to open connection to " + host + ":" + port);
    mqtt = new Paho.MQTT.Client(host,port,clientId);
    mqtt.onMessageArrived = onMessageArrived;
    // Valid properties are: timeout userName password willMessage
    //                       keepAliveInterval cleanSession useSSL
    //                       invocationContext onSuccess onFailure
    //                       hosts ports mqttVersion mqttVersionExplicit
    //                       uris
    var options = {
      timeout: 3,
      userName: "acsMonitorUser",
      password: "myUsersPass",
      keepAliveInterval: 60,
      useSSL: true,
      onSuccess: onConnect,
      mqttVersion: 3,
      };
    mqtt.connect(options);
    }
</script>
</head>
<body>
<script>
MQTTconnect();
</script>  
</body>

Wenn die Seite lädt, verbindet sich die Webanwendung mit dem MQTT websocket und subscribed den topic. Da die Nachrichten „retained“ vom Zugangskontrollsystem gesendet werden, wird auf jeden Fall der letzte Zugriff im JavaScript consolen Log angezeigt. Bei weiteren Zugängen erscheinen diese ebenfalls im Log.

Die nächsten Schritte sind nun die Anzeige auf der HTML Seite. Ich werde hier mit jQuery arbeiten um mir das Leben etwas einfacher zu machen. Einen ersten Prototypen habe ich bereits am Laufen. Die nächste Herausforderung ist nun, das Bild der Person noch aus dem LDAP Server zu laden. Ich werde berichten, sobald ich hier wieder ein Stück weiter gekommen bin.

Abschließend noch das aktuelle Architektur Schaubild:

Zugangskontrollsystem Version 2

Veröffentlicht am von
Antworten

Auslöser

Das System lief sauber durch, der Watchdog den ich entwicklet hatte, hat auch seine Arbeit getan. Als wir in Urlaub gingen hatten wir unseren Nachbarn ebenfalls Transponder gegeben. Das System funktionierte bis 3 Tage vor unserer Rückkehr aus den USA.

Seitdem verliert der Server die Verbindung zum Leser. Was auch immer geschah oder wie auch immer es geschah konnte ich bislang nicht ermitteln. Auch lässt sich der Javaprozess nicht mehr starten ohne dass der Prozess sich gleich wieder beendet.

Nun all das hat mich nun bewogen darüber nachzudenken die Plattform zu wechseln.

Plattformwechsel für Version 2

Der proof of concept aus Version 1 war durchaus erfolgreich. Allerdings bin ich mit der Lösung auf dem Raspberry 1 nicht so ganz zufrieden. Folgende Gründe sprechen für einen Plattformwechsel:

  • Die Firma FEIG ELECTRONIC GmbH unterstützt aktuell nur den Raspberry 1 (ARMv6) alle Bemühungen, die ARMv7 Treiber auf dem Raspberry 2 zum Laufen zu bringen, scheiterten bislang.
  • Die Raspberry Treiber (ARMv6) haben bis heute keine Möglichkeit verschlüsselt mit dem Leser zu kommunizieren. Der Bug wurde bereits 2015 gemeldet. Bislang gibt es hier allerdings keine Lösung.
  • Der Raspberry 1 hat leider nur 512 MB Ram, dies hat von Anfang an zu Engpässen geführt.
  • Es gibt beim Raspberry bekannte Probleme mit längeren Laufzeiten, wenn das Betriebssystem auf einer SD-Karte liegt. Das ist zwar schick, aber SD-Karten sind ja für häufige Schreibzyklen nicht ausgelegt.
  • Um Filesystemcrashes bei Stromausfall vorzubeugen kommt die PiUSV zum einsatz. Die Firma CW2 hat allerdings Konkurs angemeldet was bedeutet man müsste sich hier nach einer Alternative umsehen.
  • Das Gehäuse für den Server ist custom made. Ein professionelles, maßgeschneidertes Gehäuse erstellen zu lassen ist relativ teuer (im Vergleich zu den restlichen Komponenten)
  • Die bislang verwendeten Komponenten (PiUSV und PiFaceDigital2) sind sehr Raspberry spezifisch.

Das scheinbar größte Problem für mich war eine vernünftige Alternative für das Relayboard (PiFace) zu finden. Es sollte möglichst Betriebssystem unabhängig sein und mit Java ansteuerbar sein.

Nach einigen recherchen wurde ich bei der Bulgarischen Firma Denkovi Assembly Electronics LTD fündig. Ich entschied mich für das Produkt: USB Four(4) Relay Output Module,Board for Home Automation v2 und orderte dies.
Der Versandt ging zügig und problemlos. Die mitgelieferten Tools funktionierten problemlos unter Windows. Allerdings gab es aktuell keine Beispiele für Java. Ich kontaktierte die Firma und bekam 2 Tage später ein Beispielpaket für Java, welches ich zerlegte und die für mich interessanten Bestandteile herauslöste.
Aktuell habe ich nun eine eigene Java Bibliothek erstellt, mit der ich das Relayboard steuern kann.

Nun brauche ich noch einen neuen Server, der folgende Eigenschaften haben sollte:

  • Passiv gekühlt
  • Klein und stromsparend
  • x86 Technologie (um ein „normales“ Linux darauf laufen zu lassen)
  • richtige Festplatte
  • 2 Ethernet Schnittstellen (um das Lesernetz und das Administrationsnetz zu trennen)
  • mind. 2 USB Ports besser 4
  • passendes Gehäuse

Ich habe mich für den „Low Energy Server v2“ (LESv2) der Firma Thomas-Krenn.AG entschieden. Den Server werde ich noch diese Woche bestellen.

Ich werde über die Entwicklung weiter in diesem Blog berichten.

BinTec RS353jw

Veröffentlicht am von
Antworten

Also gestern hatte ich wieder eine Überraschung erlebt. Ich war am Mittwoch Nachmittag auf der Suche nach einem günstigen Angebot für eine BinTec RS353jw und bin bei Klarsicht-IT fündig geworden. Nach einigem hin und her (man kann das Produkt dort nur als Gewerbetreibender bestellen) hat die Bestellung dann doch geklappt.

Erstaunlicherweise war die Firewall dann am Folgetag bereits bei mir im Haus. Das nenn ich mal spitzen Logistik!

Zum Einrichten der Firewall bin ich leider noch nicht gekommen. Plane ich aber für die nächsten Tage.

NXP DocStore – Account Request rejected

Veröffentlicht am von
Antworten

Gestern Nachmittag kam die erste Absage für den Zugang zum NXP DocStore (Mail, siehe unten).

Ich werde da mal an den Support schreiben, obwohl ich so langsam Zweifel habe ob mir die Doku noch etwas bringt. Denn ich bin kurz davor eine lauffähige Beta Version des Zugangskontrollsystems fertigzustellen.

Und wenn ich eine NDA unterschreibe, darf ich ja keine Details mehr veröffentlichen 😉

 

 

  DocStore
Dear Michael,

Your registration at NXP DocStore cannot be executed. The account will not be activated due to the rejection reason shown below:

we can´t approve registrations without valid NDA. If you feel you receive this message in error, please contact NXP by using the support email address mentioned below.

Kind regards,
The NXP DocStore Team
NOTE: This mail has been generated by the DocStore system, please do not reply directly to this mail, as it is not monitored. In case of questions or problems please contact DocStore Support.

BadgeMaker

Veröffentlicht am von
Antworten

Das Angebot zum BadgeMaker kam an.

Der Vertriebspartner in der Region ist wohl:

PP high tech e.K.
Goldenbühlstrasse 12
78048 Villingen-Schwenningen

www.pphightech.com

Und hier die Brutto Preise:

  • BadgeMaker Pro (alle add-ons drinnen) kostet: 1.069,81 Euro
  • BadgeMaker Base (+ encoding add-on) kostet: 1.035,30 Euro

Übersteigt leider ein wenig das Budget. Werde wohl daher selber programmieren müssen (bin da auch schon etwas weiter gekommen).