pegasus/unrealircd
1
0
Fork 0
mirror of https://github.com/unrealircd/unrealircd.git synced 2026-06-28 13:56:38 +02:00
Code Activity

Readded examples to doc/conf.doc

Browse Source
This commit is contained in:
codemastr
2002-03-03 19:25:35 +00:00
parent 8de39f6dc5
commit b60eb8f989
2 changed files with 221 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Changes
+1 -1
View File
@@ -1210,4 +1210,4 @@ seen. gmtime warning still there
- Added a patch by Syzop to fix a possible hash bug with /list
- Made the server pass extraflags at linking for deny version validation
- Added a patch by Syzop to fix a bug preventing +I from being used (fixes #0000073)
- Readded examples to doc/conf.doc by request of several users
doc/conf.doc
+220 -6
View File
@@ -84,6 +84,13 @@ me {
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
@@ -98,6 +105,12 @@ admin {
...
};
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
@@ -113,6 +126,13 @@ class <name> {
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
@@ -134,6 +154,16 @@ allow {
redirect-port <port-to-forward-to>;
};
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
@@ -154,6 +184,15 @@ listen <ip:port> {
};
};
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
@@ -175,6 +214,7 @@ oper <name> {
};
password <password> { <auth-type>; };
class <class-name>;
snomask <snomask>;
flags <flags>;
flags {
<flag>;
@@ -183,6 +223,18 @@ oper <name> {
};
};
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.
@@ -190,10 +242,11 @@ The oper::password is the password the user must specify, oper::password:: allow
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::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.
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::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)
@@ -213,7 +266,7 @@ 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
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
@@ -230,6 +283,12 @@ drpass {
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,
@@ -240,6 +299,9 @@ and sha1.
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.
@@ -249,6 +311,9 @@ in the file name to allow you to load multiple files at once.
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.
@@ -266,6 +331,12 @@ log <file-name> {
};
};
Example:
log ircd.log {
maxsize 200KB;
flags { errors; tkl; kline; };
};
The log block allows you to assign different log files for different purposes. 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
@@ -283,6 +354,14 @@ tld {
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
@@ -298,6 +377,12 @@ ban nick {
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
@@ -311,6 +396,12 @@ ban user {
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
@@ -324,6 +415,12 @@ ban ip {
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
@@ -337,6 +434,12 @@ ban realname {
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
@@ -350,6 +453,12 @@ ban server {
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.
@@ -361,6 +470,11 @@ 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
@@ -373,6 +487,11 @@ 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.
@@ -385,6 +504,12 @@ except tkl {
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
@@ -398,6 +523,12 @@ deny dcc {
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
@@ -412,6 +543,13 @@ deny version {
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
@@ -424,7 +562,8 @@ that version is denied, and if it is a ! then all versions except the specified
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.
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)
@@ -435,6 +574,13 @@ deny link {
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
@@ -457,6 +603,12 @@ deny channel {
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.
@@ -468,6 +620,11 @@ 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.
@@ -485,6 +642,16 @@ vhost {
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
@@ -502,6 +669,12 @@ badword <type> {
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
@@ -517,6 +690,11 @@ ulines {
...
};
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.
@@ -543,6 +721,18 @@ link <server-name> {
};
};
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
@@ -577,6 +767,12 @@ alias <name> {
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
@@ -597,6 +793,14 @@ alias <name> {
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
@@ -620,6 +824,11 @@ help <name> {
...
};
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
@@ -634,6 +843,11 @@ set {
...
};
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.