http-upload in Prosody aktivieren

Um nun auch Bilder in den XMPP-Chaträumen versenden zu können, habe ich den http-upload in Prosody aktiviert. Dazu wurde zuerst ein A-Record für die Subdomain upload.intux.de angelegt. Danach musste mein Let’s Encrypt Zertifikat, welches für intux.de und www.intux.de gültig war, noch erweitert werden.

# /opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --rsa-key-size 4096 -d intux.de -d www.intux.de -d upload.intux.de

Im Anschluss wurden die Zertifikate noch in das entsprechende Verzeichnis /etc/prosody/certs kopiert.

# cp /etc/letsencrypt/live/intux.de/fullchain.pem /etc/prosody/certs
# cp /etc/letsencrypt/live/intux.de/privkey.pem /etc/prosody/certs
# chown root:prosody /etc/prosody/certs -R

Ich habe die Config von Prosody geöffnet

nano /etc/prosody/prosody.cfg.lua

und um

modules_enabled = {

.....
"http_upload";

.....
}

und 

Component "upload.intux.de" "http_upload"

erweitert. Danach wurde Prosody neu gestartet und http-upload aktiviert.

# /etc/init.d/prosody restart

Tipp

In Gajim muss das Plugin HttpUpload nachinstalliert werden.

Unerwünschte Anmeldungen in Prosody

Seit einiger Zeit kommt es auf meinem XMPP-Server immer wieder verstärkt zu Registrierungen von Spam-Accounts. Die neuen User sehen dann in etwa so aus:

l0v382l0stdust348@domain.tld

Das Schlimme dabei ist, dass solche Anmeldungen fast im Minutentakt erfolgen und sich so plötzlich dutzende neue unerwünschte Accounts in die Datenbank eintragen. Als erste Reaktion sperrte ich früher i.d.R. für eine gewisse Zeit die öffentliche Anmeldung. Da die Angriffe jedoch meist von ein und derselben IP kommen, kann man diese mit folgendem Eintrag in der /etc/prosody/prosody.cfg.lua recht erfolgreich abwehren.

Dazu setzt man dies entsprechende IP auf die Blacklist zur Registrierung. Hier ein Beispiel:

allow_registration = true
min_seconds_between_registrations = 300
registration_blacklist = { "83.218.198.86" }

Dabei werden Registrierungen zwar erlaubt, jedoch nur alle 300 Sekunden. Die IP von der die Spam-Registrierungen ausging wird gesperrt.

Prosody kann auch nerven

Es hat einige Zeit gedauert bis ich den HTTP Server unter Prosody vernünftig einbinden konnte. Eigentlich wollte ich ja nur das Webinterface mod_admin_web nutzen. Egal wie ich es anstellte, ich bekam keinen Zugang, trotz Befolgung der Installationshinweise. 

Prosody Webadmin

Das Problem kam eigentlich nur zustande, da ich die Config aus meinem Artikel zur Installation des XMPP-Servers auf Uberspace übernommen hatte. Hierbei wurde der VirtualHost vor den SSL-Pfaden gesetzt. Dies macht aber den Zugang zum HTTP-Server unmöglich. 

Nachdem ich den VirtualHost, wie in meiner aktuellen Config nach den SSL-Pfaden eingetragen hatte, konnte ich endlich auch mein Webadmin wie gewünscht erreichen.

Auszug aus meiner alten Konfiguration bei Uberspace

Hier nun meine aktuelle prosody.cfg.lua:

pidfile = "/var/run/prosody/prosody.pid"

storage = "sql"
 
sql = {
    driver = "MySQL";
    database = "prosody";
    host = "localhost";
    username = "bn";
    password = "pw";
}

plugin_paths = { "/usr/lib/prosody/prosody-modules/" }

admins = {"admin@domain.tld" }
modules_enabled = {
	"roster";
	"saslauth";
 	"tls";
	"dialback";
	"disco";
	"private";
	"vcard";
	"privacy";
	"version";
	"uptime";
	"time";
	"ping";
	"posix";
	"pep";
	"register";
	"admin_adhoc";
	"motd";
	"welcome";
	"proxy65";
	"watchregistrations";
	"register_web";
	"admin_web";
	"http_upload";
}

log = {
 debug = "/var/log/prosody/prosody.log";
 error = "/var/log/prosody/prosody.err";
}

c2s_require_encryption = true  
s2s_require_encryption = true
s2s_secure_auth = true
s2s_secure_domains = { "trashserver.net", "jabber.de", "c0by.de", "jabber.org", "xmpp.org", "xmpp.maltris.org" }
s2s_insecure_domains = {}

