Neues Modul: Signalbot (Integration für den Signal Messenger) via signal-cli

[Adimarantis]

@fettgu:
Von welcher signal-cli version hast du geupdated? Vielleicht ist deine config zu alt und er hat den Umstieg nicht geschafft. Dann wäre die alte config unter /var/lib/signal-cli am Besten ganz zu löschen und die Nummer neu zu registrieren.
Eventuell gibt ein Test rein auf der Kommandozeile mehr Aufschluss:

Code Auswählen Erweitern

sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49<registrierte Nummer> send -m "testmessage" +49<Empfänger>
Unter welchem OS und welcher HW bist du?

Code Auswählen Erweitern

cat /etc/os-release
uname -a
arch


@rubinho:
Sehr seltsam. Er bekommt für die Version ein Array statt einem String - daher meint er du bist auf Version 0
Die Grundfunktionalität sollte glaube ich da sein, aber einige set/get Befehle werden deaktiviert wenn die Version nicht stimmt.
Aber vielleicht hilft ja ein Neustart?
Wenn nicht, an dich die selbe Frage wie oben nach OS und Architektur.

[weini]

Also bei mir hat das update leider auch nicht richtig geklappt, der Service startet nicht mehr.

Code Auswählen Erweitern

sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49<registrierte Nummer> send -m "testmessage" +49<Empfänger>
liefert
[codeError loading state file for user +49<registrierte Nummer>: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null (NullPointerException)][/code]

Ich nutze einen Raspi 4 mit

Code Auswählen Erweitern

pi@raspiX:~/.config $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

kein Docker.

Java17 wurde vom Install Skript installiert. Darf die alte Java11 daneben zusätzlich installiert bleiben?

[heiko.ne]

Gleiches Problem: Trotz der hier angegebenen Lösungsansätze startet der Service nicht mehr:

Code Auswählen Erweitern


Okt 07 12:08:18 dell signal-cli[7860]: ERROR MultiAccountManager - Failed to load +49meineNummerhier: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null (NullPointerException)
Okt 07 12:08:18 dell signal-cli[7860]: java.lang.NullPointerException: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.storage.identities.IdentityKeyStore.loadIdentity(IdentityKeyStore.java:197)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.storage.identities.IdentityKeyStore.saveIdentity(IdentityKeyStore.java:61)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.storage.SignalAccount.setPniIdentityKeyPair(SignalAccount.java:1365)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:406)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:182)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:93)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:65)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Okt 07 12:08:18 dell signal-cli[7860]:         at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:73)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.App.init(App.java:191)
Okt 07 12:08:18 dell signal-cli[7860]:         at org.asamk.signal.Main.main(Main.java:60)
Okt 07 12:08:18 dell systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit signal.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 2.
Okt 07 12:08:18 dell systemd[1]: signal.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit signal.service has entered the 'failed' state with result 'exit-code'.
Okt 07 12:08:18 dell systemd[1]: Failed to start Send secure messages to Signal clients.
░░ Subject: A start job for unit signal.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit signal.service has finished with a failure.
░░
░░ The job identifier is 1775 and the job result is failed.
Okt 07 12:08:18 dell systemd[1]: signal.service: Consumed 5.376s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit signal.service completed and consumed the indicated resources.



Irgendwas scheint mit dem zugrunde liegenden Service nicht ok. Hat jemand eine Idee, wie man Abhilfe schaffen kann?

Gruß, Heiko

[Adimarantis]

Ich befürchte, dass die vorgenannten Probleme von einem zu großen Versionssprung bei signal-cli kommen.
Die Konfigurationsdaten wurden mit der Zeit erweitert und sind wahrscheinlich nur bis zu einem gewissen Punkt rückwärtskompatibel.

Man könnte jetzt vielleicht nach und nach neuere signal-cli versionen installieren und anstarten in der Hoffnung, dass die Config dabei migriert wird.
Aber ich denke es wird das Beste sein alle Daten unter /var/lib/signal-cli zu löschen (bzw. auch wegzusichern) und die Nummer neu zu registrieren.

[weini]

Ok danke, sehe ich mir gleich mal an.

Was mir gerade noch aufgefallen ist:

Code Auswählen Erweitern

pi@raspi1:~/.config $ systemctl cat signal.service
# /etc/systemd/system/signal.service
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target

