Wie ich meinen XMPP-Server auf Uberspace eingerichtet habe, wurde ich im Artikel „XMPP-Server auf Uberspace mit vorhandenem WoSign-Zertifikat installieren“ bereits erläutert. Nun wagte ich mich daran Prosody von Version 0.9.8 auf die aktuelle 0.9.10 zu schieben. Hierbei war die Gesamt-Anleitung auf pomm.es sehr hilfreich.
Ubernauten, die das Upgrade installieren wollen, brauchen jedoch starke Nerven, da die CPU-Last des Service Lua auf ca. 100% ansteigt. Das hat wieder zur Folge, dass man sich für mindestens 40 Minuten aussperrt. Irgendwann beruhigt sich das Ganze und eine Einwahl ist wieder möglich. Die Kontakte etc. erscheinen dann sehr langsam und zeitversetzt.
Empfehlen würde ich deshalb, das Upgrade am späten Abend durchzuführen und mit den ersten Einwahl-Versuchen bis zum nächsten Tag abzuwarten.
Nun zur Vorgehensweise. Zuerst wurde der Service von Prosody beendet und danach die aktuelle Version Prosody 0.9.10 aus dem Netz geladen.
|
1 |
svc -d ~/service/prosody |
|
1 |
toast disarm prosody |
|
1 |
toast arm https://prosody.im/downloads/source/prosody-0.9.10.tar.gz |
Da meine alte Beispiel-Config aus irgendwelchen Gründen nicht beschreibbar war, musste dies vorab noch geändert werden.
|
1 |
chmod 644 ~/etc/prosody/prosody.cfg.lua.stock |
Im Anschluss habe ich die Beispiel-Config nach ~/etc/prosody/ verschoben.
|
1 |
mv ~/.toast/armed/etc/prosody/prosody.cfg.lua ~/etc/prosody/prosody.cfg.lua.stock |
Dann wurde der Symlink erneut erstellt
|
1 |
ln -s ~/etc/prosody/prosody.cfg.lua ~/.toast/armed/etc/prosody/prosody.cfg.lua |
und der Service wieder gestartet.
|
1 |
svc -u ~/service/prosody |
Die alte Version 0.9.8 konnte anschließend so entfernt werden.
|
1 |
toast remove https://prosody.im/downloads/source/prosody-0.9.8.tar.gz |
Bei mir gab es keinen signifikanten Anstieg der CPU-Last. Alles läuft wie geschmiert. Deine Site befindet sich wahrscheinlich auf irgendeinem Auslaufmodell von Server.
@didi Kann ich nicht bestätigen. Das Problem Problem tritt bei mehreren Usern auf unterschiedlichen Servern auf.
Ah danke für die Rückmeldung! Dachte schon, dass ich mir irgendein Problem eingehandelt hatte, da der Service bei mir zum Anfang auch instabil war…
Hello, fellow uberspacelings… 🙂
Bin neu in der Familie und spiele gerade mit prosody auf uberspace herum; dabei hänge ich jetzt irgendwie fest… Vielleicht könnt Ihr mir ja helfen?
Also ich bin der schönen pomm.es/cosmofox Anleitung in weiten Teilen gefolgt,
(siehe -> https://pomm.es/hosting/Uberspace/prosody.html),
bekomme jedoch solche Fehlermeldungen ausgegeben:
LuaSec, das hier augenscheinlich nicht gefunden wird, habe ich aber nach der Anleitung installiert und die Ausgaben von „luarocks list“ bzw. „prosodyctl about“ spiegeln das auch wieder.
Kennt jemand das Problem?
Hallo mo,
vergleiche bitte mal Deine Vorgehensweise hiermit:
https://www.intux.de/2016/02/xmpp-server-auf-uberspace-mit-vorhandenem-wosign-zertifikat-installieren/
Dabei habe ich mich aber auch im Grunde an die Anleitung von pomm.es gehalten. Was genau bei Dir los ist kann ich aus der Ferne nicht sagen.
Setzt Du ein SSL-Zertifikat ein?
Hallo intux,
dein Walkthrough hatte ich dazu auch quergelesen, fällt mir gerade auf, wie inzwischen wahrscheinlich jede halbwegs aktuelle Anleitung mit keywords „uberspace“ + „prosody“ :/
Ja, ich setzte ein SSL-Zertifikat von Let’s Encrypt ein, für’s web funzt das auch.
Wie in der pomm.es Anleitung vorgeschlagen, habe ich das Zertifikat und den key nach ~/var/prosody/ssl/ gesymlinkt und entsprechend in meine prosody config eingetragen.
Natürlich gibt es bei meinen Versionsnummern leichte Abweichungen zur pomm.es „Referenz“…
Schau mal noch hier:
https://geeklabor.de/archives/194-Eigener-XMPP-Server-mit-Prosody-auf-Uberspace.html
Du darfst nicht die aktuellste Lua-Vesion verwenden, soviel ich weiß.
Da war ich auch schon… und Lua ist auch eine 5.1.* …also ich würde auch nicht fragen, wenn ich nicht schon viel Zeit damit verbracht hätte, denn ich möchte deine auch nicht verschwenden.
Werde mich nochmal in die Lektüre des geeklabor-Links vertiefen, vielleicht fallen mir ja gleich die Schuppen von den Flossen…
In diesem Sinne,
danke soweit! und bis später 🙂
Hi mo,
also anhand der Fehlermeldung würde ich erstmal ausschließen, dass es irgend etwas mit deinen Zertifikaten ansich zutun hat. Bist du dir sicher, dass du in dein .bash_profile LUA_PATH und LUA_CPATH korrekt angegeben hast? Hast du die Änderung danach mit source ~/.bash_profile aktiviert bzw. dich neu angemeldet? Was gibt denn „echo $LUA_PATH“ aus?
Hallo,
das ergibt folgende Ausgabe:
Was sagt „lua -l ssl“? Kannst du mal bitte die vollständige Ausgabe von „luarocks list“ posten?
habe an falscher stelle geantwortet… da oben 0o
@ intux: wenn ich wüsste wie, würde ich meine comments auch selbst ansehnlich formatieren… 🙂
Okay das müsste man sich jetzt mal im Detail anschauen. Wenn du magst schreib mir eine kurze Mail dann schauen wir mal.
Hallo nochmal,
danke für dein Angebot, Robert, da komme ich vielleicht auch drauf zurück, aber erstmal möchte ich versuchen, das selbst in den Griff zu bekommen… der Ehrgeiz hat mich gepackt und ich will ja auch was lernen…
Es eilt nicht, daher kann ich mich da nach Lust und Laune mit beschäftigen…
Sobald es bei mir läuft werde ich auf jeden Fall berichten!
Hab’s denke ich…
Bei der Installation von luasec via luarocks musste ich explizit die Versionsnummer 0.5.1-1 angeben. Ohne die Angabe wird eine neuere Version installiert, mit der prosody nicht arbeiten kann.
Also anstatt
luarocks install luasec –local OPENSSL_DIR=…
nimmt man
luarocks install luasec 0.5.1-1 –local OPENSSL_DIR=…
Hier steht das auch, bzgl. Versionsnummern…
https://prosody.im/doc/depends#luasec
Interessant, dass sich nicht schon mehr Leute mit dem Prob gemeldet haben…
Danke auf jeden Fall für eure Unterstützung!
Der Robert ist Guter!
Ich habe auch mit massiver CPU-Last auf meinem Prosody zu kämpfen. Wo gibt es denn noch mehr Infos bzw. Referenzen zu weiteren Menschen, die mit der CPU-Last von Prosody auf dem Uberspace zu kämpfen haben?
Mein Prosody läuft auf 100%, beruhight sich aber nicht sondern startet dann irgendwie neu 🙁
Die Logs sagen mir überhaupt nix, auch nicht mit debug infos.
Seit wann beobachtest du das?
Erst als ich diesen Artikel gestern gesehen habe, bin ich überhaupt auf die Idee gekommen, mal die CPU-Last von Prosody anzugucken.
Ich habe schon vor einiger Zeit beobachtet, dass die Antwortzeiten auf ein XMPP-Ping kurz nachdem ich mich mit Pidgin einlogge ziemlich lang waren. Das hat sich aber sonst immer beruhigt.
Dann habe ich neulich Prosody auf 0.9.10 aktualisiert und per svc -du neu gestarrtet – so dachte ich zumindest. Stellte sich heraus, dass Prosody damals gar nicht neu gestartet war, sondern schon kaum reagiert hatte. Nach einem ernsten svc -k dann hat es tatsächlich neu gestartet. In der Zwischenzeit hatte ich noch andere Module aktivieren wollen (und wieder mit svc -du neustarten).
Nachdem Prosody tatsächlich mal neu gestartet hat, beobachte ich nun diesen sehr verwirrenden Zustand:
Wenn ich s2s deaktiviere, ist alles cool. Ich kann aber dann nicht mit anderen Servern reden.
Wenn ich s2s aktiviere und mich mit einem Client einzuloggen versuche, dreht Prosody auf 100% CPU auf und irgendwann sehe ich dann in den debug logs, dass Prosody neu startet und alle Module neu hochfährt. Ohne, dass sich die Prozess-ID ändern würde. Das verwirrt mich total.
Und das unabhängig ob ich libevent benutze oder nicht.
Das verwirrende: Ich kann prosody nicht mit svc -t zum stoppen bringen. Ich muss svc -k benutzen, damit Prosody in endlicher Zeit anhält.
🙁
Du könntest den Dienst mit
beenden und dann den Dienst neu starten.
Mittlerweile habe ich noch etwas mit der Config herumgespielt. Libevent ist jetzt deaktiviert.
Es zeigt sich, dass Prosody jetzt schon seit über einer Stunde läuft und – wenn sich *kein* client verbindet, alles OK zu sein scheint. Solange der Client mit dem Server reden will, dreht letzterer auf 100% auf, woraufhin er kaum noch antworten kann. Dann bekommt der Client ein Timeout und der Server beruhigt sch wieder.
Auch das IM Observatory von xmpp.net gibt mir ein schönes Resultat für die Sicherheits-Settings, solange der Server klar kommt. Interessanterweise geht die CPU-Last nicht merklich hoch, wenn xmpppoke mein Prosody durchtestet.
Nur wenn sich dann mein Client verbinden will, dreht Prosody einfach durch. Vielleicht habe ich ja zu viele Kontakte in meinem Roster? Also genügend, dass Prosody eigentlich libevent benutzen müsste, das aber aus Gründen [irgendein Bug irgendwo] nicht geht.
Ich hatte genau das selbe Problem. Zu viele Kontakte würde ich ausschließen ich hatte gerade mal zwei in meiner… Leider konnte ich bisher auch noch nicht ergründen woran es liegt. Es scheint auch kein generelles Problem mit Prosody zu sein, auf einem anderen Server schnurrt Prosody ohne Probleme. Bleiben eigentlich nur irgeend welche Bedingungen in der Uberspace Umgebung die Prosody nicht mag.
o_O
Prosody kommt gerade wieder klar!
Pidgin ist verbunden und zeigt mir ein paar Kontakte als online an 🙂
Die CPU-Auslastung ist quasi Null.
🙁
Zu früh gefreut. Ich habe dann auch mal Conversations versucht mit dem Server zu verbinden – Dann ist die Last wieder hoch auf 100 und beide Clients haben einen Tiemout bekommen.
:-[
Ich hab auch (immernoch) das Lastproblem und nun testweise mal die für mich neuen Module (HTTP, HTTP_UPLOAD, MUC, …) deaktiviert. Scheint leider nichts zu bringen, ich hab immernoch ~45% CPU
Der Robert hier scheint das Problem auch zu haben: https://geeklabor.de/index.php?url=archives/194-Eigener-XMPP-Server-mit-Prosody-auf-Uberspace.html&serendipity%5Bcsuccess%5D=moderate#feedback
Robert hatte weiter oben schon erwähnt, dass er das Problem auch hatte.
Ich glaube nicht, dass das irgendwie an HTTP oder MUC liegt – nach meinem downgrade auf prosody 0.9.9 scheint alles zu laufen.
Probleme mit der Last hatte ich unter 0.9.8 genau wie unter 0.9.10. Irgendwann beruhigt sich das Ganze.
Bei aktiviertem MUC und einem neu erstellten Chatraum geht es jedoch wieder von vorn los. Es dauert dann ca. 10 Minuten bis sich alles wieder beruhigt. Während dieser Zeit kann ich mich weder mit dem Notebook noch mit dem Smartphone anmelden.
Man sollte vielleicht die Problematik in ihrer vollen Komplexität nochmals dem Support melden.
Habe mal ein wenig herumprobiert und ein ticket geöffnet
https://prosody.im/issues/issue/649
Ihr könnt gerne euren Senf dazu beitragen.
Ich habe jetzt erstmal downgegraded auf Prosody 0.9.9 – dann funktioniert der Server wenigstens erstmal wieder.
Ja bei mir auch (inkl. aller module). Hab trotzdem dank für das ticket, ich verfolge das gespannt 🙂
Ich habe nochmal Uberspace zur Problematik mit der Last kontaktiert.
https://twitter.com/intux69/with_replies
Die Lösung des Problems:
interfaces = {„x.x.x.x“, „x:x:x::x“}
auf genau die IPv4 und IPv6 adressen setzen, unter denen Prosody (genauer: euer gesamter Uberspace) erreichbar ist. Also die Adressen, die ihr gegebenenfalls auch im DNS hinterlegt habt.
Sonst versucht Prosody auf *allen* Netzwerk-Interfaces nach Kontakten zu suchen, und die schiere Anzahl der Interfaces war auf meinem Host über 500.
https://prosody.im/issues/issue/649
Danke für den Tipp. Werde es schnellstmöglich testen.
[…] Dank Adoa Coturnix von https://ctrnx.de/ konnte das Problem mit der hohen CPU-Last des XMPP-Servers auf Uberspace endlich gelöst werden (siehe Artikel „Uberspace – Porsody 0.9.8 => 0.9.10„). […]
[…] Dank Adoa Coturnix von https://ctrnx.de/ konnte das Problem mit der hohen CPU-Last des XMPP-Servers auf Uberspace endlich gelöst werden (siehe Artikel „Uberspace – Porsody 0.9.8 => 0.9.10„). […]