irc.szaf.org

nospam@example.com (Thomas Hochstein) — Thu, 11 Feb 2021 06:20:00 +0000

Webserver sind ja nichts Besonderes, meinen eigenen Mailserver betreibe ich seit 2002, und einen “richtigen” Newsserver, der nicht nur ein paar lokale Gruppen führt, ebenfalls seit 2005 - und SSH samt SCP und Co. und ggf. FTP sind ja eh dabei. Was fehlt also noch in der Liste der “klassischen” Dienste? Richtig - derjenige, mit dem ich als letztes warm geworden bin und den ich am wenigsten nutze: IRC, der “Internet Relay Chat”.

Nach dem unerwarteten Tod eines Freundes an Ostern 2020 musste sich die Gemeinschaft der Szafe auch eine neue Lösung für die bislang mitgenutzten IRC-Server einfallen lassen, so dass in der Folge selbst ein Netzwerk aufgesetzt wurde - und da wollte ich auch gerne dabei sein und meinen eigenen Server aufsetzen und einbinden.

Installation und Erstkonfiguration

Ich befürchtete schon, das werde sicherlich ganz furchtbar kompliziert, aber dem war angenehmerweise nicht so. Die Software-Wahl war auf den ngircd gefallen, den “next-generation IRC daemon”, und der ist in Debian verfügbar: apt install ngircd reicht also aus, und dann muss nur noch ein wenig an der Konfiguration in /etc/ngircd/ngircd.conf geschraubt werden:

    Name = irc.szaf.org

    AdminInfo1 = (Info zum Administrator, Zeile 1)
    AdminInfo2 = (Info zum Administrator, Zeile 2)
    AdminEMail = (Mailadresse des Administrators)

    Info = Szeep on IRC
    ;MotdPhrase = "irc.szaf.org SzafNet IRC Server. Ready. Bleat ahead."

    Network = szafnet

    Password = Swordfish

[Limits]
    MaxJoins = 20
    MaxNickLength = 25

Wenn man will, kann man auch noch die Zugangsdaten für einen IRC-Operator hinterlegen:

[Operator]
    Name = thh
    Password = pass123

TLS

Dazu dann noch eine Webseite, über die es ein Zertifikat von Let’s encrypt gibt, das man dann auch dem IRC-Server verfüttern kann; die grundsätzliche Vorgehensweise hatte ich ja bereits vor knapp fünf Jahren beschrieben.

Erstmal das Zertifikat einkopieren …

mkdir /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/fullchain.pem /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/privkey.pem /etc/ngircd/certs/

… und in der Konfiguration (/etc/ngircd/ngircd.conf) einrichten:

[SSL]
    # SSL-related configuration options.
    CertFile = /etc/ngircd/certs/fullchain.pem
    KeyFile = /etc/ngircd/certs/privkey.pem
    Ports = 6697

Nach service ngircd restart sind wir dann im Geschäft.

Das ganze lässt sich auch automatisieren - ich baue mir ein kurzes Shellscript, bspw. /etc/ngircd/certbot-deploy-certs.sh:

#!/bin/dash
cp /etc/letsencrypt/live/irc.szaf.org/fullchain.pem /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/privkey.pem /etc/ngircd/certs/
/usr/sbin/service ngircd reload

und mache es ausführbar (chmod 755 /etc/ngircd/certbot-deploy-certs.sh) und setze einen entsprechenden Cronjob vor denjenigen, der alle abgelaufenen Zertifikate rundum erneuert.

Ein kleines Manko hat die ganze Sache noch: leider kann erst der ngIRCd 26~rc1 ein TLS-Zertifikat im laufenden Betrieb nachladen, wenn er mit GnuTLS arbeitet, wie das bei Debian der Fall ist; in früheren Versionen geht das nur bei OpsenSSL. Leider hat Debian Stretch nur die Version 24-1, und auch das aktuelle Debian Buster nur die Version 25-2. Das Script funktioniert also bisher nicht; zwar wird das neue Zertifikat einkopiert, aber der Server verarbeitet es nicht. Dafür wäre ein service ngircd restart notwendig - der aber die Verbindung zu allen Clients und allen verbundenen Servern trennt. Bislang habe ich daher einen alle drei Monate wiederholten Eintrag in meinem Todo-System, um nach dem Zertifikat zu schauen und ggf. den Server manuell zu starten. Mit dem künftigen Debian Bullseye sollte das dann ein Ende haben.

Vernetzung mit anderen IRC-Servern

Alleine chatten ist nett, ein IRC-Netzwerk aufzubauen noch netter. Zu diesem Zweck muss man dem ngircd nur verklicken, welche anderen Server “dazugehören”, und mit denen ein Passwort vereinbaren. Jeder Serverbetreiber notiert dann das eigene Passwort und das der Gegenstelle in der Konfiguration, und schon vernetzen sich die Server - jeder allerdings immer nur mit einem anderen, die Topologie bildet also Linien, keine Sterne. Wenn aber ein Server aus dem Netz fällt, bspw. weil er restartet wird, verbinden sich die verbleibenden Server neu, bis sie alle wieder miteinander verbunden sind.

