nach viel getüftel, Google und Schlaflosen Nächten, weiß ich nun nicht mehr weiter.
Derzeit versuche ich unter CentOS 7 ein eJabberd-Server aufzusetzen, klappt auch alles super. Nur eine Sache da hakt es: Verschlüsselung.
eJabberd behauptet felsenfest, mein Zertifikat wäre von einem ihm unbekannten CA (ist von Let’s Encrypt).
2017-10-16 19:57:58.101 [warning] <0.274.0>@ejabberd_pkix:check_ca_dir:386 CA directory /etc/ssl/certs doesn't contain hashed certificate files; configuring 'ca_path' option might help
2017-10-16 19:57:58.151 [warning] <0.274.0>@ejabberd_pkix:mk_cert_state:240 certificate from /opt/tenguchat-server/ejabberd2.pem is invalid: certificate is signed by unknown CA
Nun habe ich durch Google Suche, schon so einiges ausprobiert, jedoch wenn ich auch nur Versuche, einen Pfad anzugeben, Crasht das ganze mit folgender Meldung:
2017-10-16 19:42:02.226 [error] <0.274.0>@filelib:wildcard:52 CRASH REPORT Process <0.274.0> with 0 neighbours exited with reason: no function clause matching filelib:wildcard(<<"/etc/pki/tls/certs/ca-bundle.crt/*.0">>) line 52 in gen_server:init_it/6 line 352
Mit meinem Latein bin ich nun schon lange am Ende, an anderen Stellen wird das Zertifikat als gültig anerkannt.
Nur eben da wo es wichtig ist nicht.
Ohne jemals mit CentOS oder ejabbers gearbeitet zu haben (ich nutze Prosody unter Debian), meine Erkenntnisse: Das hier scheint ja genau dein Problem zu sein. ejabberd möchte gerne hashed certificate files nutzen, weil die effizienter zu parsen sind, die es aber auf CentOS 7 nicht gibt. Die Lösungsansätze seinen der Parameter s2s_cafile (worauf auf immer man den dann setzen soll) zu sein, oder auf Version 17.09. zu warten, wenn ich das Github Issue richtig gelesen habe.
Du hast nun für ca_path den Pfad auf “/etc/pki/tls/certs/ca-bundle.crt/*.0” gesetzt? Das scheint ihm wohl auch nicht zu passen. Möglicherweise, weil er einen Ordner-Pfad erwartet und keinen Verweis direkt auf Dateien, bzw. vor allem nicht mit Wildcard (also Sternchen).
EDIT: Huch, die Antwort vor mit habe ich nicht gesehen - aber führt ja zum gleichen Issue. ^^
Erstmal danke für die Antworten.
Das verlinkte Issue habe ich auch schon gesehen, jedoch sind die dort verwiesenen “Workarounds” das, was ich mit der Angabe von ca_path bewirken wollte.
Was diese Angabe angeht, ist es nicht auf einen Wildcard oder ähnliches gesetzt:
ca_path: “/etc/pki/tls/certs/”
Das dann ein *.0 gesucht wird, macht eJabberd von alleine.
Und ja, derzeit nutze ich selbst noch Prosody, aber dessen ständige Abstürze und Probleme mit mir wichtigen Modulen, brachten mich zu dem Gedanken umzusteigen (wieder) auf eJabberd :).
Habe jetzt (auch wenn es vorher selbe Version war) mal via RPM installiert, beides 17.09 wo der Fehler ja hätte behoben sein sollen:
19:52:00.810 [warning] CA directory /etc/ssl/certs doesn't contain hashed certificate files; configuring 'ca_path' option might help
19:52:00.857 [warning] certificate from /opt/ejabberd/ejabberd2.pem is invalid: certificate is signed by unknown CA
19:52:00.876 [info] Application p1_mysql started on node ejabberd@localhost
19:52:01.027 [info] Application inets started on node ejabberd@localhost
Nur so aus Interesse: Ich habe auch jede Menge zusätzlicher Module aktiv und fahre sogar die nightly Version, habe aber keinerlei Probleme. Was sind das für Module die da bei dir die Abstürze verursachen?
Mit der neuen 0.10? Die Mods habe ich ebenfalls aktiv und keinerlei Probleme.
(MySQL Backend, mam, pep, http_upload, smacks, cloud_nitify, csi,…)
Bei Problemen findet man eigentlich auch recht schnell Hilfe im Prosody-MUC: prosody@conference.prosody.im
Was mich an prosody aber am meisten stört, sind die ständigen Probleme was Nachrichten angeht. Wenn jmd. Offline ist, kann man den Personen nur selten Nachrichten senden.
Solche Meldungen kommen ja auch in Dauerschleife:
Oct 20 20:11:21 sql error Error in SQL transaction: /usr/lib/prosody/util/sql.lua:176: Error preparing statement handle: Unknown column ‘key’ in 'field list’
stack traceback:
/usr/lib/prosody/util/sql.lua:176: in function </usr/lib/prosody/util/sql.lua:174>
(tail call): ?
(tail call): ?
[C]: in function ‘xpcall’
/usr/lib/prosody/util/sql.lua:233: in function ‘_transaction’
/usr/lib/prosody/util/sql.lua:247: in function ‘transaction’
/usr/lib/prosody/modules/mod_storage_sql.lua:319: in function ‘find’
/usr/lib/prosody/modules/mod_mam/mod_mam.lua:143: in function ‘?’
/usr/lib/prosody/util/events.lua:78: in function </usr/lib/prosody/util/events.lua:74>
…
[C]: in function ‘parse’
/usr/lib/prosody/util/xmppstream.lua:271: in function ‘feed’
/usr/lib/prosody/modules/mod_c2s.lua:258: in function ‘data’
/usr/lib/prosody/modules/mod_c2s.lua:281: in function </usr/lib/prosody/modules/mod_c2s.lua:278>
(tail call): ?
/usr/lib/prosody/net/server_select.lua:879: in function </usr/lib/prosody/net/server_select.lua:861>
[C]: in function ‘xpcall’
/usr/lib/prosody/…/…/bin/prosody:400: in function ‘loop’
/usr/lib/prosody/…/…/bin/prosody:431: in main chunk
[C]: ?
Was halt aber an Prosody am meisten stört, das es die Möglichkeit nicht gibt an alle Nutzer nachrichten zu senden (nur an Online), und man nicht automatisiert Dateien und User löschen lassen kann.
Weil zB Dateien via http_upload will ich nach 30 Tagen löschen lassen und Inaktive Nutzer nach 6 Monaten, zu beidem findet man nichts.
mod_blocklist und mod_blocking vertragen sich (zumindest spätestens ab 0.10) nicht, siehe hier bei Compatibility: https://modules.prosody.im/mod_blocking.html
Außerdem erfordert mod_blocking auch mod_privacy, was du aber nicht in der Liste aufgeführt hast. Ich würde einfach mod_blocking rausschmeißen und nur auf mod_blocklist setzen.
Für offline-Nachrichten ist mod_offline zuständig, ab 0.10 ist der per default aktiv (deaktivierbar über modules_disabled). Damit hatte ich noch nie Probleme. Evtl. ist bei dir ja wirklich etwas mit der Datenbank faul, wenn man diese Fehlereldungen betrachtet (mein error-Log ist komplett leer).
Hast du evtl. nach dem Upgrade auf die 0.10 das Datenbank-Schema nicht aktualisiert, wie es in den Upgrade notes steht? Dort sind ebenfalls Hinweise zu mod_privacy und mod_offline. https://prosody.im/doc/release/0.10.0#mysql_schema_upgrade
Oder evtl. hilft es dir LuaDBI zu installieren, das ist zwar optional aber vllt. stabiler als ohne auf CentOS, wer weiß. https://prosody.im/doc/depends
Zum User nach 30 Tagen löschen fällt mir jetzt spontan nichts ein aber das lässt sich bestimmt auch umsetzen. Im Zweifel einfach selbst ein Modul schreiben
So alles schön und gut, prosody läuft sauber neu Installaiert mit 0.10 doch sauber!
Probleme macht es dennoch:
-Message Archiv Managment sollte doch Angeblich nun “mitgeliefert” werden?
-http_upload über externen Webserver nicht möglich (statt über den Prosody internen)
Ja, das Module MAM wird jetzt direkt mit ausgeliefert. Findet sich im ocnfig-File unter “Nice to have” und ist per default noch auskommentiert.
Für http_upload mit externem Webserver gibt es ein separates Modul. Das war mir aber zu mühselig sodass ich dann einfach das prosody-eigene genommen habe und in meinem nginx einen entsprechenden Proxy zum prosody-Webserver eingerichet habe.
Nun gut, es scheint aber mod_mam zu sein der die Fehler ausspuckt weil das taucht nun wieder auf:
Nov 14 02:43:23 sql error Error in SQL transaction: /usr/lib64/prosody/util/sql.lua:176: Error preparing statement handle: Unknown column 'key' in 'field list'
stack traceback:
/usr/lib64/prosody/util/sql.lua:176: in function </usr/lib64/prosody/util/sql.lua:174>
(tail call): ?
(tail call): ?
[C]: in function 'xpcall'
/usr/lib64/prosody/util/sql.lua:233: in function '_transaction'
/usr/lib64/prosody/util/sql.lua:247: in function 'transaction'
/usr/lib64/prosody/modules/mod_storage_sql.lua:319: in function 'find'
/usr/lib64/prosody/modules/mod_mam/mod_mam.lua:143: in function '?'
/usr/lib64/prosody/util/events.lua:78: in function </usr/lib64/prosody/util/events.lua:74>
...
[C]: in function 'parse'
/usr/lib64/prosody/util/xmppstream.lua:271: in function 'feed'
/usr/lib64/prosody/modules/mod_c2s.lua:258: in function 'data'
/usr/lib64/prosody/modules/mod_c2s.lua:281: in function </usr/lib64/prosody/modules/mod_c2s.lua:278>
(tail call): ?
/usr/lib64/prosody/net/server_select.lua:879: in function </usr/lib64/prosody/net/server_select.lua:861>
[C]: in function 'xpcall'
/usr/lib64/prosody/../../bin/prosody:400: in function 'loop'
/usr/lib64/prosody/../../bin/prosody:431: in main chunk
[C]: ?
Ja das ist die Importierte von 0.9.x, jedoch hab ich unlängst bei das Datenbank Schema updaten lassen.
Und was mod_mam angeht, wird wohl ja Version genommen, die mit 0.10 geliefert wurde :). Denn die prosody-modules Version hab ich gar nicht mehr dazu gepackt.
