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-2006

Bitte lesen Sie diese Anleitung, bevor Sie um Hilfe bitten und schauen Sie WIRKLICH erst einmal 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 (ansonsten wird es 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)

Windows:

• 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!

Getestete & unterstützte Betriebs Systeme:

• *NIX Versionen:
  • Linux (2.2.*, 2.4.*, 2.6.*)
  • FreeBSD (4.*, 5.*, 6.*)
  • NetBSD (2.*)
  • OpenBSD (3.7, 3.8, 3.9)
  • Solaris (9,10)
• Windows Versionen:
  • Windows 2000 (Pro, Server, Advanced Server)
  • WindowsXP (Home, Pro)
  • Windows 2003
• Getestete Architektueren (Prozessoren):
  • ia32 (i386, i486, i586, i686)
  • ia64
  • amd64
  • alpha

Im Falle, dass Unreal3.2 korrekt unter anderen Betriebssystemen läuft, bitte Details an coders@lists.unrealircd.org senden.

Installationsanleitungen
Linux:

1. gunzip -d Unreal3.2.X.tar.gz
2. tar xvf Unreal3.2.X.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, weil man ansonsten Konzepte wie cloaking, snowmask etc. nicht verstehen wird..

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 wird nur 1 solches  Modul mitgeliefert:
cloak:
Hierbei handelt es sich um das neue offizielle Cloaking Modul, welches viel sicherer, als der alte Algorithmus ist. Es verwendet intern md5 und erfordert, dass 3 set::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. 

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)

Per Default ist eingestellt, dass einem User, der einfach nur den Modus +s setzt, bestimmte Flags eingestellt werden. Für Nicht-Opers ist das die snomask +ks, und für Opers die snomask +kscfvGqo.

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 empfiehlt 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. Hier 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

Damit wird zu 127.0.0.1 über Port 6667 verbunden, der Datenverkehr wird verschlüsselt und weitergeleitet an irc.myserv.com port 6900 (ein SSL Port).

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, dass 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, j = join throttling (Beschränkung der Joins je User)

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:

Typ:	Name:	Default Action:	mögliche weitere Actions:	Kommentar
c	CTCPs	auto +C	m, M
j	joins	auto +i R
k	knocks	auto +K		(nur für lokale Clients)
m	messages/notices	auto +m	M
n	nickchanges	auto +N
t	text	kick	b	in messages/notices wie das alte +f. Kickt oder bannt User.

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.

Channel mode j
Der +f Modus enthält ein Feature, um join Floods zu vermeiden, allerdings ist dieses Feature "global." Lautet z.B. die Einstellung 5:10 und 5 verschiedene User joinen in 10 Sekunden, spricht der Flood Schutz an. Der Channel Mode +j arbeitet anders. Dieser Modus arbeitet auf einer pro User Basis. Anders als Join Floods wirkt er gegen join-part Floods (eine Art ständig sich wiederholendes rein - raus). Der Modus benötigt einen Parameter in der Form X:Y, wobei X die Anzahl der Joins und Y die Anzahl der Sekunden ist. Überschreitet ein User dieses Limit, wird er für diesen Channel gesperrt und kann nicht mehr joinen.

Einfache Bann-Typen und verdeckte Hosts
UnrealIRCd unterstützt die einfache Bann Form: +b nick!user@host.
Angenommen, der verdeckte Host von jemandem ist 'rox-ACB17294.isp.com' und es wird ein Bann auf *!*@rox-ACB17294.isp.com gesetzt, dann wird auch, wenn der User sich selbst -x setzt (und sein Host z.B. zu 'dial-123.isp.com' wird), der Bann weiterhin gelten. Banns werden immer sowohl gegen reale Hosts UND verdeckte Hosts geprüft.
Auch IP Banns (z.B.: *!*@128.*) sind möglich und werden ebenso immer geprüft.

