Server Features

Current revision as of 05:52, 5 January 2013

This page needs an update. Information posted here has been viewed as incorrect, incomplete, or out of date. Anyone is welcome to correct these flaws if this page has not been locked. Otherwise, contact a Support Team member and give them notice of this issue. Thank you.

This page documents various features supported by ircd-darenet that can be configured at run-time.

DOMAINNAME

Sets the domain the ircd will consider as "local", which is ONLY used for statistical purposes.

The /STATS w and /STATS usrload commands return statistical data, such as how many clients have connected to the server in the last minute, hour and day. These statistics are shown for all connections, including servers, with a separate entry for clients who's hostname ends on the domain specified for DOMAINNAME.

The string should not start with a '.' and cannot be empty. If you don't want to specify a domain, do not define this feature.

RELIABLE_CLOCK

You should really ONLY specify "TRUE" here when your system clock is stable and accurate at all times (within a few seconds). If you are running ntpdate on a regular basis, or an equivalent like xntpd, to keep your system clock synchronized over the network, then you might have an accurate clock. However, this is not guaranteed; for example, it is known that xntpd gives unstable results on Linux in some cases.

An unstable clock is worse than a clock that has a constant offset, because ircd-darenet will attempt to correct for a constant offset, but will not correct jumps of your system clock! In general, you SHOULD be running ntpdate or equivalent AND make sure it works when you run a production server on DareNET, and specify "FALSE" here. If unsure, specify "FALSE"!

BUFFERPOOL

This specifies (in bytes) the maximum amount of RAM that your sever will allocate for buffering sendQs. Small leafs can use a value as little as 1000000, while large HUBS need to specify a value as high as 20000000. If you run out of memory, clients and/or servers are dropped with the error "Buffer allocation error"; then you will have to increase this number (and install more RAM if appropriate).

If you want a more educated guess for this value then realize that any value is good if you _really_ would rather drop servers and clients than allocate more memory; this will be the case when there is the danger you may run out of memory for other allocations. Even if you run the daemon on a dedicated machine, specifying all of the RAM you have is a bad thing, because running out of memory is a lot worse than dropping clients in a controlled way; if possible you should have memory left for all the internal structures (channels, clients, ban lists, receive buffers) at all times. On average, clients seem to use 150 bytes of sendQ, but at peak moments this can easily increase to 2032 bytes per client (sendQs are allocated in chunks of 2032 bytes).

The maximum possible amount that can be allocated for sendQs is the number of connected clients times whatever you specified as the maximum sendQ in your Class blocks in the ircd.conf file. That value will likely be larger then the amount of RAM you have. The educated guess I talked about earlier would be "number of clients" times * 2048 bytes + "size of net.burst" * n, where "n" is 1 for leafs and up to 5 for HUBs. The "size of net.burst" is about 125 bytes per online client (on the whole network). For large HUBs with 4000 clients on a network with 30,000 users, this results in 27 Mb. Leafs could use 12 Mb. Of course you can use less when you have less than 4000 local clients.

HAS_FERGUSON_FLUSHER

If you have a server with a lot of resources available, this option will cause the server to attempt to flush its internal buffers before dropping clients during a net break. Don't define this if you don't know for certain; if you're not careful this can end up rebooting FreeBSD boxes. For more information, refer to doc/freebsd.txt.

CLIENT_FLOOD

Currently, everything that a client sends to a server is read by the server and stored in a buffer (the clients receive queue). The server will process messages from this queue one by one (running over all clients each time). When a client sends new messages faster than they get processed, and the size of its receive buffer reaches this value, the client is dropped with the error "Excess flood." A reasonable value is 1024 bytes. The maximum size is 8000 bytes.

SERVER_PORT

When an IRC operator attempts a connect to another server, he or she may not know which port the connect should go to. In ircd-darenet, that operator may use the special port 0, in which case the server will take the port from the Connect block. If no port is specified in the Connect block, then the port specified by this option will be used instead.

NODEFAULTMOTD

Every time a client connects to your server, the full Message of the Day (as specified by the Motd blocks or by the file specified by the MPATH option) is sent to the client. The server sends the Message of the Day even though many clients permit the user to ignore it. Many users never read the message of the day anyway, making it a huge waste of bandwidth. If you specify "TRUE" here, then the server won't send the MOTD to the client by default; instead, it will only tell the client when the MOTD was last changed, and give instructions on how to obtain it by typing /MOTD.

MOTD_BANNER

If the NODEFAULTMOTD option is enabled, then the one-line banner specified here is sent to the client in addition to the instructions, as mentioned above.

REMOTE_MOTD

Controls the use of remote message of the day's.

PROVIDER

This string is added to the 001 numeric prefixed with "via" before the string. It's used for providing promotional space to providers.

GEO_LOCATION

This string is added to the 003 numeric, used for providing the location of the servers, e.g. "Los Angeles, CA, USA".

KILL_IPMISMATCH

When a client connects to your server, the IP address of the client is reverse-resolved to obtain a hostname. Then that hostname is resolved to an IP address and compared with the IP address of the client. If they don't match, the client will appear with the IP address instead of the hostname, unless KILL_IPMISMATCH is "TRUE," in which case the client is simply disconnected.

IDLE_FROM_MSG

The IRC command WHOIS gives an idle time for clients. If you want this idle time to be set to zero only when the client sends a PRIVMSG, then you should specify "TRUE" here. If you specify "FALSE," then the idle time will be nullified on all messages except the server PING/PONG.

HUB

