unrealircd/doc/conf.doc

UnrealIRCd Configuration Documentation v3.2-beta5

Table of Contents
 1.0 Abstract
 1.1 Introduction
 2.0 Me block (M:line)
 3.0 Admin block (A:line)
 4.0 Class block (Y:line)
 5.0 Allow block (I:line)
 6.0 Listen block (P:line)
 7.0 Oper block (O:line)
 8.0 Drpass block (X:line)
 9.0 Include directive (N/A)
10.0 Loadmodule directive (N/A)
11.0 Log block (N/A)
12.0 Tld block (T:line)
13.0 Ban nick block (Q:line)
13.1 Ban user block (K:line)
13.2 Ban ip block (Z:line)
13.3 Ban realname block (n:line)
13.4 Ban server block (q:line)
14.0 Except ban block (E:line)
14.1 Except scan block (e:line)
14.2 Except tkl block (N/A)
15.0 Deny dcc block (dccdeny.conf)
15.1 Deny version block (V:line)
15.2 Deny link block (D:line and d:line)
15.3 Deny channel block (chrestrict.conf)
16.0 Allow channel block (N/A)
17.0 Vhost block block (vhost.conf)
18.0 Badword block (badwords.*.conf)
19.0 Ulines block (U:line)
20.0 Link block (C:line, N:line, H:line, L:line)
21.0 Alias block (N/A)
22.0 Help block (N/A)
23.0 Set block (networks/unrealircd.conf and networks/*.network)
24.0 Conclusion

1.0 Abstract
Welcome to the new Unreal configuration format. This format may seem very confusing at first,
but hopefully this document will clear up any confusion. This file will show you the new config
file directives as well as tell you the old format equivilent (where one exists) to help you get
a feel for the new file.

1.1 Introduction
Each entry, or block, in the new format has a specific format. The format works like:

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

<block-name> is the type of block, such as me, or admin. <block-value> sometimes specifys a 
value, such as /oper login, but other times it will be a sub-type such as in ban user. 
<block-directive> is an individual variable specific to the block, and <directive-value> is the
associated value. Directives and their values do not have to be seperated by an equal sign, but
they maybe if you choose to do so. If <directive-value> contains spaces, or characters that 
represent a comment it must be contained in double quotes. If you want to use a quote character
inside a quoted string use \" and it will be understood as a quote character. A 
<block-directive> can have directives within it, if thats the case it will have it's own set of
curly braces surrounding it. Some blocks do not have directives and are specified just by 
<block-value>, such as include. Also note that there is no set format, meaning the whole block 
can appear on one line or over multiple lines. The format above is what is normally used (and
what will be used in this file) because it is easy to read. Note: the configuration file is 
currently case sensitive so BLOCK-NAME is not the same as block-name. There is a special 
notation used to talk about entries in the config file. For example, to talk about 
<block-directive> in the example above, you'd say <block-name>::<block-directive>, and if that 
directive has a sub-block you want to reference, you would add another :: and the name of the 
sub directive. To talk about an unnamed directive you would do <block-name>:: which would in 
this case mean <block-value>, or it could be an entry in a sub block that has no name.

Comments are supported in three formats, both multi-line and single-line comments are supported.
To comment a single line there are two options, a shell style comment, or a C++ style comment.
A shell style comment begins with a # and a C++ style begins with a //. These comments can 
appear anywhere in a line and comment anything until the end of the line. For multi-line 
comments, a C style comment is supported. To start the comment you enter /* and anything from 
there until the */ is commented.

2.0 Me block (M:line)

Syntax:
me {
	name <name-of-server>;
	info <server-description>;
	numeric <server-numeric>;
};

Example:
me {
	name irc.unrealircd.com;
	info "UnrealIRCd Development Server";
	numeric 21;
};

These values are pretty obvious. The me::name specifies the name of the server, me::info 
specifies the server's info line, me::numeric specifies a numeric to identify the server. This 
must be a value between 1 and 255 that is unique to the server meaning no other servers on the 
network may have the same numeric.

3.0 Admin block (A:line)

Syntax:
admin {
	<text-line>;
	<text-line>;
	...
};

Example:
admin {
	"codemastr";
	"codemastr@unrealircd.com";
};

The admin block defines the text displayed in a /admin request. You can specify as many lines 
as you want and you they can contain whatever information you choose, but it is standard to 
include the admin's nickname and email address at a minimum. Other information may include any 
other contact information you wish to give.

4.0 Class block (Y:line)

Syntax:
class <name> {
	pingfreq <ping-frequency>;
	connfreq <connect-frequency>;
	maxclients <maximum-clients>;
	sendq <send-queue>;
};

Example:
class clients {
	pingfreq 90;
	maxclients 100;
	sendq 50000;
};

The class block is a vastly simplified version of the Y:lines. You are no longer limited to 
naming them with a number, you can now use an alpha-numeric string which is specified in the 
class::. The values of this block define the connection classes, class::pingfreq specifies the 
number of seconds between PINGs, class::connfreq is only used in server classes to specify the 
time in seconds between connection attempts, class::maxclients specifies the maximum amount of 
clients that may use this class to connect, and class::sendq specifies the amount of information
that can remain in the send queue buffer.

5.0 Allow block (I:line)

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

Example:
allow {
	ip *@*;
	hostname *@*;
	class clients;
	maxperip 2;
	redirect-server irc2.unrealircd.com;
	redirect-port 6667;
};

The allow class is similar to an I:line but provides more features. The allow::ip specifies a 
user@ip hostmask for a user to match to connect and allow::hostname specifies a user@host to 
match to connect, allow::class is the name of a preexisting (appears before this block in the 
config) class block that will be used for this class. The rest of the directives are optional, 
allow::password specifies a password that users must enter to connect. The allow::password:: 
allows you to specify an authentication method. Currently supported methods are crypt, md3, and
sha1. If you are using plain-text you can just leave this sub-block out. This directive also 
allows you to configure close killing, allow::maxperip lets you specify the maximum number of 
clients that may connect from a single IP. Lastly, the allow block supports redirection when 
the server is full, allow::redirect-server specifies the address of a server to forward to, and
allow::redirect-port specifies the port, if no port is specified, 6667 is assumed. Note: for 
auto-redirection to occur the client must have support for the redirection numeric, at this 
time not many clients do. The allow::options defines two option flags, the noident option
instructs the IRCd to use the username supplied by the client rather than using what is
returned by an ident response. The useip flag tells the IRCd to use the IP of the client as
the host even if it is possible to resolve the IP to a hostname.

6.0 Listen block (P:line)

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

Examples:
listen 192.168.1.1:6667;

listen 192.168.1.1:6697 {
	options {
		ssl;
	};
};

This block allows you to specify the ports on which the IRCd will listen. If no options are 
required, you may specify this without any directives in the form listen <ip:port>;. Valid 
listen::options are clientsonly (only users may connect), serversonly (only servers name
connect), java (CR javachat support), ssl (SSL encrypted port). A combination of any of those
flags may be specified. Since IPv6 is now supported, and the IPv6 seperator is a : it makes the
ip:port format a bit difficult. To compensate, you should enclose the IP in brackets. For 
example, [::1]:6667. Which will bind to the localhost on port 6667. If you are using IPv6 and 
want to listen on an IPv4 IP use the format [::ffff:<ip>]:<port>. For example, 
[::ffff:203.123.67.1]:6667. Which will bind to the IPv4 203.123.67.1 on port 6667. You may also
specify * as the IP to bind to all interfaces.

7.0 Oper block (O:line)

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

Example:
oper codemastr {
	from {
		userhost codemastr@staff.unrealircd.info;
		userhost codemastr@unrealircd.com;
	};
	password "testpass";
	class clients;
	snomask "+kfc";
	flags OAaRDNz^t;
};

The oper block allows you to assign IRC Operators for your server. The oper:: specifies the 
login name for the /oper. The oper::from::userhost is a user@host mask that the user must 
match, you can specify more than one hostmask by creating more than one oper::from::userhost. 
The oper::password is the password the user must specify, oper::password:: allows you to 
specify an authentication method for this password, valid auth-types are crypt, md5, and sha1. 
If you want to use a plain-text password leave this sub-block out. The oper::class directive 
specifies the name of a preexisting (appears before this in the config file) class name that 
the oper block will use. The oper::snomask directive lets you specify the default snomask
the \oper will receive, this overrides the standard snomask that is normally set. The 
oper::swhois directive allows you to specify an swhois line that will be set when the user 
/oper's. Note: This directive will be overridden if you use an IRC Services program that also 
sets swhois. The oper::flags directive has two formats. If you wish to use the old style
oper flags i.e., OAa, you use the flags <flags> method, if you want to use the new style, i.e.,
services-admin, then you use the flags { <flag>; } method. Below is a list of all the flags 
(in both formats) and what they do.

o	local			Makes you a local operator (contains rhgwlckbBn)
O	global			Makes you a global operator (contains oLKG)
C	coadmin			Makes you a coadmin
A	admin			Makes you an admin
a	services-admin		Makes you a services admin
N	netadmin		Makes you a netadmin
r	can_rehash		Oper may use /rehash
D	can_die			Oper may use /die
R	can_restart		Oper may use /restart
h	helpop			Oper receives +h (helpop)
w	can_wallops		Oper can send /wallops
g	can_globops		Oper can send /globops
c	can_localroute		Can connect servers locally
L	can_globalroute		Can connect servers globally
k	can_localkill		Can /kill local users
K	can_globalkill		Can /kill global users
b	can_kline		Can use /kline
B	can_unkline		Can use /unkline
t	can_gkline		Can use /gline and /shun
Z	can_gzline		Can use /gzline
n	can_localnotice		Can send local server notices
G	can_globalnotice	Can send global server notices
z	can_zline		Can use /zline
W	get_umodew		Sets +W when you oper
H	get_host		Sets your host to an oper host
^	can_stealth		Can use +I

8.0 Drpass block (X:line)

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

Example:
drpass {
	restart "0CvoXHMDB45pY" { crypt; };
	die "0BMFSJ6FWd23s" { crypt; };
};

This block sets the /restart and /die passwords with drpass::restart and drpass::die 
respectively. The drpass::restart:: and drpass::die:: allow you to specify the type of 
authentication used by this item. The currently supported authentication types are crypt, md5, 
and sha1.

9.0 Include directive (N/A)

Syntax:
include <file-name>;

Example:
include "badwords.channel.conf";

This directive specifies a filename to be loaded as a seperate configuration file. This file 
may contain any type of config block and can even include other files. Wildcards are supported 
in the file name to allow you to load multiple files at once.

10.0 Loadmodule directive (N/A)

Syntax:
loadmodule <file-name>;

Example:
include "src/modules/commands.so";

This directive specifies a filename to be loaded as a module. Some modules may have there own 
documentation which should be consulted when setting it up. Loadmodule also supports wildcards 
to easily load multiple modules at once. 


11.0 Log block (N/A)

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

Example:
log ircd.log {
	maxsize 200KB;
	flags { errors; tkl; kline; };
};

The log block allows you to assign different log files for different purposes. If the log 
filename is syslog and your system has syslogd, then syslogd will be used to log for this file.
If you do not have syslogd, then specifying a filename of syslog will simply write to a file 
named syslog. The log:: contains the name of the log file. log::maxsize is an optional 
directive that allows you to specify a size that the log file will be wiped and restarted. You
can enter this string using MB for megabytes, KB, for kilobytes, GB, for gigabytes. The 
log::flags specifies which types of information will be in this log. You can specify one or 
more of the following, errors, kills, tkl (G:lines and Shuns), connects, server-connects, 
kline, and oper. 

12.0 Tld block (T:line)

Syntax:
tld {
	mask <hostmask>;
	motd <motd-file>;
	rules <rules-file>;
	channel <channel-name>;
};

Example:
tld {
	mask *@*.es;
	motd motd.spanish;
	rules rules.spanish;
	channel "#help-spanish";
};

The tld block allows you to specify a motd, rules, and channel for a user based on their host. 
This is useful if you want different motds for different languages. The tld::mask is a
user@host mask that the user's username and hostname must match. The tld::motd and tld::rules 
specify the motd and rules file, respectively, to be displayed to this hostmask. Lastly the 
tld::channel is optional, it allows you to specify a channel that this user will be forced to 
join on connect. If this exists it will override the default auto join channel.

13.0 Ban nick block (Q:line)

Syntax:
ban nick {
	mask <nickname>;
	reason <reason-for-ban>;
};

Example:
ban nick {
	mask "*Serv";
	reason "Reserved for services";
};

The ban nick block allows you to disable use of a nickname on the server. The ban::mask allows 
wildcard masks to match multiple nicks, and ban::reason allows you to specify the reason for 
which this ban is placed. Most commonly these blocks are used to ban usage of the nicknames 
commonly used for network services.

13.1 Ban user block (K:line)

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

Example:
ban user {
	mask *@*.bobs.com;
	reason "Abuse from domain";
};

This block allows you to ban a user@host mask from connecting to the server. The ban::mask is a
wildcard string of a user@host to ban, and ban::reason is the reason for a ban being placed. 
Note, this is only a local ban and therefore the user may connect to other servers on the 
network.

13.2 Ban ip block (Z:line)

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

Example:
ban ip {
	mask 127.0.0.1;
	reason "No local connections allowed";
};

The ban ip block bans an IP from accessing the server. This includes both users and servers 
attempting to link. The ban::mask parameter is an IP which may contain wildcard characters, and
ban::reason is the reason why this ban is being placed. Since this ban affects servers it should
be used very carefully.

13.3 Ban realname block (n:line)

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

Example:
ban realname {
	mask "*sub7*";
	reason "Sub7 Drones are not allowed";
};

The ban realname block allows you to ban a client based on the GECOS (realname) field. This is 
useful to stop clone floods because often clone bots use the same realname. The ban::mask 
specifies the realname which should be banned. The mask may contain wildcards. The ban::reason 
specifies the reason why this ban is being placed.

13.4 Ban server block (q:line)

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

Example:
ban server {
	mask irc.lamerland.com;
	reason "Too many lamers";
};

This block disables a server's ability to connect to your server. The ban::mask field specifies
a wildcard mask to match against the server attempting to connect's name, and ban::reason 
specifies the reason for which this ban has been placed.

14.0 Except ban block (E:line)

Syntax:
except ban {
	mask <hostmask>;
};

Example:
except ban {
	mask *@*.unrealircd.com;
};

The except ban block allows you to specify a user@host that will override a ban placed on a 
broader host. This is useful when you want an ISP banned, but still want specific users to be 
able to connect. The except::mask directive specifies the user@host mask of the client who will
be allowed to connect.

14.1 Except scan block (e:line)

Syntax:
except scan {
	mask <ipmask>;
};

Example:
except scan {
	mask 192.168.1.23;
};

The except scan block allows you to specify an IP mask that will override the scanners. This 
only works if you have chosen to load the scanner modules. The except::mask specifies an IP 
mask that will not be banned because of any type of scanner problem.

14.2 Except tkl block (N/A)

Syntax:
except tkl {
	type <type>;
	mask <hostmask>;
};

Example:
except tkl {
	type gline;
	mask *@*.unrealircd.com;
};

The except tkl block lets you set a host as being exempt from certain types of tkls. The
except::type specifies the type of tkl the mask will be exempt from. Valid entries are gline,
gzline, tkline, tzline, or shun. The except::mask specifies a user@host that will be exempt
from the ban.

15.0 Deny dcc block (dccdeny.conf)

Syntax:
deny dcc {
	filename <file-to-block>;
	reason <reason-for-ban>;
};

Example:
deny dcc {
	filename "dmsetup.exe";
	reason "Dmsetup is a trojan";
};

The deny dcc block allows you to specify a filename which will not be allowed to be sent via 
DCC over the server. This is very useful in helping stop distribution of trojans and viruses. 
The deny::filename parameter specifies a wildcard mask of the filename to reject sends of, and 
deny::reason specifys the reason why this file is blocked.

15.1 Deny version block (V:line)

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

Example:
deny version {
	mask *;
	version *;
	flags !R;
};
	
This block allows you to deny a server from linking based on the version of Unreal it is running
and what compile time options it has. The format for this block is somewhat complex but isn't 
too hard to figure out. The deny::mask directive specifies a wildcard mask of the server name 
this applies to. The deny::version specifies the protocol number of the version this refers to.
For example, 3.0 is 2301, 3.1.1/3.1.2 is 2302, 3.2 is 2303. The first character of this 
parameter can be one of the following >, <, =, !. This character tells the IRCd how to 
interpret the version. If the first character is a > then all version greater than the 
specified version are denied, if it is a < all versions lower are denied, if it is an = only 
that version is denied, and if it is a ! then all versions except the specified are denied. The
deny::flags directive allows you to specify what compile time flags the server may or may not 
have. The flags are arranged one after the other with no seperation between, if a character is 
prefixed by a ! then it means the server may not have this flag compiled into it, if it does not
have a ! prefix, then it means the server must have this flag compiled. An * can be specified for both
the version and the flags to indicate that all are allowed.

15.2 Deny link block (D:line and d:line)

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

Example:
deny link {
	mask *.ca;
	rule "connected(hub.irc.net)";
	type all;
};

This block allows you to use specific rules to deny a server from linking. The deny::mask 
specifies a wildcard mask of the server name to apply this rule to. The deny::rule directive is
very complex. A crule expression allows you to control the link in great detail, and it is set 
up like a programming expression. Four operators are supported, connected(<servermask>), returns
true if a server matching servermask is connected, directcon(<servermask>), returns true if the
server matching servermask is directly connected to this server, via(<viamask>,<servermask>), 
returns true if a server matching servermask is connected by a server matching viamask, and 
directop(), which returns true if the operator issuing a /connect is directly connected to this
server. These operators can be combined using && (and) and || (or), items may also be enclosed 
in parenthesis to allow grouping. In addition, an operator preceded with a ! checks if the 
operator returned false. If the entire expression evaluates to true, then the link is denied. 
The deny::type allows two different values, auto (only applies to autoconnects, /connect will 
still work), and all (applies to all connection attempts).

15.3 Deny channel block (chrestrict.conf)

Syntax:
deny channel {
	channel <channel-mask>;
	reason <reason-for-ban>;
};

Example:
deny channel {
	channel "#*hack*";
	reason "Hacking channels are not allowed";
};

The deny channel block allows you to disallow users from joining specific channels. The 
deny::channel directive specifies a wildcard mask of channels the users may not join, and the 
deny::reason specifies the reason why the channel may not be joined. 

16.0 Allow channel block (N/A)

Syntax:
allow channel {
	channel <channel-mask>;
};

Example:
allow channel {
	channel "#help";
};

The allow channel block allows you to specify specific channels that users may join. The 
allow::channel directive specifies the wildcard mask of the channels which may be joined.

17.0 Vhost block (vhost.conf)

Syntax:
vhost {
	vhost <vhost>;
	from {
		userhost <hostmask>;
		userhost <hostmask>;
		...
	};
	login <login-name>;
	password <password> { <auth-type>; };
};

Example:
vhost {
	vhost "i.love.unrealircd.com";
	from {
		userhost "*@unrealircd.com";
	};
	login "codemastr";
	password "hjddfsre";
};

The vhost block allows you to specify a login/password that can be used with the /vhost command
to obtain a fake hostname. The vhost::vhost parameter can be either a user@host or just a host 
that the user will receive upon successful /vhost. The vhost::from::userhost contains a 
user@host that the user must match to be eligable for the vhost. You may specify more than one 
hostmask. The vhost::login in the login name the user must enter and vhost::password is the 
password that must be entered. Lastly vhost::password:: allows you to specify the type of 
authentication used by this item. The currently supported authentication types are crypt, md5, 
and sha1.

18.0 Badword block (badwords.*.conf)

Syntax:
badword <type> {
	word <regex-to-match>;
	replace <replace-with>;
};

Example:
badword channel {
	word "ass";
	replace "butt";
};

The badword block allows you to manipulate the list used for user and channel mode +G to strip 
"badwords". The badword:: specifies the type, valid types are channel and messages, channel is 
for the channel +G list, and message is for the user +G list. The badword::word is a regular 
expression of the word we should search for and remove. The badword::replace is what we should 
replace this match with. If badword::replace is left out, the word is replaced with <censored>.

19.0 Ulines block (U:line)

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

Example:
ulines {
	services.unrealircd.com;
};

The ulines block lets you define certain servers as having extra abilities. This should only be 
used for servers such as services and stats. This should not be set for a normal server. Each 
entry is the name of the server which will receive the extra abilities.

20.0 Link block (C:line, N:line, H:line, and L:line)

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 <ciphers>;
	options {
		<option>;
		<option>;
		...
	};
};