Banns auf verdeckte IPs erfordern einige Erklärungen:
Angenommen, ein User hat die IP 1.2.3.4, dann könnte sein verdeckter Host '341C6CEC.8FC6128B.303AEBC6.IP' sein.
Wenn man auf '*!*@341C6CEC.8FC6128B.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.3.4' (einleuchtend...)
Wenn man auf '*!*@*.8FC6128B.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.3.*'
Wenn man auf '*!*@*.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.*'
(Die "Stelle" in der verdeckten IP ist also genau anders herum, wie in der realen IP)
Diese Information könnte hilfreich sein, wenn man entscheidet, wie breit eine Maske sein soll.

Erweiterte bann Typen
Erweiterte Bann Typen sind so aufgebaut: '~[!]<type>:<stuff>'. Gegenwärtig gibt es folgende Typen:

Typ	Name	Erklärung
~q	quiet	User, auf die dieser Bann gesetzt ist, können joinen, aber nicht schreiben, solange sie nicht +v oder höher haben. Beispiel: ~q:*!*@blah.blah.com
~n	nickchange	User, auf die dieser Bann gesetzt ist, können ihre Nicks nicht ändern, solange sie nicht +v oder höher haben. Beispiel: ~n:*!*@*.aol.com
~c	Channel	Wenn der User in diesem Channel ist, kann er nicht joinen. Beispiel: ~c:#lamers. Es kann hier auch ein Prefix (+/%/@/&/~) angegeben werden, wodurch erreicht wird, dass dies nur für User mit diesem oder höheren Rechten im angegebenen Channel Auswirkungen hat. Beispiel: +b ~c:#lamers, +e ~c:@#trusted
~r	Realname	Wenn der Realname des Users gebannt ist, kann der User nicht joinen. Beispiel: ~r:*Stupid_bot_script* Zu Beachten: Ein Unterstrich ('_') bedeutet beides, sowohl ein Leerzeichen (' '), als auch den Unterstrich ('_') selbst. Der Bann aus dem Beispiel oben würde also  'Stupid bot script v1.4' treffen.

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.

Spamfilter ist ein neues System gegen Spam, Belästigungen, Würmer etc. Es arbeitet ein wenig ähnlich wie 'badwords', hat aber einige Erweiterungen..

Spamfilter werden durch den  /spamfilter Befehl mit der folgenden Syntax gesetzt:
/spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [reason] [regex]

[type]	gibt an, auf welchen Nachrichtentyp reagiert werden soll;
	Zeichen:	Config Eintrag		Bedeutung
	c	channel		Nachricht im Channel (öffentlich)
	p	privat		Private Nachricht (von User --> User)
	n	private-notice		Private Notiz
	N	channel-notice		Channel Notiz
	P	part		Grund Angabe beim Verlassen des Channels
	q	quit		Grund Angabe beim Beenden des Chats
	d	dcc		DCC Dateiname
	a	away		Away Meldung
	t	topic		Setzen eines Topics
	u	user		bannt User, geprüft wird auf nick!user@host:realname
	Es ist möglich, mehrere Ziele anzugeben, wie z.B.: cpNn
