Archiv der Kategorie: ACS Allgemein

ACS Containerisierung

Veröffentlicht am von
Antworten

Wir sind aktuell dabei unsere Fenster im Haus zu tauschen, was dazu führte, dass wir die Wand am eingangsbereich neu machen mussten (Holz weg, richtig dämmen, verputzen, streichen).
Da wir von Anfang an den RFID Leser im Eingangsbereich nur „provisorisch“ installiert haben, habe ich mir nun ein schickes Edelstahlgehäuse anfertigen lassen.

Lesereinbau vorher/nachher

Der Leser war wärend der Zeit der Renovierung leider offline.

Reboot mit Problemen

Der Server für das Zugangskontrollsystem ist das Letzte Artefakt, das ich noch nicht Containerisiert habe. Ich habe zwar dran gearbeitete, aber es gab hier noch diverse Probleme und die Integrationstests haben letztlich auch gefehlt. Ich wollte dies in aller Ruhe im sommerurlaub mal angehen. einen alten gebrauchten Testrechner habe ich dafür auch schon installiert gehabt, aber zu diesem Zeitpunkt war das System nicht einsatzbereit.

Auf dem alten Rechner den Docker zum Laufen bringen klappt nicht, da das darunterliegende OS (Ubuntu 16.04 LTS) zu alt war für die Java Requirements. D.b. ich muss den Server komplett neu aufsetzen und ein „Schwenk“ zu einem Container wäre nicht so schnell machbar gewesen. Wäre aber wünschenswert, dann hätte man den Container einfach hin und her schieben können um den Server in Ruhe auf den neuesten Stand updaten zu können.

Aber da der Rechner ja eh schon unten war (aufgrund der Renovierungsarbeiten) wollte ich zumindest mal ein OS Update fahren um die ganzen aktuell anstehenden Patches in Ubuntu 16.04 LTS nachzuziehen. Dabei kam dann der Rechner nach dem Reboot nicht wieder hoch. Scheinbar hat nach der langen Uptime der Rechner (den LESv2 der Thomas Krenn AG) den Reboot nicht verkraftet. Fakt ist, es kommt kein Bild, keine Ausgabe, nichts.

Tja, da half dann nur noch Flucht nach vorne. Ich habe den kleinen alten Testrechner ein Intel NUC) in den Serverschrank gepackt und frisch das OS draufgepackt. Erst ein Ubuntu Server 24.04 LTS, und, aufgrund von Betriebsproblemen (siehe unten), einen Tag später ein Ubuntu Server 22.04 LTS.
Danach binnen 2 Tagen den ACS-Server als Container so fertig bekommen, dass er läuft und alle Funktionalitäten wieder abdeckt (Mail, Pushover, MQTT, Relais ansteuern).
Zwischenzeitlich läuft der Server sogar nicht priviligiert als NonRoot im readonly Modus, das war schon seit Anfang an ein Problem, dass ich aber im Laufe der letzten Tage lösen konnte.

Ubuntu Server 24.04 LTS und HID Devices mit MCP2200 Chipsatz

Ubuntu Server 24.04 LTS ist das aktuelle Ubuntu Betriebssystem. Daher war es naheliegend dieses auch zu verwenden. Ich verwende für das Öffnen der Türe aktuell ein per USB angeschlossenes Relaisboard (USB Relay Module 4 Channels, for Home Automation – v2) der Firma Denkovi Assembly Electronics LTD. Das Board verwendet einen MCP2200 Chip und gibt sich als HiD Device aus. In der Regel wird im Linux unter den Devices dann ein /dev/hidraw0 und ein /dev/usb/hiddev0 angelegt. Leider funktionierte das nur bis Ubuntu Server 22.04 LTS. In Ubuntu Server 24.04 LTS hat sich das System strikt geweigert das Relais so anzulegen wie ich es erwartet hätte. Leider habe ich nach 1 Tag udev Regeln anlegen dann aufgegeben und bin auf Ubuntu Server 22.04 LTS gegangen.

Das Verhalten muss ich bei Zeiten mal genauer untersuchen bzw. wenn es mir hier nicht gelingt eine Lösung zu finden eine Relais Alternative zu suchen. Denkovi hat hier ja diverse alternative Möglichkeiten. Ggf. switche ich ja zu einer IP basierten Lösung.

ACS Komponenten im Container