[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME="
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal

[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service


Die Environment-Zeile für JAVA_HOME kommt mir komisch vor, soll das wirklich so sein?

[Adimarantis]

Re Java Version:

Wenn ich Testweise Java11 verwende bekomme ich folgenden Fehler:

Code Auswählen Erweitern

/opt/signal/bin/signal-cli --version
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
        java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

Daher gehe ich mal davon aus, das euere Fehler nicht auf eine falsche Java Version zurückzuführen sind.

Der Eintrag

Code Auswählen Erweitern

Environment="JAVA_HOME="
führt einfach dazu, dass JAVA_HOME auf leer gesetzt wird, womit der System Standard angezogen wird.
Auf meinem "buster" system mit eigener Java version schaut es dann so aus:

Code Auswählen Erweitern

Environment="JAVA_HOME=/opt/java"


[tomcat.x]

Oh Mann, hier mal ein dummer Tipp (oder guter Tipp für dumme User?): Man darf das Installations-Script natürlich nicht einfach (in der alten Version) neu aufrufen, sondern muss es vorher neu in das Verzeichnis runterladen, in dem man es ausführt. Vielleicht passiert das nur mir, aber die Fehlermeldungen passen zu einigen aus den vorherigen Beiträgen.

[rubinho]

@rubinho:
Sehr seltsam. Er bekommt für die Version ein Array statt einem String - daher meint er du bist auf Version 0
Die Grundfunktionalität sollte glaube ich da sein, aber einige set/get Befehle werden deaktiviert wenn die Version nicht stimmt.
Aber vielleicht hilft ja ein Neustart?
Wenn nicht, an dich die selbe Frage wie oben nach OS und Architektur.

Habe gerade ein Update auf Signalbot 3.11 durchgeführt und danach ein restart von Fhem.
Jetzt wird wieder alles erkannt. Was jetzt die Lösung war kann ich nicht sagen. Ist mir aber auch egal 

PS.
Mein OS ist Ubuntu 22.04 64bit  Arch ist x86_64

[Jamo]

signal-cli-0.11.3 ist vor 2 Stunden bereitgestellt worden.

[Adimarantis]

Installer update 3.11

Der Author von signal-cli hat gerade signal-cli 0.11.3 veröffentlicht.
Dort ist ein Commit enthalten der "Fix update from old versions without PNI" heisst.
Möglicherweise ist das der Grund warum so viele Probleme mit der Config hatten und ihre Nummer neu registrieren mussten.
Da diese Version die selben native libraries verwendet, habe ich einen schnellen Patch des Installers online gestellt, der 0.11.3 mit den 0.11.2 libs installiert.
Vielleicht erspart das einigen die noch nicht upgedated haben die erneute Registrierung.

Vorgehen wie gehabt: "set reinit" um den neuen Installer nach www/signal zu laden, mit "sudo -E ./signal_install.sh" ausführen.

Anmerkung:
- Der neue Installer updated Dbus auf 0.22 - das kann etwas dauern
- Die signal.service Datei bekommt ein paar Änderungen, die race conditions beim Neustart verhindern sollen. Muss man nicht unbedingt übernehmen.

[rubinho]

Wunderbar,  zwei Updates innerhalb 24 Stunden. So bleibt man in Übung

[weini]

Das neue Update auf 11.3 hat das Problem bei mir gelöst, ich kann jetzt wunderbar mit der "alten" Konfiguration weitermachen.

Vielen Dank für die Unterstützung!

[sukram]

Installer update 3.11

Der Author von signal-cli hat gerade signal-cli 0.11.3 veröffentlicht.

Leider macht das Update von signal-cli die Installation auf Ubuntu 18.04 LTS kaputt. Die fertigen Packages wollen alle glibc >= 2.28, im System steckt 2.27. Die alternative Repo für die libsignal_jni, siehe https://github.com/exquo/signal-libs-build/ funktioniert seit Monaten nicht mehr. Selber kompilieren der libsignal-client Library hängt sich mit einem cmake Fehler weg, weil die Version die --parallel Option, die Rust verwendet, noch nicht unterstützt. Und der Patch für die cmake Rust lib, der das korrigiert, ist noch nicht in das Haupt Repository übernommen worden. Dependency Hell vom feinsten.

Ich habs gerade echt soo satt.

[heiko.ne]

Das neue Update auf 11.3 hat das Problem bei mir gelöst, ich kann jetzt wunderbar mit der "alten" Konfiguration weitermachen.

Vielen Dank für die Unterstützung!

Das hat's bei mir auch gebracht. Alles geht wieder!
Ich sage "herzlichen Dank" für den Support.

Gruß, Heiko

[Adimarantis]

@sukram:
Das Cmake --parallel Problem hatte ich auch unter Raspbian Buster.
Dafür habe ich mir die aktuelle cmake version geholt und drüberkopiert - dann hats geklappt.
Schau mal unter
https://apt.kitware.com/
Da scheint es apt packages für Ubuntu 18.04 zu geben.

Probiere ich später vielleicht selber. Falls du eine entsprechende library übersetzt bekommst, nehme ich sie gerne in mein repository/installer auf.