Ungültige / abgelaufene (expired) Schlüssel der Linux-Paketquellen unter Debian aktualisieren

Bei der Wartung des Linux-Betriebssystems Debian trat das Problem auf, dass die GPG-Schlüssel des GNU-Privatsphärenschutzes (GNU Privacy Guard) von einzelnen Paketquellen abgelaufen (engl. expired) waren. Genauer gesagt trat dieses Problem beim Neueinlesen bzw. Aktualisieren der verfügbaren Pakete auf.

 sudo apt-get update 

Analyse

Um sich alle abgelaufenen Schlüssel auflisten zu lassen, kann folgender Befehl verwendet werden.

 sudo LANG=C apt-key list | grep -A 1 expired 

Mit dem Parameter "LANG=C" wird sichergestellt, dass die Ausgabe der Liste immer in englisch erfolgt und zwar unabhängig von der aktuellen Spracheinstellung des Betriebssystems. Somit kann mit grep nach dem Wort "expired" gefiltert werden.

Lösung

Um das Problem zu lösen, muss der abgelaufene Schlüssel aktualisiert werden.

 sudo apt-key adv --keyserver keys.gnupg.net --recv-keys <key> 


Mit dem Programm apt-key  für den Schlüsselverwaltungsdienst
, kann der vom Programm Advanced Package Tool (apt) zur Authentifizierung von Paketen verwendete Schlüsselring verwaltet werden. Der Parameter "<KEY>" muss natürlich durch den entsprechenden Schlüssel ersetzt werden.

 sudo apt-key adv --keyserver keys.gnupg.net --recv-keys B188E2B695BD4743 

Danach sollte „apt-get update“ wieder ohne Fehlermeldung durchgeführt werden können.

Warn-App NINA – Eventhandler-Script um Nachrichten zu verarbeiten & weiterzuleiten

Mit der Notfall-Informations- und Nachrichten-App (NINA) des Bundes, können wichtige amtliche Warnungen und Informationen erhalten werden. Dazu zählen u. a. Informationen des Bevölkerungsschutzes für unterschiedliche Gefahrenlagen wie z. B. Gefahrstoffausbreitung, Wetterwarnungen des Deutschen Wetterdienstes und Hochwasserinformationen der zuständigen Stellen der Bundesländer.

Script – Beschreibung
Damit nicht jede Person in unserer Familie die NINA-App installieren muss, wurde ein kleines Script entwickelt, welches diese Informationen regelmäßig verarbeitet und an unterschiedliche Systeme weiterleiten kann. Implementiert wurde bisher die Anbindungen der Notification-Dienste für Pushover und Telegram.

Script – Voraussetzung
Durch den NINA-Adapter für ioBroker, können diese Nachrichten regelmäßig abgerufen und in das System integriert werden. Diese ist Voraussetzung und muss vorab installiert werden.

Je nachdem welche Anbindung verwendet werden soll, muss hierzu ein entsprechender Adapter für den Dienst installiert und eingerichtet werden.
Pushover Adapter
Telegram Adapter

Script – Quellcode
Aktuelle Version des Scripts findet man unter:
https://github.com/mesche/iobroker-scripts/tree/master/nina_messages_eventhandler


Workaround: Script-Editor – Icons werden nicht angezeigt – Codicon Font defekt

Seit einigen Versionen (aktuell 5.0.15) des Javascript Script Engine – Adapters für ioBroker besteht leider das Problem, dass die Icons/Grafiken im Script-Editor nicht mehr angezeigt werden.

Ursache:
Der Grund für das Problem dürfte eine defekte Codicon TrueType-Schriftartendatei sein. Diese stellt normalerweise die Grafiken für die Icons bereit.

Bug-Tickets:
Ticket #751 – Suchfunktion -> Grafikfehler
Ticket #761 – Icons are not displayed

Workaround:

cd /opt/iobroker/
cd node_modules/iobroker.javascript/admin/vs/base/browser/ui/codicons/codicon/
cp codicon.ttf codicon.ttf-org
curl -L -o codicon.ttf https://github.com/microsoft/vscode-codicons/blob/main/dist/codicon.ttf?raw=true
iobroker upload javascript

Workaround zurücksetzen:

cd /opt/iobroker/
cd node_modules/iobroker.javascript/admin/vs/base/browser/ui/codicons/codicon/
mv codicon.ttf-org codicon.ttf
iobroker upload javascript

Wichtig: Ggf. Pfad zum ioBroker-Verzeichnis anpassen und Befehle mit entsprechenden Benutzer ausführen.

Ergebnis:

Node „pcap“ Module – Error: „socket: Operation not permitted“ – Fehler wenn PcapSession geöffnet wird

Für unixartige Betriebssysteme stellt die Bibliothek „libpcap“ (packet capture library) Funktionen zur Verfügung, um den Datenverkehr, welcher über die Netzwerkschnittstellen läuft, mitzuschneiden und zu analysieren. Das JavaScript Modul „pcap“ stellt die entsprechenden Bindungen (engl. Bindings) für diese Bibliothek zur Verfügung. Diese können dann mit Node.js verwendet werden.

Problem

Diese Bibliothek wird gerne in Node.js Modulen, wie z. B. dem Amazon Dashbutton Adapter für ioBroker, verwendet. Da die libpcap Bibliothek auf Funktionen des Betriebssystems zugreift, kann es zu folgender Fehlermeldung kommen, wenn der Code ausgeführt wird.

Error: socket: Operation not permitted

Der Benutzer, durch den der Code ausgeführt wurde, besitzt anscheinend nicht die notwendigen Rechte.

Am Beispiel des Amazon Dashbutton Adapters, würde dann folgende Fehlermeldung im Log auftauchen.

error   at Adapter. (/opt/iobroker/node_modules/iobroker.amazon-dash/main.js:50:29)
error   at Object.exports.createSession (/opt/iobroker/node_modules/iobroker.amazon-dash/node_modules/pcap/pcap.js:123:12)
error   at new PcapSession (/opt/iobroker/node_modules/iobroker.amazon-dash/node_modules/pcap/pcap.js:49:39)
error   Error: socket: Operation not permitted
error   uncaught exception: socket: Operation not permitted

Lösung

Um das Problem zu lösen, müssen die Dateisystem „Capabilities“ für das Programm „node“ angepasst werden. Dies kann durch das Kommandozeilen-Tool „setcap“ erreicht werden.
Hierzu muss folgender Befehl in der Kommandozeile ausgeführt werden.

sudo setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))

Mit dem Tool „getcap“ kann geprüft werden, ob alles korrekt gesetzt wurde. Hierzu muss folgender Befehl in der Kommandozeile ausgeführt werden.

sudo getcap $(readlink -f $(which node))

Dies Ausgabe sollte dann z. B. so aussehen:

/usr/bin/nodejs = cap_net_admin,cap_net_raw+eip

Hier noch eine kurze Erklärung aus der Dokumentation

 In many distributions you can use the 'setcap' utility to add capabilities to individual files.
 CAP_NET_RAW: 
       Allow use of RAW and PACKET sockets.
 CAP_NET_ADMIN:
       Allow various network-related operations (e.g. setting privileged socket options, enabling multicasting, setting promiscuous mode, interface configuration, modifying routing tables).
       The “+eip” means you’re adding the file capability sets Effective, Inherited and Permitted.
       
       Each thread has three capability sets containing zero or more of the above capabilities: 
		 The three file capability sets are:
             e: Effective  -  The capabilities used by the kernel to perform permission checks for the thread. 
             i: Inherited  -  The capabilities preserved across an execve(2). A child created via fork(2) inherits copies of its parent's capability sets. See below for a discussion of the treatment of capabilities during exec(). Using capset(2), a thread may manipulate its own capability sets, or, if it has the CAP_SETPCAP capability, those of a thread in another process.
             p: Permitted  -  The capabilities that the thread may assume (i.e., a limiting superset for the effective and inheritable sets). If a thread drops a capability from its permitted set, it can never re-acquire that capability (unless it exec()s a set-user-ID-root program).


Prüfung

Um zu prüfen, ob das pcap Module korrekt funktioniert, kann die im Module mitgelieferte Bespieldatei „network_grep.js“ über die Kommandozeile ausgeführt werden. Diese Datei befindet sich z. B. im Ordner „node_modules“ unter pcap/examples/network_grep.js

Beispiel Befehl:

node /opt/iobroker/node_modules/pcap/examples/network_grep.js

Hier sollte dann folgender Fehler NICHT mehr auftreten:

/opt/iobroker/node_modules/pcap/pcap.js:49
        this.link_type = this.session.open_live(this.device_name, this.filter, this.buffer_size, this.outfile, packet_ready, this.is_monitor);

Error: socket: Operation not permitted
    at new PcapSession (/opt/iobroker/node_modules/pcap/pcap.js:49:39)
    at Object.exports.createSession (/opt/iobroker/node_modules/pcap/pcap.js:123:12)
    at Object.<anonymous> (/opt/iobroker/node_modules/pcap/examples/network_grep.js:2:25)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:427:7)


