DareNET IRCd Configuration

Current revision as of 01:44, 13 September 2010

IRCds of ircd-darenet 1.2.x's generation have an annoying configuration file format where every line has a prefix that identifies what it's for and then a fixed number of fields that the configuration options need to be crammed into. This is hard to read, very unnatural, and can be difficult to extend. Starting with ircd-darenet 1.3.x, we will begin to utilize a bind-style configuration format that looks more like:

BlockName
{
  setting = number;
  setting2 = "string";
  setting3 = yes;
};

Comments may continue to start with a hash(#), or use the C or C++ style. For example:

# This is a valid comment

/* This is a valid C-style comment. */

// This is a valid C++ style comment.

Whitespace(space, tab or carriage return/linefeed) are ignored and may be used to make the configuration more readable. In fact, we recommend you use utilizie whitespace -- don't cram everything together, as you only make it more difficult for others to read/edit.

Note: Configuration file crash bug:

This new configuration file format also 'fixes' a known bug with early ircu versions, and consequently ircd-darenet pre 1.3.x, as detailed here.

Order of blocks:

When the ircd puts the configuration lines into practice, it parses them backwards. That is, it uses the blocks exactly in reverse than how they are listed in the configuration file. This means that you should start with Client {} blocks with the "fall through", most vanilla and end with the most detailed.

Other notes:

There is a difference between the "hostname" and "server name" of the machine that the ircd is run on. For example, the host can have an FQDN of "deviant.nitemare.name", and "deviant.ca.us.darenet.org" as its server name. A "server mask" is something like "*.us.darenet.org", which would be matched by "deviant.ca.us.darenet.org" but not by "technologic.uk.eu.darenet.org".

General Block

The General {} block defines some information about the server itself.

General 
{
  name = "servername";
  vhost = "ipv4vhost";
  description = "description";
  numeric = numericnumber;
};

<virtual host> must contain either a * or a valid IPv4 address in dotted quad notation (e.g. 127.0.0.1). The address MUST be the address of a physical interface on the host. This address is used for outgoing connections only; see Port {} blocks for listener virtual hosting. If in doubt what to put here, use the IP of your primary interface here.

Note that <server numeric> must be unique on the network the server is running, and may be between 0 and 4095. It is not updated on a rehash. If linking to DareNET, you should use the numeric assigned to you by the Server Management team.

Example block:

General 
{
  name = "servername.area.zone.darenet.org";
  description = "DareNET Client Server";
  vhost = "127.0.0.1";
  numeric = 10;
};

Admin Block

The Admin {} block defines information that can be retrieved with the /ADMIN command.

Admin 
{
  Location = "string 1 here";
  Location = "string 2 here";
  Contact = "string 3 here";
};

Example block:

Admin 
{
  Location = "DareNET";
  Location = "Server Management Team";
  Contact = "<routing@darenet.org>";
};

Class Block

All connections to the server are associated with a "connection class", whether they be incoming or outgoing (initiated by the server), be they clients or servers.

Class
{
  name = "<class>";
  pingfreq = time;
  connectfreq = time;
  maxlinks = number;
  sendq = size;
  usermode = "+modes";
};

For connection classes used on server links, maxlinks should be set to either 0 (for hubs) or 1 (for leafs). Client connection classes may use maxlinks between 0 and approximately 4,000,000,000. A maxlinks of 0 means there is no limit on the number of connections using the class.

<connect freq> applies only to servers, and specifies the frequency that the server tries to auto connect. Setting this to 0 will cause the server to attempt to connect repeatedly with no delay until the <maximum links> condition is satisfied. This is a Bad Thing(tm). Time can be specified as a number, or by giving something like: 1 minutes 2 seconds, or 1*60+20.

For connection classes intended for operator use, you can specify privileges used when the Operator {} block (see below) names this class. The local (aka globally_opered) privilege MUST be defined by either the Class or Operator block. It is highly recommended privileges be specified in the operator's Operator {} block, instead of in Class {} blocks.

Example blocks:

Uplinks you are not a hub for:

Class
{
  name = "Server";
  pingfreq = 1 minutes 30 seconds;
  connectfreq = 5 minutes;
  maxlinks = 1;
  sendq = 9000000;
};

Leaf servers you hub for:

Class
{
  name = "Leaf Server";
  pingfreq = 1 minutes 30 seconds;
  connectfreq = 5 minutes;
  maxlinks = 0;
  sendq = 9000000;
};

All clients:

Class
{
  name = "Users";
  pingfreq = 1 minutes 30 seconds;
  sendq = 60000;
  usermode = "+iw";
};

Opers:

Class
{
  name = "Opers";
  pingfreq = 1 minutes 30 seconds;
  sendq = 60000;
  whox = yes;
};

Client Block

To allow clients to connect, they need authorization. This can be done based on hostmask, address mask and/or with a password. With intelligent use of classes and the maxlinks field in the Client {} blocks, you can let in a specific domain, but get rid of all other domains in the same top level, thus setting up some sort of "reverse Kill {} block."

Client 
{
  host = "host";
  ip = "127.0.0.0/8";
  password = "password";
  class = "classname";
  maxlinks = number;
};

Everything in a Client {} block is optional. If a username mask is specified, it must match the clients username from the IDENT protocol. If a hostmask is given, the client's hostname must resolve and match the hostmask. If a CIDR-style IP mask is given, the client must have an IP matching that range. If maxlinks is given, it limits the number of matching clients allowed from a particular IP address.

Technical Description:

For every connectiong client, the IP address is known. A reverse lookup is performed on this IP-number to get the (/all) hostname(s). Each hostname that belongs to this IP-number is matched to <hostmask>, and the Client {} block is used when any matches; the client will then show with this particular hostname. If none of the hostnames match, then the IP-number is matched against the <IP mask ...> field, and if this matches, the Client {} block is used nevertheless and the client will show with the first (main) hostname, if any. If the IP-number does not resolve, then the client will show with the dot notation of the IP-number.

There is a special case for UNIX domain sockets and localhost connections. In these cases, the <IP mask...> field is compared with the name of the server (thus not with any IP-number representation). The name of the server is the one returned in the numeric 002 reply. For example:

002 Your host is 2.darenet.org[jolan.ppro], running version ...

In this example, "jolan.ppro" is the name used for matching. Therefore, UNIX domain sockets, and connections to localhost, would match this block:

host = "*@jolan.ppro";

Example blocks:

Prevent unresolved clients from connecting:

Client 
{
  host = "*@*";
  class = "Users";
  maxlinks = 5;
};

Only accept two connections from dial up accounts that have "dial??.*" as host mask:

Client 
{
  host = "*@dial??.*";
  class = "Users";
  maxlinks = 2;
};

Allow anyone to connect:

Client 
{
  host = "*@*";
  ip = "*@*";
  class = "Other";
  maxlinks = 5;
};

motd Block

It is possible to show a different Message of the Day (MOTD) to a connecting client depending on its origin.

motd
{
  host = "Users";
  file = "path/to/motd/file";
};

More than one host = "mask"; entry may be present in one block; this has the same effect as one motd {} block for each host entry, but makes it easier to update the message's filename. Additionally, you may specify a the name of a Class {} block to match against in the <host> portion.

Example block:

motd
{
  host = "*@*.jp";
  file = "japanese.motd";
};

Connect Block

Connect {} blocks define what servers the server may connect to, and which servers are allowed to connect.

IRC servers connect to other servers forming a network with a star or tree topology. Loops are not allowed. In this network, two servers can be distinguished: "hub" and "leaf". Leaf servers connect to hubs; hubs connect to each other. Of course, many servers can't be directly classified in either of these categories. Both a fixed and a rule-based decision making system for server links exists to aide ircd in deciding what links to allow, what to let humans do themselves and what links to (forcefully) disallow.

Connect
{
  name = "servername";
  host = "hostnameORip";
  password = "passwd";
  port = portno;
  class = "classname";
  maxhops = 2;
  hub;
  leaf = no;
  autoconnect = no;
};

The "port" field defines the default port the server tries to connect to if an operator uses /CONNECT without specifying a port. This is also the port used when the server attempts to auto-connect to the remote server. You may tell ircd-darenet to not automatically connect to a server by adding "autoconnect = no;"; the default is to auto connect.

The maxhops field causes an SQUIT if a hub tries to introduce servers farther away than that; the element 'leaf;' is an alias for a maxhops of 0. The hub field limits the names of servers that may be introduced by a hub; the element 'hub;' is an alias for hub = "*";.

Example block:

Our primary uplink:

Connect 
{
  name = "servername.hub.darenet.org";
  host = "1.2.3.4";
  password = "passwd";
  port = 7325;
  class = "Server";
  hub;
};

CRULE Block

For an advanced, real-time rule-based routing decision making system, you can use the crule {} blocks. For more information, see doc/readme.crules. If more than one server mask is present in a single rule, the rule applies to all servers.

Using all = yes; makes the rule always apply; otherwise, it only applies to auto connects.

CRULE 
{
  server = "servermask";
  rule = "connectrule";
  all = yes;
};

Example blocks:

CRULE
{
  server = "*.us.darenet.org";
  rule = "connected(*.us.darenet.org)";
};

Recommended for all leafs:

CRULE
{
  server = "*";
  rule = "directcon(*)";
};

Port Block

As more users use the server, you will notice delays when trying to connect to the primary listening port. It is possible, via Port {} blocks, to specify additional ports for the ircd to listen for connections on. De facto ports are: 6667 - standard; 6660-6669, 7000 - additional client ports; 6697 & 9999 = SSL. DareNET uses 7325 for server listener ports.

These are just hints, they are in no way official IANA or IETF policies. IANA says we should use port 194, but that requires us to run as root, so we don't do that.

Port
{
  port = number;
  mask = "ipmask";
  // Use this to control the interface you bind to.
  vhost = "virtual host ip";
  // Setting to yes makes this server only.
  server = yes;
  // Setting to yes makes the port "hidden" from stats.
  hidden = yes;
  // Setting to yes makes the port accept SSL connections from clients.
  crypt = yes;
  // Setting to yes makes the port exempt from connection restrictions
  // during a timed /restart or /die.
  exempt = yes;
};

The mask setting allows you to specify a range of IP addresses that you will allow connections from. This should only contain IP addresses and '*' if used. This field only uses IP addresses. This does not use DNS in any way, so you can't use it to allow *.jp or *.uk, and so on. Attemptinh to specify anything other than numbers, dots and starts [0-9.*] will result in the port allowing connections from anyone.

The <virtual host> setting allows multiple homed hosts to specify which interface to use on a port by port basis. If an interface is not specified, the default interface will be used. The interface MUST be the complete IP address for a real hardware interface on the machine running ircd. If you want to use virtual hosting YOU MUST USE THIS; otherwise, it WILL bind to all interfaces -- not what most people seem to expect.

Example blocks:

Port
{
  port = 7325;
  vhost = "127.0.0.1";
  server = yes;
  hidden = yes;
};

Port
{
  port = 6667;
  vhost = "168.8.21.107";
  crypt = yes;
};

Operator Block

Inevitably, you have reached the part about "IRC Operators." Oper status grants some special privileges to a user, like the power to make the server break or (try to) establish a connection with another server. and to "kill" users off the network.

More than one host = "mask"; entry may be present in one block; this has the same effect as one Operator block for each host entry, but makes it easier to update operator nicks, passwords, classes, and privileges.

NOTE: Starting with ircd-darenet 1.3.3, the username portion is matched against both identd and unidentd clients. Previously, usernames were only matched against identd clients.

Operator
{
  host = "host/IP mask";
  name = "opername";
  password = "encryptedpass";
  flags = "oper flags";
  class = "classname";
  local = no;
  display_mode = yes;     routing = yes;        routeinfo = yes;
  show_all_invis = yes;   check = yes;          see_secret_chan = yes;    
  serverinfo = yes;       uauspex = yes;        causpex = yes;            
  wallusers = yes;        mnotices = yes;  
};

You can also set any operator privilege within the Operator {} block itself. A privilege defined for a single operator will override any privilege settings that may be present in the specified Class {} block, and the default setting.

NOTE: On DareNET, adding privileges you have not been authorized to your operator block may result in it being removed during periodic audits and/or the server being juped.

By default, the password is hashed using the system's native crypt() function. Other password mechanisms are available; the umkpasswd utility from the ircd directory can hash passwords using those mechanisms. If you use a password format that is NOT generated by umkpasswd, ircd-darenet will not recognize the oper's password.

If you want to use a more secure password authentication system then generate a 1024bit RSA key, specify the path to the key as the password and add R as the oper flag. This will use the /CHALLENGE system instead of /OPER. See doc/challenge.txt for more information.

Note that the <connection class> is optional, but omitting it puts the oper in class "default". which usually only accepts one connection at a time. If you want users to be able to /OPER more than once per block, then use a connection class that allows more than one connection.

Once you /OPER, your connection class changes no matter where you are or what your previous connection class was. If the defined connections class is Opers for the Operator {} block, then your new connection class is Opers.

There are currently 8 types of flags:

• o - Local Operator
• O - Global Operator
• A - Server Administrator
• r - O:Line can be used from remote servers
• W - Allowed to set user mode +W (whois notice)
• I - Allowed to set user mode +I (hide idle)
• n - Allowed to set user mode +n (hide channels)
• R - Use /CHALLENGE instead of /OPER
• j - Allowed to use juped nicknames
• F - Allowed to set user mode +F (flood exempt)

Note that you need at least an o or O flag for your block. Additionally, you cannot specify *@* in the host field.

Example block:

Operator
{
  name = "JoeOper";
  host = "*joe@*.uu.net";
  password = "/home/irc/keys/joeoper.key";
  flags = "OrWInR";
  class = "Opers";
  local = no;
  kill = yes;
};

UWorld Block

UWorld {} blocks allow a server to broadcast any mode change (without regard to TimeStamps), among other things.

UWorld 
{
  name = "realservername";
};

You may have have more than one name listed in each block.

Note, these lines must be the same on every single server; otherwise, results may be disastrous.

Example block:

UWorld
{
  name = "services.darenet.org";
  name = "statistics.darenet.org";
};

NickJupe Block

It is possible to "jupe" nicknames, so that users may not use them. This also prevents opers from using them. You may also specify wildcards of * and ?.

NickJupe
{
  nick = "comma separated list of nicks";
};

Example block:

NickJupe
{
  nick = "A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,{,|,},~,-,_,`";
  nick = "login,darenet,protocol,pass,newpass";
  nick = "ChanS?rv,NickS?rv,MemoS?rv,HelpS?rv,OperS?rv,BotS?rv,RootS?rv,StatS?rv,SpamS?rv";
  nick = "oper,operator,admin,administrator,network,global,staff";
};

Ban Block

While running your server, you will most probably encounter individuals or groups of person that you do not want to have access to your server. For this purpose, ircd-darenet understands Ban {} blocks. These are also known as K-lines, by virtue of the former config file format.

Ban
{
  host = "user@host";
  reason = "The reason the user will see";
  klineprompt;
  name = "mark";
};

If klineprompt; is present, users may bypass the ban by using Login-on-Connect (LOC). You can also mark clients by using name = "mark here";

Ban
{
  realname = "realname here";
  reason = "The reason the user will see";
};

It is also possible to ban based on username.

Ban
{
  username = "username here";
  reason = "The reason the user will see";
};

It is also possible to use a file as comment for the ban, using.

Ban
{
  host = "user@host";
  file = "path/to/file/with/reason/to/show";
};

The file can contain for example, a reason, a link to the server rules and a contact address. Also, note the combination of username and host in the host field. IP-based Ban {} blocks apply to all hosts, even if an IP address has a properly resolving host name.

Additionally, you may specify a hostmask prefixed with $V to indicate a match should be performed against the CTCP version of the user rather han the host/IP.

Ban
{
  version = "string";
  reason = "reason here";
};

Example blocks:

Ban
{
  host = "*@*.aol.com";
  reason = "Due to abuse, AOL users must login with their DareNET account to connect.";
  klineprompt;
};

Ban
{
  host = "192.168.*";
  reason = "Monkeys.";
};

Ban
{
  username = "sub7";
  realname = "s*7*";
  reason = "You are infected with a Trojan";
};

Ban
{
  username = "sub7";
  realname = "s*7*";
  reason = "You are infected with a Trojan";
};

Except Block

Except {} blocks can be used to exempt a user from Kill {} blocks, GLINEs, ZLINEs, SHUNs, spam filters, IDENT_CHALLENGE and LIST restrictions.

Except
{
  mask = "<mask>";
  flags = "<flags>";
};

<mask> is an ident@ip/host/cidr mask that is to match the user to be exempted. <flags> is one or more of the following flags to specify what the exempt is to match.

• g - Except affects GLINEs.
• i - Except affects ident challenges (see IDENT_CHALLENGE feature).
• j - Except affects NickJupes.
• s - Except affects SHUNs.
• z - Except affects ZLINEs.
• F - Forces umode +F on user to bypass message flood checks.
• I - Exempts user from rapid (re)connection throttling & clone checks.
• L - Except affects LIST restrictions.
• N - Exempts user from "no connections" restrictions, allowing them to connect anyway.
• S - Except affects spam filters.

NOTE: For throttling/clone exemptions (I), only IP addresses are supported, since these checks are performed before any DNS resolutions or identd replies are received.

Example block:

Except
{
  host = "*@*.darenet.org";
  flags = "kgzsL";
};

Except
{
  host = "*@127.0.0.1";
  flags = "T";
};

Command Block

Command {} blocks aim to improve the generic IRC users ability to use network services. Each block sets up a /<service> alias so that users may type that instead of a full /msg command. Some might argue this is a bit more secure as well :)

