Diese Anleitung wurde exklusiv zur Verwendung von UnrealIRCd geschrieben. Die Verwendung des Textes mit anderer Software oder das Anbieten zusammen mit anderer Software ohne schriftliche Genehmigung des UnrealIRCd Entwicklungsteams ist streng verboten. Solange es der Benutzung von UnrealIRCd dient, darf dieses Dokument beliebig kopiert/gedruckt/veröffentlicht, jedoch nicht verändert werden. – Copyright UnrealIRCd Development Team 2002-2004

Bitte lesen Sie diese Anleitung, bevor Sie um Hilfe bitten und schauen Sie WIRKLICH erst ein mal in die FAQ, da rund 80% der Fragen dort beantwortet sind. Hilft dies alles nicht, kann bzgl. Support bei irc.ircsystems.net (Port 6667) Channel #unreal-support nach Unterstützung gefragt werden (Wir erwarten UNBEDINGT, dass zuvor Dokumentation und FAQ gelesen wurden und wir helfen nur zu UnrealIRCd, nicht zu Services!). Im Falle eines echten Bugs (z.B. einem Crash) bitte Nachricht an http://bugs.unrealircd.org.

Bei einem Upgrade von Unreal3.1.x auf Unreal3.2 wird als erstes die völlig veränderte Konfigurations- Datei auffallen. Anfänglich ist dies eine große Umstellung, aber nachdem man erst einmal umgestellt hat, wird man feststellen, dass die neue Form viel besser ist!

Nicht vergessen, im Teil 3 über neue Features nachzulesen! Auch wenn einige Features aus früheren Versionen bekannt sind, finden sich hier auch eine Reihe neuer Features!

Am besten verzichtet man auf mischen/linken von 3.1.x mit 3.2, aber wenn das doch gewollt ist, wird mindestens 3.1.4 benötigt. Jedoch wird Version 3.1.5.1 unbedingt empfohlen.

Der empfohlene Weg für ein Upgrade ist:
Linux:

• Altes UnrealIRCd Verzeichnis umbenennen (oder es wird im nächsten Schritt überschrieben)
• Neue UnrealIRCd Version entpacken und "./Config" und "make" laufen lassen (*NIX).
• Alte Konfigurationsdateien in das neue Verzeichnis kopieren (unrealircd.conf, motd, rules, server.* [SSL certs], network file, etc)

• Alle Konfigurationsdateien in einen temporären Ordner kopieren.
• Die Deinstallation des vorhandenen Unreal starten.
• Den Installer für den neuen Unreal starten.
• Die alten Config Files in den neuen Ordner kopieren.

Bitte auch die RELEASE.NOTES lesen und ggf. jede Changes Datei um zu sehen, was sich geändert hat. Falls Änderungen (oder Bugs) zwischen Versionen festgestellt werden, AUF JEDEN FALL ERST IN DIESEN DATEIEN NACHLESEN bevor ein Bug gemeldet wird!

• *NIX Versionen:
  • Linux 2.2.x
  • Linux 2.4.x
  • FreeBSD 4.6-STABLE
  • FreeBSD 4.5-STABLE
  • Solaris 2.x
• Windows Versionen:
  • WindowsXP Home
  • WindowsXP Pro
  • Windows 2000 Pro
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows 98
  • Windows Me

Installationsanleitungen
Linux:

1. gunzip -d Unreal3.2.2.tar.gz
2. tar xvf Unreal3.2.2.tar
3. cd Unreal3.2
4. ./Config
5. Die hierbei angezeigten Fragen nach bestem Wissen beantworten. Allgemein ist es empfehlenswert, bei Unsicherheiten den Default zu belassen.
6. make
7. Nun die eigene unrealircd.conf und die anderen Konfigurationsdateien erstellen, siehe Teil 4.

Windows:

1. Den Unreal Installer starten
2. Nun die eigene unrealircd.conf und die anderen Konfigurationsdateien erstellen, siehe Teil 4.

In diesem Abschnitt werden einiger der größeren besonderen Features erläutert. Es wird ein genereller Überblick gegeben, in dem sich manchmal auf die .conf Datei bezogen wird (die Neuanfängern momentan noch unbekannt sein dürfte).

Dieser Abschnitt kann auch übersprungen werden, obwohl es sinnvoll ist ihn vor oder nach der Installation zu lesen.

Das Cloaking ist eine Möglichkeit, den echten Hostnamen vor Usern zu verbergen. Wenn z.B. der echte Host d5142341.cable.wanadoo.nl lautet, wird er (in join, part, whois, etc) als rox-2DCA3201.cable.wanadoo.nl angezeigt. Das ist hilfreich, um sich davor zu schützen, dass User sich gegenseitig flooden, da sie die echte Host/IP nicht erkennen können.

Eingestellt wird dies durch den Usermode +x (also: /mode yournick +x), Admins können +x auch als Default erzwingen oder so einstellen, dass User kein -x einstellen können.

Ein durch Cloaking geschützter Host wird durch ein Cloaking Modul (wenigstens eines muss geladen sein) erzeugt. Momentan sind 2 solche offizielle Module verfügbar:
cloak:
Hierbei handelt es sich um das neue offizielle Cloaking Modul, welches viel sicherer, als das alte ist. Es verwendet intern md5 und erfordert, dass 3 ::cloak-keys:: gesetzt sind, die gemischt Kleinbuchstaben (a-z), Großbuchstaben (A-Z) und Ziffern (0-9) enthalten [z.B. "AopAS6WQH2Os6hfosh4SFJHs"] . Siehe auch example.conf für ein Beispiel. 
oldcloak:
Hierbei handelt es sich um den alten Cloaking Algorithmus, wie er in Unreal3.2 und früher benutzt wurde. Es gibt ihn nur, um beim Upgrade Prozess zu helfen. Diese Methode ist nicht länger sicher (es wird eine Warnung angezeigt, wenn man sie benutzt) und sollte beim nächten Upgrade der Server umgehend durch die neue Methode 'cloak' ersetzt werden.

Die Keys MÜSSEN identisch auf ALLEN SERVERN im Netzwerk sein und sie sollten GEHEIM gehalten werden. Wenn jemand diese drei Keys kennt, kann er den geschützten Host erkennen und den realen Host ermitteln (was dem Usermodus +x sinnlos macht).

UnrealIRCd unterstützt Module, was sehr nützlich ist, weil:
- Module können bei laufendem ircd geladen/ersetzt/gelöscht werden (durch /rehash). Dadurch können verschiedene Bugs gefixt oder neue Module hinzugefügt werden, ohne dass ein Neustart erforderlich ist!
- Andere Entwickler können weitere Module mit neuen Befehlen oder anderen Usermodi erstellen.
UnrealIRCd selbst enthält nur wenige Module. Durch eine Suche auf www.unrealircd.com (modules) oder per Google können weitere 3rd party Module gefunden werden.

Achtung: Minimal müssen zwei Module geladen sein, oder der ircd wird nicht starten!
- das commands Modul: commands.so (oder commands.dll bei Windows)
- das cloaking Modul: üblicherweise cloak.so (oder cloak.dll bei Windows)

Bei Snomasks handelt es sich um Server notice masks, eine spezielle Form der Usermodi, durch die gesteuert wird, welche Server Nachrichten man empfängt (in der Regel von Opern benutzt)

Sie können durch "/mode yournick +s SNOMASK" eingestellt werden, z.B.: /mode yournick +s +cF
(d.h. +s leitet dem Modus "snomask" ein, danach folgen die Flags)
Um aktuelle snomasks zu löschen, gibt man z.B. ein: /mode yournick +s -c
Will man sämtliche snomask Flags löschen, gibt man ein: /mode yournick -s

Momentan unterstützte snomasks Flags sind:
c - lokale Connects
F - ferne Connects (also auf anderen Servern im Netz - mit Ausnahme der U-lined Server)
f - Flood Meldungen
k - Kill Meldungen
e - 'eyes' Meldungen
j - 'junk' Meldungen
v - vhost Meldungen
G - gline/shun Meldungen
n - lokale nick Änderungs-Meldungen
N - globale nick Änderungs- Meldungen
q - deny nick (Q:line) Meldungen zu Abweisung gesperrter Nicks
s - Server Nachrichten anzeigen [*]
S - Spamfilter Nachrichten anzeigen
o - Oper-up Meldungen anzeigen
[*: Diese snomask ist auch für Nicht-IrcOps möglich]

Es kann eingestellt werden, welche snomasks man automatisch erhält (set::snomask-on-connect) und welche man als Oper erhält (set::snomask-on-oper, set::oper::snomask)

Mit Alias können serverseitig bestimmte Befehle eingestellt und dadurch vereinfacht werden. So ist es z.B. möglich, dass der Befehl "/ns identify blah" direkt an Nickserv geleitet und übersetzt wird in: "privmsg nickserv identify blah". Man kann auch recht komplexe Alias Definitionen vornehmen, die beispielsweise den Befehl /register an Chanserv weiterleitet, wenn der erste Parameter mit einem # beginnt oder an Nickserv, wenn der erste Parameter nicht mit einem # beginnt. (Im ersten Fall soll ein Channel registriert werden, im zweiten Fall ein Nickname)

Aliases werden in alias Blocks in der Konfigurationsdatei definiert oder in einer Include Datei mit den häufigsten Default Aliassen. 

UnrealIRCd hat ein integriertes Hilfesystem, auf welches mit dem Befehl "/helpop" zugegriffen werden kann. Über den Help Block in der Konfigurationsdatei bzw. die beigefügte "help.conf" ist die anzuzeigende Hilfe völlig frei konfigurierbar. Grundlegende Hilfen sind in der mitgelieferten help.conf schon vorkonfiguriert.
Beispielsweise wird nach dem Befehl  /helpop chmodes ein Überblick über sämtliche Channel Modi von UnrealIRCd angezeigt.
Zu beachten ist, dass ein ircop (helpop) vor den Suchbegriff ein '?' setzten muss, also statt /helpop ist /helpop ? einzugeben und statt /helpop chmodes ist /helpop ?chmodes einzugeben etc.. (Alternative: Vor der Abfrage das +h Flag per "/mode <nick> -h" entfernen)

Es gibt verschiedene Oper Levels in UnrealIRCd und jeder Level kann um zusätzliche Rechte (wie z.B. use /gline) erweitert werden, so dass jedem Oper genau die benötigten Rechte gegeben werden können..

Gesteuert wird dies über die Oper Flags im Oper Block. (siehe oper block für weitere Informationen.)

UnrealIRCd hat eine Reihe mächtiger Befehle für Opers, die im Abschnitt User & Oper Befehlsliste erklärt werden. Es empfiehl sich, diese nach der Installation zu lesen :).

SSL ist die Abkürzung für "Secure Socket Layer" und ermöglicht sichere verschlüsselte Verbindungen. Dadurch kann  server<->server Traffic verschlüsselt werden, aber auch die Verschlüsselung client<->server ist möglich. Üblicherweise wird SSL als Schutz vor "Sniffing" (Abhören von Netz Traffic) und zur sicheren Authentifizierung eingesetzt.

Um das zu ermöglichen, ist es erforderlich, dass der IRC Server mit SSL Support kompiliert wird. Um einen SSL Port einzustellen, muss
"set listen::options::ssl" eingetragen sein.

Zu einem SSL Port kann nicht normal verbunden werden (also nicht den Port 6667 auf  SSL einstellen!), sondern es wird ein Client oder ein Tunnel benötigt, der das SSL Protokoll unterstützt.