OData V4 – Implementierung eines Services unter Java EE mittels Apache Olingo

Aktuell beschäftige ich mich damit, wie Daten strukturiert von einer Java EE Anwendung abgerufen und einem Client zur Verfügung gestellt werden können. Bisher habe ich RESTful Web Services implementiert, welche die Daten im JSON-Format geliefert bzw. verarbeiten haben. Hierzu wurde z. B. das Jersey Framework (Referenzimplementierung) verwendet, welches die Java API for RESTful Web Services (JAX-RS) Spezifikation implementiert. Dabei ist zwar JSON ist ein kompaktes und schlankes Datenaustauschformat, jedoch war es hier umständlich weitere Metadaten zu integrieren.

Auf der Suche nach möglichen Lösungansätzen bin ich auf das Open Data Protocol (OData) gestoßen. Dieses Protokol wurde von Microsoft entworfen und definiert einen Standard, um einen strukturierten Datenaustausch zu ermöglichen. Die Schwerpunkte des Protokols liegen grundsätzlich bei der Server-zu-Server-Kommunikation und der Möglichkeit, einen angebotenen Service mittels einen Servicedokuments und des Datenmodells (EDM) einzubinden zu können.

Die ersten OData Versionen 1-3 wurden per Microsoft Open Specification Promise freigegeben. Die Version 4.0 wurde nach der Übergabe an OASIS und dessen Weiterentwicklung, am 26. Februar 2014 freigegeben.

Im OData-Standard werden u. a. die Definition des Datenmodells per Entity Data Model (EDM), der Datenaustausch mittels Services im Service Document und die Datenformate wie z. B. Atom und JSON festgelegt. Zusätzlich sind Funktionen in Form der System Query Options, Service Operations und Batch Processing definiert. Dadurch ist es mittels Query-Anfragen ($filter, $select, $top ..) möglich, die Datenmenge einzugrenzen und somit nur die notwendigen Daten abzurufen. Die Bearbeitung der Daten kann mit CRUD-Operationen nach den REST-Prinzipien erfolgen.

OData Java-Bibliotheken

Die Recherche nach Java-Bibliotheken, welche die OData V4 Spezifikation implementieren, war leider etwas ernüchternd. Im Vergleich zu anderen Programmiersprachen (wie z. B. .NET) konnte ich nur eine Handvoll an Bibliotheken finden, die erstmal vielversprechend aussahen. Leider stellte sich schnell heraus, dass die Meisten davon nur die OData Spezfikationen von Version 1-3 implementiert haben. In die engere Auswahl kam somit mich eigentlich nur das SDL OData Framework und die Apache Olingo Projekt.

SDL OData Framework

Das SDL OData Framework implementiert die OData V4 Spezifikation und bietet nicht nur die serverseitige Komponente, sondern auch die Möglichkeit zur Entwicklung eines OData Java Clients. Ein weiterer Pluspunkt ist, dass es sowohl eine JPA Erweiterung gibt, sowie die Möglichkeit das EDM mittels Java-Annotationen zu definieren. Leider scheint dieses Framework hauptsächlich in Verbindung mit Spring bzw. Spring Boot gedacht zu sein und ist somit im Java EE Umfeld eher umständlich einzusetzen.

Apache Olingo Bibliotheken

Das Apache Olingo Projekt besteht aus einer Sammlung von Java und JavaScript Bibliotheken und bietet aktuell Support für die OData V2 und die OData V4 Version. Leider bietet aktuell nur die OData V2 Implementierung einen JPA Prozessor und die Unterstützung für Java-Annotationen zur Definition des EDM an. Die Implementierung des V4 Standards selbst, scheint für mich aber ausgereift, deshalb lohnte es sich, die Bibliotheken etwas detailierter zu betrachten.

Beispielprojekt: Java EE – OData V4 Service mittels Apache Olingo

Auf Basis des Tutorials „Basic Tutorial: Create an OData V4 Service with Olingo“ habe ich ein kleines Beispielprojekt erstellt. Die Java EE Web-Anwendung stellt einen OData V4 Service bereit, welcher mit Hilfe der Apache Olingo Bibliothek erstellt wurde.

Eigene EDM Java-Annotationen

Um die Erstellung des OData Services etwas flexibler zu haben, wurden eigene Java-Annotationen und ein spezieller Annotationen-Prozessor erstellt, um auch in Version 4 die Definition des EDM mittels Annotationen zu ermöglichen.

Quellcode

Der komplette Quellcode für dieses Projekt, kann in meinem GitHub Repository gefunden werden:
GitHub: ODataV4 – JavaEE – Example – Apache Olingo