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.
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.
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).
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.
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:
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)
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.
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.
DocStore