Nach der Installation folgt die Konfiguration des IRC-Servers. Die spielt sich im Wesentlichen in einer Datei namens
»ircd.conf
«
ab, die unter Verwendung des Standard-Präfix in
»/usr/local/ircd/etc/ircd.conf
«
liegen muss. Wer früher bereits einen IRC-Server konfiguriert hat, erinnert sich an deren etwas kryptische Syntax, bestehend aus I-Lines, O-Lines, C-Lines sowie den berüchtigten K-Lines, die Benutzer vom Server aussperren. Geblieben ist von dieser Syntax in Ratbox nichts, stattdessen kommt eine Syntax mit einzelnen Konfigurations-Abschnitten zum Einsatz, die das Verständnis der Konfiguration deutlich erleichtern.
Es kann an dieser Stelle nicht jeder einzelne Konfigurationsparameter diskutiert werden, aber im Quelltext-Ordner von Ratbox findet sich in
»doc
«
eine
»exmaple.conf
«
, die als Grundalge für
» ircd.conf
«
gute Dienste leistet. Viele Einträge erklären sich von selbst: So ist im Abschnitt
»serverinfo
«
in der Beispieldatei der Eintrag
»hades.arpa
«
durch den Namen zu ersetzen, den der IRC-Server haben soll (hierbei muss es sich übrigens nicht um einen per DNS auflösbaren Hostnamen handeln).
Im gleichen Abschnitt ist auch der Name des IRC-Netzwerks anzugeben und eine kurze Beschreibung dieses Servers. Weiterhin sollten die Ports definiert sein, an denen Ratbox auf eingehende Verbindungen wartet (der klassische IRC-Port aus Gewohnheit ist 6667, er ist bei den meisten Clients voreingestellt).
Interessant ist der
»auth
«
-Abschnitt, denn in diesem legen Admins fest, wer sich überhaupt mit dem IRC-Server verbinden darf. Einträge dieses Typs dürfen in der Konfiguration mehrmals vorkommen, um verschiedenen IP-Bereichen oder Hosts den Zugriff zu erlauben. Interessant ist das
»spoof
«
-Keyword: Darüber lässt sich ändern, welchem Host eine Person zugeordnet ist. Das wird innerhalb des IRC-Netzes angezeigt. Wer beispielsweise einen IRC-Server nicht nur für die interne Kommunikation im Unternehmen betreibt, sondern auch Kunden den Zugriff für Support-Zwecke erlaubt, kann die Mitarbeiter des Unternehmens so kennzeichnen.
Nicht zuletzt lassen sich mittels einer
»class
«
-Definition Benutzerklassen festlegen, denen einzelne
»auth
«
-Abschnitte danach zuzuweisen sind. Über das System der Benutzerklassen lässt sich festlegen, wie viele Benutzer pro
»auth
«
-Eintrag gleichzeitig mit dem Server verbunden sein dürfen, wann der Server die Verbindung kappt, wenn er keine Antwort auf seine Ping-Requests erhält, und wie groß die internen Puffer sind, die der Server pro verbundenem Client dieser Klasse anlegt.