[action]	gibt an, welche Aktion erfolgen soll (es kann nur 1 Aktion angegeben werden)
	kill		Killt den User
	tempshun		setzt für die laufende Verbindung einen Shun auf den User (bei Reconnect ist der Shun aufgehoben
	shun		Setzt einen Shun auf den Host
	kline		Setzt eine kline auf den Host
	gline		Setzt eine gline auf den Host
	zline		Setzt eine zline auf den Host
	gzline		Setzt eine gzline (globale zline) auf den Host
	block		Blockiert lediglich die Nachricht
	dccblock		markiert den User derart, dass er nicht in der Lage ist, irgend welche DCCs zu senden
	viruschan		User wird aus allen Channels entfernt, wird in den unter set::spamfilter::virus-help-channel eingetragenen Channel geforwardet, alle Befehle außer PONG und ADMIN werden deaktiviert und msg/notices werden zum Channel aus set::spamfilter::virus-help-channel geleitet.
[tkltime]	Die Zeitdauer, die für eine durch den Filter gesetzte *line/shun gilt. Um den Default zu benutzen oder zum Übergehen (z.B. wenn action = 'block'), lediglich ein '-' eintragen,
[reason]	Der anzuzeigende Grund für Block- oder *lines/shun Befehle. Man kann hier KEINE Leerzeichen eintragen, aber Unterstriche ('_') werden zur Laufzeit in Leerzeichen umgesetzt. Ein doppelter Underscore ('__') erzeugt einen Underscore ('_') in der Ausgabe. Auch hier ein '-' eintragen, um den Default zu benutzen.
[regex]	gibt den Ausdruck oder das 'bad word' an, welches geblockt werden soll, oder worauf die Aktion erfolgen soll

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/shuns, die durch den Spamfilter gesetzt wurden (default: 1 Tag)
set::spamfilter::ban-reason ermöglicht die Festlegung eines Grundes für die *lines/shuns (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, oper::from::userhost, 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 bietet die Möglichkeit, festzulegen, welche Zeichensätze/Sprachen in Nicknamen gestattet sein sollen. Dies wird festgelegt in set::allowed-nickchars.
Hier eine Liste der möglichen Einstellungen:

Name:	Beschreibung:	Character set/encoding:
catalan	Katalanische Zeichen	iso8859-1 (latin1)
danish	Dänische Zeichen	iso8859-1 (latin1)
dutch	Niederländische Zeichen	iso8859-1 (latin1)
french	Französische Zeichen	iso8859-1 (latin1)
german	Deutsche Zeichen	iso8859-1 (latin1)
swiss-german	Schweiz-Deutsche Zeichen (kein 'ß')	iso8859-1 (latin1)
icelandic	Isländische Zeichen	iso8859-1 (latin1)
italian	Italienische Zeichen	iso8859-1 (latin1)
spanish	Spanische Zeichen	iso8859-1 (latin1)
swedish	Schwedische Zeichen	iso8859-1 (latin1)
latin1	katalanisch, dänisch, niederländisch, französisch, deutsch, schweizer deutsch, spanisch, isländisch, italienisch, schwedisch	iso8859-1 (latin1)
hungarian	Ungarische Zeichen	iso8859-2 (latin2), windows-1250
polish	Polnische Zeichen	iso8859-2 (latin2)
romanian	Rumänische Zeichen	iso8859-2 (latin2), windows-1250, iso8859-16
latin2	ungarisch, polnisch, rumänisch	iso8859-2 (latin2)
polish-w1250	Polnische Zeichen, Windows Variante (leider mehr allgemein, als iso)	windows-1250
slovak-w1250	Slowakische Zeichen, Windows Variante	windows-1250
czech-w1250	Tschechische Zeichen, Windows Variante	windows-1250
windows-1250	polnisch-w1250, slowakisch-w1250, tschechisch-w1250, ungarisch, rumänisch	windows-1250
greek	Griechische Zeichen	iso8859-7
turkish	Türkische Zeichen	iso8859-9
russian-w1251	Russische Zeichen	windows-1251
belarussian-w1251	Belarussische Zeichen	windows-1251
ukrainian-w1251	Ukrainische Zeichen	windows-1251
windows-1251	russisch-w1251, belarussisch-w1251, ukrainisch-w1251	windows-1251
hebrew	Hebräische Zeichen	iso8859-8-I/windows-1255
chinese-simp	Einfaches Chinesisch	Multibyte: GBK/GB2312
chinese-trad	Traditionelles Chinesisch	Multibyte: GBK
chinese-ja	Japanisch Hiragana/Pinyin	Multibyte: GBK
chinese	chinese-*	Multibyte: GBK
gbk	chinese-*	Multibyte: GBK

 

Anmerkung 1: Zu beachten ist, dass einige Kombinationen Probleme verursachen können. Beispielsweise kann eine Kombination aus latin* und chinesisch-* nicht korrekt von IRCd behandelt werden und es wird ein Fehler angezeigt. Das Mischen von Zeichensätzen kann der Grund von Anzeige Problemen sein. Aus diesem Grund wird Unreal eine Warnung anzeigen, wenn versucht wird, latin1/latin2/greek oder andere inkompatibele Gruppen zu mischen.

Anmerkung 2: Die Übereinstimmung von Zeichen, also welcher Großbuchstabe zu welchem Kleinbuchstaben gehört, erfolgt nach dem US-ASCII, was bedeutet, dass ö und Ö nicht als 'gleiches Zeichen' erkannt werden und deswegen jemand beispielsweise den Nick Bär haben kann, während jemand anderes gleichzeitig den Nick BÄr hat. Das ist eine Einschränkung durch das aktuelle System und IRCd Standards, die nicht binnen kurzer Zeit gelöst werden können. Den Usern sollte diese Einschränkung klar sein. Zu beachten dabei ist, dass es diese Einschränkung schon immer bei den Channelnamen gegeben hat, in denen ja fast alle Zeichen erlaubt sind und schon immer die US-ASCII Regeln der Zeichenübereinstimmung gegolten haben.

Anmerkung 3: Die Basis Nick Zeichen (a-z A-Z 0-9 [ \ ] ^ _ - { | }) sind immer erlaubt/aktiviert.


Beispiel 1, für West-Europäer:

set { allowed-nickchars { latin1; }; };

Beispiel 2, wenn man überwiegend chinesische User hat und normale chinesische Schriftzeichen gestatten will:

set { allowed-nickchars { chinese-simp; chinese-trad; }; };

UnrealIRCD unterstützt eine CGI:IRC Host Manipulation. Das bedeutet: Man kann bestimmte CGI:IRC Gateways als "trusted" ("vertraut") festlegen, wodurch der IRCd veranlasst wird, statt Host/IP des CGI:IRC Gatewäys überall im IRC die reale Host/IP des Users anzuzeigen.

Nähere Informationen, wie dies konfiguriert wird, stehen im cgiirc Block 

Es ist für die IRC Server sehr wichtig, immer die korrekte Zeit eingestellt zu haben. Ohne korrekte - insbesondere unterschiedliche Zeit zwischen Servern - können Channel desynchronisieren (auf verschiedenen Servern wird etwas anderes im gleichen Channel angezeigt), ahnungslose User grundlos gekillt werden, Channels gar nicht oder falsch in der /List Anzeige eingetragen sein. Kurzum: es entstehen sehr große Probleme.´

UnrealIRCd hat eine eine Unterstützung zur Zeitsybchronisation integriert. Obwohl sie nicht optimal ist (die Zeiten können weiterhin um wenige Sekunden differieren), sollten damit die meisten Zeitunterschiede beseitigt werden. Soweit möglich ist es weiterhin empfehlenswert, eine Zeitsynchronisations Software wie 'ntpd' auf  *NIX Systemen oder den Zeit Synchonisations Service von Windosws laufen zu haben. In diesem Fall kann man die Unreal Zeitsynchronisation abschalten. (mehr dazu später)

Per Default versucht UnrealIRCd beim Start einen Versuch der Zeitsynchronisation. Es werden hierzu einige Anforderungen an Zeitserver gesendet und sobald die erste (schnellste) Antwort empfangen wird die interne IRCD Uhr (NICHT die Systemuhr) danach eingestellt. Wenn aus irgendwelchen Gründen nicht binnen 3 Sekunden eine Zeitabfrage beantwortet wird, startet der IRCD ohne Zeitsynchronisation (sollte nur selten passieren).

Zeitsynchronisation wird im set::timesynch Block konfiguriert (oder abgeschaltet). Siehe in der Set-Block Beschreibung für weitere Informationen.

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 15 - 60 Minuten. Eine gute unrealircd.conf zu erstellen, wird bedeutend länger dauern. Man sollte nicht hetzen, um den IRCd rasch gestartet zu bekommen, sondern lieber Schritt für Schritt vorangehen.  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 */

Nachdem nun klar ist, wie das funktioniert, sollte man die doc/example.conf in das UnrealIRCd Verzeichnis kopieren (z.B.: /home/user/Unreal3.2) und in unrealircd.conf umbenennen. (Oder man erstellt eine unrealircd.conf und kopiert sich die entsprechenden Blöcke und editieret sie). 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 0 und 254 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 Blö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 statt Hostnamen anzeigen
   noident kein ident verwenden, sondern 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.

Altes Flag	Neues Flag	Description
o	local	Macht User zu lokalem Operator
O	global	Macht User zu globalem Operator
C	coadmin	Macht User zum Coadmin
A	admin	Macht User zum Admin
a	services-admin	Macht User zum Services Admin
N	netadmin	Macht User zum Netzwerk Admin
r	can_rehash	Oper kann /rehash durchführen
D	can_die	Oper kann /die durchführen
R	can_restart	Oper kann /restart durchführen
h	helpop	Oper empfängt umode +h (helpop)
w	can_wallops	Oper kann /wallops senden
g	can_globops	Oper kann /globops senden
c	can_localroute	Kann zu Servern lokal verbinden
L	can_globalroute	Kann zu Servern global verbinden
k	can_localkill	Kann /kill auf lokale User ausführen
K	can_globalkill	Kann /kill auf globale User ausführen
b	can_kline	Kann /kline setzen
B	can_unkline	Kann mit /kline -u@h K-Line löschen
n	can_localnotice	Kann lokale Server Notices senden
G	can_globalnotice	Kann globale Server Notices senden
z	can_zline	Kann /zline setzen
t	can_gkline	Kann /gline, /shun und /spamfilter setzen
Z	can_gzline	Kann /gzline setzen
W	get_umodew	Setzt Umode +W (Anzeige von externem /whois) wenn man (via /oper) als Operator identifiziert
H	get_host	Setzt Host auf Oper host (Durch das Flag wird die Anzeige der Funktion unterdrückt)
v	can_override	Kann OperOverride ausführen
q	can_setq	Kann Usermode +q setzen
X	can_addline	Kann den Befehl /addline benutzen
d	can_dccdeny	Kann /dccdeny und /undccdeny benutzen

Bestimmte Flags setzen andere Flags per Default:

local	global	admin/coadmin	services-admin	netadmin
can_rehash	can_rehash	can_rehash	can_rehash	can_rehash
helpop	helpop	helpop	helpop	helpop
can_globops	can_globops	can_globops	can_globops	can_globops
can_wallops	can_wallops	can_wallops	can_wallops	can_wallops
can_localroute	can_localroute	can_localroute	can_localroute	can_localroute
can_localkill	can_localkill	can_localkill	can_localkill	can_localkill
can_kline	can_kline	can_kline	can_kline	can_kline
can_unkline	can_unkline	can_unkline	can_unkline	can_unkline
can_localnotice	can_localnotice	can_localnotice	can_localnotice	can_localnotice
	can_globalroute	can_globalroute	can_globalroute	can_globalroute
	can_globalkill	can_globalkill	can_globalkill	can_globalkill
	can_globalnotice	can_globalnotice	can_globalnotice	can_globalnotice
		global	global	global
		can_dccdeny	can_dccdeny	can_dccdeny
			can_setq	can_setq
				admin
				services-admin

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;
};

Einige Infos zu OperOverride:
OperOverride bedeutet z.B. joining in einen +ikl Channel und Übergehung von Banns (trotzdem muss man zuvor für sich selbst ein /invite durchführen), sich selbst Op in einem Channel zu geben etc.
Das "can_override" gibt es, um Missbrauch dieser Möglichkeiten einzuschränken. Per Default kann kein Oper vorhandene Einstellungen übergehen, solange nicht das Operflag "v" explizit gesetzt ist.

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:

Flag	Bedeutung
errors	selbsterklärend
kills	zeichnet /kill Meldungen auf
tkl	zeichnet Infos auf über *lines, shuns und Spamfilter (setzen, löschen, Ablauf)
connects	Zeichnet connects/quits der User auf
server-connects	Zeichnet connects/squits der Server auf
kline	Zeichnet Infos /kline auf
oper	Zeichnet Oper Zugriffe auf (sowohl fehlgeschlagene als auch erfolgreiche)
sadmin-commands	Zeichnet die Verwendung von /sa* (samode, sajoin, sapart etc.) auf
chg-commands	Zeichnet die Verwendung von /chg* (chghost, chgname, chgident, etc.) auf
oper-override	Zeichnet die Verwendung von Operoverrides auf
spamfilter	Zeichnet Übereinstimmungen zu Spamfiltern auf

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>;
        opermotd <opermotd-file>;
        botmotd <botmotd-file>;
	channel <channel-name>;
	options {
		ssl;
	};
};