Diese Clients unterstützen SSL: XChat, irssi, mIRC (6.14 und höher, weitere zusätzliche Schritte erforderlich)

Für Clients, die kein SSL unterstützen, kann man einen Tunnel wie stunnel benutzen. Hie ein Beispiel für eine stunnel.conf Beispiel (für stunnel 4.x):

   client = yes
   [irc]
   accept = 127.0.0.1:6667
   connect = irc.myserv.com:6900

StunTour für mIRC kann ebenfalls hilfreich sein.

Es sollten auch die Zertifikate überprüft werden, wenn man zu einem Server verbindet und diesen nicht blind vertrauen (wie im stunnel Beispiel), andernfalls ist man noch durch "active sniffing" Angriffe (ssl redirects) empfänglich. Das ist allerdings ein anderes Thema und führt zu weit von der Erklärung zum IRCd weg. Hierzu gibt es eigene Sites im Internet um das zu lernen. Nicht bei Unreal nachfragen, es hat nichts mit dem UnrealIRCd zu tun. (mIRC und XChat öffnen ein Popup Fenster und fragen nach, ob ein Zertifikat erlaubt oder zurückgewiesen wird und das ist gut!)

UnrealIRCd unterstützt  IPv6, seit beta15 stabil zu sein scheint.
Das Betriebssystem muss IPv6 unterstützen und es ist erforderlich, IPv6 Unterstützung in UnrealIRCD zu aktivieren (die entsprechende Frage bei ./config mit "yes" beantworten). 

Obwohl Microsoft eine experimentelle IPv6 Unterstützung in w2k/XP implementiert hat, wird diese (noch) nicht von UnrealIRCd unterstützt.

Zip Links können für  server<->server Verbindungen aktiviert werden. Dadurch werden die Daten durch Verwendung von zlib komprimiert und es können so  60-80% Bandbreite eingespart werden. Das ist sinnvoll für Links mit niedriger Bandbreite oder für Links mit vielen Usern und kann ein wenig beim Linken helfen, da eine Menge von Daten über jeden User und jeden Channel zu übertragen sind.

Um mit  zip links Support zu kompilieren, muss die zlib Frage mit "Yes" bei ./config beantwortet werden und dieses mit  link::options::zip eingetragen sein.

UnrealIRCd hat einige (neue) Features, die es ermöglichen, dass User dynamische IP's verwenden können (wie z.B.: blah.dyndns.org). Sollen zwei Hosts mit dynamischer DNS gelinkt werden, so ist set link::options::nodnscache und link::options::nohostcheck einzutragen.

Throttling
Throttling nennt man die Methode, mit der geregelt wird, wie schnell ein User die Verbindung trennen und sich erneut zum Server verbinden kann. Im  "set::throttle block" kann eingestellt werden, X Verbindungen innerhalb von YY Sekunden von derselben IP zu gestatten.

Channel Modi
Weiterhin gibt es einige Channel Modi, welche sehr effektiv gegen Flood sein können. Einige davon sind:
K = no /knock (kein Anklopfen, um in Channel eingeladen zu werden), N = no nickchanges (keine Änderung der Nicknamen möglich), C = no CTCPs (keine CTCP möglich), M = nur registrierte User können schreiben
Seit der Beta 18 gibt es zusätzlich noch den erweiterten Modus +f...
Channel mode f
Um nicht Scripts und Bots zum Schutz gegen Channel Flood benutzen zu müssen, ist der notwendige Schutz nun im IRCd integriert.
Ein Beispiel für den +f Modus ist: *** Blah sets mode: +f [10j]:15
Das bedeutet, dass 10 joins innerhalb von 15 Sekunden im Channel gestattet sind. Wird dieser Wert überschritten, wird der Channel automatisch auf  +i eingestellt.

Für folgende Flood Arten stehen Aktionen zur Verfügung:

Beispiel:

*** ChanOp sets mode: +f [20j,50m,7n]:15
<ChanOp> lalala
*** Evil1 (~fdsdsfddf@Clk-17B4D84B.blah.net) has joined #test
*** Evil2 (~jcvibhcih@Clk-3472A942.xx.someispcom) has joined #test
*** Evil3 (~toijhlihs@Clk-38D374A3.aol.com) has joined #test
*** Evil4 (~eihjifihi@Clk-5387B42F.dfdfd.blablalba.be) has joined #test
-- snip XX lines --
*** Evil21 (~jiovoihew@Clk-48D826C3.e.something.org) has joined #test
-server1.test.net:#test *** Channel joinflood detected (limit is 20 per 15 seconds), putting +i
*** server1.test.net sets mode: +i
<Evil2> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil12> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil15> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil10> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil8> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
-- snip XX lines --
-server1.test.net:#test *** Channel msg/noticeflood detected (limit is 50 per 15 seconds), putting +m
*** server1.test.net sets mode: +m
*** Evil1 is now known as Hmmm1
*** Evil2 is now known as Hmmm2
*** Evil3 is now known as Hmmm3
*** Evil4 is now known as Hmmm4
*** Evil5 is now known as Hmmm5
*** Evil6 is now known as Hmmm6
*** Evil7 is now known as Hmmm7
*** Evil8 is now known as Hmmm8
-server1.test.net:#test *** Channel nickflood detected (limit is 7 per 15 seconds), putting +N
*** server1.test.net sets mode: +N