Command
{
  cmd = "<alias name>";
  service = "<target>";
  prefix = "<anything to prepend to the message>";
};

If prefix = ""; is given, then ircd-darenet will prefix the specified string to whatever the user inputs before sending it to the service.

Example blocks:

Command
{
  cmd = "AUTH";
  service = "NickServ@services.darenet.org";
  prefix = "AUTH";
};

Command
{
  cmd = "NICKSERV";
  service = "NickServ@services.darenet.org";
};

Forward Block

Forward {} blocks enable the server to forward any messages which are prefixed and specific with a Forward {} block. This allows users to use Services' fantasy commands without a service client being in the channel (provided the channel is registered). This also removes the need for ChanServ to monitor channel traffic (e.g. allowing the use of umode +d).

Forward
{
  "<prefix>" = "<server>";
};

Example block:

Forward
{
  "." = "services.darenet.org";
  "?" = "services.darenet.org";
};

Redirect Block

When a client connects and his/her host matches a Redirect {} block, then a 010 reply is sent back to the client with the redirection server and port.

Currently only EPIC supports auto redirection when it gets a 010 reply (e.g. it will automatically connect to the server specified in the 010 reply). Other clients will get a message specifying what server and port to connect to. as well as an unauthorized disconnect.

Redirect
{
  mask = "<mask>";
  server = "<redirection server>";
  port = "<redirection port>";
};