Example:
link irc2.unrealircd.com {
	username *;
	hostname 127.0.0.1;
	bind-ip *;
	port 7018;
	password-connect "tstlnk";
	password-receive "tstlnk";
	hub *;
	class servers;
};

The link block is a simplified way to link servers. The link:: should be the name of the server 
which is to be linked, link::username is a wildcard mask of the username the server must have, 
and link::hostname is an IP mask the server must match. If you are running with IPv6 enabled and
you want to link to an IPv4 server, specify the hostname in the format ::ffff:<ip>, example 
::ffff:203.123.67.1. The link::bind-ip specifies an IP that the server will bind to in order to 
make this connection and link::port specifies the port it will establish the connection on. The 
link::password-connect must be a plain-text password since it will be sent to the other server, 
but link::password-receive may be encrypted using a method specified in 
link::password-receive:: valid methods are crypt, md5, and sha1. You can leave the auth-type 
parameter out to have it remain plain-text. The link::hub and link::leaf directives may not be 
used together, either a server is a hub or a leaf. If link::hub is specified, the value is a 
mask of what servers this hub may connect. If link::leaf is specified the value specifies the 
mask that this server will act like a leaf towards. The link::leafdepth directive should only 
be specified if link::leaf exists and is also optional. This value specifies the depth (number 
of hops) this server may have beneath it. The link::class is the name of a preexisting (appears 
before this in the config) class block that will be used for the server connecting with the 
link block. The link::options is a list of one or more options you wish this server to use, 
valid options are ssl (the server will connect using SSL encryption), autoconnect (the server 
will be autoconnected based on the value in the specified link::class), quarantine (opers on 
this server will maintain locop status). If the server is set to link via SSL, the
link::ciphers directive may be used. This allows you to specify the ciphers that will be
used for this link. The ciphers are specified as a : seperated list in the order of preference. 
Different systems support different ciphers, so the best way to get a list of available ciphers
for your system is to execute the openssl ciphers command. This will return a : seperated list
of the available ciphers.