Es laufen alle Komponenten des Zugangskontrollsystems nun auf einem Container. Damit werden Migrationsszenarien deutlich einfacher werden. Die Java Komponenten laufen in einem Debian Basiscontainer mit JRE21. Alle anderen Komponenten basieren auf schlanken Alpine Basiscontainern.

Alle Container sind mit Trivy sicherheitsüberprüft. Alle erkannten Vulnerabilities werden im Buildprozess dann entsprechend behandelt.

KomponenteBasisStand
ACS ServerDebian + JRE21Containerisiert
ACS ManagerAlpine + Nginx + PHP 8.1Containerisiert
ACS Tag ManagerDebian + JRE21Containerisiert
ACS Pushover ServiceAlpine + Python 3.11Containerisiert
REDISAlpineContainerisiert
LDAPAlpineContainerisiert
MQTTAlpineContainerisiert
ACS, Stand der Containerisierung

Offene Punkte

  1. Hausinterne DNS Probleme in den Griff bekommen: Entweder die Namensauflösung im ACS Server anpassen (herkömmlich statt den Ubunt Standard mit resolverd) oder, da es ein generelles Problem ist, hier mal eine echte Lösung finden.
  2. Erhöhung der RFID Leser Sensitivität, durch Durchbrechen des Faradayschen Käfigs. Leider schirmt der Edelstahlkasten die elektromagnetische Strahlung sehr ab. Ich versuche heute mla mit der Flex den Käfig mit einem Schnitt zu unterbrechen.
  3. RFID Leser mit Ubuntu Server 24.04 LTS ans Laufen bringen (siehe oben).

    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

    Coderefresh

    Veröffentlicht am von
    Antworten

    Seit dem letzten Firmwareupdate hat sich nicht viel getan. Seit dem sind 2,5 Jahre vergangen und das System leistet anstandslos seinen Dienst ohne jegliche Ausfälle.

    Vor 3 Wochen habe ich begonnen den Quellcode nach Azure DevOps umzuziehen. Via Azure Pipelines werden nun die einzelenen Java Bibliotheken voll automatisiert gebaut.

    Vor 2 Wochen habe ich angefangen mich nun endlich um das Management System zu kümmern. Dieses wird als PHP WebAnwendung umgesetzt und als Docker Container bereitgestellt. Mit start dieses Projekts kam nun auch die Idee, die Java Anwendungen als Docker Container zur Verfügung zu stellen. Die ersten Tests mit der FEIG Bibliothek OBIDISC4J 4.8.0 waren allerdings nicht erfolgreich. Bei start des Tagmanagers (zur Initialisierung der RFID Medien) beendet dieses sich nach dem Start direkt mit einem Coredump. Ein Ad-Hoc upgrade auf die Version 5.5.2 (die aktuelle Version) endet mit einer Fehlermeldung, dass die Feig Crypto Componente sich nicht initialisieren lässt. Daraufhin habe ich mich mal an den Support der Firma FEIG ELECTRONIC GmbH gewendet.

    Die Firma arbeitet allerdings aktuell an einer neuen Generation der Java Bibliotheken und mir wurde empfohlen gleich auf die dritte Generation upzugraten, allerdings wird hier einiges an Codingaufwand auf mich zukommen. Der 18. Januar 2021 ist offizielles Releasedatum des ersten Release Candidate der neuen Java Bibliothek. Allerdings noch ohne Crypto Componente.

    Ich habe mich dazu entschlossen das Angebot anzunehmen und die Anwendung(en) entsprechend umzuschreiben. Ich werde diese Gelegenheit nutzen um folgende Optimierungen durchzuführen:

    • Überführung der Konfiguration aus der Konfigurationsdatei in den LDAP
    • Dynamische Ermittlung der Zugangspunkte (aus dem LDAP) und erstellen der Listener, damit soll es möglich sein mehrere Leser mit einer Serveranwendung zu versorgen.

    Vorbereitungen für den Coderefresh, wie ein Upgrade auf Java 11, das aktualisieren der anderen eingebundenen Bibliotheken und die eEinbindung der neuesten Maven Plugins, habe ich heute abgeschlossen.

    Da ich jetzt wieder Betatester spiele, wird es wohl auch wieder mehr Updates hier im Blog geben.

    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:

    FEIG Firmware v2.9.0

    Veröffentlicht am von
    Antworten

    Seit dem letzten Firmware Update lief nun der Leser eine lange Zeit ohne Abbrüche. Das Prolem scheint wohl gelöst zu sein. Leider hatte mit der Firmware allerdings die Signalisierung der LEDs und des Buzzers am Leser nicht mehr funktioniert.

    Nachdem nun einiges an Zeit vergangen ist hatte ich nochmals bei der FEIG nachgefragt ob der Fehler zwischenzeitlich erkannt und behoben wurde.

    Prompt erhielt ich schon eine neue Firmware v2.9.0. Nach einspielen der Firmware scheint nun die Ansteuerung der LEDs und Buzzer wieder zu funktionieren. Ob diese Firmware auch stabil läuft wird die Zeit zeigen. Bisher gab es allerdings keine Ausfälle zu verzeichnen.

    Neues Feig Java SDK 4.8.0

    Veröffentlicht am von
    Antworten

    Kuze Info am Rande.

    Es gibt ein neues Java SDK von der Firma FEIG Electronic GmbH. Heruntergeladen ist es. Leider ist das SDK nicht kompatibel mit v4.7. Daher musste ich ein paar Anpassungen am Listener vornehmen. Ob das SDK tut wie es soll und ob der SSL Bug damit behoben wurde werde ich die kommenden Tage mal testen.

    Ich werde berichten 🙂

    Aktuell sieht die Architektur so aus. Mal sehen ob die 2 gelben Verbindungen bald grün werden.

    Server läuft weiterhin aber FEIG SSL Bug weiterhin offen

    Veröffentlicht am von
    Antworten

    Am 8. August 2016 habe ich die Version 2 des Zugangskontrollsystems live genommen. Bisher ist nicht viel passiert. Das System läuft ohne murren vor sich hin und verrichtet seinen Dienst ohne Störungen.

    Gelegentlich hört der Leser auf KeepAlive Requests zu senden, aber das war schon von anfang an so. Der Workaround mit dem CPU reset funktioniert prima.

    Leider ist noch immer die Sache mit der verschlüsselten Kommunikation offen.
    Nachdem einige Zeit ins Land gegangen war hatte ich hierzu Anfang der Woche nochmals bei der Firma FEIG nachgefragt wie denn der Stand der Fehlerbehebung sei. Hierauf kam erfreulicherweise die Meldung dass es ein neues JavaSDK (v4.7.0) gibt, bei dem der Fehler auf Linux wohl behoben wurde.
    Heute Abend habe ich dann die neue Version installiert und getestet. Aber leider habe ich noch immer das selbe Problem. Nach aktivierung des Crypto Mode kann ich zwar dem Leser Befehle senden aber sobald ich den Listener initialisiere erhalte ich eine Java Exception:

    de.feig.FedmException: StartAsyncTask

    Dies habe ich eben gemeldet. Mal sehen was passiert.

    Bericht zum Betrieb des Zugangskontrollsystems

    Veröffentlicht am von
    Antworten

    Nun ist der Prototyp bereits eine Weile in Betrieb. Er macht seine Sache ganz gut bis auf ein paar Kleinigkeiten.

    Zum Beispiel wächst die Serverload im Laufe der Wochen an. Man merkt dies auch am Leser selbst wenn der Zeitpunkt von Einlesen der Karte und Verarbeitung auf dem Server wieder über eine Sekunde benötigt. In diesem Fall hilft es, den Prozess einfach durchzustarten.

    Im Januar hatte ich einen Servercrash der das Filesystem der SD Karte quasi komplett zerstörte. Seit dem Wiederaufsetzen gab es jedoch keine weiteren Störungen. Leider konnte ich nicht herausfinden wie es dazu kam. In dem Zuge habe ich mir jedoch überlegt einen Teil der Systemschreibzugriffe zu minimieren und auf eine RamDisk auszulagern. Hierzu bin ich allerdings noch nicht gekommen.

    Ein Interesanten Phänomen hatte ich im April. Hier ist der Serverprozess abgestürzt (vermutlich das Loadproblem von oben). Der Absturz ist genau dann ausgelöst worden als ein Zugangsversuch vorgenommen wurde. Der Leser wollte die Daten an den Serverprozess zur weiteren Verarbeitung übermitteln. Der Serverprozess hat dies allerdings nicht mehr quitiert und ist gestorben. Nach dem Neustart Abends hat sich dann die Türe geöffnet, da die Transponderdaten noch im Speicher des Lesers hingen. Da es sich hier um eine echte Sicherheitslücke handelt habe ich nun einen CPU Reset des Lesers eingebaut bei der Initialisierung des Serverprozesses. dieser CU reset hilft auch prima bei den gelegentlich auftretenden Verbindungsproblemen vom Leser zum Server. Seit tausch von „Signalisierung triggern“ zu CPU reset triggern hat der Leser die Verbindung gehalten.

    Tja und dann gibt es noch die ganzen offenen Punkte aus dem vorherigen Artikel von November. Hier gibt es nicht viel zu Berichten außer dass das mit der RandomUID nicht funktionieren wird.

    Ré­su­mé

    Das Ding schnurrt vor sich hin und tut seinen Dienst. Mein Sohn und meine Frau finden es toll. Größere Schwierigkeiten (außer dem Filesystem Crash im Januar) gab es bislang nicht. Um einen Absturz des Serverprozesses abzufangen habe ich nun einen Watchdog geschrieben der den Prozess automatisch versucht neu zu starten. Auch das Loadproblem versuche ich nun mit einem Housekeeping Script in den Griff zu bekommen (automatisierter restart des Serverprozesses).

    Leider ist der Server (der alte Raspberry) etwas schwach auf der Brust. Daher habe ich bereits über einen Plattformwechsel nachgedacht.

    Komerzialisieren

    Sollte ich die Lösung vertreiben wollen (wie und in welcher Form ist noch nicht klar) wird es 3 Änderungen geben. Statt dem Raspberry wird ein x86 zum Einsatz kommen (mit 2 Ethernet Schnittstellen für Leser Netz und Management Netz) und statt dem Relaisboard werde ich das externe Relais des Feig Lesers nutzen das es optional zu kaufen gibt. Auf die mini USV werde ich in diesem Design verzichten, da ja keine SD Karte mehr zum Einsatz kommt.
    Dieses Redisign wird dann mehr Luft nach oben haben und zusätzlich etwas Balast abwerfen. Es wird hoffentlich auch etwas robuster sein. Aber bis es soweit ist, wird wohl auch noch etwas Zeit ins Land gehen.

    Aktueller Stand der Implementation

    Veröffentlicht am von
    Antworten

    Heute möchte ich mal wieder über den aktuellen Stand der Implementation berichten.

    Allgemein:

    2015-11-27-Architektur-Schaubild

    • Die Konfigurationsdatei auf dem Server wurde auf das nötigste reduziert.
    • Der workaround mit dem Benutzerrepository als Propertiesdatei wurde mit dem neuen OpenLDAP Backend abgelöst.
    • Die Initialisierung der Karten schreibt automatisch in das LDAP Backend
    • Die Generierung eines random secret per Transponder Chipkarte findet nun automatisiert bei jeder Initialisierung neu statt und landet ordnungsgemäß im LDAP Backend.
    • Die Methode zur Ermittlung der Karteninhalte wurde zentralisiert.
    • Mails werden nun in einem Hintergrund Thread versendet um die Zeit beim Verbindungsaufbau zum Mailserver nicht im Authentisierungsprozess mit dabei zu haben.
    • Die Authentisierung als extra background thread zu integrieren habe ich wieder zurückgenommen. Der Leser liest einfach die Karten im Feld zu schnell aus und da kam es zu mehrfach Authentisierung.
    • Monitor integriert um Verbindungsabbrüche vom Leser zu erkennen um ggf. Aktionen einzuleiten.
    • Serverüberwachung in die FHEM Console integriert (CPU / Load / Speicher / Prozesse / Swap)

    Offene Punkte:

    • Der Call bei der FEIG bezüglich der fehlenden SSL Implementierung in den Raspberry Treibern ist noch offen. Hier warte ich auf ein neues Release das bislang nicht angekündigt wurde.
    • Call bei der FEIG eröffnet bzgl. der RandomUID Option der DESFire Karten. Die reale UID wird wohl bei der Authentifizierung nicht ausgelesen und übermittelt.
    • Monitoring Thread erkennt aktuell potentielle Verbindungsabbrüche zwischen Leser und Server. Er schickt daraufhin einen Notifizierungsrequest um den Leser wieder aufzuwecken. Das ist aktuell nur ein Versuch um hinter das Problem zu kommen.
      Evtl. muss ich hier auch noch einen Call bei der FEIG aufmachen.
    • LDAP Kommunikation mit SSL verschlüsseln
    • Ordentlicher Stop-Mechanismus für den Serverprozess
    • Planung und Entwicklung eines grafischen Frontends um die Daten (Benutzer, Transponder, Zugangspunkte, Rollen und Regeln) zu verwalten. Hier bin ich noch am Überlegen ob ich für die Verwaltung einen WebService entwickle oder eine Android App. Ersteres wäre generisch und letzteres stylisch und hip. 🙂

    Der erste Monat Testzeitraum

    Veröffentlicht am von
    Antworten

    Vor ca. 1 Monat habe ich das Zugangskontrollsystem in Betrieb genommen. Seit dem gab es die ein oder anderen Problemchen.

    1. Der Server schmiert mit einem OutOfMemory ab
    2. Bei Notifikation per Mail (kann man bei Rollen hinterlegen) kann es zu Verzögerungen von bis zu 30 Sekunden kommen.
    3. Der Leser hört auf, KeepAlive requests zu senden

    Das erste Problem war relativ schnell gelöst. Schuld war hier die Temparaturmessung des Raspberry. Bei, Auslesen von /proc gibt es hier manchmal einen deadlock. Ich hoffe dass dies bei dem ein oder anderen OS Update behoben wird. Vorläufig habe ich die Temparaturmessung aber deaktiviert.

    Das zweite Problem hoffe ich nun so zu lösen, indem ich meine Klasse hierzu mit „Runnable“ ausstatte und die Klasse zur Laufzeit initialisiere und dann im Hintergrund die Mail versenden lasse. Warum nicht multi threading nutzen wenn es die Plattform hergibt.

    Das dritte Problem bin ich nur am Rande angegangen. Hier muss ich erst noch ein paar Informationen sammeln. Hierzu habe ich meinen Monitor Thread umgebaut und berechne nun die Zeit, die zum letzten KeepAlive vergangen ist. Wenn hier ein Schwellwert überschritten wird, sende ich einen Befehl an den Leser. Ich möchte versuchen Ihn darüer zu bewegen wieder KeepAlive Requests zu senden.

    In dem Zuge habe ich nun auch die LDAP Anbindung eingebaut und die Authentication Klasse ebenfalls als Hintergrundthread implementiert. Dadurch kommt der Notify Thread schneller zurück und kann dadurch schneller neu getriggert werden.

    Die Optimierungen und Bugfixes habe ich zwischenzeitlich alle im Programm, jedoch steht der Test noch aus. Ich hoffe dies morgen durchführen zu können. Aktuell sitz ich nämlich in Katzenelbogen in einem Café fest und warte auf meine Frau. 🙂

    Der erste Zugriff beim ACS Prototyp

    Veröffentlicht am von
    Antworten

    Der Kartenleser wurde letztes Wochenende an der Fassade vor der Haustüre montiert. Der Umbau des Netzwerks erwies sich leider als nicht als so einfach (Stichwort 1&1 VoIP Telefonie mit Telefonen in einem privaten Netzwerksegment).

    Nach dem Umplanen der Netzwerkumgebung und dem erneuten Aufsetzen der Firewall konnte ich heute den ersten erfolgreichen Zugriff auf das entwickelte System inklusive Türöffnung verzeichnen (siehe Log):

    1st_access

    Offene Punkte sind:

    • Logfile mit UTF-8 encoding
    • PoE Injektor besorgen für zusätzlichen RFID Leser (der kam heute an)
    • RFID Medien bestellen (Schlüsselanhänger und Armbänder)
    • RandomUID Option bei Karteninitialisierung aktivieren
    • Kommunikationsproblem zwischen Server und Leser lösen das nur auf dem Raspberry auftritt (Call bei Feig ist bereits offen)
    • Batterie für PiUSV
    • OpenLDAP Anbindung realisieren

     

    RFID TAG Initialisierung (3rd try) und Entwicklungsstand

    Veröffentlicht am von
    Antworten

    2015-09-23-Architektur-SchaubildEs ist vollbracht 🙂

    Vor ein paar Minuten hat mein Zugangs-Kontrollsystem eine vollständig Initialisierte Karte, mit Hilfe des rollenbasierten Zugriffsschutzes, validiert und mir den Zugang gewährt!

    Nach einigen Tagen Dokus im Internet suchen/lesen/verstehen, nach einigen Tagen reverse Engineering bin ich nun doch zu einem ersten Beta gekommen.

    Auf meiner ToDo Liste sind nun folgende Dinge:

    • Aufräumarbeiten im SourceCode um mehrfach genutzte Methoden in eine bzw. mehrere HelperKlasse(n) auszulagern.
    • Die Klasse ConfigFile erweitern um Methoden um gleich den passenden Datentyp zurück zu bekommen (String, Boolean, Integer, Byte).
    • Den Status des Türschlosses übermitteln auf den Server und entsprechend behandeln (Signal wenn Authorisiert, die Türe aber verriegelt ist).
    • Eine vernünftige Abbruchbedingung implementieren
    • Fixen des Bugs im „Card Management System“ zum Schlüsseltausch des PICC MasterKey (Default ist DES, ich will aber AES und die JavaSDK gibt das m.e. im Moment nicht her obwohl es via ChipMan funktioniert. Sollte also irgendwie gehen). Hier warte ich noch auf eine Lösung vom Technischen Support bei der Feig.
    • Das SDK und die zugehörigen Bibliotheken auf dem Raspberry installieren
    • Das Java Programm auf den Raspberry portieren und mit der PiFaceDigital 2 Klasse testen (und damit die Haustüre öffnen).
    • Ach ja und danach:
      • Firewall kaufen und einrichten
      • 2ten RFID Reader kaufen und einrichten (zur Karten Initialisierung)
      • RFID Tags kaufen, personalisieren und verteilen

    Gehäuse fertig, Open Collector vs Rellais und PiUSV+

    Veröffentlicht am von
    1

    Gehäuse

    Also nun ist es am Wochenende doch noch fertig geworden. Blau-Metallic lackiert sieht es schon recht schick aus.

    20150912_11204020150912_12090420150912_120914

    PiFace Digital 2

    Nach dem Zusammenbauen habe ich den OpenCollector Ausgang nochmals geprüft, dabei ist mir aufgefallen dass der Ausgang auf Masse gezogen wird wenn der Server aus ist. Das ist nun doch etwas ungünstig, denn bei einem Server Ausfall würde ja dann die Türe aufgehen. Daher bin ich nun doch kurzfristig umgestiegen auf das Relais.
    Da der Traffo genug Power hat (10 Ampére) konnte ich das PiFace Digital 2 auch direkt mit Strom versorgen.

    PI USV+

    Leider ist mir noch etwas aufgefallen für das ich derzeit noch keine Lösung habe. Der Akku der für die Notfall-Stromversorgung da sein sollte funktioniert nicht wie gewünscht. Die PI USV+ hat 4 Status LEDs. Aber das Bild das ich hier sehe gibt es in der Doku nicht.

    In der Doku (Kapitel 2.1, Seite 7) steht folgendes:

    • LED1 (Rot): Betrieb über Akku
    • LED2 (Gelb): Status Anzeige des Akkus. LED Blinkt: Akku wird geladen, LED leuchtet dauerhaft: Akku ist voll
    • LED3 (Grün): Status Anzeige PiUSV+. LED Blinkt: USV funktioniert ordnungsgemäß
    • LED4 (Grün): Betrieb über Primäreingang

    Nun zeigt sich bei mir folgendes Bild:

    • LED1: blinkt schnell
    • LED2: ist aus
    • LED3: blinkt langsam
    • LED4: leuchtet dauerhaft

    Das sehe ich, ob ich nun einen Akku dran habe oder nicht. Als Akku verwende ich derzeit einen Panasonic NCR18650B Lithium-Ionen Akku (3400mAh).

    Gemäß PiUSV+ Doku (Kapitel 2.2, Seite 7) muss der Akku folgende Spezifikationen aufweisen:

    • Technologie: Lithium Ionen (LiIon) oder Lithium Polymer (LiPo)
    • Zellen: 1
    • Kapazität: min. 300mAh
    • Spannung: +3.7V
    • Entladestrom: min. 3A
    • Ladespannung: +4.2V
    • Ladestrom: 100mA

    sollte demnach passen. Aufgeladen ist der Akku auch. Keine Ahnung was da jetzt los ist. Das Gehäuse lasse ich aber bis zur Lösung wohl offen.

    Hab auch mal bei de PiUSV Facebook Seite nachgefragt (Link zum Post).

    Links

     

    Gehäuse „fast“ fertig

    Veröffentlicht am von
    Antworten

    20150911_132828

    Das Servergehäuse wär quasi „fast“ fertig. Ich möchte es jetzt noch lackieren damit es gut aussieht. Aber funktional wäre es schon einmal.

    Im Moment bin ich mir auch noch nicht sicher ob ich noch einen Lüfter einplanen muss. Das überlasse ich der Temparatur Auswertung. 20150911_131817

    Die Anschlüsse und Kabel sind zwischenzeitlich auch alle verlötet oder gekrimpt. Sobald das Gehäuse dann so aussieht wie gewünscht, geht es an das zusammenschrauben.