proxy65_ports = { 55555 }

authentication = "internal_hashed"

allow_registration = true
min_seconds_between_registrations = 300
registration_blacklist = { "83.218.198.86" }

ssl = {
        key = "/etc/prosody/certs/privkey.pem";
        certificate = "/etc/prosody/certs/fullchain.pem";
       
        dhparam = "/etc/prosody/certs/dh-4096.pem";
 
        ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
 
        options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" }

}

VirtualHost "domain.tld"

register_web_template = "/etc/prosody/register-templates/Prosody-Web-Registration-Theme"

Component "proxy.domain.tld" "proxy65"

	proxy65_acl = { "domain.tld" }

Component "conference.domain.tld" "muc"
        name = "Prosody Chatrooms"
        restrict_room_creation = false

Component "upload.domain.tld" "http_upload"

Prosody – Migrator

Vor ein paar Tagen habe ich nachträglich Prosody auf meinem Server an eine MySQL-Datenbank angebunden. Diese Funktion hat einige Vorteile gegenüber der herkömmlichen Speicherung der Daten im Datenverzeichnis. 

Die Anbindung an MySQL ist relativ einfach. Deshalb möchte ich hierauf nicht weiter eingehen.

Mit dem Prosody Migrator kann man nun den Altbestand der User in die Datenbank übernehmen. Der Pfad des Datenverzeichnisses ist in meinem Fall /etc/prosody/data. Zu beachten wäre, dass alle schon vorhandenen User-Daten dabei überschrieben werden.

Um mit der Migration zu beginnen, wechselt man in das Verzeichnis in dem der Ordner „data“ liegt. 

# cd  /etc/prosody

Von der Beispiel-Konfiguration sollte man vorhe eine Sicherung anlegen.

# cp migrator.cfg.lua migrator.cfg.lua_bak

Nun öffnet man die Config und bearbeitet diese folgendermaßen:

# nano migrator.cfg.lua
local data_path = '/etc/prosody/data';

input {
type = "prosody_files";
path = data_path;
}

mydatabase {
type = "prosody_sql";
driver = "MySQL";
database = "Name der Datenbank";
username = "Benutzername der Datenbank";
password = "Passwort der Datenbank";
host = "localhost";
}
--[[

input {
type = "prosody_files";
path = data_path;
}
output {
type = "prosody_sql";
driver = "SQLite3";
database = data_path.."/prosody.sqlite";
}

]]

Hierbei ist der Pfad (falls data woanders liegt) sowie die Zugangsdaten zur MySQL-Datenbank anzupassen. Das Ganze speichert man mit Ctrl + o und verlässt den Editor mit Ctrl + x. Nun migriert man mit 

# prosody-migrator input mydatabase

alle bestehenden Accounts. Erscheint

Migrating…
Done!

war die Migration erfolgreich.

Viel Spaß!

Uberspace – Prosody 0.9.10 => 0.9.11

Seit einiger Zeit betreibe ich meinen eigenen XMPP-Server auf meinem Uberspace. Mittlerweile wird auch dieser Server mit einem Let’s Encrypt Zertifikat verschlüsselt. 

Da ich nun gestern dabei war Roundcube zu aktualisieren und alles so reibungslos lief, habe ich mich im Nachgang an Prosody gewagt. Hier lief noch die Version 0.9.10.

Zuerst wurde der Service angehalten,

svc -d ~/service/prosody
toast disarm prosody

dann die neue Version 0.9.11 installiert

toast arm https://prosody.im/downloads/source/prosody-0.9.11.tar.gz

und die Beispiel-Config nach ~/etc/prosody/ verschoben.

mv ~/.toast/armed/etc/prosody/prosody.cfg.lua ~/etc/prosody/prosody.cfg.lua.stock

Nun musste der Symlink zur Config erneut erstellt werden.

ln -s ~/etc/prosody/prosody.cfg.lua ~/.toast/armed/etc/prosody/prosody.cfg.lua

Im Anschluss wurde der Service zu Prosody neu gestartet

svc -u ~/service/prosody

und die alte Version 0.9.10 deinstalliert.

toast remove https://prosody.im/downloads/source/prosody-0.9.10.tar.gz

Ein abschließender Check zeigt nun aktuelle Version (siehe Screenshot).

toast status prosody

Nachtrag

Einige Anpassungen habe ich laut der Anleitung https://0101010.one noch nachgeschoben. Dazu gehören eine neue OpenSSL-Version sowie zwei Anpassungen von Lua.