Mit dem TLD Block kann man eine motd (Messageoftheday), rules und channels für 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, tld::opermotd, tld::botmotd, und tld::rules legen die jeweiligen Dateien für motd, shortmotd, opermotd, botmotd und rules fest, die in Abhängigkeit von der Hostmask angezeigt werden. Dabei sind tld::shortmotd, tld::opermotd und tld::botmotd optional.
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 Channel.
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.

Anm. des Übersetzers: Die Ausnahmen funktionieren wirklich nur bei gebanntem breiteren Host (123.123.* oder *@url). Man kann damit z.B. nicht einen versehentlichen Bann auf Localhost verhindern.

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, 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 rule 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 behandeln. badword:: legt den Typ fest, wobei hier gültige Werte sind: 'channel', 'message' und 'quit'. 'channel' gilt für Channel Modus +G Liste, 'message' gilt für User Modus +G Liste, 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> ersezt. 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 solange ein leaf, wie es keine hub Anweisung gibt. Ebenso ist er ein leaf, wenn in der Anweisung lediglich * definiert ist oder die leaf Tiefe (Anzahl der hops) 1 ist.

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

leaf (optional)
Dieser Wert gibt an, zu welchen Servern dieser Hub nicht verbindet. Hier einen * anzugeben ist das selbe, wie keine hub Anweisung zu haben.

