Configuration

This page explains the ircd-yeti configuration file.

ircd-yeti is simlar to other services in that it uses a text-based configuration file written in a particular format. By default, the file is named ircd.conf and is placed in etc/ where ircd-yeti was installed.

The configuration file consists of directives and their parameters. Simple directives each end with a semicolon. Other directives act as "containers", also known as blocks, that group together releated directives, enclosing them in curly braces. Shell, C and C++ style comments are also supported.

Accepted units of time are: seconds, minutes, hours, days, weeks, months, and years.

Accepted units of size are: bytes, kilobytes, megabytes, gigabytes and terabytes.

Example:

blockname {    token value;    token "string";    token value1, value2;    token 123;    token;    "string" "string";
    sub-blockname {        ...    }}

Include

A special include directive is supported, which allows you to include other configuration files. This is useful for splitting up your configuration instead of having one large configuration file.

Usage example

.include "filename"

General

The general block defines some information about the server itself.

Syntax:	name "...";
Default:	None
Context:	general

The name of the server.

Syntax:	numeric integer;
Default:	None
Context:	general

A unique ID for the server, between 1 and 4095.

This must be unique within the network the server is linked to.

Syntax:	description "...";
Default:	None
Context:	general

A short description for the server.

Syntax:	vhost "ipaddress";
Default:	vhost "*";
Context:	general

Sets the IP address to bind to for outgoing connections, unless overriden by a connect block.

Setting "*" will allow the system to choose an address.

Syntax:	dns vhost "ipaddress";
Default:	None, ircd will let the system assign the address
Context:	general

Sets the IP address to use for DNS lookups.

Syntax:	dns server "...";
Default:	None, ircd will use the servers read from /etc/resolv.conf
Context:	general

Sets the DNS servers to use for DNS lookups.

Syntax:	message_digest_algorithm "...";
Default:	message_digest_algorithm "sha256";
Context:	general

Configures which cryptographic hash function to use for generating fingerprint hashes for X.509 certificates.

tip

A list of supported message digest algorithms can be obtained by running:

$ openssl list-message-digest-algorithms

Usage example

general {        name "irc.example.com";        description "An IRC server";        numeric 1;        vhost "192.0.2.6";        vhost "2001:db7:2::6";        dns server "8.8.8.8";        dns server "8.8.4.4";        message_digest_algorithm "sha256";}

Admin

The admin block defines information for the /ADMIN command.

Syntax:	location "...";
Default:	location "";
Context:	admin

You can specify up to two location directives, which will configure the first two lines that are shown for the /ADMIN command output. They may contain whatever information you choose.

Syntax:	contact "...";
Default:	contact "";
Context:	admin

Usage example

admin {    location "An ircd-yeti test server";    location "DareNET Development";    contact "<dev@lists.darenet.org>";}

TLS

The TLS block configures TLS options for the server.

There may be multiple TLS blocks. For example, you may define two options, such as one for users and another for servers, allowing more backwards compatibility for users than for servers.

A TLS block can have one or more identities, see below.

Syntax:	name "...";
Default:	None
Context:	tls

Sets the name for these TLS options.

This is used for referencing this TLS block in other sections of the configuration file, and may be any arbritrary string.

Syntax:	dh_param_file "file";
Default:	None
Context:	tls

The file containing Diffie-Hellman parameters to use.

DH parameters are required when using ciphers with ephemeral Diffie-Hellman (EDH) key exchange.

Depending on your security needs, you should regenerate them every few weeks or so.

tip

The longer the key length, the more CPU time a TLS handshake will consume.

A DH parameter file can be created by running:

$ openssl dhparam -out dhparam.pem 2048

Syntax:	supported_groups "...";
Default:	supported_groups "X25519:P-256";
Context:	tls

Sets the curve to use for Elliptic Curve Diffie-Hellman (ECDH) algorithm.

Syntax:	cipher_list "...";
Default:	cipher_list "EECDH+HIGH:EDH+HIGH:HIGH:!aNULL";
Context:	tls

Sets the list of TLSv1.2 ciphers to support.

This can be used to enforce specific ciphers from incoming and outgoing TLS connections. If a client is not capable of using any of the ciphers listed, the connection is rejected.

The ciphers are specified in a format understood by the OpenSSL library – multiple ciphers are separated by colons. The order of preference is from left to right.

tip

A list of supported ciphers by OpenSSL can be obtained by running:

$ openssl ciphers -s -tls1_2 -v

Syntax:	cipher_suites "...";
Default:	cipher_suites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";
Context:	tls

Sets the list of TLSv1.3 cipher suites to support on the server.

OpenSSL currently supports the following TLSv1.3 cipher suites:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

Syntax:	rsa_private_key_file "file";
Default:	None
Context:	identity

The file containing the RSA key.

tip

Example commands to store a 4096 bit RSA key in rsa.key:

$ openssl genrsa -out rsa.key 4096
$ chown <ircd-user>.<ircd-group> rsa.key
$ chmod 0600 rsa.key

You must specify this before the certificate_file directive; otherwise, reading the configuration file will fail with the message: "No rsa_private_key_file specified; TLS support disabled"

Syntax:	certificate_file "file";
Default:	None
Context:	identity

The file containing our TLS certificate. It should be in PEM format and sorted starting with the subject's certificate, followed by intermediate CA certificates (if applicable), and ending at the highest level (root) CA.

tip

Example commands to generate certificate (assuming we have rsa.key):

$ openssl req -new -days 365 -x509 -key rsa.key -out cert.pem`

See http://www.openssl.org/docs/HOWTO/certificates.txt

Syntax:	server_name "...";
Default:	None
Context:	identity

Defines the server name as used for Server Name Indication (SNI).

If you use more than one TLS identity in the same or in separate profiles, setting the server_name directive is highly suggested; otherwise, results may be indeterminate if not set.

There may be multiple server_name directives.

Syntax:	advertise_sts yes | no;
Default:	advertise_sts no;
Context:	identity

Enables or disables advertising a STS policy for this TLS profile.

Syntax:	sts_duration time;
Default:	sts_duration 0;
Context:	identity

Sets the duration for a persistence policy for the advertised STS policy.

Syntax:	sts_preload yes | no;
Default:	sts_preload no;
Context:	identity

If enabled, the server will indicate to the client, in the advertised STS policy, that it agrees to be included in STS preload lists.

Usage example

tls {    name "users";    identity {        server_name "test.darenet.org";        rsa_private_key_file "test.darenet.org.key";        certificate_file "test.darenet.org.crt";    };    identity {        server_name "irc.darenet.org";        rsa_private_key_file "irc.darenet.org.key";        certificate_file "irc.darenet.org.crt";    };    dh_param_file "dhparam.pem";    supported_groups "X25519:P-256";    cipher_list "EECDH+HIGH:EDH+HIGH:HIGH:!aNULL";    cipher_suites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";}

Class

The class block defines connection classes for users and servers.

While the server will start without a class block, it will not be very usable.

There may be multiple class blocks.

Syntax:	name "...";
Default:	None
Context:	class

Defines the name for this class block.

The name is used to reference the class in other sections of the configuration file.

Syntax:	pingfreq time;
Default:	pingfreq 1 minute 30 seconds;
Context:	class

Defines how often a client or server must respond to a PING from the server before they're dropped.

Syntax:	sendq size;
Default:	sizeq 40 kilobytes;
Context:	class

The amount of data allowed in a client or server's queue before they're dropped.

Syntax:	recvq size;
Default:	recvq 1024 bytes;
Context:	class

The amount of data allowed in a client's receive queue before they're dropped for flooding. The maximum size is 8000 bytes.

If omitted, the value of the CLIENT_FLOOD feature is used.

Syntax:	maxlinks integer;
Default:	maxlinks 0;
Context:	class

For clients, sets the maximum number of users allowed in this class. Once this limit is reached, any additional connections will receive a "Sorry your connection class is full - try again later or try another server" error.

For servers, if autoconnect is enabled, the server will attempt to automatically connect until the number of servers in the class is greater or equal to what is set for maxlinks. Usually 0 for hubs, and 1 for leafs.

Syntax:	usermodes "+modes";
Default:	None
Context:	class

Defines the user modes to automatically set for the client.

Syntax:	maxchans integer;
Default:	maxchans 50;
Context:	class

Defines the maximum number of a channels the client may join.

If omitted, the value of the MAXCHANNELSPERUSER feature is used.

Syntax:	fake_lag_minimum time;
Default:	fake_lag_minimum 2 seconds;
Context:	class

Defines the minimum number of seconds the server should wait before processing commands received by the client.

Syntax:	fake_lag_factor integer;
Default:	fake_lag_factor 120;
Context:	class

Defines the value the message length will be divided by to determine any additional fake lag penalty to apply to the client.

Syntax:	flags flag[,flagN];
Default:	None
Context:	class

Available flags for clients:

• no_create - prevents users in this class from creating channels
• no_nickchange - prevents users in this class from being able to change their nickname
• restrict_privmsg - users in this class can only private message opers and services

Syntax:	marks { ... };
Default:	None
Context:	class

Defines the marks to be applied to users in this connection class.

marks {    "<mark>" "<mark value>";    "<markN>" "<mark value>";}

Syntax:	connectfreq time;
Default:	connectfreq 0;
Context:	class

For servers, sets the frequency at which auto-connections are tried. For autoconnects to take place, the connect block using this class must have a valid port specified, and there must be less than class::maxlinks connected servers in the class.

note

Setting connectfreq to 0 will cause the server to attempt to connect repeatedly without delay until the condition is satisfied. This reconnection in quick succession may, in the worst case, cause a hosting provider to blacklist the connecting server for awhile.

Usage example

Users

class {    name "Users";    pingfreq 1 minute 30 seconds;    sendq 100 kilobytes;    maxlinks 10000;    usermode "+i";}
// Class block for operatorsclass {    name "Opers";    pingfreq 5 minutes;    sendq 100 kilobytes;    maxlinks 30;
    /* Operator privileges may be listed in a class block, which     * apply to all operators using the class, or in the oper's     * operator block.     */    local no;}

Servers

class {    name "Servers";    pingfreq 3 minutes;    sendq 2 megabytes;    maxlinks = 1;    connectfreq 5 minutes;}

Client

Client blocks define what clients are allowed to connect to the server, and places them into connection classes.

While the server will start without a client block, no clients will be able to connect.

There may be multiple client blocks.

Syntax:	class "...";
Default:	None
Context:	client

The name of the connection class to place the client in.

Syntax:	host "...";
Default:	None
Context:	client

The hostname(s) and/or IP(s) to match against.

There may be multiple host lines in a single client block.

The first matching client block is used.

Syntax:	password "...";
Default:	None
Context:	client

Sets a password that a client must supply with the PASS command to use this block.

Syntax:	certfp "...";
Default:	None
Context:	client

Sets the fingerprint that the user's client certificate must match to use this block.

Syntax:	maxlinks integer;
Default:	maxlinks 65535;
Context:	client

Sets the maximum number of clients allowed from the same IP address (globally).

Syntax:	flags flag[,flagN];
Default:	None
Context:	client

Flags allow you to set additional restrictions or exemptions for clients using this client block.

Available flags:

• can_flood - Allows the user to set umode +F to exempt themselves from flood protection and fake lag
• gline_exempt - Exempts the user from G-lines
• kline_exempt - Exempts the user from K-lines
• list_exempt - Exempts the user from /LIST restriction
• need_account - Requires the user to successfully authenticate to a service account using SASL
• need_ident - Requires the use of identd
• need_tls - Requires the user to connect using TLS
• no_tilde - Prevents prefixing the username with ‘~’ if no ident response is received
• shun_exempt - Exempts the user from Shuns
• target_exempt - Exempts the user from target limits

Usage example

client {    class "Users";    ip "198.51.100.0/24";    certfp "BE205BC7EC2FACCD6CCE9D0FC9AEA45FF2A5FFB006D2E20EAD242805587CD0B0";    maxlinks 5;    flags list_exempt, need_tls;}

Exempt

Exempt blocks are used to configure exemptions for IPcheck and WebIRC port restrictions based on IP address.

Syntax:	ip "ipaddress|netmask";
Default:	None
Context:	exempt

The IP address to exempt. You may specify an IPv4 address, IPv6 address or netmask.

There may be multiple ip entries.

Syntax:	flags flag[,flagN];
Default:	None
Context:	exempt

The exemptions to grant. If omitted, defaults to ipcheck; however, this behaviour may be changed in a future release, thus it shouldn't be relied upon.

Available flags:

• iauth - Exempts the client from IAuth queries
• ipcheck - Exempts the client from IPcheck limits and restrictions

Usage example

exempt {    ip "127.0.0.1";    flags ipcheck;}

MOTD

MOTD blocks allow showing a different Message of the Day (MOTD) to clients based on their origin. If no motd blocks are defined, or match the client, the value of the MPATH feature (default: ircd.motd) will be used.

Syntax:	host "...";
Default:	None
Context:	motd

The mask to match against. Multiple host entries are allowed.

Syntax:	file "file";
Default:	None
Context:	motd

The MOTD file to show.

Usage example

motd {    host = "*.de";    host = "*.ch";    host = "*.at";
    file = "german.motd";}

Connect

Connect blocks configure what servers to connect to.

Syntax:	name "...";
Default:	None
Context:	connect

The server's name.

Syntax:	class "...";
Default:	None
Context:	connect

The connection class to place the server in.

Syntax:	host "...";
Default:	None
Context:	connect

The host or IP address of the server.

Syntax:	password "...";
Default:	None
Context:	connect

The password we send and accept.

Syntax:	vhost "...";
Default:	None
Context:	connect

The IP address to bind to when making outgoing connections to this server. This overrides the general block's vhost directive.

Syntax:	port integer;
Default:	None
Context:	connect

The default port the server will try to connect to if an operator uses /CONNECT without specifying one. This is also the port used when the server attempts to autoconnect.

Syntax:	fingerprint certfp | spkifp "...";
Default:	None
Context:	connect

Enhances security by checking against a fingerprint.

Supported types:

• certfp - Matches against the server's TLS certificate fingerprint.
• spkifp - Matches against the server's SPKI fingerprint, which is the Base64-encoded output of the SHA256 hash of the DER-encoded ASN.1 representation of the Subject Public Key Info of the server's TLS certificate. It has the advantage of staying the same, so long as the private key does not change, even if the certificate is reissued.

Syntax:	maxhops integer;
Default:	None
Context:	connect

Causes an SQUIT if a hub tries to introduce servers farther away than the value given here.

Syntax:	leaf ;
Default:	None
Context:	connect

An alias for maxhops = 0;

Syntax:	hub "...";
Default:	None
Context:	connect

A mask of servers that may be introduced by a hub.

The hub; tag is an alias for hub = "*";.

Syntax:	autoconnect yes | no;
Default:	autoconnect yes;
Context:	connect

Enables or disables autoconnects.

See class blocks for more informtion.

Syntax:	tls yes | no;
Default:	autoconnect no;
Context:	connect

Enables or disables using TLS for this connection.

Syntax:	ca_file "file";
Default:	None
Context:	connect

If defined, requires that the server use a TLS certificate signed by the given Certificate Authority (CA).

Syntax:	tls_options "...";
Default:	None
Context:	connect

The TLS options to use for the outbound connection.

The TLS options for the inbound connection are defined in the listen block accessed by the remote server.

note

If you have more than one TLS identity, it is strongly recommended to define the tls_options parameter for each connect block; otherwise, results may be indeterminate if not set.

See TLS blocks for more information.

Usage example

connect {    name "uplink.example.com";    host "192.0.2.4";    password "secret";    fingerprint certfp "BE205BC7EC2FACCD6CCE9D0FC9AEA45FF2A5FFB006D2E20EAD242805587CD0B0";    port 4400;    class "Servers";    hub;    tls yes;    tls_options "servers";    ca_file "ca.pem";}

Listen

Listen blocks configure what portd the ircd will listen on.

There may be multiple listen blocks.

• De facto port: 6667
• Standard ports: 6660-6669 and 7000
• Standard TLS ports: 6697 and 9999

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

Syntax

Syntax:	port [ipv4 | ipv6] "integer";
Default:	None
Context:	listen

The specific port to listen on.

If an address family is specified, it will be restricted to that type.

Syntax:	mask "...";
Default:	None
Context:	listen

A range of IP addresses to allow connections from. This should only contain IP addresses, as this does not use DNS in any way.

Syntax:	vhost [ipv4 | ipv6] "..." [port];
Default:	None
Context:	listen

Set a specific IP address to listen on.

There may be multiple vhost entries.

If omitted, the default is to bind to all available interfaces.

Syntax:	server yes | no;
Default:	server no;
Context:	listen

If enabled, only server connections are allowed on this port.

Syntax:	hidden yes | no;
Default:	hidden no;
Context:	listen

If enabled, the port is not shown in /STATS ports.

Syntax:	tls yes | no;
Default:	tls no;
Context:	listen

If enabled, only TLS connections are permitted on this port.

Syntax:	tls_options "...";
Default:	None
Context:	listen

The TLS options to use for inbound connections.

The TLS options for outbound connections to other servers is defined in the connect block for the remote server.

See TLS blocks for more information.

Syntax:	defer_accept yes | no;
Default:	defer_accept no;
Context:	listen

If enabled, the server will wait for clients to send IRC handshake before accepting them. You'll want to leave this disabled for ports used by clients such as BOPM/HOPM, since they depend on the server replying first.

Syntax:	http yes | no;
Default:	http no;
Context:	listen

If enabled, only HTTP connections are accepted on this port.

It is highly recommended that you don't expose this to the outside.

Usage example

listen {    port 4400;    server yes;    tls yes;    tls_options "servers";    hidden yes;}
listen {    port 6697;    vhost "192.0.2.2";    tls yes;    tls_options "users";}
listen {    port 7001;    hidden yes;    webirc yes;    tls yes;    tls_options "users";}

Operator

Operator blocks are used to configure IRC operator privileges on the server.

There may be multiple operator blocks.

Syntax:	name "...";
Default:	None
Context:	operator

The username for this operator block, as used in the /OPER command.

Syntax:	host "...";
Default:	None
Context:	operator

The user@host mask the operator must match to use this block

Multiple host entries are supported.

Syntax:	password "...";
Default:	None
Context:	operator

The password required to /OPER.

By default, the password is encrypted using the provided umkpasswd tool.

Syntax:	class "...";
Default:	None
Context:	operator

The connection class to place this operator in.

Syntax:	certfp "...";
Default:	None
Context:	operator

Enhances security by allowing you to "pin" the operator's client certificate fingerprint, which is checked against the client certificate presented by the user.

Multiple certfp entries are supported.

Syntax:	snomask "...";
Default:	None
Context:	operator

The default server notice mask(s) to set for the operator.

If omitted, the server's default snomask will be used.

Syntax:	flags flag[,flagN];
Default:	None
Context:	operator

Allows you to set additional restrictions for this operator.

Available flags:

• need_account - Requires that the operator be authenticated to a services account
• need_tls - Requires that the operator be connected using TLS

Privileges

Operator privileges may be listed in a class block, which apply to all operators using the class, or in the oper's operator block. If a privilege is present in both blocks, the value of the privilege contained in the operator block will take precedence.

The local privilege must be specfied by either the class or operator block.

Usage example

operator {    name "god";    host "god@192.0.2.0/26";    host "*god@127.0.0.1";    password "$pbkdf2_sha256$128000$bljllcjeiekqrjta$2f11f4d4cc723b43159ed739391f2898ca2e4a72b26d33c5418f1d21e23384ff";    certfp "BE205BC7EC2FACCD6CCE9D0FC9AEA45FF2A5FFB006D2E20EAD242805587CD0B0";    snomask "+Ksgox";    class "Opers";    flags need_tls;
    /* privileges */    local = no;    whox = yes;}

Kill

Kill blocks are used to disallow connections from clients based on specific ident, gecos and/or host.

These blocks, also known as K-lines, are a flexible general client ban mechanism. Clients matching a block will be disconnected. Existing clients will be scanned for possible matches when new blocks are loaded.

All kill blocks are local to the server.

There may be multiple kill blocks.

Syntax:	host "...";
Default:	None
Context:	kill

Host or user@host mask to match against.

This directive is optional if using the username and/or realname directives.

Syntax:	username "...";
Default:	None
Context:	kill

Username mask to match against.

This directive is optional if using the host and/or realname directives.

Syntax:	realname "...";
Default:	None
Context:	kill

Gecos mask to match against.

This directive is optional if using the host and/or username directives.

Syntax:	reason "...";
Default:	reason "Connection from your host is refused on this server";
Context:	kill

The reason shown to the user when they're disconnected.

Syntax:	file "file";
Default:	None
Context:	kill

If specified, a file containing text that will be shown to the user when they're disconnected.

Usage example

kill {    host "*@192.167.0.0/24";    reason "You are infected with a Trojan.";    file "/path/to/file/with/reason/to/show";}
kill {    /* ban based on username and realname. */    username "sub7";    realname "s*7*";    reason "You are infected with a Trojan.";};
kill {    /* ban based on username. */    username "root";    reason "Don't IRC as root!";}
kill {    /* ban based on user@host mask using a file that containts     * the reason text.     */    host "*luser@unixbox.flooder.co.uk";    file "klines/youflooded.txt";}
kill {    /* IP-based bans apply to all hosts, even if the client's     * IP address has a properly resolving hostname.     */    host "192.168.*";    file "klines/martians.txt";}

UWorld

UWorld blocks configure what servers are allowed to do special network things (e.g., network services).

UWorld servers are permitted do things typical network services would want to do, such as apply network bans, manage channel modes, etc; the details are too numerous and complex to describe here.

UWorld blocks must be the same on every single server linked to the network or the results can be disastrous.

Syntax:	name "...";
Default:	None
Context:	uworld

Server name or wildcard mask.

Multiple name entries are allowed.

Usage example

uworld {    name "services.darenet.org";    name "services2.darenet.org";    name "control.darenet.org";}

Jupe

Jupe blocks configure what nicknames cannot be used.

Syntax:	"nickname" "reason";
Default:	None
Context:	jupe

nickname may be a single nickname, or list of nicknames (comma delimited) to disallow. Wildcards are supported.

reason is what will be shown to a user when they try to use the nickname.

There may be multiple entries.

Usage example

jupe {    "ChanS?rv,NickS?rv,MemoS?rv,HostS?rv,OperS?rv" "Reserved for services.";    "login" "Invalid nickname";    "protocol,pass,newpass" "Invalid nickname.";}

Resv

Resv blocks configure what channels are disallowed by non-operators.

Syntax:	"channel" "reason";
Default:	None
Context:	resv

channel is the name of the channel to reserve.

reason is what will be shown to a user when they try to join the channel.

Usage example

resv {    "#wtf" "Whiskey Tango Foxtrot";}

Quarantine

Quarantine blocks are used to prevent operators from using OPMODE and CLEARMODE on specific channels.

note

Operators with the force_opmode, and force_local_opmode for local channels, privilege may override the quarantine.

Syntax:	"channel" "reason";
Default:	None
Context:	quarantine

channel is the name of the channel to quarantine.

reason is what will be shown to a operator when they try to use OPMODE or CLEARMODE on the channel.

Multiple entries are allowed.

Usage example

quarantine {    "&kiddies" "They can take care of themselves";    "#shells" "Thou shalt not support the h4><0rz";}

CRule

CRule blocks are used to configure connection rules.

Connections rules are a real-time, rule-based, routing decision system.

There may be multiple crule blocks.

See doc/readme.crules.

Syntax:	server "...";
Default:	None
Context:	crule

Server mask.

Syntax:	rule "...";
Default:	None
Context:	crule

The connection rule.

Syntax:	all yes | no;
Default:	all no;
Context:	crule

If enabled, indicates that this rule always applies; otherwise, it will only apply to auto-connects.

Usage example

crule {    server "*.us.example.com";    rule "connected(*us.example.com)";    all yes;}

Pseudo

Pseudo blocks are used to configure server-side aliases to send messages to a service.

There may be multiple pseudo blocks.

Syntax:	pseudo "alias" {
Default:	None
Context:	pseudo

The alias name must be specified before the block's opening brace.

Syntax:	name "...";
Default:	None
Context:	pseudo

The service name; used for error messages.

Syntax:	nick "...";
Default:	None
Context:	pseudo

Defines where the messages should be delivered to.

Multiple nick entries may be specified, with the one last one listed having the highest priority.

Syntax:	prepend "...";
Default:	None
Context:	pseudo

Text to prepend to the user's message.

Syntax:	default "...";
Default:	None
Context:	pseudo

Defines default text to use if the user doesn't provide any arguments.

Syntax:	allow_empty yes | no;
Default:	allow_emtpy node;
Context:	pseudo

If enabled, this alias does not require any arguments to specified.

This is ignored if text has been defined for the default directive.

Syntax:	oper_only yes | no;
Default:	oper_only node;
Context:	pseudo

If enabled, the user must be an IRC operator to use the alias. Any non-operator use of the alias is treated as though the alias does not exist.

Usage example

pseudo "AUTH" {    name "N";    nick "N2@services2.darenet.org";    nick "N@services.darenet.org";    prepend "AUTH ";}
/* operator only alias */pseudo "OS" {    name "O";    nick "O2@services2.darenet.org";    nick "O@services.darenet.org";    oper_only yes;    allow_empty yes;}

Cloak

Cloak blocks configure a cloaking mechanism.

There may be multiple cloak blocks.

Syntax:	name "...";
Default:	None
Context:	cloak

Name of the cloaking mechanism to use; ircd-yeti ships with HMAC-SHA256, hostchange, and ipcloak.

Syntax:	host "...";
Default:	None
Context:	cloak

The user@host mask the cliemt must match to use this block

Multiple host entries are supported.

Syntax:	value "...";
Default:	None
Context:	cloak

Defines the format used for the generated cloak.

For the HMAC-SHA256 cloaking mechanism, the available variable substitutions are:

Variable	Value
${hash1}	Hash 1 (a.b.c.d)
${hash2}	Hash 2 (a.b.c.*)
${hash3}	Hash 3 (a.b.*)
${hash4}	Hash 4 (a.*)

For the hostchange cloaking mechanism, the available variable substitutions are:

Variable	Value
${nick}	Nickname (or hash of nickname if too long or contains invalid characters)
${username}	Username (or hash of nickname if too long or contains invalid characters)

For the ipcloak cloaking mechanism, the available variable substitutions are:

Variable	Value
${hash}	The cloak hash

Syntax:	mark "key" "value";
Default:	None
Context:	cloak

The mark a client must have to use this block.

Syntax:	cidr_len_ipv4 integer;
Default:	cidr_len_ipv4 32;
Context:	cloak

The cloak hash is derived from the CIDR (i.e. the most significant bits of the IP address), as configured here.

This directive is only used by the ipcloak mechanism.

Syntax:	cidr_len_ipv6 integer;
Default:	cidr_len_ipv6 64;
Context:	cloak

Analogus to the cidr_len_ipv4 directive, but for IPv6 addresses.

This directive is only used by the iplocak mechanism.

Usage example

cloak {    name "hostchange";    host "*.irccloud.com";    value "gateway/irccloud.com/${username}";}
cloak {    name "HMAC-SHA256";    host "*";    mark "tor" "tor";    value "gateway/tor/${hash1}-${hash2}-${hash3}-${hash4}";}
cloak {    name "HMAC-SHA256";    host "*";    value "darenet/guest/${hash1}-${hash2}-${hash3}-${hash4}";}
#cloak {#    name "ipcloak";#    host "*";#    cidr_len_ipv4 32;#    cidr_len_ipv6 64;#    value "guest/x-${hash}"'#}

Modules

The modules block configures what modules are to be loaded on startup and rehash.

Syntax:	path "...";
Default:	None
Context:	modules

Defines a path to search for modules. Multiple path entries are supported.

Syntax:	module "...";
Default:	None
Context:	modules

The name of the module to load.

You should append the .la suffix to the name of the module.

Multiple module entries are supported.

Usage example

modules {    path "lib/ircd-yeti/modules";    module "cloak_hmac_sha256.la";    module "sasl.la";}

WebIRC

WebIRC blocks configure what connections may use WEBIRC.

Multiple webirc blocks are supported.

important

A rehash will disconnect clients using a webirc block that was removed. A webirc block is considered removed if there is no block in the new config with the same IP address and password.

Syntax:	ip "ipaddress|netmask";
Default:	None
Context:	webirc

The IP address. You may specify an IPv4 address, IPv6 address or netmask.

There may be multiple ip entries.

Syntax:	password "...";
Default:	None
Context:	webirc

The password we expect in the WEBIRC command.

By default, the password is encrypted using the provided umkpasswd tool.

Syntax:	name "...";
Default:	None
Context:	webirc

A short name shown in a /WHOIS reply on a WebIRC user.

Syntax:	hidden yes | no;
Default:	hidden no;
Context:	webirc

If enabled, the IP address is hidden in a /STATS webirc.

Syntax:	strip_certfp yes | no;
Default:	strip_certfp no;
Context:	webirc

If the client issuing the WEBIRC command presents a TLS client certificate, the fingerprint for it will not be stored if this option is specifed and set to 'yes'.

You should always set to this 'yes' for public WebIRC gateways.

Syntax:	enable_options yes | no;
Default:	enable_options no;
Context:	webirc

Enables or disables support for IRCv3's WEBIRC options parameter.

Usage example

webirc {    ip "127.0.0.1";    password "$pbkdf2_sha256$128000$bljllcjeiekqrjta$2f11f4d4cc723b43159ed739391f2898ca2e4a72b26d33c5418f1d21e23384ff";    name "Awesome WebIRC Client";    strip_certfp yes;}

Forwards

The forwards block configures prefixed channel message forwarding.

Matching prefixed channel messages are forwarded to the specified UWorld server. This allows users to use in-channel (fantasy) commands without the service client having to be present in the channel.

Syntax:	"prefix" "uworld-server";
Default:	None
Context:	forwards

prefix is the prefix a channel message must have for it to be forwarded.

uworld-server is the UWorld server to forward the prefixed channel message to.

Multiple entries are allowed.

Usage example

forwards {    "!" "services.darenet.org";    "?" "services2.darenet.org";    "." "services.darenet.org";}

Filter

Filter blocks are used to configure a spam filter.

Syntax:	match "...";
Default:	None
Context:	filter

The string that should be blocked or the specified action should be performed on.

Syntax:	type value;
Default:	None
Context:	filter

The type of match string being used.

There are currently two available types:

• simple - Simple glob-style matching
• regex - Regular expression matching

Syntax:	target value[,valueN];
Default:	None
Context:	filter

Specifies the target type, i.e. the targets this filter will look into.

• channel_message - Channel messages
• channel_notice - Channel notices
• private - Private messages
• notice - Private notices

Syntax:	action value;
Default:	None
Context:	filter

The action to take on a positive match.

• gline - Glines the offender
• soft_gline - Glines the offender, only if they're not authenticated
• shun - Shuns the offender
• soft_shun - Shuns the offender, only if they're not authenticated
• kill - Disconnects the offender
• soft_kill - Disconnects the offender, only if they're not authenticated
• block - Blocks the offending message
• soft_block - Blocks the offending message, only if the offender isn't authenticated
• warn - Warns opers that a filter has been matched
• soft_warn Warns opers that a filter has been matched by a non-authenticated user

Syntax:	duration time;
Default:	None
Context:	filter

Defines the duration to use for Gline/Shun actions.

This directive is required if using a Gline or Shun action.

Syntax:	reason "...";
Default:	None
Context:	filter

Defines the reason message to use for Gline/Shun actions.

This directive is required if using a Gline or Shun action.

Syntax:	flags flag[,flagN];
Default:	None
Context:	filter

Allows you to change the behavior of a filter.

Available flags:

• exempt_authed - Do not filter matching messages if the user is authenticated
• exempt_opers - Do not filter matching message if the user is an IRC operator
• strip_color - Strip color/control codes before checking the message

Syntax:	exempt { "target"; }
Default:	None
Context:	filter

Where target is a users or channel to exempt from the filter.

Multiple targets may be specified.

Usage example

filter {    match "*bad juju*";    type simple;    target channel_message, channel_notice;    action soft_block;    exempt {        "#help";        "god";    }}

Restrict

The Restrict block allows commands to be restricted or completely disabled for users without having to unload its corresponding module.

Allows commands to be restricted or completely disabled for users without having to unload its corresponding module.

Syntax:	restrict "command" {
Default:	None
Context:	restrict

The command name must be specified before the block's opening brace.

Syntax:	type value;
Default:	None
Context:	restrict

Defines the type of restriction.

Avaiable types:

• delay - Delays use of the command after connection for a specified duration
• disable - Disables use of the command

Syntax:	duration time;
Default:	duration 0;
Context:	restrict

For delay restrictions, specifies how long a user must be connected before they may use the command.

Syntax:	exempt authed yes | no;
Default:	exempt authed no;
Context:	restrict

If enabled, exempts authenticated users from the restriction.

Syntax:	exempt karma integer;
Default:	None
Context:	restrict

If enabled, exempts users with karma at least equal or greater than this value from the restriction.

Usage example

restrict "JOIN" {    type delay;    duration 1 minute;    exempt authed yes;    exempt karma 5;}

IAuth

The IAuth blocks configures which IAuth helper program to use.

IAuth helper programs are used to determine if a client should be allowed to connect to the server or not.

Syntax:	program "path" ["args"];
Default:	None
Context:	iauth

Specifies the path to the IAuth program, as well as any additional arguments to use.

Usage example

iauth {    program "/home/user/iauthd" "-c" "server.conf" "-d";}

Features

Features blocks are used to configure various server settings.

Multiple feature blocks are allowed, and multiple settings may be specified in a single features block.

Syntax:	"setting" "value";
Default:	None
Context:	features

Where setting is the name of the feature setting, and value is the value to set for the setting.

Usage example

features {    "LOG" "SYSTEM" "FILE" "ircd.log";    "LOG" "SYSTEM" "LEVEL" "CRIT";
    "HUB" "TRUE";}