Eine solche Konfiguration kann dann bspw. so aussehen:

[Server]
    Name = irc.anderer-server.example
    Host = irc.anderer-server.example
    Port = 6697
    MyPassword = OhmyOhmyOhmy
    PeerPassword = Ramalamadingdong
    Group = 1
    Passive = no
    SSLConnect = yes

Das weist diesen Server der Gruppe 1 zu (wenn ein Server innerhalb einer Gruppe nicht verfügbar ist, wird ein anderer ausprobiert), lässt automatische Verbindungen zu und verlangt dafür SSL/TLS. Die Gegenstelle (irc.anderer-server.example) muss natürlich die Werte für MyPassword und PeerPassword vertauschen.

Server neu starten, et voilà: das IRC-Netzwerk steht. Das war einfach - und tut seit April 2020 sehr zuverlässig.

Titelbild © AliFuat - stock.adobe.com

[Nachträglich veröffentlicht im August 2021.]

Strange things are happening

nospam@example.com (Thomas Hochstein) — Sun, 24 Apr 2016 09:00:00 +0000

Nach über einem Jahrzehnt habe ich dieser Tage mal wieder einen Eggdrop installiert und konfiguriert - einen IRC-Bot, für diejenigen, denen letzteres mehr sagt als ersteres. Das ist ganz praktisch, denn u.a. loggt der Bot einen Channel mit, so dass sich aus dem Log ebenso lustige wie unsinnige bunte Statistiken erzeugen lassen, und zum anderen kann er mir morgens das Logfile des letzten Tages mailen, damit ich nichts wichtiges verpasse: FOMO at its best. (Wobei ich gestehen muss, seit Jahren nicht mehr in die Mails hineingeschaut zu haben, aber nun gut.)

Eigentlich ist das gar nicht so schwer: es gibt ein Debian-Paket, die Konfiguration ist weitgehend selbsterklärend und lässt sich ansonsten aus der alten Installation ableiten, einige wenige Scripts samt gesammelter Daten und Konfiguration lassen sich umkopieren … und dann sollte alles tun.

Heute morgen habe ich dann einmal in die Mail mit dem gestrigen Channel-Log geschaut und festgestellt, dass der Bot irgendwann aufgehört hat, den Chat zu loggen. Ereignisse (/join und /leave) sind da, Actions (/me) auch, aber der eigentliche Chat nicht. Höchst seltsam, nachdem der Bot bereits einige Tage lang - und bis gestern nachmittag - ordnungsgemäß funktioniert hat. Es muss also irgendetwas mit den gestrigen Modifikationen zu tun gehabt haben. Nur was?

Die Ursachensuche, für die ich auf Google angewiesen bin - nein, Tcl spreche ich nicht -, wird nicht gerade dadurch erleichtert, dass offenbar die DNS-Einträge für egghelp.org aus dem Netz gefallen sind: die zuständigen Nameserver, die sich aus dem whois-Eintrag ableiten lassen, haben sie noch, aber offenbar fehlen in der .org-Zone die Einträge für die Nameserver. So muss also der Google-Cache herhalten. (Oder man hilft dem System durch einen passenden Eintrag in die /etc/hosts bzw. C:\Windows\System32\drivers\etc\hosts auf die Sprünge, aber ich schweife ab.)

Jedenfalls ist die Lösung dann eine der Art, auf die man sicherlich nie von alleine gekommen wäre:

There is a known “issue” with pubm-bindings in eggdrop1.6.18; If the command invoked returns 1 (TCL_OK), eggdrop will not log the message that triggered the binding.
I would suspect this to be the reason why your bot does not log public chat, that is, there seems to be a script running on your system with a pubm-binding that blocks public chat from being logged on that channel.

10 Jahre alt ist der Foreneintrag, aber offenbar immer noch stimmig (auch für eggdrop 1.6.21). Es läuft nämlich tatsächlich seit gestern nachmittag ein Script, das (u.a.) per bind pubm “public chat” in eine Funktion umleitet (um nämlich zu zählen, wer wieviel sagt - für sinnlose Statistiken, ich erwähnte es schon). Und diese Funktion hat keinen Rückgabewert, was offenbar einem impliziten return 1 entspricht.

Also habe ich versuchsweise ein return 0 am Ende der Funktion eingefügt und den Bot neu gestartet - alles paletti.

Computer sind seltsame Wesen.

Netz - Rettung - Recht (Artikel mit Tag irc)

irc.szaf.org

Installation und Erstkonfiguration

TLS

Vernetzung mit anderen IRC-Servern

Strange things are happening