Redirect
{
  mask = "*.aol.com";
  server = "irc.aol.com";
  port = "6667";
};

Spoofhost Block

Spoofhost {} blocks allows clients/opers to spoof their host.

Spoofhost "<spoof host>"
{
  pass = "<password>";
  host = "<*.host.cc|a.b.c.*|CIDR>";
  username = "<ident>";
};

• <spoof host> - The spoofed hostname.
• <pass> - A password for this spoof host. Used if SETHOST_USER is set to TRUE.
• <host> - A hostmask to match against users that are to be auto-spoofed. Used if SETHOST_AUTO is set to TRUE. Can be in the form of: host.domain.cc, 127.0.0.1 or 127.0.0.0/24, supports wildcards for non-CIDR.
• <username> - A mask for matching against the user's ident reply.

Example block:

Spoofhost "sline.darenet.org"
{
  pass = "anygoodpass";
  host = "127.0.0.1";
  username = "*";
};

Quarantine Block

Quarantine {} blocks, in ircd-darenet, allow you to specify channels that non-opers cannot join. The reason specified will be shown to users when they try to join the channel. Note, these are only checked at /JOIN. So, if you add a channel and rehash, users will not be kicked if they're already in the channel.

Quarantine
{
  "<channel>" = "reason";
};

Example block:

Quarantine
{
  "#help" = "For assistance, please join #Support instead.";
};

DNSBL Block

DNSBL {} blocks allow you to prevent clients connecting who are listed on DNS blacklists. Their connection will be rejected during the connection process along with the name and reason you give for the DNSBL they have been matched on.

DNSBL
{
  server = "<dnsbl.site.org";
  name = "<name>";
  flags = "<flags>";
  replies = "<replies/mask>";
  reply = "<rejection message>";
  rank = "<rank>";
};

Available flags:

• b (Bitmask DNSBL) - See your DNSBL provider as to whether you should use this or not.
• r (Reply DNSBL) - See your DNSBL provider as to whether you should use this or not.
• a (Allow Connect) - Allow the client to connect anyway. This could used with a DNSBL whitelist. This could also be used to allow users to still connect, but mark their hosts so that channel ops can easily ban them from their channels.
• d (Deny Connect) - If the user is found on this DNSBL, then they can't connect, even if they are allowed on through another DNSBL {} block.
• m (Mark Hostname) - Mark the hostname of a skipped client

The name option is used for the Mark Hostname flag, and may only contain hostname valid characters only (e.g. NO spaces). With Reply DNSBL's you need to list the replies in a comma separated list. See below for an example. With Bitmask DNSBL's, again, specify the replies you need to match for. The server will sum them up and match them against the DNSBL reply. The rejected user's nick, username, ip, and host can be placed into the rejection message by using these codes:

•  %n - Nickname
•  %u - Username
•  %h - Hostname
•  %i - IP Address

The rank number must be unique over all DNSBL {} blocks. The higher the number, the greater precedence it has. The highest ranking DNSBL {} block which is a matched against a user will get its name marked in the hostname.

Notes: MAKE SURE you read the DNSBL website before you go ahead and use it as they may have rules for large sites/servers who use them. If you do not wish to use DNSBL checking then simply do not create any DNSBL {} blocks.

Example blocks:

Reply DNSBL:

DNSBL
{
  server = "dnsbl.sorbs.net";
  name = "sorbs.net";
  flags = "r";
  replies = "1,2,3,4";
  reply = "%n!%u@%h Found On Sorbs DNSBL http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP=%i";
  rank = "1";
};

Bitmask DNSBL:

DNSBL
{
  server = "dnsbl.dnsbl.net";
  name = "dnsbl.net";
  flags = "b";
  replies = "1,3,5";
  reply = "%n!%u@%h Found On DNSBL";
  rank = "2";
};

WebIRC Block

WebIRC {} blocks allow you display the real hostname of users connecting via CGI:IRC clients and sites such as Mibbit.com. These clients will send a WEBIRC command along with the user's hostname, ip and WebIRC {} block password to the server. The password needs to be encrypted like Operator {} block passwords. When the ircd receives the command, instead of using the hostname of the site the users is connecting from, the hostname sent in WEBIRC will be set. All this is done before the client enters the network completely. Please remember to enclose the description using quotes otherwise things will break.