leaf-depth (optional)
Dieser Wert gibt die  Tiefe (Anzahl der hops)an, die dieser Server darunter haben darf. Beispielsweise bedeutet 1, dass der Server keine Links hat (ist ein leaf), 2 bedeutet, es kann zu Servern gelinkt werden, aber diese können zu keinem anderen linken (dieser Hub kann also nur zu leafs linken). Ein Wert von 0 bedeutet, dass es kein Limit gibt und das ist auch Default.

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 können keine GLOBAL Oper Privilegien erhalten (sie werden gekilled), dient zu Test Links etc.

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>;
	spamfilter <yes|no|>
};

(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) "normal" (der User ist normaler User auf irgendeinem Server) und "channel" (das Ziel ist ein Channel Name). Wenn alias::spampfilter (optional) auf 'yes' eingestellt ist, werden auch Spamfilter geprüft (Default ist 'no'). Der "alias block" hat auch einen weiteren nachfolgend erklärten Zweck.

Syntax [Befehl alias]:

alias <name> {

	/* Für Aliase, die an User/Channels gesendet werden */
	format <regex-expression> {
		target <nick-to-forward-to>;
		type <type-of-alias>;
		parameters <parameter-string>;
	};
	/* For 'echte Aliase' */
	format <regex-expression> {
		command <command>;
		type real;
		parameters <parameter-string>;
	};
	/* Etc... You can have as many format blocks as you wish.. */

	format <regex-expression> {
		...
	};
	type command;
	spamfilter <yes|no>
};

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, bei "realen Aliasen" wird allerdings alias::format::command benutzt. alias::format::type definiert den Typ des Alias, zu dem die Nachricht geleitet wird. Neben den zuvor erwähnten Typen in der Syntax bein Standard Alias, kann hier auch der Typ "Real" für reale Aliase angegeben werden. 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"; };
};