Check der Version von OpenSSL vorher:

openssl version
toast arm https://www.openssl.org/source/openssl-1.0.2j.tar.gz && . ~/.bash_profile

Check der Version von OpenSSL nach der Installation:

openssl version

Check der Versionen der Lua-Module vorher:

luarocks list
luarocks install luafilesystem --local
luarocks install luasec 0.5.1 --local OPENSSL_DIR=~/.toast/armed/usr/local/

Check der Versionen der Lua-Module nach der Installation:

luarocks list

Let’s Encrypt und Prosody

Nachdem mein Let’s Encrypt Zertifikat via Skript auf Uberspace erneuert wurde, bekam ich genau 10 Tage später, beim Aufbau der Verbindung zu meinem XMPP-Server, eine Fehlermeldung, dass mein Zertifikat für Prosody abgelaufen sei. Obwohl ich auf die Symlinks meines Zertifikates und des privaten Schlüssels in der Config verwies.

ssl = {  
        key = "/home/intux/var/prosody/ssl/prosody_intux.de_private.key";
        certificate = "/home/intux/var/prosody/ssl/prosody_intux.de.crt";

Prosody lief quasi seit dem Aussetzen durchweg und wusste somit nichts von der Erneueung des Zertifikats. Dies kann man aber durch Stoppen und erneutem Starten des Service Prosody mitteilen. Dies geht auf Uberspace so:

svc -du ~/service/prosody

Ob der Service dann wieder fehlerfrei arbeitet checkt man wie folgt:

tail ~/service/prosody/log/main/current | tai64nlocal
2016-07-15 17:57:55.518977500 c2s2754260 info Client disconnected: closed
2016-07-15 17:57:55.518994500 c2s2a5d350 info Client connected
2016-07-15 17:57:55.518995500 c2s2a5d350 info Client disconnected: closed
2016-07-15 17:57:55.518996500 c2s28ec9c0 info Client connected
2016-07-15 17:57:55.518996500 c2s28ec9c0 info Authenticated as intux@intux.de
2016-07-15 17:57:55.518997500 c2s2805cb0 info c2s stream for intux@intux.de/phone closed: Replaced by new connection
2016-07-15 17:57:55.519038500 c2s2805cb0 info Client disconnected: connection closed
2016-07-15 17:57:55.519039500 c2s28ec9c0 info Client disconnected: closed
2016-07-15 17:57:55.519040500 s2sout2739140 info Beginning new connection attempt to jabber.cz ([88.86.102.58]:5269)
2016-07-15 17:57:55.519041500 s2sout2739140 info outgoing s2s connection intux.de->jabber.cz complete

Ein halbes Jahr Uberspace

Seit einem halben Jahr bin ich nun Ubernaut. Irgendwie musste ich aber erst zu meinem Glück gezwungen werden, obwohl ich mit meinem damaligen Hoster und dessen Angebot bzw. meinem Vertrag recht zufrieden war. Ich hatte inzwischen einiges über Uberspace gelesen. Nun wollte auch ich mich auf dieses Abenteuer einlassen.

Was hatte ich für Erwartungen?

Eigentlich hatte ich keine Großen. Ich wollte Webspace, einen eMail-Account, eine Domain und und dazu einen geekigen SSH-Zugang. Das war es eigentlich auch schon. Der Wermutstropfen dabei ist jedoch, dass dem Ubernauten leider nur magere 10GB zur Verfügung stehen. Das sollte aber vorerst reichen dachte ich mir.

Also gesagt, getan. Ich habe mir einen Zugang  eingerichtet und vergeblich nach der Möglichkeit gesucht meine Domain zu Uberspace mitzunehmen. Diese Option wurde inzwischen abgeschafft, da man der Meinung ist, das Hosting sollte strikt von der Domain getrennt werden. Anfangs gefiel mir das nicht und im Zusammenhang mit der Größe des gebotenen Webspace hätte ich hier fast einen Rückzieher gemacht. Inzwischen finde ich die Idee dahinter sehr gut, wenn die Domain bei einem anderen Anbieter, wie in meinem Fall bei INWX liegt. Hier bieten sich vielfältige Möglichkeiten Records, wie A,AAAA, MX etc. nach Belieben zu setzen. Gerade bei einem Umzug ist das wichtig, damit keine Mail verloren geht. Nachdem ich meinen SFTP-Zugang eingerichtet und meine Daten übertragen hatte, stieß ich auf das nächste Problem. Es kam zu einer Unverträglichkeit meiner MySQL-Datenbank (Version 5). Hier wurde mir jedoch eine Alternativmöglichkeit aufgezeigt diese auf einem anderen MariaDB-Server einzuspielen. Sicher ist es nicht einfach gewesen alles zu Laufen zu bekommen. Doch da mir das Terminal und SSH durch meine Linux-Vorgeschichte nicht unbekannt waren, bekam ich auch Dank des tollen Supports von Uberspace alles recht schnell zum Laufen. Die Einrichtung der eMail und der SSL-Verschlüsselung via Let’s Encrypt war dabei ein Kinderspiel.

Da nun alles lief wie beim alten Hoster, war ein wenig experimentieren angesagt. So wurde ein XMPP– und einen Cloud-Server installiert. Ich konnte dadurch zwei Raspberry Pi vom Netz nehmen und nebenbei auch noch Strom sparen.

Alles in Allem ist Uberspace im Moment für meine Bedürfnisse der beste Hoster. Die Probezeit ist damit offiziell für mich beendet!

Wer sich also nicht davor scheut tiefer in die Technik einzutauchen und sein Hosting-Paket nach seinem eigenen Gusto anzupassen, dabei das Ganze über die Kommandozeile zu erledigen, wird mit Uberspace in eine neue Galaxy eintauchen. Das alles mit einem Preis-Modell was seinesgleichen sucht.

WeeChat für IRC

news-707

news-708

Seit ein paar Tagen beschäftige ich mich mit dem Internet Relay Chat (IRC). Um hier in die entsprechenden Chaträume zu gelangen, muss man sich mit einem IRC-Netzwerk verbinden. Eines der beliebtesten ist Freenode. Diese Kommunikationsplattform wird rege von der Open Source Community genutzt.

Um im IRC jedoch chatten zu können, benötigt man einen entsprechenden Client. Linux-Nutzer können hier schnell auf grafische Lösungen wie Pidgin oder Empathy zurückgreifen, die meist schon vorinstalliert sind und genau das tun was man von ihnen verlangt. Nach der Verbindung zu einem Netzwerk wie Freenode, kann man sofort in den gewünschten Chatraum springen.

Da ich den Jabber-Client MCabber immer häufiger einsetze, wollte ich für den IRC auch einen entsprechenden Terminal-Client. So bin ich nach einigen Tests bei WeeChat gelandet. WeeChat ist schlank und ressourcensparend. Die Bedienung ist nach ein wenig Einarbeitung recht einfach und übersichtlich. Eine umfangreiche deutsche Benutzeranleitung sowie ein Quickstart-Anleitung helfen dabei sich schnell zurecht zu finden. WeeChat wirkt auf mich auf den ersten Blick wie der große Bruder von MCabber.

Für die Bedienung habe ich hier die für mich wichtigsten Befehle kurz zusammen gestellt.

IRC – Befehle und Tastenkombinationen

/connect freenode – Verbinden
/nick „neuer Nick“ – Nicknamen ändern
/join #“Raum“ – Raum betreten
/query „Benutzername“ „Nachricht“ – Einzelchat mit User
/list -re #ubuntu.* – Räume auflisten die mit „ubuntu“ anfangen
/msg nickserv register „Passwort“ „eMail“ – Registrierung
/msg nickserv identify „Benutzername“ „Passwort“ – Login
/msg ChanServ REGISTER #“Channel“ – Channel registrieren
/msg chanserv op #“Raum“ – OP wiedererlangen
/close – WeeChat verlassen
/quit – WeeChat beenden
Bild-Tasten – im Hauptfenster blättern
F5 / F6 – zwischen Fenstern blättern
F11 / F12 – in User-Liste blättern
Alt + a – wechseln zum aktiven Fenster
/close – Raum schließen
/quit – WeeChat beenden

Problem mit der CPU-Last auf Uberspace gelöst

200px-XMPP_logo.svg

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„).

Dazu ist es notwendig den Service zu beenden.

svc -d ~/service/prosody

Nun wird die Config geöffnet

nano ~/etc/prosody/prosody.cfg.lua

und folgende Zeile vor s2s eingetragen. Hierzu muss man die IPv4 und die IPv6 an den entsprechenden Uberspace-Server anpassen.

interfaces = { "IPv4-Adresse", "IPv6-Adresse " } -- IPv4-Adresse und IPv6-Adresse des Uberspace-Servers eintragen!

news-705

Dann wird der Service neu gestartet und Prosody läuft wie gewünscht flott und ohne Probleme.

svc -u ~/service/prosody

Viel Spaß!