WebIRC
{
  mask = "<mask>";
  pass = "<password>";
  flags = "<flags>";
  ident = "<ident>";
  desc = "<description>";
};

Available flags:

• m - Marks each client connected via the WebIRC {} block using the provided description.
• s - Sets the ident specified in the ident field for each WEBIRC client.
• u - Uses the ident from USER that the WEBIRC client sends.

Note: Do not use both s and u, only choose one of them.

Example:

WebIRC
{
  mask = "*@webchat.darenet.org";
  pass = "VRKLKuGKn0jLs";
  flags = "ms";
  ident = "webirc";
  desc = "DareNET WebChat";
};

SpamFilter Block

This is probably the most controversial addition to ircd-darenet 1.3.x; however, sadly, it may become useful.

SpamFiler {} blocks allow you to filter PRIVMSG's, NOTICE's, TOPIC's and AWAY's for spam. The filtering is done using regular expressions, so please be careful.

SpamFilter {
   regex = "<regex>";                   
   rtype = "<watch flags>";                
   action = "<action flags>";              
   reason = "<reason>";
   channel = "<optional alert channel>";   
   length = <length in seconds>;                        
};

• <regex> - PCRE format regular expression to match against.
• <watch flags> - See below for a list.
• <action flags> - See below for a list.
• <reason> - Used in error messages displayed to the user and/or kills/shuns/glines/zlines.
• <optional alert channel> - Requires the C action flag.
• <length in seconds> - Only applies to glines, zlines and shuns.