Mit dem Spamfilter Block kann man lokale (nicht netzweite) Spam Filter festlegen.
Siehe auch Features - Spamfilter für genauere Erläuterungen zu Spam Filtern.

Syntax:

spamfilter {
        regex <word>;
        target { <target(s)> };
        action <action>;
        reason <reason>;
        ban-time <time>;
};

regex ist der Ausdruck, auf den geprüft wird.
target gibt die Ziele an. Eine Liste möglicher Ausdrücke (z.B.: 'channel') kann hier nachgelesen werden..
action gibt die Aktion an, die erfolgen soll. Eine Liste möglicher Aktionen (z.B.: 'gline') kann hier nachgelesen werden.
reason ist optional und legt den Grund für die Aktion fest, der dem User angezeigt wird. Der Text ist in Anführungszeichen anzugeben und sollte - anders als beim /spamfilter Befehl - keinerlei Undersores "_" zwischen den Worten enthalten (andernfalls werden die Underscores mit angezeigt).
ban-time ist optional und legt die Zeit für einen *line/shun Bann fest. Ohne Angabe gilt der Default von 1 Tag.

Beispiele:

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 Cgiirc Block können Host Manipulationen für vertraute CGI:IRC Gateways konfiguriert werden (weitere Informationen).

Syntax:

