1 Many of the old compile-time options are now configured through the
2 server configuration file, ircd.conf. This file is intended to
3 document each of these features. Logging, although also configured
4 through the use of F-lines, is documented in doc/readme.log.
8 * Default: picked by ./configure from /etc/resolv.conf
10 This option allows you to specify what you consider to be "local." It
11 is only used for statistics. When you issue the IRC command /STATS w,
12 the server will respond with statistics of how many clients have been
13 connecting to your server in the last minute, hour and day. It will
14 give these statistics for all connections (including the servers), all
15 clients (from anywhere) and also for clients whose hostname ends on
16 the domain you specify here. So if you are an ISP and you want to
17 know what the client load from your own domain is, specify that domain
18 here. If you are unsure what to do, then it isn't really important
19 what you give here, just don't give an empty string. A good guess is
20 the last two parts of your own hostname (i.e., if your hostname is
21 foo.bar.nowhere.org, specify "nowhere.org"). Note that the string you
22 give should NOT start with a "." and you should not use quotes.
28 You should really ONLY specify "TRUE" here when your system clock is
29 stable and accurate at all times (within a few seconds). If you are
30 running ntpdate on a regular basis, or an equivalent like xntpd, to
31 keep your system clock synchronized over the network, then you might
32 have an accurate clock. However, this is not guaranteed; for example,
33 it is known that xntpd gives unstable results on Linux in some cases.
34 Note that an unstable clock is worse then an clock that has a constant
35 offset, because the servers attempt to correct for a constant offset,
36 but do not correct jumps of your system clock! In general you SHOULD
37 be running ntpdate or equivalent AND make sure it works when you run a
38 production server on Undernet. Otherwise leave your clock alone and
39 specify "FALSE" here. If unsure specify "FALSE"!
45 This specifies the maximum amount of RAM that your server will
46 allocate for buffering sendQs. Small leafs can use a value as little
47 as 1000000, while large HUBs need to specify a value as high as
48 20000000. If you run out of memory, clients and/or servers are
49 dropped with the error "Buffer allocation error"; then you will have
50 to increase this number (and install more RAM if appropriate). If you
51 want a more educated guess for this value then realize that any value
52 is good if you _really_ would rather drop servers and clients than
53 allocate more memory; this will be the case when there is the danger
54 you may run out of memory for other allocations. Even if you run the
55 daemon on a dedicated machine, specifying all of the RAM you have is a
56 bad thing, because running out of memory is a lot worse than dropping
57 clients in a controlled way; if possible you should have memory left
58 for all the internal structures (channels, clients, ban lists, receive
59 buffers) at all times. On average, clients seem to use 150 bytes of
60 sendQ, but at peak moments this can easily increase to 2032 bytes per
61 client (sendQs are allocated in chunks of 2032 bytes). The maximum
62 possible amount that can be allocated for sendQs is the number of
63 connected clients times whatever you specified as the maximum sendQ in
64 your Y: lines in the ircd.conf file. That value will likely be larger
65 then the amount of RAM you have. The educated guess I talked about
66 earlier would be "number of clients" times * 2048 bytes + "size of
67 net.burst" * n, where "n" is 1 for leafs and up to 5 for HUBs. The
68 "size of net.burst" is about 125 bytes per online client (on the whole
69 network). For large HUBs with 4000 clients on a network with 30,000
70 users, this results in 27 Mb. Leafs could use 12 Mb. Of course you
71 can use less when you have less than 4000 local clients. This value
78 If you have a server with a lot of resources available, this option
79 will cause the server to attempt to flush its internal buffers before
80 dropping clients during a net break. Don't define this if you don't
81 know for certain; if you're not careful this can end up rebooting
82 FreeBSD boxes. For more information, refer to freebsd.txt, also in
89 Currently, everything that a client sends to a server is read by the
90 server and stored in a buffer (the clients receive queue). The server
91 will process messages from this queue one by one (running over all
92 clients each time). When a client sends new messages faster they get
93 processed, and the size of its receive buffer reaches this value, the
94 client is dropped with the error "Excess flood." A reasonable value
95 is 1024 bytes. The maximum size is 8000 bytes.
101 When an IRC operator attempts a connect to another server, he or she
102 may not know which port the connect should go to. In this server
103 version, that operator may use the special port 0, in which case the
104 server will take the port from the C-line. If no port is specified in
105 the C-line, however, the port specified by this option will be used
112 Every time a client connects to your server, the full Message of the
113 Day (as specified by the T-lines or by the file specified by the MPATH
114 option) is sent to the client. The server sends the Message of the
115 Day even though many clients permit the user to ignore it. Many users
116 never read the message of the day anyway, making it a huge waste of
117 bandwidth. If you specify "TRUE" here, then the server won't send the
118 MOTD to the client by default; instead, it will only tell the client
119 when the MOTD was last changed, and give instructions on how to obtain
126 When a client connects to your server, the IP address of the client is
127 reverse-resolved to obtain a hostname. Then that hostname is resolved
128 to an IP address and compared with the IP address of the client. If
129 they don't match, the client will appear with the IP address instead
130 of the hostname, unless KILL_IPMISMATCH is "TRUE," in which case the
131 client is simply disconnected.
137 The IRC command WHOIS gives an idle time for clients. If you want
138 this idle time to be set to zero only when the client sends a PRIVMSG,
139 then you should specify "TRUE" here. If you specify "FALSE," then the
140 idle time will be nullified on all messages except the server
147 All servers of an IRC "network" are connected in a "tree" (no loops).
148 Servers that are only connected to one other server (called the
149 "uplink") are called "leafs"; servers that are connected to more than
150 one other server are called HUBs. If you specify "FALSE" here then
151 your server will prevent itself from accidentally connecting to two
152 servers at once, thus keeping servers in poor network locations from
153 routing traffic. Note that on Undernet, all newly linked servers are
154 linked as leafs during their test phase, and should specify "FALSE"
161 Setting this option removes the ability for clients that are not IRC
162 operators to see wallops messages.
168 If you are playing with the server off-line, and no DNS is available,
169 then long delays occur before the server starts up because it tries to
170 resolve the name given on the M-line (which usually isn't given in
171 /etc/hosts) and for each connecting client. If you specify "TRUE"
172 here, then a call to gethostbyname() will be done only for the real
173 hostname, and the server will not try to resolve clients that connect
174 to "localhost." Note that other calls to gethostbyname() are still
175 done if you use VIRTUAL_HOST; also note that the server still tries to
176 resolve clients that connect to the real IP address of the server.
182 When a client connects, the server sends the client a "cookie,"
183 consisting of a random number. The client must return the cookie to
184 the server verbatim. This is done to prevent IP spoofing. The cookie
185 is generated by a pseudorandom number generator included in ircd.
186 This generator must be seeded with a phrase that is kept secret, to
187 ensure that the numbers it generates are not easily guessed. The
188 value given to RANDOM_SEED may be a string of any length. It should
189 not contain any characters that are considered special by the
190 configuration file system, such as ":" or "#"; the string should be at
191 least 8 characters long, but longer strings are better. The
192 RANDOM_SEED may not be retrieved online.
198 The LIST command takes a single optional argument. If given, that
199 argument is either a channel or a filter. If that argument is not
200 given, then by default, /LIST will list all channels on the network.
201 Needless to say, this can generate a large amount of data on large
202 networks with many channels, as well as chewing up a lot of CPU time.
203 Server administrators can therefore set a default filter to be applied
204 to the channel list if the optional argument to LIST is omitted.
206 NICKNAMEHISTORYLENGTH
210 This value specifies the length of the nick name history list, which
211 is used for /WHOWAS and some nickname chasing in /KILL and /KICK. It
212 uses about 300 to 400 bytes per entry. Note that at a net break, so
213 many client disappear that the whole "whowas" list is refreshed a few
214 times (unless you make it rather large). A reasonable value is "total
215 number of clients" / 25.
221 If a user changes his or her nickname just before an operator issues a
222 /KILL, the /KILL will be changed to follow the user the operator
223 intended to get. This option specifies the time limit, in seconds,
224 for this nickname change; if the user changed his or her nickname more
225 than this many seconds ago, the /KILL will not be changed. Don't
226 change this unless you really need to.
232 This is the maximum number of channels a user can be in at a time.
233 The "mandatory" value on Undernet is currently 10. Since it only
234 influences the local server when you decrease it, its up to you to
235 decide if you want to use a smaller value. Do not use a larger value
236 however, because it DOES cost more memory and bandwidth on all other
237 servers when you allow users to join more channels simultaneously.
238 One of the most important reasons to choose a smaller value is the
239 fact that the "GUI" clients tend to stay on every channel they join
240 (they aren't bothered by flooding in other channels). It DOES take
241 your bandwidth however to send all those messages for 10 different
242 channels to all your users.
248 This is the expected average ban mask length. Leave it at 40.
254 This is the maximum number of bans a user may set on a given channel.
260 This is the maximum number of masks a user can silence at a time. The
261 silence command allows users to filter messages directed at them from
262 certain users or domains, at the source server. Increasing this
263 number allows users to use up more memory with inefficient use of the
264 command. If you're not sure, don't change this.
270 Often the net breaks for a short time and it is useful to try to
271 reestablish the same connection faster than CONNECTFREQUENCY would
272 allow, but to keep from trying again on a bad connection, we require
273 that the connection be open for a certain minimum time. The
274 recommended value is 300 seconds.
280 When attempting to quickly reestablish a connection to a good link, we
281 give the net a few seconds to calm down. This time must be long enough
282 for the other end to also notice that the connection is broken. The
283 recommended value is 10 seconds.
289 Number of seconds to wait for a connect(2) call to complete. NOTE:
290 this must be at *LEAST* 10. When a client connects, it has
291 CONNECTTIMEOUT - 10 seconds for its host to respond to an ident lookup
292 query and for a DNS lookup to complete. It is recommended that you not
293 change this value, but if you do, consider the fact that users whose
294 clients do not support NOSPOOF will have to type /QUOTE PING <big
295 number> before registration.
301 This is the maximum idle time for the server. If no messages are
302 received in TIMESEC seconds, PINGFREQUENCY and CONNECTFREQUENCY are
303 checked. Recommended value is 60 seconds.
309 This is the maximum number of links for the built-in client class 0.
310 Leave this value at 1.
316 If the daemon doesn't receive anything from any of its links within
317 PINGFREQUENCY seconds, then the it will attempt to check for an active
318 link with a PING message. If no reply is received within
319 (PINGFREQUENCY * 2) seconds, then the connection will be closed. This
320 value may be overridden by a Y-line in "ircd.conf" if the connection's
321 I- or C-line in "ircd.conf" assigns a specific class to the connection
328 This is the default frequency that the server attempts to reconnect
329 with its uplink server if it is set to auto connect to it. Note that
330 this value is overridden by a Y-line in ircd.conf if the C-lines in
331 ircd.conf assign a specific class to the connection (recommended).
333 DEFAULTMAXSENDQLENGTH
337 This is the default value of the maximum sendQ length of Y-line
338 classes (see doc/example.conf for details on Y-lines). You will
339 probably always override this value in your "ircd.conf" with the
340 Y-lines. The given value used to be an often used value for client
347 G-lines that affect too many users have to be set with a special
348 command, to prevent accidental G-lines of large blocks of users. This
349 feature sets that particular threshold.
353 * Default: "ircd.motd"
355 MPATH is the filename (relative to DPATH) or the full path of the
356 "Message of the Day" file. The contents of this file will be sent to
357 every client that connects to the server, after registration.
361 * Default: "remote.motd"
363 RPATH is the filename (relative to DPATH) or the full path of the
364 "Remote Message of the Day" file. The contents of this file will be
365 sent to every remote client that issues a /MOTD <your server name>.
366 Only the first three lines are sent, so you might want to keep that in
367 mind while writing the file.
371 * Default: "ircd.pid"
373 PPATH is the filename (relative to DPATH) or the full path of the
374 "PID" file. It is used for storing the server's process ID so that a
375 ps(1) isn't necessary.
381 This option is only needed when you wish to run multiple IRC servers
382 on the same machine, and they must share at least one port. This will
383 require having multiple IP addresses for the machine that will be
384 hosting the servers. If you specify "TRUE" here, you can cause the
385 server to bind to one of these IP addresses. Use the second field of
386 the M-line (the "password" field) to specify the IP address. If you
387 are unsure, stick with "FALSE."
393 This option is used to specify the type of service that will be
394 requested for connections to other servers. The value may be given as
395 a hexadecimal integer.
401 This option is used to specify the type of service that will be
402 requested for connections to users. The value may be given as a
409 In order to allow certain users to become IRC operators, they must
410 authenticate themselves with a password. This password is matched
411 against an O-line in the "ircd.conf" configuration file; see
412 doc/example.conf for more details. If you specify "TRUE" here, you
413 must use the crypted form of these passwords in your "ircd.conf" file.
414 Since compromises of the "ircd.conf" file have happened in the past,
415 you are highly encouraged to use this option. You can find a program
416 called "mkpasswd" in the tools directory that will allow you to
417 generate crypted passwords.
423 If this option is set to "TRUE," IRC operators may join as many
424 channels as they need to. This is primarily intended to permit
425 administrators to run a channel service for local ("&") channels.
431 If this option is set to "TRUE," IRC operators may change the channel
432 modes on local ("&") channels. This is primarily intended to permit
433 administrators to run a channel service for local channels.
435 OPER_WALK_THROUGH_LMODES
439 If this option is set to "TRUE," IRC operators may join local ("&")
440 channels regardless of any restrictive modes, including bans. This
441 requires giving the special password "OVERRIDE." This is primarily
442 intended to permit administrators to run a channel service for local
449 If this option is set to "TRUE," IRC operators may not be deopped on
450 local ("&") channels. This is primarily intended to permit
451 administrators to run a channel service for local channels.
457 If you specify "TRUE" here, then your (local) IRC Operators will be
458 able to see all local invisible users (clients connected to your own
459 server). This should be used only for investigating instances of
460 abuse; make sure your operators do not use this for spying on
463 SHOW_ALL_INVISIBLE_USERS
467 If you specify "TRUE" here, then your global IRC Operators will be
468 able to see ALL invisible users. This should be used only for
469 investigating instances of abuse; make sure your operators do not use
470 this for spying on individuals.
476 A /WHO command can sometimes return several hundred lines of
477 information. To reduce the flood potential, the output is truncated.
478 By setting this option to "TRUE," when an IRC Operator uses /WHO, the
479 output will not be truncated, no matter how much data is returned.
485 If this option is set to "TRUE," operators of this server may only
486 KILL clients directly connected to this server. Operators will not be
487 able to issue KILLs for clients on other servers. Some networks may
488 require that this be turned on for newly linking servers.
494 For u2.10.11, several new oper-only features have been added that
495 involve changes to the server<->server protocol. Until the entire
496 network is running the new version, these features cannot be enabled.
497 This configuration option provides a single switch to prevent the use
498 of these features until the entire network has been upgraded. It is
499 not required that all servers set this to "TRUE" in order for the
506 This selects whether global IRC operators on this server are permitted
507 to issue the /KILL command.
513 This selects whether global IRC operators on this server are permitted
514 to issue the /REHASH command.
520 This selects whether global IRC operators on this server are permitted
521 to issue the /RESTART command.
527 This selects whether global IRC operators on this server are permitted
528 to issue the /DIE command.
534 This selects whether global IRC operators on this server are permitted
535 to issue global G-lines.
541 This selects whether global IRC operators on this server are permitted
542 to issue local G-lines.
548 This selects whether global IRC operators on this server are permitted
549 to issue global jupes.
555 This selects whether global IRC operators on this server are permitted
556 to issue local jupes.
562 This selects whether global IRC operators on this server are permitted
563 to use /OPMODE and /CLEARMODE on ordinary ("#") channels.
569 This selects whether global IRC operators on this server are permitted
570 to use /OPMODE and /CLEARMODE on local ("&") channels.
576 This selects whether global IRC operators on this server are permitted
577 to issue global BADCHANs. USE OF THIS ON THE UNDERNET IS STRICTLY
578 REGULATED BY THE UNDERNET ADMINISTRATION.
584 This selects whether global IRC operators on this server are permitted
585 to issue local BADCHANs. USE OF THIS ON THE UNDERNET IS STRICTLY
586 REGULATED BY THE UNDERNET ADMINISTRATION.
592 This selects whether global IRC operators on this server are permitted
593 to use the /SET command to set various feature values.
595 OPERS_SEE_IN_SECRET_CHANNELS
599 If you specify "TRUE" here, then your global IRC Operators will be
600 able to see who is on a specified secret channel, without joining
601 themselves. This can be used to make a reasonable judgment in the
602 case of a "channel takeover" being reported, while the channel is set
603 invite-only. See doc/readme.who for more details.
609 This selects whether global IRC operators on this server are permitted
610 to use the /GLINE command with the ! flag to force slightly wide
617 This selects whether local IRC operators are permitted to use the
618 /KILL command on local clients.
624 This selects whether local IRC operators are permitted to use the
631 This selects whether local IRC operators are permitted to use the
638 This selects whether local IRC operators are permitted to use the /DIE
645 This selects whether local IRC operators are permitted to issue local
652 This selects whether local IRC operators are permitted to issue local
659 This selects whether local IRC operators are permitted to use /OPMODE
660 and /CLEARMODE on local ("&") channels.
666 This selects whether local IRC operators are permitted to issue local
667 BADCHANs. USE OF THIS ON THE UNDERNET IS STRICTLY REGULATED BY THE
668 UNDERNET ADMINISTRATION.
674 This selects whether local IRC operators are permitted to use the /SET
675 command to set various feature values.
677 LOCOP_SEE_IN_SECRET_CHANNELS
681 If you specify "TRUE" here, then your local IRC Operators will be
682 able to see who is on a specified secret channel, without joining
683 themselves. This can be used to make a reasonable judgment in the
684 case of a "channel takeover" being reported, while the channel is set
685 invite-only. See doc/readme.who for more details.
691 This selects whether local IRC operators are permitted to use the
692 /GLINE command with the ! flag to force slightly wide G-lines to be
projects / ircu2.10.12-pk.git / blob