Available watch flags:

• n - Notices.
• N - Channel notices.
• p - Privmsgs.
• C - Channel privmsgs.
• q - Quits.
• P - Parts.
• d - DCCs.
• a - Away messages.
• t - Topics.
• u - Connects (nick!user@host:gecos).
• i - Nickname changes.

Available action flags:

• a - Auth. If used, logged in clients will be exempt from the filter.
• C - Channel alert. If used, filter matches will be sent to what is set in the SpamFilter {} block channel setting.
• S - Server (snotice) alert.
• k - Kill anyone who matches the filter.
• g - Gline anyone who matches the filter. The length can be given in seconds.
• z - Zline anyone who matches the filter. The length can be given in seconds. This zlines *@ip, so you do not need the i action flag.
• s - Shun anyone who matches the filter. The length can be given in seconds.
• i - Uses the client's IP vice host in a Gline/Shun.
• b - Block; will prevent the PRIVMSG/NOTICE/TOPIC/AWAY from going through.
• n - Notify; will notify the person matching the filter, stating they've matched a filter, and deny their message.
• m - Mark; will mark the client as being a spam source.
• K - Kick; will kick the user triggering the Spam Filter. The kick reason given will be the reason set in the Spam Filter. This Flag will only work with the N and C watch flags.
• o - Ops/HalfOps; exempts ops and halfops from any checks which have a channel target.
• v - Voice; exempts voiced users from any checks which have a channel target.

Notes:

• Shuns and Glines will be set using *@hostname. If you would them to be set using *@ip use the 'i' action flag.
• If you do not specify a length, then FILTER_DEFAULT_LENGTH will be used.
• The 'b' action flag cannot be used with the 'u' watch flag. You will need to use a kill flag to block them.

Features Block

ircd-darenet has a large number of options and features, most of which can be configured using a Features {} block. If linking to DareNET, your Features {} block will be rather bare, since most DareNET-specific settings have been already defined in the source.

Features
{
  "featurename" = "value";
  "featurename2" = "value2";
};

You only need one Features {} block, in which you use "featurename" = "value1";, "featurename2" = "value2";, and so on. Please note all values, whether integers or strings, must be enclosed in double quotes.

See the servers features page for a list of available features.

Example block:

Features
{
  "LOG" = "SYSTEM" "FILE" "ircd.log";
  "LOG" = "SYSTEM" "LEVEL" "CRIT";
  "HUB" = "FALSE";
};