21.0 Alias block (N/A)

Syntax [standard alias]:
alias <name> {
	nick <nick-to-forward-to>;
	type <type-of-alias>;
};

Example:
alias nickserv {
	nick "nickserv";
	type services;
};

The alias block [standard alias] allows you to forward a command to a user, for example 
/chanserv sends a message to the user chanserv. The alias:: specifies the name of the command 
that will be the alias, ex /chanserv, alias::nick is the nickname it will forward to, if the 
alias:: is the same as the nick it will forward to, alias::nick can be left out. The 
alias::type specifies the type of alias, valid types are services (the user is on the services 
server), stats (the user is on the stats server), and normal (the user is a normal user on any 
server). The alias block also has another purpose which is explained below.

Syntax [command alias]:
alias <name> {
	format <regex-expression> {
		alias <alias-to-forward-to>;
		parameters <parameter-string>;
	};
	format <regex-expression> {
		...
	};
	type command;
};

Example:
alias ghost {
	format "*" {
		alias nickserv;
		parameters "GHOST %1-";
	};
};

When the alias block is used in this format, it allows you a much broader range of usage. For 
example you can create aliases such as /identify. The alias:: is the same as above, the name of 
the alias command. The alias::format specifies a regular expression that compares against the 
text sent to the alias command, when matched the sub-entries of that alias::format will be used,
you may have multiple alias::format's to make the command do different things depending on the 
text sent to it. The alias::format::alias is the name of a preexisting (appears before this in 
the config file) alias block in the standard format that when that format is matched will be 
used. The alias::format::parameters is what will be sent as the parameters to this alias. To 
specify one of the parameters given to the command alias specify % followed by a number, for 
example, %1 is the first parameter. To specify all parameters from a given parameter to the end 
do % followed by the number and a -, for example %2- returns all parameters from the second 
till the last. For examples of using the alias block in the command format, consult 
doc/example.conf.