All servers of an IRC "network" are connected in a "tree" (no loops). Servers that are only connected to one other server (called the "uplink") are called "leafs"; servers that are connected to more than one other server are called HUBs. If you specify "FALSE" here then your server will prevent itself from accidentally connecting to two servers at once, thus keeping servers in poor network locations from routing traffic. Note that on DareNET, all newly linked servers are linked as leafs during their test phase, and should specify "FALSE" here.

WALLOPS_OPER_ONLY

Setting this option removes the ability for clients that are not IRC operators to see wallops messages.

NODNS

If you are playing with the server off-line, and no DNS is available, then long delays occur before the server starts up because it tries to resolve the name given in the General block (which usually isn't given in /etc/hosts) and for each connecting client. If you specify "TRUE" here, then a DNS lookup will be done only for the real hostname, and the server will not try to resolve clients that connect to "localhost." Note that other DNS lookups are still done for outbound connections.

RANDOM_SEED

When a client connects, the server sends the client a "cookie," consisting of a random number. The client must return the cookie to the server verbatim. This is done to prevent IP spoofing. The cookie is generated by a pseudorandom number generator included in ircd-darenet. This generator must be seeded with a phrase that is kept secret, to ensure that the numbers it generates are not easily guessed.

The value given to RANDOM_SEED may be a string of any length. It should not contain any characters that are considered special by the configuration file system, such as ":" or "#"; the string should be at least 8 characters long, but longer strings are better. The RANDOM_SEED may not be retrieved online.

DEFAULT_LIST_PARAM

The LIST command takes a single optional argument. If given, that argument is either a channel or a filter. If that argument is not given, then by default, /LIST will list all channels on the network. Needless to say, this can generate a large amount of data on large networks with many channels, as well as chewing up a lot of CPU time. Therefore, you may set a default filter to be applied to the channel list if the optional argument to LIST is omitted.

NICKNAMEHISTORYLENGTH

This value specifies the length of the nick name history list, which is used for /WHOWAS and some nickname chasing in /KILL and /KICK. It uses about 300 to 400 bytes per entry. Note that at a net break, so many clients disappear that the whole "whowas" list is refreshed a few times (unless you make it rather large). A reasonable value is "total number of clients" / 25.

HOST_HIDING

This selects whether local users can set umode +x, thus allowing them to hide their hostname if they have also registered and authenticated with N (i.e. they have the ACCOUNT flag set).

OPERHOST_HIDING

When TRUE any oper setting +x will get the hidden host set via HIDDEN_OPERHOST instead of the host set in HIDDEN_HOST.

HOST_HIDING_STYLE

Value 1 will use ircu-style hostmasking. Value 2 uses Ultimate IRCd style hostmangling, such as a43sd.a3523f.isp.tld.

HIDDEN_HOST

This selects the suffix for the hidden hostmask (see HOST_HIDING).

HOST_HIDING_PREFIX

This selects the suffix for the hidden hostmask style 2.

HIDDEN_OPERHOST

This selects the suffix for the hidden hostmask for IRC Operators (see OPERHOST_HIDING).

HIDDEN_IP

This selects a fake IP to be shown on /USERIP and /WHO %i when the target has a hidden host (see HOST_HIDING).

CONNEXIT_NOTICES

This feature controls the generation of server notices when a user connects to or disconnects from the server. Enabling this feature may have a performance impact. If using this feature make sure you take a look at SNOMASKs.

EXTENDED_ACCOUNTS

This enables 'extended' style AC syntax (used by your service to set the account name.) TRUE uses the subcommand parameter R,M,U,C,A,D to do LOC, rename and removal. FALSE uses old style. Set this to TRUE if you're linking to DareNET / using services-darenet, FALSE for other services.

LOGIN_ON_CONNECT

This selects whether local clients can specify a service bot login in the connection phase. Read doc/readme.login-on-connect for details.

DNSBL_LOC_EXEMPT

This allows a user who has successfully authed to a service using login on connect (above) to bypass a DNSBL rejection if they get a positive result from the earlier check.

DNSBL_LOC_EXEMPT_N_ONE

If DNSBL_LOC_EXEMPT is enabled and a user matches a dnsbl then they will be sent a notice containing the string for this feature.

DNSBL_LOC_EXEMPT_N_TWO

If DNSBL_LOC_EXEMPT is enabled and a user matches a dnsbl then they will be sent a notice containing the string for this feature.

DNSBL_WALLOPS_ONLY

If enabled DNSBL filter matches will be alerted to opers via wallops.

DNSBL_MARK_FAKEHOST

If enabled then users who match DNSBL's will be marked.

LOC_DEFAULT_SERVICE

This is what nick on IRC the login-on-connect account verification is sent to. Users can override it (to any service that supports it) using 3 param LOC.

DEFAULT_UMODE

This defines the user modes set when a local user connects. +x should not be included in this setting if using host hiding style 1, since users cannot later remove that flag.

KILLCHASETIMELIMIT

If a user changes his or her nickname just before an operator issues a /KILL, the /KILL will be changed to follow the user the operator intended to get. This option specifies the time limit, in seconds, for this nickname change; if the user changed his or her nickname more than this many seconds ago, the /KILL will not be changed. Don't change this unless you really need to.

MAXCHANNELSPERUSER

This is the maximum number of channels a user can be in at a time. The "mandatory" value on DareNET is currently 10. Since it only influences the local server when you decrease it, its up to you to decide if you want to use a smaller value. Do not use a larger value however, because it DOES cost more memory and bandwidth on all other servers when you allow users to join more channels simultaneously.

One of the most important reasons to choose a smaller value is the fact that the "GUI" clients tend to stay on every channel they join (they aren't bothered by flooding in other channels). It DOES take your bandwidth however to send all those messages for 10 different channels to all your users.