Das Ganze kann noch erweitert (damit aber auch komplizierter) werden:
Anstelle der Default Aktion kann für einige Flood Typen auch eine andere Aktion gewählt werden, wie z.B.: +f [20j#R,50m#M]:15
Dieser Channel wird auf +R gestellt, wenn das Join-Limit erreicht ist (>20 Joins in 15 Sekunden), und wird auf +M gesetzt, wenn das Msg Limit erreicht ist (>50 Nachrichten in 15 Sekunden).

Zusätzlich gibt es eine  "Lösche nach X Minuten" Einstellung: +f [20j#R5]:15 setzt den Channel auf +R, wenn das Limit erreicht wird und nach 5 Minuten wieder auf -R.
Ein Server kann eine Default Unset-Zeit haben (set::modef-default-unsettime), die bewirkt, dass eine Angabe von  +f [20j]:15 automatisch in +f [20j#i10]:15 umgewandelt wird. Es handelt sich hierbei lediglich um einen Default und man kann weiterhin auch andere Angaben wie [20j#i2]:15 setzen. Ebenso kann man den Lösch Channel Modus  auch ganz abschalten, indem man +f [20j#i0]:15 angibt (also explizit den Wert 0 setzt).

Der alte +f Modus (messageflood per User) ist weiterhin vorhanden, allerdings als 't'. Der Eintrag +f 10:6 lautet nun +f [10t]:6 und 
+f *20:10 ist jetzt +f [20t#b]:10. Aktuell wird der ircd alte +f Modi automatisch in die neuen Modi umwandeln. Zu beachten ist, dass es keine Unsettime Einstellung für 't' Banns gibt.  ([20t#b30]:15 funktioniert nicht!).

Was der beste +f Modus ist, hängt vom jeweiligen Channel ab. Wie viele User hat der Channel? Läuft möglicherweise ein Spiel in dem Channel, welches viele längere Messages erfordert? Handelt es sich um einen Hauptchannel, möglicherweise mit auto-join? Das, was in dem einen Channel Flood ist, kann in einem anderen völlig normal sein...
Es gibt also keinen perfekten Channelmodus +f, der für alle Channels geeignet ist. Aber für den Anfang seien hier einige Beispiele gegeben, die man auf die eigenen Bedürfnisse anpassen kann:
+f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15
30 Joins pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 10 min auf +i gesetzt
40 Messages pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 10 min auf +m gesetzt
7 CTCP pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 15 min auf +C gesetzt
10 Nickänderungen pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 15 min auf +N gesetzt
30 Knocks pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 5 min auf +K gesetzt

In bestimmten größeren Channels (>75 User?) sollte man die Join Grenze erhöhen (auf z.B.: 50) und auch das Message Limit (z.B. 60 oder 75).
Speziell die Lösch-Modi erfordern viel Feinabstimmung. Man sollte bedenken, was passiert, wenn kein Op anwesend ist, der eine Situation regulieren kann. Soll ein Channel 15 Minuten gesperrt sein (nicht so schön für die User)? Oder nur 5 Minuten (dann warten Flooder möglicherweise 5 min um dann erneut zu flooden)? Das hängt auch vom Typ des Floods ab. Es beeinträchtigt User mehr, wenn sie nicht joinen können (+i) oder nicht schreiben können (+m) als wenn sie keinen Nick ändern können (+N) oder keine CTCP senden können (+C). Es sollten daher unterschiedliche Zeiten für das Löschen der Modi angegeben werden..

Diese Bann Typen werden auch in der Ausnahme Liste der Channels (channel exception list [+e]) berücksichtigt.
Ebenso können über Module andere erweiterte Bann Typen definiert werden.

Beispiele: (man beachte die Striche '-', die Default Angaben erzwingen)

/spamfilter add pc gline - - Come watch me on my webcam
Wenn der Text "come watch me on my webcam" entweder in einer priv msg oder in einer Channel Nachricht auftaucht, wird er blockiert und auf den Sender eine G-Line gesetzt.

/spamfilter add pc block - - come to irc\..+\..+
Hier wird auf Werbungen wie "Hi, come to irc.blah.net" usw. geprüft und die Nachricht wird einfach nur geblockt.

Und ein Beispiel mit time/reason:

/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam
Wenn der Text "come watch me on my webcam" in einer privaten Nachricht gefunden wird, erfolgt eine G-Line für 3 Stunden mit dem Grund: "Please go to www.viruscan.xx/nicepage/virus=blah".

Spamfilter die über /spamfilter definiert werden, gelten netzweit. Sie wirken unabhängig davon, ob der User +G gesetzt hat und nur Oper und U-Lines (Services) sind von der Filterung ausgenommen.

Spamfilter können auch in der Config Datei eingetragen sein, doch sie sind dann nur lokal für den Server, auf dem sie eingetragen sind (also nicht netzweit), gültig. Die Syntax dieser spamfilter { } Blöcke wird hier erklärt:

Beispiel:

spamfilter {
regex "//write \$decode\(.+\|.+load -rs";
target { private; channel; };
reason "Generic $decode exploit";
action block;
};

set::spamfilter::ban-time ermöglicht die Festlegung einer Default Bann Dauer für *lines die durch den Spamfilter gesetzt wurden (default: 1 Tag)
set::spamfilter::ban-reason ermöglicht die Festlegung eines Grundes für die *lines (Default: 'Spam/advertising'). Mehrere Worte sind durch Underscores ("_") und nicht durch Leerzeichen zu trennen.
set::spamfilter::virus-help-channel ermöglicht die Angabe eines Channels, in den bei der Action 'viruschan' gejoined wird (Default: #help)
set::spamfilter::virus-help-channel-deny ermöglicht es, normale Joins in den virus-help-channel zu blockieren (Default: no)

UnrealIRCd unterstützt nun auch CIDR (Classless Interdomain Routing). CIDR ermöglicht es, IP Bereiche zu bannen. IPs werden an Internet Service Provider (ISP) unter Verwendung von CIDR vergeben. Daher ist es möglich unter Verwendung eines CIDR basierten Banns auf einfache Weise ganze ISPs zu sperren. Unreal unterstützt CIDR sowohl für IPv4 als auch für IPv6. CIDR Masken können benutzt werden bei: allow::ip, ban user::mask, ban ip::mask, except ban::mask, except throttle::mask, und except tkl::mask (für gzline, gline, and shun). Zusätzlich kann  CIDR bei /kline, /gline, /zline, /gzline, und /shun benutzt werden. Unreal verwendet die Standard Syntax von IP/bits, z.B. 127.0.0.0/8 (passt auf 127.0.0.0 - 127.255.255.255), und fe80:0:0:123::/64 (passt auf fe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff).

UnrealIRCd hat eine Reihe weiterer Features, die hier nicht alle einzeln aufgeführt sind. Man wird sie während der Konfiguration selbst herausfinden ;)

Beim ersten Mal wird das Erstellen einer guten unrealircd.conf Datei eine gewisse Zeit in Anspruch nehmen - je nach Vorerfahrung etwa 10 - 60 Minuten. Man kann versuchen, so rasch wie möglich den ircd zu starten und später zu verfeinern oder man kann die Haupt Abschnitte Schritt für Schritt erlernen (was der empfohlene Weg ist ;P). Im Falle auftretender Probleme zuerst die Syntax überprüfen, diese Anleitung und auch die FAQ bevor man nach Hilfe fragt oder einen Bug meldet.

Das neue System benutzt ein Block-basiertes Format. Jeder Eintrag, also jeder Block, in der neuen Form hat ein spezielles Format, welches etwa so aussieht:

<block-name> <block-value> {
	<block-directive> <directive-value>;
};

<block-name> ist der Typ des Blocks wie z.B. "me", oder "admin". 
<block-value> gibt bei einigen Typen einen notwendigen Wert an, wie z.B. "/oper login", oder in anderen Fällen einen Untertyp wie in  "ban user".

<block-directive> ist eine speziell auf den Block bezogene Variable 
<directive-value> ist der zugewiesene Wert. Falls <directive-value> Leerzeichen oder Kommentarzeichen enthält, muss die Abgabe von Anführungszeichen eingeschlossen sein. Soll das Anführungszeichen ebenfalls Bestandteil des Eintrags sein, muss im das Zeichen "\" vorangestellt werden, damit es als Anführungszeichen erkannt wird.

Innerhalb von <block-directive> können Anweisungen stehen, die dann mit geschweiften Klammern "{ }" eingeschlossen sind. Einige Blöcke haben keine Anweisungen sondern lediglich eine <block-value> Angabe, wie z.B. "include". Ebenso ist zu beachten, dass es kein spezielles Einstellungsformat gibt. Ein Block kann also in einer einzigen Zeile angegeben werden oder in mehreren Zeilen. Normalerweise wird das oben angegebene Format benutzt, welches leicht zu lesen ist und auch in der mitgelieferten unrealircd.conf benutzt wird.

Achtung: Die Konfigurationsdatei ist derzeit "case sensitive", daher ist "BLOCK-NAME" nicht dasselbe wie "block-name". Es gibt eine spezielle Notation wie Einträge in der Konfigurationsdatei als Beschreibung angegeben werden. Spricht man z.B. über "<directive-name>" im obigen Beispiel, so wird angegeben "<block-name>::<block-directive>" (also zwei Doppelpunkte dazwischen), und falls die Anweisung einen Unterblock hat, auf den sich bezogen wird, würde ein weiteres Paar "::" hinzugefügt, gefolgt vom Namen der Unteranweisung.

Bei einer Anweisung ohne Namen wird  "<block-name>::" gesagt, was einfach nur "<block-value>" bedeutet, oder es könnte ein Eintrag in einem Unterblock sein, der keinen Namen hat.

Es gibt drei Arten von Kommentaren::

# Ein-Zeilen Kommentar
// Ein-Zeilen Kommentar
/* Kommentar
    über mehrere
    Zeilen */

Es sollte nun klar sein, wie das Block Format der .conf funktioniert und nun kann begonnen werden, eine eigene unrealircd.conf zu erstellen. Hierzu kann man auch dei Beispielsdatei oder Teile der Dokumentation verwenden und sich die entsprechenden Blöcke in die eigene Datei kopieren und editieren. Es ist empfehlenswert, sich Schritt für Schritt durch alle Blöcke und diese Anleitung als Referenz durchzuarbeiten.

Syntax:

me {
name <Name-des-Servers>;
info <Server-Beschreibung>;
numeric <Server-Nummer>;
};

Diese Werte sollten klar sein. Der name gibt den Namen des Servers an (nicht dessen Internetadresse!), info eine kurze Info Zeile zur Beschreibung des Servers und numeric bedeutet eine Zahl zur Identifikation des Servers. Hierbei muss es sich um einen Wert zwischen 1 und 255 handeln, der EINMALIG im Netzwerk ist, es darf also KEIN Server im Netzwerk denselben numeric Wert haben.

Beispiel:

me {
	name "irc.foonet.com";
	info "FooNet Server";
	numeric 1;
};

Syntax:

admin {
	<Text-Zeile>;
	<Text-Zeile>;
};

Im Admin Block werden die Informationen über die Serveradministration angegeben. Wenn ein User später eintippt:  "/admin" (oder "/admin <servername>"), so wird ihm die hier angegebene Information dargestellt. Es können beliebig viele Zeilen eingetragen werden, die jede beliebige Information enthalten können, aber es gilt als Standard, mindestens den Nicknamen des Admins und dessen email Adresse anzugeben. Weitere Informationen können Kontakt Infos sein, die man angeben möchte.

Beispiel:

admin {
	"Bob Smith";
	"bob";
	"widely@used.name";
};

Syntax:

class <name> {
	pingfreq <Ping-Frequenz>;
	connfreq <Connect-Frequenz>;
	maxclients <Maximum-Clients>;
	sendq <send-queue>;
	recvq <recv-queue>;
};

Class Blöcke definieren Verbindungs Klassen in welche Verbindungen eingeordnet werden (z.B. von Allow Blöcken oder Server von Link Blöcken). Im Allgemeinen hat man mehrere Class Blöcke (z.B. für Server, für Clients, für Opers)

Verbindungsklassen definieren eine Reihe von Parametern für Verbindungen, die folgendes umfassen:

name ist ein beschreibender Name wie "clients" oder "servers", dieser Name wird später in anderen Blöcken als Referenz verwendet.

pingfreq ist die Anzahl von Sekunden zwischen PINGs von diesem Server.

connfreq wird nur für Server verwendet und ist die Anzahl Sekunden zwischen zwei Verbindungsversuchen, falls autoconnect eingeschaltet ist.

maxclients gibt die maximale Gesamtzahl an Clients und Servern an, die in dieser Klasse sein können.

sendq gibt die Menge an Daten an, die sich in der Sende Queue befinden dürfen (sehr hoch für Server mit geringer Bandbreite, mittel für Clients)

recvq gibt die Menge an Daten an, die sich in der Empfangsqueue befinden können und wird zur Flood Kontrolle verwendet (das betrifft nur normale User, es sollte mit Werten zwischen 3000-8000 experimentiert werden, >8000 ergibt keine Änderung und 8000 ist Default).

Beispiele:

class clients {
	pingfreq 90;
	maxclients 500;
	sendq 100000;
	recvq 8000;
};

class servers{
	pingfreq 90;
	maxclients 10; /* Maximum an gleichzeitigen möglichen Server Verbindungen */
	sendq 1000000;
	connfreq 100;  /* Wieviele Sekunden zwischen jedem Verbindungs Versuch */
};

Syntax:

allow {
	ip <user@ip-connection-mask>;
	hostname <user@host-connection-mask>;
	class <connection-class>;
	password <connection-password> { <auth-type>; };
	maxperip <max-connections-per-ip>;
	redirect-server <server-to-forward-to>;
	redirect-port <port-to-forward-to>;
	options {
		<option>;
		<option>;
		...
	};
};

In Allow Blöcken wird angegeben, wer zum Server connecten darf. Es können mehrere Allow Blöcke vorhanden sein (was in der Regel auch erforderlich ist).

Anmerkungen zu Übereinstimmung (matching)
Die Zugangskontrolle arbeitet folgendermaßen: Es müssen entweder IPs übereinstimmen ODER Hosts. Einträge von "hostname *@*;" und "ip *@1.2.3.4;" stimmen also mit allem überein und gestatten einen universellen Zugang. Allow Blöcke in der unrealircd.conf werden von unten nach oben ausgewertet, deswegen müssen spezielle Host/IP Böcke NACH den allgemeinen *@* Allow Blöcken aufgeführt werden. Soll ein Block ausschliesslich für eine IP gelten, so ist das Feld "hostname" auf irgendeinen ungültigen Wert zu setzen, wie z.B. "hostname NOBODY;". Dadurch wird der Allow Block ausschliesslich auf Übereinstimmung der IP eingestellt.

ip
Für die IP Maske gilt die Form user@ip, dabei ist user der ident und meist mit * eingetragen, ip ist eine gültige IP Adresse, die ebenfalls Wildcards enthalten kann. Einige Beispiele: *@* (jeder von überall her), *@192.168.* (jeder, dessen IP Adresse mit 192.168 beginnt), etc.

host
Für die host gilt die Form user@hostmask, dabei ist user der ident und meist mit * eingetragen, hostmask eine Internetadresse. Einige Beispiele: *@* (jeder von überall her), *@*.wanadoo.fr (nur User von wanadoo.fr).

password (optional)
Die Verbindung erfordert ein Passwort. Zusätzlich kann hier eine Verschlüsselungs Methode angegeben werden.

maxperip (optional, aber empfohlen)
Festlegung, wieviele Verbindungen mit derselben IP auf dem Server erlaubt sind (z.B.: maxperip 4;).

redirect-server (optional)
Wenn die Klasse voll ist, werden User zu diesem Server umgeleitet (wenn der Client das unterstützt [mIRC 6 unterstützt es]).

redirect-port (optional)
Wenn ein redirect-server angegeben ist, kann hier der Port eingetragen werden. Ohne Eintrag wird 6667 als Default angenommen.

options block (optional)
Gültige Optionen sind:
   useip immer nur IP stat Hostnamen anzeigen
   noident kein ident verwendensondern den vom Client übergebenen Usernamen
   ssl Übereinstimmung ist nur gegeben, wenn der User via SSL verbindet
   nopasscont Überprüfung fortsetzen, wenn kein Passwort angegeben wurde (dadurch kann man User, die ein Passwort übermitteln in eine extra Klasse
   packen).

Beispiele:

allow {
	ip *;
	hostname *;
	class clients;
	maxperip 5;
};

allow {
	ip *@*;
	hostname *@*.passworded.ugly.people;
	class clients;
	password "f00Ness";
	maxperip 1;
};

Syntax:

listen <ip:port> {
	options {
		<option>;
		<option>;
		...
	};
};

Mit diesem Block können spezielle Ports angegeben werden, auf die der IRCD reagiert. Falls keine Optionen erforderlich sind, kann man diesen Eintrag auch in der einfachen Form setzen:
<ip:port>;.

ip und port
Die IP wird normalerweise auf "*" eingestellt, aber man kann auch eine IP eingeben, um ausschließlich diese an den Port zu binden.. Der Port ist die Nummer des Ports, der hier eingestellt werden soll. Man kann sowohl einen Portbereich als auch einen einzelnen Port angeben Beispielsweise bewirkt die Angabe "6660-6669", dass auf jeden Port von 6660 bis 6669 (einschließlich) reagiert wird. IPv6 User: siehe nächster Absatz.

Info für IPv6 User
Wenn für den Server IPv6 aktiviert ist, müssen die IPs in eckige Klammern (Brackets, "[ ]") eingeschlossen sein, wie z.B.: "[::1]:6667" (reagiere auf Local Host an Port 6667). Verwendet man IPv6 und es soll eine bestimmte IPv4 Adresse definiert werden, gilt das Format: "::ffff:ipv4ip". Ein Beispiel: [::ffff:203.123.67.1]:6667 (reagiert wird auf IP 203.123.67.1 auf Port 6667). Allerdings kann man auch "*" mit IPv6 verwenden.

options block (optional)
Für den Port können besondere Optionen angegeben werden. Gültige Optionen sind:

clientsonly	Port ist nur für Clients
serversonly	Port ist nur für Server
java	CR javachat support
ssl	SSL encrypted port

Beispiele:

listen *:6601 {
	options {
		ssl;
		clientsonly;
	};
};

Oder, wenn es keine Optionen gibt:

listen *:8067;
listen *:6660-6669;

oper <name> {
	from {
		userhost <hostmask>;
		userhost <hostmask>;
	};
	password <password> { <auth-type>; };
	class <class-name>;
	flags <flags>;
	flags {
		<flag>;
		<flag>;
		...
	};
	swhois <whois info>;
	snomask <snomask>;
	modes <modes>;
	maxlogins <num>;
};

Mit dem Oper Block können für den Server IRC Operatoren festgelegt werden. 
Der oper:: Eintrag legt den Login Namen für den /oper Befehl fest. 
Der Eintrag oper::from::userhost ist eine user@host Maske, die zum User passen muss. Man kann hier mehr als eine Maske angeben, indem man mehrere oper::from::userhost Einträge erstellt. 
Der Eintrag oper::password enthält das Passwort, dass der User angeben muss. Hier kann zusätzlich eine Verschlüsselungsmethode für dieses Passwort angegeben werden, gültige Typen sind dann: crypt, md5, und sha1, ripemd-160. Soll ein einfaches unverschlüsseltes Passwort verwendet werden, bleibt dieses Feld einfach leer.

Zu beachten ist, dass sowohl der Loginname als auch das Passwort case sensitive sind.

Beim Eintrag oper::class muss es sich um eine schon definierte Klasse handeln, die in der Konfigurationsdatei schon vor dieser Blockdefinition auftaucht (also ERST Class definieren und erst DANACH oper!).

Bei der oper::flags Anweisung gibt es zwei Formate. Falls man die frühere Form der Operflags vorzieht (mit Buchstaben wie z.B.: "OAa", verwendet man die  "flags <flags>" Methode. Wenn man dagegen die neue Form (wie z.B.: "services-admin") verwenden möchte, benutzt man die "flags { <flag>; }" Methode.

Nachfolgend eine Liste aller Flags in beiden Formaten und ihre Bedeutung.

Bestimmte Flags setzen andere Flags per Default:

Mit der oper::swhois Anweisung kann eine zusätzliche Zeile für die whois Information eines Opers gesetzt werden. [optional]

Mit der oper::snomask Anweisung kann eine server notice Mask für einen Oper voreingestellt werden, so dass man beim oper Befehl bestimmte Flags automatisch voreingestellt sind. Siehe Abschnitt 3.3  für Infos über snomasks. [optional]

Mit der oper::modes Anweisung können Modi für Opers voreingestellt werden, so dass man beim oper Befehl bestimmte Flags automatisch voreingestellt sind. [optional]

Mit der oper::maxlogins Anweisung kann man die die Anzahl gleichzeitiger Oper Logins einschränken. Wenn hier z.B. der Wert 1 eingestellt wird, kann immer nur eine Person über diesen Oper Block eingeloggt sein. [optional]

Beispiel:

oper bobsmith {
	class clients;
	from {
		userhost bob@smithco.com;
		userhost boblaptop@somedialupisp.com
	};
	password "f00";
	flags {
		netadmin;
		can_gkline;
		can_gzline;
		can_zline;
		can_restart;
		can_die;
		global;
	};
	swhois "Beispiel einer whois Maske";
	snomask frebWqFv;
};

Syntax:

drpass {
	restart <restart-password> { <auth-type>; };
	die <die-password> { <auth-type>; };
};

Mit den Blöcken drpass::restart und drpass::die werden die Passworte für die Befehle "/restart" und "/die" festgelegt. Ebenfalls ist es möglich, einen Typ der Authentifizierung festzulegen. Gültige Typen sind hierbei crypt, md5, und sha1, ripemd-160.

Beispiel:

drpass {
	restart "I-love-to-restart";
	die "die-you-stupid";
};

Syntax:

include <file-name>;

Mit dieser Anweisung wird eine separate Konfigurationsdatei mit dem Namen "file-name" geladen. Diese Datei kann jeden Typ von Config Blöcken enthalten und ihrerseits weitere Include Anweisungen enthalten. Wildcards im Dateinamen werden unterstützt, wodurch es auch möglich ist, mehrere Dateien auf einmal zu laden..

Beispiel 1: eine network Datei

include mynetwork.network;

Diese Anweisung lädt die Datei "mynetwork.network, wenn man eine eigene network Datei verwenden möchte. Eigene network Dateien sind eigentlich nicht mehr erforderlich, da sämtliche Anweisungen auch in der unrealircd.conf stehen können. Mit einer Include Anweisung kann man das File statt dessen getrennt halten und laden.

Beispiel 2: aliases

include aliases/ircservices.conf

Ein weiteres Beispiel für die Anwendung von Alias Blöcken. UnrealIRCd wird mit einigen Dateien geliefert, die schon die wesentlichen Aliasse für die meisten Services enthalten.:

• aliases/ircservices.conf (IRCServices, Daylight)
• aliases/epona.conf (Epona)
• aliases/anope.conf (Anope)
• aliases/auspice.conf (Auspice)
• aliases/generic.conf (Magick, Sirius, Wrecked)
• aliases/cygnus.conf (Cygnus)
• aliases/operstats.conf (OperStats)
• aliases/genericstats.conf (GeoStats, NeoStats)

Syntax:
loadmodule <file-name>;

Warum Module hilfreich sind, kann hier nachgelesen werden.

Folgende Module werden standardmäßig bei Unreal3.2 mitgeliefert:

commands.so /commands.dll - Enthält sämtliche  / Befehle (noch nicht wirklich alle, aber sicher in einer der nächsten Versionen) ERFORDERLICH
cloak.so / cloak.dll - Cloaking Modul (oder irgend ein anderes Cloaking Modul - dient der Unterdrückung echter Hosts) ERFORDERLICH

Es ist sicherzustellen, dass diese Module in jedem Fall geladen werden:

loadmodule "src/modules/commands.so";
loadmodule "src/modules/cloak.so";

oder unter Windows:

loadmodule "modules/commands.dll";
loadmodule "modules/cloak.dll";

Syntax:

log <file-name> {
	maxsize <max-file-size>;
	flags {
		<flag>;
		<flag>;
		...
	};
};

Mit dem Log Block kann man verschiedene Logfiles zu den unterschiedlichsten Zwecken erstellen lassen. Dabei bezeichnet log:: den Namen der Logdatei.
log::maxsize ist eine optionale Anweisung, um eine Größe anzugeben, ab der die Datei gelöscht und neu begonnen wird. Die Zahlenangabe dahinter kann gefolgt sein von  MB für Megabytes, KB für Kilobytes oder GB  für Gigabytes. Bei log::flags wird angegeben, welche Art von Informationen in der Log Datei gespeichert werden sollen. Angegeben werden kann hier einer oder mehrere der unten aufgelisteten Flags. Siehe hierzu die nachfolgende Liste möglicher Flags.

Es können auch mehrere Log Blocks definiert sein, um unterschiedliche Dinge in verschiedenen Dateien zu loggen.

Gültige Flags:

Beispiel:

log ircd.log {
	maxsize 5MB;
	flags {
		errors;
		kills;
		oper;
		kline;
		tkl;
	};
};

Syntax:

tld {
	mask <hostmask>;
	motd <motd-file>;
	rules <rules-file>;
	shortmotd <shortmotd-file>;
	channel <channel-name>;
	options {
		ssl;
	}
};

Mit dem TLD Block eine motd (Messageoftheday), rules und channels für einen User basierend auf deren Host festlegen. Das ist nützlich, falls man verschiedene motd's für verschiedene Sprachen verwenden möchte.
tld::mask ist eine user@host Maske, die zum Usernamen und seiner Hostmask passen muss.
tld::motd, tld::shortmotd, und tld::rules legen die jeweiligen Dateien für motd und rules fest, die in Abhängigkeit von der Hostmask angezeigt werden.
tld::channel ist optional, und ermöglicht es, einen Channel festzulegen, in den der User beim Connect geleitet wird. Wenn dieser Eintrag existiert, überschreibt er einen Default Auto join.
tld::options ermöglicht es, noch weitere notwendige Bedingungen zu setzen, bislang ist hier aber nur  tld::options::ssl möglich.

TLD Einträge werden von unten nach oben abgearbeitet.

Beispiel:

tld {
	mask *@*.fr;
	motd "ircd.motd.fr";
	rules "ircd.rules.fr";
};

Syntax:

ban nick {

	mask <nickname>;
	reason <grund-für-bann>;
};

Mit dem Ban Nick Block können bestimmte Nicknamen auf dem Server gesperrt werden. 
ban::mask gestattet Masken mit Wildcards um mehrere Nicknamen zu erfassen
ban::reason ermöglicht es, einen Grund für den Bann anzugeben. 
In der Regel werden in TLD Blöcken die Namen der Services angegeben, so dass kein User diese Namen als seinen Nick wählen kann.

Beispiel:

ban nick {
	mask "*C*h*a*n*S*e*r*v*";
	reason "Reserved for Services";
};

Syntax:

ban user {
	mask <hostmask>;
	reason <reason-for-ban>;
};

Mit diesem Block kann man verbieten, dass sich ein user@host zum Server verbindet.
ban::mask ist eine user@host Maske, die gebannt werden soll, wobei Wildcards möglich sind.
ban::reason ist der Grund, der dem gesperrten User beim Verbindungsversuch angezeigt wird.
Zu beachten ist, dass dieser Bann nur lokal wirkt und deswegen der betreffende User ohne weiteres über andere Server zum Netzwerk verbinden kann.

Beispiel:

ban user {
	mask *tirc@*.saturn.bbn.com;
	reason "Idiot";
};

Syntax:

ban ip {
	mask <ipmask>;
	reason <reason-for-ban>;
};

Der Ban IP Block verhindert das Verbinden von bestimmten IP Adressen her zum Server. Das gilt sowohl für Verbindungsversuche von Usern als auch von Servern.
ban::mask ist eine IP, die Wildcards enthalten kann
ban::reason ist der Grund, warum der Bann eingetragen wurde.
Da dieser Bann auch Server betreffen kann, sollte man beim Eintrag von IP Adressen sehr vorsichtig sein.

Beispiel:

ban ip {
	mask 192.168.1.*;
	reason "Nimm eine richtige IP, du Lamer!";
};

Syntax:

ban server {
	mask <server-name>;
	reason <reason-for-ban>;
};

Dieser Block verhindert, dass sich bestimmte Server zum eigenen Server verbinden können.
ban::mask beinhaltet eine Maske, die Wildcards gestattet und zu dem Namen eines Servers passt, der nicht verbinden darf.
ban::reason Der Grund, warum dieser Bann existiert.

Beispiel:

ban server {
	mask broken.server.my.network.com;
	reason "Its broken!";
};

Syntax:

ban realname {
	mask <realname-mask>;
	reason <reason-for-ban>;
};

Der Ban Realname Block ermöglicht es, Clients auf das GECOS (Realname) Feld zu testen und entsprechend zu bannen, Das kann hilfreich sein, um Floods von Clones zu vermindern, da Floodbots des öfteren denselben Eintrag im Realnamen Feld verwenden.
ban::mask legt den Realnamen fest, der gebannt werden soll. Die Maske kann Wildcards enthalten.
ban::reason legt den anzuzeigenden Grund für den Bann fest.

Beispiel:

ban realname {
	mask "Bob*";
	reason "Bob sucks!";
};

Syntax:

ban version {
	mask <version-mask>;
	reason <reason-for-ban>;
	action [kill|tempshun|shun|kline|zline|gline|gzline];
};

Mit dem "ban version block" kann man Clients in Abhängigkeit der von ihnen verwendeten IRC Software bannen. Dazu wird die Antwort auf die CTCP Versions Abfrage ausgewertet. Deshalb wird dieser Bann dann nicht wirksam sein, wenn der entsprechende Client keine CTCP Version sendet. Mit diesem Feature ist es möglich, bestimmte möglicherweise störende Scripts zu blocken und damit zu verbieten.
ban::mask legt die Version des Clients fest, der gebannt werden soll. Die Maske kann Wildcards enthalten.
ban::reason legt den Grund fest, der dem User angezeigt wird.
ban::action kann ebenfalls festgelegt werden. Dabei ist der Default auf "kill". tempshun setzt ein shun auf die Verbindung des Users und arbeitet effektiv gegen zombies und/oder Bots mit dynamischer IP, weil sie unschuldige User nicht beeinträchtigen. shun/kline/zline/gzline setzen einen Bann auf die IP (*@IPADDR). Die Dauer dieser Banns kann mit 'set::ban-version-tkl-time' konfiguriert werden und beträgt per Default 1 Tag.

Beispiele:

ban version {
	mask "*SomeLameScript*";
	reason "SomeLameScript enthält Backdoors!";
};

ban version {
        mask "*w00tZombie*";
        reason "I hate those hundreds of zombies";
        action zline;
};

Syntax:

except ban {
	mask <hostmask>;
};

Mit dem "except ban Block" kann man user@host Masken angeben, die von den gesetzten Banns der Blöcke zuvor ausgenommen werden sollen. So etwas kann verwendet werden, falls man z.B. ganze ISP bannen möchte, aber einzelnen Usern trotzdem die Verbindung erlauben möchte. Dazu bei except::mask den oder die Hosts eintragen (als user@host Mask) die trotz globalem Bann connecten dürfen.

Beispiel:

except ban {
	mask myident@my.isp.com;
};

Syntax:

except tkl {
	mask <hostmask>;
	type <type>;
	type { 
		<type>;
		<type>;
		...
	};
};

Mit dem "except tkl Block" kann man user@host Masken angeben, die von den gesetzten tkl Banns (also G-Lines, Shuns, GZ Lines) auf breitere Hosts ausgenommen werden sollen. So etwas kann verwendet werden, falls man z.B. ganze ISP bannen möchte, aber einzelnen Usern trotzdem die Verbindung erlauben möchte. Dazu bei except::mask den oder die Hosts eintragen (als user@host Mask) die trotz globalem Bann connecten dürfen. Bei except::type wird angegeben, welcher Bann Typ ausgenommen werden soll. Gültige Typen sind hier: gline, gzline, qline, gqline und shun, für Ausnahmen von Glines, Global Zlines, Qlines, Global Qlines und Shuns. Wenn das {} Format benutzt wird, können unterschiedliche Typen angegeben werden.

Beispiel:

except tkl {
	mask myident@my.isp.com;
	type gline;
};

Syntax:

except throttle {
	mask <ipmask>;
};

Der "except throttle block" gestattet die Angabe einer IP Maske, für die das throttling System nicht gelten soll. Dieser Block hat nur eine Auswirkung, wenn throttling im "set Block" auch aktiviert ist. Die bei except::mask angegebene IP Maske wird nicht wegen Throttlings gebannt.

Beispiel:

except throttle {
	mask 192.168.1.*;
};

Syntax:

deny dcc {
	filename <file-to-block>;
	reason <reason-for-ban>;
	soft [yes|no]
};

Im "deny dcc Block" können Dateinamen angegeben werden, die nicht per DCC über den Server versandt werden dürfen. Das kann helfen, die Verteilung von Viren und Trojanern zu verhindern.

Der Parameter deny::filename definiert eine Maske von Dateinamen, deren Versand blockiert wird, Wildcards sind hier möglich. deny::reason legt den anzuzeigenden Grund für die Sperrung der Datei fest.

Ferner gibt es eine deny::soft Option. Wenn diese auf  'yes' gesetzt ist, ist dcc so lange gesperrt, bis der User es explizit via /DCCALLOW +nickname-der-versucht-zu-senden erlaubt.
Siehe dccallow.conf für ein gutes Konfigurationsbeispiel zu dccallow.

Beispiel:

deny dcc {
	filename *.exe;
	reason "Ausführbare Datei";
	soft yes;
};

Syntax:

deny version {
	mask <server-name>;
	version <version-number>;
	flags <compile-flags>;
};

Mit diesem Block ist es möglich, Server aufgrund der Version ihres Unreal Ircds bzw. des Compilierungszeitpunktes oder bestimmter Optionen vom Linken auszuschliessen. Das Format des Blockes ist etwas komplex, aber nicht so schwer zu verstehen.
deny::mask definiert eine Wildcard Maske, für welchen Server die Ablhnung gelten soll.
deny::version bezeichnet eine Protokoll Nummer, um welche Version es geht.

Ein Beispiel: Für den UnrealIRCD Version 3.0 ist die Versionsnummer 2301, für 3.1.1/3.1.2 ist es 2302 und für  3.2 ist es 2303. Das erste Zeichen des Parameters kann eines der folgenden sein: >, <, =, !. Dieses Zeichen gibt an, wie der IRCD die Version interpretieren soll. Ist also z.B. das erste Zeichen ein ">" so werden alle Versionen mit einer größeren Nummer abgelehnt. Handelt es sich um ein "<", so werden alle kleineren Versionen abgelehnt. Bei einem "=" wird nur die angegebene Version abgelehnt. Bei einem "!" werden alle Versionen außer der angegebenen abgelehnt.
deny::flags ermöglicht die Angabe von Compile Zeit Flag, die der Server haben oder nicht haben darf. Die Flags müssen direkt nacheinander ohne Zwischenräume angegeben sein. Wird einem Zeichen ein "!" vorangestellt, darf der Server dieses Flag nicht haben, steht kein "!" davor, so muss der Server dieses Flag haben, um vom Linken ausgeschlossen zu sein.

Syntax:

deny link {
	mask <server-name>;
	rule <crule-expression>;
	type <type-of-denial>;
};

Mit diesem Block können Regeln angegeben werden, nach denen man Server vom Linken ausschliessen kann.
deny::mask definiert eine Wildcard Maske auf den Servernamen, für den die Regel gelten soll.
deny::rule ist ein sehr komplexer Ausdruck. Ein crule Ausdruck erlaubt es, den Link sehr detailliert zu steuern und ist aufgebaut wie eine Programm Anweisung. Vier Operatoren werden unterstützt:
    connected(<servermask>) ergibt 'wahr', wenn ein Server zu dem die angegebene deny::mask passt, verbunden ist.
    directcon(<servermask>) ergibt 'wahr', wenn ein Server zu dem die angegebene deny::mask passt, direkt verbunden ist.
    via(<viamask>,<servermask>) ergibt 'wahr', wenn ein Server aus deny::mask über einen Server verbunden ist, auf den viamask passt.
    directop() ergibt wahr, wenn der Operator über /connect direkt zu diesem Server verbunden hat. 
Diese Operatoren können durch Verwendung von && (und) und || (oder) miteinander kombiniert werden. Durch Verwendung von Klammern um die eizelnen Items sind auch Gruppierungen möglich. Darüber hinaus kann einem Operator ein "!" vorangestellt sein, um darauf zu testen, ob der Operator 'falsch' ergibt. Wenn der gesamte Ausdruck 'wahr' ergibt, wird der Link abgelehnt.
deny::type kann zwei Werte haben: "auto" (gilt nur für autoconnects, /connect funktioniert trotzdem), und "all" (gilt für alle Verbindungsanfragen).

Syntax:

deny channel {
	channel "<channel-mask>";
	reason <reason-for-ban>;
	redirect "<channel-name>";
	warn [on|off];
};

Mit dem "deny channel Block" kann man Usern das joinen bestimmter Channels verbieten. In deny::channel wird die Maske der Channels angegeben, die die User nicht betreten dürfen, Wildcards sind erlaubt. In deny::reason wird der anzuzeigende Grund eingetragen, weswegen der Channel nicht betreten werden kann.  Darüber hinaus kann in deny::redirect ein Channel angegeben werden, in den ein User umgeleitet wird, falls er versucht einen gesperrten Channel zu betreten. Darüber hinaus kann über deny::warn (falls eingestellt) angegeben werden, dass eine OperNotice (an EYES snomask) gesendet wird, wenn ein User versucht, einen solchen Channel zu joinen.

Beispiel:

deny channel {
	channel "#unrealsucks";
	reason "Nein, tut es nicht!";
};

deny channel {
	channel "#*teen*sex*";
	reason "You == dead";
	warn on;
};

deny channel {
	channel "#operhelp";
	reason "Unser Hilfe Channel ist #help und nicht #operhelp";
	redirect "#help";
};

Syntax:

allow channel {
	channel "<channel-mask>";
};

Mit dem "allow channel Block" kann man Channels festlegen, in die User joinen dürfen. In allow::channel wird eine Channel Maske angegeben, die auch Wildcards enthalten kann und festlegt, in welche Channels die User joinen dürfen.

Beispiele:

allow channel {
	channel "#something";
};

allow channel {
	channel "#smart_*";
};

Syntax:

allow dcc {
	filename "<filename-mask>";
	soft [yes|no];
};

Mit dem "allow dcc Block" kann man Ausnahmen zum deny dcc Block festlegen, wobei Wildcards erlaubt sind. Wenn allow dcc::soft auf 'yes' gesetzt ist, gilt die 'soft dcc Bann Liste', wenn 'no' eingestellt ist, gelten normale ('harte') dcc Banns.

Beispiel:

allow dcc {
	filename "*.jpg"; /* Bilder sind üblicherweise sicher */
	soft yes;
};

Syntax:

vhost {
	vhost <vhost>;
	from {
		userhost <hostmask>;
		userhost <hostmask>;
		...
	};
	login <login-name>;
	password <password> { <auth-type>; };
	swhois "<swhois info>";
};

Der "vhost Block" ermöglicht es, eine "login"/"Passwort" Kombination festzulegen, die in Verbindung mit dem /vhost Befehl einen Fake Hostnamen ermöglicht. Der vhost::vhost Parameter kann entweder in der Form "user@host"  oder einfach als Hos angegeben werden, damit der User erfolgreich /vhost durchführen kann. vhost::from::userhost enthält einen "user@host"  der zu dem User passen muß, um einen vhost zu erhalten. Es kann mehr als eine Host Maske angegeben werden. vhost::login ist der Login Name, den der User eingeben muss und vhost::password ist das einzugebende Passwort. Darüber hinaus kann bei vhost::password:: auch ein Authentifizierungstyp für Verschlüsselung angegeben werden. Unterstützt werden hier z.Zt.  crypt, md5, und sha1, ripemd-160. vhost::swhois ermöglicht es, eine Extra Zeile für eine /whois Abfrage einzufügen, genau wie im Oper Block bei "oper::svhost".

Beispiel:

vhost {
	vhost my.own.personal.vhost.com;
	from {
		userhost my@isp.com;
		userhost myother@isp.com;
	};
	login mynick;
	password mypassword;
	swhois "Ich bin wichtig ;)";
};

Syntax:

badword <type> {
	word <text-to-match>;
	replace <replace-with>;
	action <replace|block>;
};

Mit dem Badword Block kann die Liste für User- und Channelmodus +G bearbeitet werden, um bestimmte "badwords" zu beahandeln. badword:: legt den Typ fest, wobei gültige Werte hier sind: channel, message und quit. channel gilt für Channel Modus +G list, message gilt für User Modus +G list, und quit gilt für die quit Meldung. badword::word kann ein einfaches Wort sein oder ein Ausdruck, nach dem gesucht werden soll. badword::replace ist ein Ersetzungstext, der anstelle des gefundenen Badwords angezeigt wird. Wird hier nichts eingetragen, so wird ein gefundenes Badword durch  <censored> erstezt. Bei badword::action wird angegeben, was im Falle eines gefundenen Badwords geschehen soll. Wird hier das Wort "replace" eingetragen, dann wird das Badword ersetzt. Falls hier "block" angegeben wird, wird die gesamte Nachricht gar nicht erst angezeigt. Falls "badword::action" nicht gesetzt ist, wird "replace" als Default angenommen.

Beispiel:

badword channel {
	word shit;
	replace shoot;
};

Syntax:

ulines {
	<server-name>;
	<server-name>;
	...
};

Mit dem ulines block können bestimmte Server mit speziellen Zwecken definiert werden. Das sollte ausschließlich für Server wie "services" oder "stats" benutzt werden und nicht für normale Server. Jeder Eintrag steht für den Namen des Servers mit einem besonderen Zweck.

Beispiel:

ulines {
	services.mynetwork.com;
	stats.mynetwork.com;
};

Syntax:

link <server-name> {
	username <usermask>;
	hostname <ipmask>;
	bind-ip <ip-to-bind-to>;
	port <port-to-connect-on>;
	password-connect <password-to-connect-with>;
	password-receive <password-to-receive> { <auth-type>; };
	hub <hub-mask>;
	leaf <leaf-mask>;
	leafdepth <depth>;
	class <class-name>;
	ciphers <ssl-ciphers> 
	options {
		<option>;
		<option>;
		...
	};
};

Dieser Block wird benötigt, um Server zueinander linken zu lassen. Man sollte sich Zeit nehmen, hierzu alles genau zu lesen, weil das Ganze nicht unkompliziert ist und hier die häufigsten Fehler gemacht werden.

Der erste Eintrag, server-name, ist der Name des zu verbindenden entfernten Servers, so wie er in dessen Me { } Block definiert wurde (z.B.: hub.blah.com). Es darf sich nicht um eine IP handeln und der Eintrag kann sich von "hostname" unterscheiden.

username
Hier kann zu Zwecken der Authentifizierung über ident ein Eintrag erfolgen, aber normalerweise wird nur "*" eingestellt.

hostname
Der Hostname oder die IP des entfernten Servers. Der Eintrag gilt gleichermaßen für das Verbinden UND die Authentifizierung seitens des eigenen Servers.
Einige Beispiele:

1.2.3.4	normale IP
hub.blah.com	Host: nur für ausgehende Verbindung, kann keine eingehenden Verbindungen akzeptieren, solange nicht "link::options::nohostcheck" gesetzt ist.
*	kann nicht selbst zu anderen Servern verbinden, aber akzeptiert eingehende Serververbindungen (mit korrektem Passwort) von überall her.
::ffff:1.2.3.4	für Linking ipv6 zu ipv4.

bind-ip (optional)
Kann genutzt werden, um eine bestimmte IP (z.B.: 192.168.0.1) daran zu binden, von wo aus verbunden werden soll, wird allerdings so gut wie nie benutzt.

port
Port zu dem verbunden wird (auf welchen der entfernte Server reagiert).

password-connect
Das Passwort, welches zum Verbinden erforderlich ist. Es muss im Klartext vorliegen und darf nicht verschlüsselt sein.

password-receive
Das Passwort, welches zur Überprüfung eingehender Verbindungen verwendet wird, kann auch verschlüsselt sein (gültige Methoden sind  crypt, md5, sha1, ripemd-160). Der "auth-type" Parameter kann auch frei gelassen werden, um das passwort im Klartext zu verwenden. Normalerweise ist das Passwort hier dasselbe, wie bei "password-connect".

hub oder leaf
Zu einem hub sind mehrere Server verbunden, ein leaf hat immer nur eine Verbindung. Ein Server ist entweder ein hub oder ein leaf - die beiden Optionen können nicht kombiniert werden.

hub (optional)
Der Wert ist eine Maske, auf welche Server dieser hub connecten darf (z.B.: *.my.net).

leaf (optional)
Der Wert ist eine Maske, dass dieser Server wie ein leaf in Richtung zum eigenen Server fungiert.

leaf-depth (optional)
Falls dies angegeben ist, sollte auch "leaf" angegeben sein. Angegeben wird die Tiefe (Anzahl der hops) die dieser Server darunter haben darf.

class
Die Klasse, in die der Server kommt, oft ist eine eigene Klasse für Server definiert.

compression-level (optional)
Gibt den Kompressions Level (1-9) für diesen Link an. Wird nur verwendet, wenn auch "link::options::zip" gesetzt ist.

ciphers (optional)
Gibt die SSL Verschlüsselung an, die für diesen Link benutzt wird. Um eine Liste der verfügbaren Verschlüsselungscodes zu erhalten, kann man den 'openssl ciphers' Befehl benutzen. ciphers ist als eine durch ':' getrennte Liste anzugeben. 

options block
Eine oder mehrere Optionen für eine Verbindung zu diesem Server. Wird manchmal nicht benötigt.

ssl	wenn zu einem SSL Port verbunden wird.
autoconnect	Server versucht autoconnect, Zeit, wie in "class::connfreq" spezifiziert wird (wird am besten nur auf einer Seite aktiviert,wie leaf->hub)
zip	wenn komprimierte Verbindungen gewollt sind, muß auf beiden Seiten mit +set zip compiliert sein.
nodnscache	IP für ausgehende Serververbindung nicht im cache speichern, wird bei oft wechselndem Host benutzt (wie dyndns.org)
nohostcheck	den entfernten Host nicht überprüfen (link::hostname), wird bei oft wechselndem Host benutzt (wie dyndns.org)
quarantine	Opers auf diesem Server behalten locop Status bei

Beispiel:

link hub.mynet.com {
	username *;
	hostname 1.2.3.4;
	bind-ip *;
	port 7029;
	hub *;
	password-connect "LiNk";
	password-receive "LiNk";
	class servers;
	options {
		autoconnect;
		ssl;
		zip;
	};
};

Syntax [standard alias]:

alias <name> {
	target <nick-to-forward-to>;
	type <type-of-alias>;
};

(Hinweis: siehe auch hier , welche Standard Alias Dateien bei UnrealIRCd mitgeliefert werden.)

Mit dem "alias block [standard alias]" kann festgelegt werden, dass ein Befehl an einen User geleitet wird. So wird z.B. durch /chanserv eine Nachricht an den "User" chanserv weitergeleitet. alias:: legt den Namen des Befehls fest, der das Alias wird, z.B. 'chanserv'. alias::target ist der Nickname, an den weitergeleitet wird. Wenn "alias::" identisch mit dem Nick ist, an den weitergeleitet wird, kann "alias::target" weggelassen werden. alias::type gibt den Typ des Alias an, gültige Typen sind hier "services" (der User ist auf dem Services Server), "stats" (der User ist auf dem Stats Server), und "normal" (der User ist normaler User auf irgendeinem Server). Der "alias block" hat auch einen weiteren Zweck, der nachfolgend erklärt ist.

Syntax [Befehl alias]:

alias <name> {
	format <regex-expression> {
		target <nick-to-forward-to>;
		type <type-of-alias>;
		parameters <parameter-string>;
	};
	format <regex-expression> {
		...
	};
	type command;
};

Wird der "alias Block" in diesem Format benutzt, ermöglicht er eine breitere Anwendungsweise. Beispielsweise kann man einen Alias wie /identify erstellen. alias:: ist dasselbe wie oben, der Name des Alias Befehls. alias::format legt einen regulären Ausdruck fest, der mit dem Text verglichen wird, der als Alias Befehl gesandt wurde. Es können mehrere "alias::format" angegeben werden, um unterschiedliche Dinge in Abhängigkeit vom gesandten Text durchführen zu lassen. alias::format::target ist das Ziel (der Name), an den der Alias weitergeleitet wird. alias::format::type definiert den Typ des Alias, zu dem die Nachricht geleitet wird. alias::format::parameters ist, was als Parameter an den Alias geschickt wird. Um Parameter für einen Befehl an den Alias anzugeben, wird ein "%" gefolgt von einer Nummer angegeben. So ist z.B. %1 der erste Parameter, %2 der zweite Parameter usw.  Man kann auch festlegen, dass ab einem Parameter alle bis zum Ende gelten sollen, dann gibt man z.B. an:  %1- (das Minuszeichen bedeutet: "alle weiteren") Zusätzlich kann man %n angeben, was durch den Nicknamen des Users ersetzt wird, der den befehl ausgeführt hat. Um Beispiele zum Alias Block zu sehen, schaue man in doc/example.conf.

Syntax:

help <name> {
	<text-line>;
	<text-line>;
	...
};

(zu beachten: Normalerweise genügt es statt dessen die help.conf per Include einzufügen)

Der "help block" ermöglicht es, Einträge zur Verwendung für den Befehl "/helpop" zu erstellen. help:: ist der Begriff, der später dem /helpop Befehl als Parameter übergeben wird. Wird hier kein Begriff angegeben, wird das Feld so verwendet, wie wenn bei "/helpop" kein weiterer Parameter angegeben ist (also z.B. eine globale Hilfe Übersicht).  Die Einträge für den "help Block" sind der Text, der später dem User nach der Eingabe von "/helpop" angezeigt werden.

Syntax:

official-channels {
"#channel" { topic "The default topic"; };
};

Offizielle Channels werden in der Channelliste (/list) auch angezeigt, wenn keine User im Channel sind. Das topic ist optional und wird nur angezeigt, wenn der Channel 0 User hat.

Beispiel:

official-channels {
"#Help" { topic "The official help channel, if nobody is present type /helpop helpme"; };
"#Home";
"#Main" { topic "The main channel"; };
};

spamfilter {
        regex "Come watch me on my webcam";
        target { private; channel; };
        action gline;
        reason "Du hast einen Trojaner, bitte schaue hier nach: www.antivirus.xx/blah/virus=GrrTrojan";
        ban-time 6h;
};

spamfilter {
        regex "come to irc\..+\..+";
        target { private; channel; };
        action gline;
        reason "Kein Spam erlaubt"
};

Im Set Block findet sich das, was früher in der networks/unrealircd.conf und der networks Datei von UnrealIRCd angegeben wurde. In Einzel-Server Netzwerken kann man die Set Anweisungen einfach in die unrealircd.conf eintragen, während es empfehlenswert ist, in größeren Netzwerken mit mehreren Servern weiterhin eine "networks" Datei zu verwenden.

Wenn nämlich der Server in ein Netzwerk eingebunden ist, werden wahrscheinlich überall die selben "Set" Einstellungen verwendet, so dass es mehr Sinn macht, eine "network" Datei zu verwenden, die mit der include Anweisung eingebunden wird. Weiter unten werden sämtliche möglichen "Set" Anweisungen im Einzelnen beschrieben.

In dieser Dokumentation werden Einstellungen / Anweisungen im <block-name>::<block-directive> Format angegeben. Dieses Format kann jedoch NICHT so in die unrealircd.conf eingetragen werden! Die Angaben MÜSSEN in das nachfolgend beschriebene Format konvertiert werden!  Die Darstellung im vereinfachten Format dient nur der vereinfachten Beschreibung der möglichen Einstellungen.

Syntax:

set {
	<entry> <value>;
	<entry> <value>;
	...
};

Im  "Set Block" werden die Optionen für bestimmte Server Funktionen eingestellt. Jeder Eintrag bewirkt etwas anderes und deshalb wird jeder einzeln beschrieben. Es gibt viele zu berücksichtigende Anweisungen und alle nachfolgend beschriebenen Anweisungen können in EINER "Set" Definition eingetragen werden. Wenn eine Anweisung Optionen ermöglicht oder erfordert, werden diese genauso in der einzelnen "Set" Anweisung mit angegeben.

Beispiel:

set {
	kine-address my@emailaddress.com;
	auto-join #welcome;
	options {
		hide-ulines;
	};
	hosts {
		local LocalOp.MyNet.com;
		global globalop.mynet.com;
	};
};

Sollen die "Set" Anweisungen getrennt erfolgen, also z.B. die Optionen in einer einzelnen Zeile aufgeführt werden,  ist auch dies möglich:.
Beispiel:
set { options { hide-ulines; no-stealth; }; };

set::kline-address <email-address>;
Eine email Adresse, an die Fragen zur K-Line gesandt werden sollen. Es muss hier ein Wert angegeben sein.

set::modes-on-connect <+modes>;
Die Modi, die für einen User nach einer Verbindung eingestellt werden.

set::snomask-on-connect <+modes>
Die snomask (Server Notice mask), die für einen User nach einer Verbindung eingestellt wird.

set::modes-on-oper <+modes>;
Die Modi, die eingestellt werden, wenn User (berechtigterweise) den /oper Befehl verwenden.

set::snomask-on-oper <+modes>;
Die snomask (Server Notice mask), die eingestellt wird, wenn User (berechtigterweise) den /oper Befehl verwenden.

set::modes-on-join <+modes>;
Die Modi, die für einen Channel eingestellt werden, wenn er das erste mal (durch /join) erstellt wird. Nicht alle Modi sind mit diesem Befehl möglich. Die Modi +qaohvbeOAzlLk können NICHT durch diesen Befehl gesetzt werden.

set::restrict-usermodes <modes>
Die User-Modi, die User wählen können werden auf die hier angegebenen Modi eingeschränkt. (kein + oder - angeben!).
Beispielsweise kann man  +G in 'modes-on-connect' setzen und G in 'restrict-usermodes', wodurch erreicht wird, dass sämtliche User  +G erhalten, aber kein -G anwenden können.

set::restrict-channelmodes <modes>
Die Channel-Modi, die User wählen können werden auf die hier angegebenen Modi eingeschränkt. (kein + oder - angeben!).
Beispielsweise kann man  +G in 'modes-on-join' setzen und G in 'restrict-channelmodes', wodurch erreicht wird, dass sämtliche (neuen) Channels  +G erhalten, aber kein -G eingestellt werden kann.
ACHTUNG: Es kann weiterhin möglich sein, diese Channel Modi durch Services über MLOCK zu benutzen. Wir können dagegen leider nichts tun, es obliegt den Codern der Services, ebenfalls ein restrict-channelmodes feature zu implementieren.

set::restrict-extendedbans <types|*>
Den Usern ist nicht gestattet, irgendwelche erweiterten Banns ("*") zu benutzen oder es werden nur bestimmte Typen verboten (z.B.:"qc").

set::auto-join <channels>;
Der oder die Channel(s), in den/die User beim Connect automatisch geforwardet werden. Soll mehr als ein Channel angegeben werden, so sind diese durch Kommata zu trennen.
[Achtung: nicht vergessen, Anführungszeichen zu verwenden, wie: auto-join "#chan";]

set::oper-auto-join <channels>;
Der oder die Channel(s), in den/die User bei /oper automatisch geforwardet werden. Soll mehr als ein Channel angegeben werden, so sind diese durch Kommata zu trennen.
[Achtung: nicht vergessen, Anführungszeichen zu verwenden, wie: auto-join "#chan";]

set::anti-spam-quit-message-time <timevalue>;
Eine Zeitangabe, in der festgelegt wird, wie lange ein User verbunden gewesen sein muss, bevor eine /quit Meldung angezeigt wird. Das dient der Vermeidung von Spam. Ein Zeitwert ist ein numerischer String, in dem 'd" Tage bedeutet, 'h' Stunden, 'm' Minuten und 's' Sekunden. Beispiel: 1d2h3m bedeutet 1 Tag, 2 Stunden und 3 Minuten.

set::prefix-quit <text-to-prefix-quit>;
Hier wird der Text festgelegt, der einer Quit Meldung vorangestellt wird. Ist hier eine 0 eingetragen, wird der Standard "Quit:" verwendet.

set::static-quit <quit message>;
Hiermit kann eine feste Quit Meldung eingestellt werden, die immer angezeigt wird, wenn ein Client ausloggt. Das kann die 'anti-spam-quit-message-time' ebenso überflüssig machen, wie das 'set::prefix-quit'. Fehlermeldungen werden NICHT durch diese Einstellung ersetzt! (z.B. wird "ping timeout" weiterhin angezeigt)

set::static-part <no|yes|part message>;
Ein Wert von 'yes' unterdrückt sämtliche Kommentare bei 'part', ein Wert von 'no' läßt 'part' wie gewohnt arbeiten, jede andere Angabe wird als Kommentar für 'part' fest eingestellt (z.B.: static-part "Bye!"). Da dies auch als belästigend empfunden werden kann, sollte man dies mit Bedacht wählen.

set::who-limit <limit>;
Stellt den Maximalwert ein, wie viele Angaben bei einem  /who angezeigt werden sollen. Ohne Eintrag hier gibt es kein Limit.

set::silence-limit <limit>;
Stellt den Maximalwert der anzeigbaren SILENCE Einträge ein. Ohne Eintrag ist hier ein Limit von 15 voreingestellt.

set::oper-only-stats <stats-list>;
Definiert eine Liste von Stats-Flags, die nur von Opers benutzt werden können. Die Flags sind ohne Trennungen (keine Kommata, keine Leerzeichen) anzugeben. Wird hier nichts angegeben, können alle User sämtliche Flags benutzen, bei Angabe von '*' keines. Es dürfen nur kurze Operflags angegeben werden.

set::oper-only-stats {<stats-flag>; <stats-flag>;};
Definiert eine Liste von Stats Flags, die nur von Opers benutzt werden können. In dieser Syntax dürfen nur lange Operflags angegeben wwerden.

set::maxchannelsperuser <amount-of-channels>;
Einstellung, in wie vielen Channels ein User gleichzeitig sein darf.

set::maxdccallow <amount-of-entries>;
Legt fest, wie viele Einträge ein User in seiner DCCALLOW Liste haben kann.

set::channel-command-prefix <command-prefixes>;
Stellt das Vorzeichen für Services in "channel Befehlen" ein. Nachrichten, die mit einem dieser Zeichen beginnen, werden auch noch gesendet, wenn der Client +d ist. Die Voreinstellung lautet "`".

set::allow-userhost-change [never|always|not-on-channels|force-rejoin]
Einstellung, was passiert, wenn sich der user@host ändert (+x/-x/chghost/chgident/setident/vhost/etc).
never schaltet sämtliche Befehle ab, always gestattet so etwas auch in Channel immer (was zu desyncs von Clients führen kann)  [default], not-on-channels bedeutet, dass solche Befehle nur erlaubt sind, wenn der User in keinem Channel ist, force-rejoin bewirkt einen rejoin in sämtlichen Channels sowie re-op/voice/etc falls notwendig.

set::options::hide-ulines;
Wenn dies eingestellt ist, werden Ulined Server bei  /links von Nicht-Opers nicht angezeigt.

set::options::flat-map;
Wenn dies eingestellt ist, werden alle Server bei /map und /links als direkt gelinkt angezeigt. Dadurch kann man nicht mehr erkennen, welcher Server mit welchem gelinkt ist. Das ist eine kleine Hilfe gegen (D)DoS Attacken, weil potentielle Angreifer jetzt nicht mehr länger mögliche "Schwachpunkte" erkennen können.

set::options::show-opermotd;
Falls eingestellt wird die opermotd den Usern angezeigt, die erfolgreich /oper benutzen.

set::options::identd-check;
Falls eingestellt, wird die Präsenz eines identd Servers geprüft und der Rückgabewert für den Usernamen verwendet. Wird kein Rückgabewert geliefert oder existiert der identd Server nicht, wird dem Usernamen ein '~' vorangestellt. Wird diese Einstellung ausgelassen, erfolgt keine Überprüfung.

set::options::show-connect-info;
Falls eingestellt, werden dem User beim Connect Notices wie "ident request", "hostname lookup", etc. angezeigt.

set::options::dont-resolve;
Wenn eingestellt, werden die Hosts connectender User nicht aufgelöst. Das kann nützlich sein, um die Verbindung zu beschleunigen, falls viele User keinen Host haben.
Zu beachten ist, dass man keine host basierten allow Blöcke verwenden kann, wenn dies eingestellt ist.

set::options::mkpasswd-for-everyone;
Stellt ein, dass /mkpasswd von jedem User verwendet werden kann und nicht nur von Opers. Die Anwendung dieses Befehls durch Nicht-Oper wird an die EYES snomask gesendet.

set::options::allow-part-if-shunned;
Erlaubt es Usern, auf die ein /shun gesetzt ist, den /part Befehl zu benutzen.

set::dns::timeout <timevalue>;
Ein Wert, der angibt, innerhalb welcher Zeit ein DNS Server zu antworten hat, bevor "timeout" gemeldet wird. Der Zeitwert ist ein numerischer String, in dem 'd' Tage bedeutet, 'h' Sunden, 'm' Minuten und 's' Sekunden. Beispiel: '1d2h3m' bedeutet 1 Tag, 2 Stunden, 3 Minuten.

set::dns::retries <number-of-retries>;
Ein Zahlenwert, durch den festgelegt wird, wie oft versucht werden soll, die DNS aufzulösen, bevor ein Fehler gemeldet wird.

set::dns::nameserver <name-of-dns-server>;
Gibt den Hostnamen des Servers an, der zur DNS Namensauflösungen dient.

set::network-name <name-of-network>;
Gibt den Namen des Netzwerks an, in dem der Server läuft (also den Namen des irc Netzes!) Dieser Eintrag sollte auf allen Servern im Netzwerk absolut identisch sein.

set::default-server <server-name>;
Legt den Namen des Servers fest, der den Usern mitteilt, wo sie connecten sollen, wenn dieser Server voll ist.

set::services-server <server-name>;
Legt den Namen des Servers fest, zu dem die Services Bots verbunden sind. Muß angegeben sein, der Wert ist auf so etwas wie 'services.yournet.com' zu setzen, wenn man keine Services hat.

set::stats-server <server-name>;
Stellt den Namen des Servers ein, auf dem die Stats laufen. Die Angabe kann ausgelassen werden, wenn man keine Stats laufen hat.

set::help-channel <network-help-channel>;
Legt den Namen des Hilfe Channels in diesem Netzwerk fest.

set::cloak-keys { <"key1">; <"key2">; <"key3">; };
Stellt die Verschlüsselungs Keys ein, die für die Erstellung eines +x Host erforderlich sind. Diese Einstellung muss auf allen Servern identisch sein, ansonsten linken die Server nicht. Jeder Wert in 'set::cloak-keys::' muss ein String zwischen 5 bis 100 Zeichen sein (10-20 ist gut), der gemisch Großbuchstaben (A-Z), Kleinbuchstaben (a-z) und Ziffern (0-9) enthält. Diese Regeln gelten für cloak.so/cloak.dll, bei anderen Cloaking Modulen können andere Zeichen erlaubt/erforderlich sein. Es müssen exakt 3 Werte angegeben werden.

set::hiddenhost-prefix <prefix-value>;
Legt die ersten Zeichen eines verdeckten Hosts (+x) fest. Üblicherweise nimmt man hier 3 oder 4 Buchstaben, die den Netzwerksnamen bezeichnen.

set::hosts::local <locop-host-name>;
Legt den Hostnamen fest, der lokalen Operatoren zugewiesen wird, wenn sie +x setzen. Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::global <globop-host-name>;
Legt den Hostnamen fest, der globalen Operatoren zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::coadmin <coadmin-host-name>;
Legt den Hostnamen fest, der co-admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::admin <admin-host-name>;
Legt den Hostnamen fest, der Admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::servicesadmin <servicesadmin-host-name>;
Legt den Hostnamen fest, der Service-Admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::netadmin <netadmin-host-name>;
Legt den Hostnamen fest, der Netadmins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::host-on-oper-up <yes/no>;
Falls auf 'yes' eingestellt, wird das H/get_host Flag akzeptiert und  +x wird automatisch bei /oper gesetzt.. Falls 'no', muss sich der User manuell +x setzen, um einen oper Host zu erhalten.

set::ssl::egd <filename>;
Gibt an, dass EGD (Entropy Gathering Daemon) Unterstützung aktiviert wird. Hat man OpenSSL 0.9.7 oder höher laufen, dann wird /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool, und /etc/entropy per Default gesucht und es ist kein Dateiname erforderlich. Dann legt man einfach 'set::ssl::egd' ohne Wert fest. Verwendet man ältere Versionen von OpenSSL, oder soll der EGD socket woanders als in den oben angegebenen Ordnern liegen, muss man den Dateinamen des UNIX Domain Socket angeben, an dem  EGD lauscht.

set::ssl::certificate <filename>;
Gibt den Dateinamen an, wo das SSL Zertifikat des Servers liegt.

set::ssl::key <filename>;
Gibt den Dateinamen an, wo der private SSL Key des Servers liegt.

set::ssl::trusted-ca-file <filename>;
Gibt den Dateinamen der Zertifikate der vertrauten CAs an.

set::ssl::options::fail-if-no-clientcert;
Stellt ein, dass Clients ohne Zertifikat nicht connecten können.

set::ssl::options::no-self-signed;
Verbietet Verbindungen von Usern mit selbst erstellten Zertifikaten.

set::ssl::options::verify-certificate;
Stellt ein, dass Unreal  SSL Zertifikate auf Gültigkeit überprüft, bevor eine Verbindung akzeptiert wird.

set::throttle::period <timevalue>
Wie lange muss ein User zum erneuten Connecten warten, wenn er häufiger, als unter 'set::throttle::connections' eingestellt, verbunden war.

set::throttle::connections <amount>;
Wie oft muss ein User mit demselben Host verbinden, bevor er temporär gesperrt wird.

set::ident::connect-timeout <amount>;
Zeitangabe von Sekunden, ab wann aufgegeben wird zum Ident Server zu verbinden (Default: 10s).

set::ident::read-timeout <amount>;
Nach wie viele Sekunden Warten auf einen Reply soll aufgegeben werden (Default: 30s).

set::anti-flood::unknown-flood-bantime <timevalue>;
Gibt an, wie lang ein Flooder mit 'unknown connection' gebannt wird.

set::anti-flood::unknown-flood-amount <amount>;
Legt eine Datenmenge (in KiloBytes) fest, die eine ' unknown connection' senden muss, damit der User gekillt wird.

set::anti-flood::away-flood <count>:<period>
Schutz vor 'Away Flood': legt fest, wie viele  ('count') /away Änderungen innderhalb welcher Zeit in Sekunden ('period') erfolgen dürfen.. Das erfordert, dass in der config.h die Einstellung 'NO_FLOOD_AWAY' aktiviert wurde. Beispiel: away-flood 5:60s; bedeutet maximal 5 Änderungen innerhalb von 60 Sekunden.

set::anti-flood::nick-flood <count>:<period>
Nickflood Schutz: Beschränkt Nickänderungen auf  'count' pro 'period' Sekunden. Beispiel: nick-flood 4:90 bedeutet maximal  4 Nickänderungen in 90 Sekunden. Default ist  3 per 60.

set::default-bantime <time>
Default Bann Dauer wenn /kline, /gline, /zline, /shun, etc ohne Zeitangabe gesetzt werden (wie /gline *@some.nasty.isp). Default ist permanent (0). Beispiel: default-bantime 90d; (90 Tage)

set::modef-default-unsettime <value>
Für den Channel Modus +f kann eine Default Abschaltzeit festgelegt werden. Wird z.B. der Wert 10 festgelegt, dann wird +f [5j]:15 in [5j#i10]:15 umgewandelt. Default ist keine Abschaltzeit.

set::modef-max-unsettime <value>
Maximalwert in Minuten für eine Modus +f Abschaltzeit (z.B. in +f [5j#i<TIME>]:15). Der Wert kann zwischen 0 und 255 liegen und Default ist 60 (= 1 Stunde).

set::ban-version-tkl-time <value>
Definiert man in 'ban version' eine Aktion, wie zline/gline/etc, dann kann man hier die Dauer des Banns auf die IP in Sekunden angeben. Default ist 86400 (1 Tag).

set::spamfilter::ban-time <value>
Genauso, wie oben, aber für  *lines, die durch den Spam Filter gesetzt wurden.

set::spamfilter::ban-reason <reason>
Anzuzeigender Grund bei  *lines, die durch den Spam Filter gesetzt wurden. Mehrere Worte sind durch Underscores ("_") und nicht durch Leerzeichen zu trennen.

set::spamfilter::virus-help-channel <channel>
Festlegung des Channels für die Aktion 'viruschan'  in Spamfilter

set::spamfilter::virus-help-channel-deny <yes|no>
Falls auf 'yes' (oder '1') gesetzt, erhält jeder normalen User, der versucht, diesen Channel zu joinen, die Antwort 'invite only'. Nur Opers, User, bei denen der Spamfilter zutrifft oder User, die eingeladen werden, können diesen Channel joinen.

set::spamfilter::except <target(s)>
Diese Ziele werden vom Spamfilter ausgenommen (es wird also keine Aktion durchgeführt). Es sind einzelne Ziele oder eine durch Kommata getrennte Liste möglich. Beispiel: except "#help,#spamreport"

ACHTUNG: die /helpop Dokumentation ist aktueller, nutze /helpop Befehl (oder /helpop ?Befehl wenn Du Oper bist), um zusätzliche Informationen über einen Befehl zu erhalten.

Wenn man um die Sicherheit besorgt ist (und das sollte man sein!), findet man in diesem Abschnitt Hilfe, um einen Überblick über Risiken und deren Bedeutung zu erhalten. Man kann diesen Abschnitt auch als "Checkliste" benutzen, um die Netzwerk Konfiguration zu überprüfen und sie sicherer zu machen.

Die Liste ist na Popularität/Risiko und Level der am meisten verwendeten Methoden bei Attacken geordnet:

1. Der Name des Hubs sollte auf einen Host eingestellt sein, der nicht existiert (z.B.: 'hub.yournet.com'), aber es sollte kein DNS Eintrag für ihn erfolgen. Dadurch kann ein Angreifer den Host nicht zu einer IP auflösen und ihn damit nicht flooden. Dann werden Server und Hub einfach durch Angabe der IP oder einen weiteren nicht öffentlichen Hostnamen gelinkt.
   Beispiel 1: link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };.
   Beispiel2: link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };.
   Nebenbei bemerkt muss für das zweite Beispiel sichergestellt sein, dass der Nameserver keine Zonenübertragungen erlaubt, aber das führt hier zu weit vom Thema weg.
2. Ein weiterer wichtiger Punkt ist,  '/stats c' und andere Stats Informationen zu verbergen, andernfalls können Angreifer einfach die Link Blöcke einsehen. Sinnvollerweise, wenn man so extrem wie der Autor auf Sicherheit bedacht ist, kann man folgendes eintragen: set { oper-only-stats "*"; }; und verhindert somit jeglichen Gebrauch von  /stats.
   Wenn das nicht gewollt ist, ist wenigstens "CdDlLXz" zu verbergen. Mehr dazu im nächsten Abschnitt.

Allerdings sind solche Dinge wenig hilfreich, wenn sie später (z.B. nach einigen Monaten) durchgeführt werden, statt von Anfang an. Sonst könnte die IP nämlich bereits bekannt sein und auch einigen böswilligen Menschen.

Es ist auch zu beachten, dass Angreifer weiterhin die Nicht-Hub Server flooden können, aber das bedeutet einen höheren Aufwand, als lediglich 1-2 Schwachpunkte (die Hubs) anzugreifen. Das trägt damit ebenso zum Überleben von Hubs & Services bei :).

MAP / LINKS
Es wurde häufig gefragt, ob es möglich sei,  /map oder /links zu deaktivieren. Unnsere Position hier zu ist, dass dies leichtfertig wäre und ein falsches Gefühl von Sicherheit gäbe. Um das zu erklären: Server zu verbergen, die aktuell von Usern benutzt werden, ist sinnlos, da die Server den Usern ja schon bekannt sind. Für alle anderen Server, auf denen man keine User möchte, siehe Abschnitt 8.6.
Nun, was KANN man tun? Seit der Version 3.2.1 gibt es eine Option namens 'flat map' (set::options::flat-map), die bewirkt, dass bei /map und /links Befehlen alle Server als direkt gelinkt erscheinen lässt. Dadurch können normale User nicht mehr erkennen, welcher Server zu welchem gelinkt ist. Dies kann ein netter zusätzlicher Schutz sein, weil dadurch nicht mehr irgendwelche Kiddies irgendwelche "Schwachpunkte" per /map und /links erkennen können. Somit ist es empfehlenswert, diese Option zu benutzen. Zu beachten ist, dass das nicht narrensicher ist. Denn bei einem Netsplit kann man noch erkennen, welcher Server mit welchem gelinkt war und dies gilt auch für einige andere Dinge genauso.

NORMAL USERS & SNOMASKS
Ein nicht allgemein beakanntes Feature ist, dass normale User ebenfalls einige eingeschränkte snomasks gesetzt haben können, insbesondere +s +sk. Dadurch können sie Dinge wie rehashs, oper ups, kills und verschiedene andere Meldungen lesen.
Um das zu deaktivieren, kann man set::restrict-usermodes benutzten, wie hier: set { restrict-usermodes "s"; };.

Das ganze "Verbergen von Informationen" ist natürlich keine "echte" Sicherheit. Allerdings macht es Angriffe schwieriger und erhöht den Aufwand für einen Angriff oder hack.

Die FAQ kann man online hier lesen .