22.0 Help block (N/A)

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

Example:
help oper {
	"The oper command gives you IRC operator access";
};

The help block allows you to create entries for use in /helpop. The help:: is the value that 
must be passed to /helpop as a parameter, if the help:: is left out, then it will be used when 
no parameter is passed to /helpop. The entries for the help block are the text that will be 
displayed to the user when requesting the /helpop.

23.0 Set block (networks/unrealircd.conf and networks/*.network)

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

Example:
set {
	kline-address "codemastr@unrealircd.com";
};

The set block sets options for individual server features. Each entry does something different 
and therefore each will be described below. Some directives have sub blocks which will also be 
described.

set::kline-address <email-address>;
The email address that K:line questions should be sent to. This value must be specified.

set::modes-on-connect <+modes>;	
The modes that will be set on a user at connection.

set::modes-on-oper <+modes>;
The modes that will be set on a user when they /oper.

set::auto-join <channels>;	
The channel(s) a user will be forced to join at connection. To specify more than one channel 
use a comma seperated list.

set::oper-auto-join <channels>;
The channel(s) a user will be forced to join when they /oper. To specify more than one channel 
use a comma seperated list.

set::anti-spam-quit-message-time <timevalue>;
A time value specifying the length of time a user must be connected for before a /quit message 
will be displayed. Used to prevent spam. A time value is a numeric string with d meaning days, 
h meaning hours, m meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2 
hours, 3 minutes.

set::oper-only-stats <stats-list>;
Specifies a list of stats flags with no seperators that defines stats flags only opers can use. 
Leave this value out to allow users to use all flags, or specify * for users to be able to use 
no flags.

set::maxchannelsperuser <amount-of-channels>;
Specifies the number of channels a single user may be in at any one time.

set::options::hide-ulines;
If this is present, Ulined server will be hidden in a /links requested by non-opers.

set::options::no-stealth;
If present usermode +I may not be used by anyone on this server.

set::options::show-opermotd;
If present the opermotd will be shown to users once they successfully /oper.

set::options::identd-check;
If present the presence of an identd server will be checked and the returned value will be used 
for the username. If no ident request is returned or the identd server doesn't exist, the user's
specified username will be prefixed with a ~. If this value is omitted no such check is made.

set::options::show-connect-info;
If present notices showing "ident request", "hostname lookup", etc. will be displayed when a user connects.

set::dns::timeout <timevalue>;
A time value specifying the length of time a DNS server has to respond before a timeout. A time 
value is a numeric string with d meaning days, h meaning hours, m meaning minutes, and s meaning
seconds, for example 1d2h3m means 1 day, 2 hours, 3 minutes.

set::dns::retries <number-of-retries>;
A numeric value specifying the number of times the DNS lookup will be retried if failure occurs.

set::dns::nameserver <name-of-dns-server>;
Specifies the hostname of the server that will be used for DNS lookups.

set::network-name <name-of-network>;
Specifies the name of the network on which this server is run. This value should be exactly the 
same on all servers on a network.

set::default-server <server-name>;
Defines the name of the default server to tell users to connect to if this server is full.

set::services-server <server-name>;
Specifies the name of the server that the services bots are connected to. If services are not 
run this value may be left out.

set::stats-server <server-name>;
Sets the name of the server on which the stats bot is located. If stats are not run this value 
may be left out.

set::help-channel <network-help-channel>;
Sets the name of the help channel for this network.

set::prefix-quit <text-to-prefix-quit>;
Sets the text that will be used to prefix a quit message. If this value is set to 0 then the 
standard "Quit:" is used.

set::cloak-keys { <value>; <value>; <value>; };
Sets the keys to be used to generate a +x host. This value must be the same on all servers or 
the servers will not link. Each of the set::cloak-keys:: must be a numeric value greater than 
10000. You must have exactly three values specified.

set::hiddenhost-prefix <prefix-value>;
Defines the prefix that will be used on hiddenhosts (+x) this is usually three or four letters 
representing the network name.

set::hosts::local <locop-host-name>;
Defines the hostname that will be assigned to local opers when they set +x.

set::hosts::global <globop-host-name>;
Defines the hostname that will be assigned to global operators when they set +x.

set::hosts::coadmin <coadmin-host-name>;
Sets the hostname that will be assigned to co-admins when they set +x.

set::hosts::admin <admin-host-name>;
Defines the hostname that will be set for admins when they set +x.

set::hosts::servicesadmin <servicesadmin-host-name>;
Sets the hostname that will be given to services-admins when they set +x.

set::hosts::netadmin <netadmin-host-name>;
Sets the hostname that will be given to netadmins when they set +x.

set::hosts::host-on-oper-up <yes/no>;
If set to yes, the H/get_host flag will be honored and +x will be automatically set at /oper. 
If set to no, the user must set +x manually to receive the oper host.

set::scan::endpoint <ip:port>;
Specifies the IP and port that the server will tell an incomming open proxy to connect to.
This must be a valid IP and port, in addition the port on the specified IP must be open and
able to accept connections. Therefore it is a good idea to specify the IP of your server
and a port you know is open.

set::scan::bantime <timevalue>;
A time value that defines the length of time that a user caught by the scanner will be
banned for. A time value is a numeric string with d meaning days, h meaning hours, m
meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2 hours, 3 minutes.

set::scan::timeout <timevalue>;
A time value specifying the amount of time that is spent waiting for a proxy to respond to
the scanner's request.  A time value is a numeric string with d meaning days, h meaning
hours, m meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2 hours, 
3 minutes.

24.0 Conclusion
Well hopefully that cleared up some of the issues you had with the new config file format. 
There are some additional documents that may help you with other problems such as 
doc/example.conf and doc/example.settings. If you need an example in more detail on how to use 
these directives, refer to one of those files.