cgiirc {
	type <webirc|old>;
	username <mask>; /* optional */
	hostname <mask>;
	password <password>; /* only for type webirc */
};

 

type ist entweder 'webirc' oder 'old'.
username wird auf die Ident geprüft (wenn angegeben). Falls nicht definiert, wird '*' angenommen.
hostname ist die Hostmaske, auf die geprüft wird.
password ist das webirc Passwort, wird nur beim Typ 'webirc' benutzt.

Konfiguration mit der 'webirc' Methode (empfohlene Methode)
In der CGI:IRC Konfigurationsdatei (cgiirc.conf) wird für "webirc_password" ein gutes Passwort festgelegt.
Danach wird in der unrealircd.conf ein cgiirc block eingetragen, um diesen Host mit diesem Passwort zu erlauben.
Dann wird für 'set cgiirc::type'  "webirc" eingetragen.

Beispiel:
In die CGI:IRC Konfigurationsdatei (cgiirc.conf) wird eingetragen:

webirc_password = LpT4xqPI5

Danach wird die unrealircd.conf um einen Cgiirc Block erweitert:

cgiirc {
	type webirc;
	hostname "1.2.3.4";
	password "LpT4xqPI5";
};

 

Konfiguration mit Methode 'old'
ACHTUNG: Dies ist nicht die empfohlene Methode, da sie zwei Nachteile hat: Diese Methode sendet den IP/Host, der zu verändern ist, als ein Server Passwort, was bedeutet,  als  CGI:IRC User kein Server Passwort angeben kann. Außerdem ist die Zugriffskontrolle nur IP-basiert und erfordert kein Extra Passwort, wie die 'webirc' Methode. Kurz gesagt sollten Sie nicht diese Methode nur verwenden, wenn es einen triftigen Grund dazu gibt.

In der CGI:IRC Konfigurationsdatei (cgiirc.conf) wird 'realhost_as_password' auf 1 gesetzt.
Danach wird die unrealircd.conf um einen Cgiirc Block erweitert, um diesen Host zu erlauben.

Beispiel:
In die CGI:IRC Konfigurationsdatei (cgiirc.conf) wird eingetragen:

realhost_as_password = 1

Danach wird die unrealircd.conf um einen Cgiirc Block erweitert:

cgiirc {
	type old;
	hostname "1.2.3.4";
};

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 Eint